• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

Moving towards OTC

What should we do


  • Total voters
    57
  • Poll closed .
Status
Not open for further replies.
As ive said before, yes :p
Just wanna wrap up a couple of the things I got going right now - one being the new frame groups.
And since no on else uploads things im not gonna rush :p

Once I find a way to increase performance I will make a pull request, but who knows how long that will take.

I did start using xperf to stackwalk the otclient and try to find out what is taking up the most CPU usage, but it might just be the GPU that is slowing it down.

-- Double Post Merged --

Been trying to find applications that would help find out exactly what is wrong, currently using GPU PerfStudio.

Just a fun little image I'd like to share:
nmtxQd3.png


So OTClient takes up 0.73ms CPU per a busy frame. But 22.27 ms GPU on the same busy frame.

My CPU could run it at 1374 fps, but my graphics card lowers it to 44.9 fps.
Now, I do know nothing on how to fix this, but at least I know it is the GPU causing the FPS to be so low.

(BTW you can see my graphics card above, which is capable of playing generally any game with high graphics)
I literally get better FPS on Crysis than I do on OTClient.
 
Last edited by a moderator:
I found weird situation related to fps drop. When i open 2 mc and login temple ab'dendriel the fps drops to 20~ and after some seconds it goes back to normal 70~ fps.
It's something with light or alot of animations like water?
 
I found weird situation related to fps drop. When i open 2 mc and login temple ab'dendriel the fps drops to 20~ and after some seconds it goes back to normal 70~ fps.
It's something with light or alot of animations like water?

I do find that Animations do slow it down. Which is strange, because whether an item is Animated or not, it is the same amount of "Draw calls".

This means, the way the otclient pulls animated items/tiles/characters is bad, when it first locates the item, it should cache the entire animation for easy access because it knows it is going to have to play the whole thing.

Now for lights, The reason lighting causes so many issues is, a lot of tiles have lighting on it (lava, swamp I think, underwater tiles, etc) so when using these tiles, you are literally doubling the amount of draw-calls, then not only that, underwater/lava/swamp tiles usually have a lot of animated tiles that go along with it, so it causes even more fps drops.

--For your issue of it going down to 20 fps, then back up to 70. Maybe once it finished all the animations it had them cached for quick access. But it may have needed to play through all the animations before it could go quickly.
 
I do find that Animations do slow it down. Which is strange, because whether an item is Animated or not, it is the same amount of "Draw calls".

This means, the way the otclient pulls animated items/tiles/characters is bad, when it first locates the item, it should cache the entire animation for easy access because it knows it is going to have to play the whole thing.

Now for lights, The reason lighting causes so many issues is, a lot of tiles have lighting on it (lava, swamp I think, underwater tiles, etc) so when using these tiles, you are literally doubling the amount of draw-calls, then not only that, underwater/lava/swamp tiles usually have a lot of animated tiles that go along with it, so it causes even more fps drops.

--For your issue of it going down to 20 fps, then back up to 70. Maybe once it finished all the animations it had them cached for quick access. But it may have needed to play through all the animations before it could go quickly.
Nice research! Then what is slowing down OTC is the process of getting the same thing all the time?
 
Nice research! Then what is slowing down OTC is the process of getting the same thing all the time?

I just did some more testing, The difference between having a screen full of items that do not animate, and a screen full of animating items, is only 10%-15% fps drop.

But the difference between a screen full of monsters, vs a screen full of items that do not animate, is about a 80%-90% fps drop.
And that is true even if you make the monsters look like an item. (Doesn't matter what outfit you use, still huge fps drop when drawing creatures)


I created the ability to create slow-moving animations a while back, so I used this to test how many sprites can be drawn before my fps goes below 50.

Here is a lot of my testing.
 
nice to see yall are still working on this
 
I just did some more testing, The difference between having a screen full of items that do not animate, and a screen full of animating items, is only 10%-15% fps drop.

But the difference between a screen full of monsters, vs a screen full of items that do not animate, is about a 80%-90% fps drop.
And that is true even if you make the monsters look like an item. (Doesn't matter what outfit you use, still huge fps drop when drawing creatures)


I created the ability to create slow-moving animations a while back, so I used this to test how many sprites can be drawn before my fps goes below 50.

Here is a lot of my testing.
Keep in mind that now you have a viewport of 17x17, 400 tiles to be rendered and also 289 creatures on the screen. By default we have 252 tiles, that use about 35% less resources.
 
Keep in mind that now you have a viewport of 17x17, 400 tiles to be rendered and also 289 creatures on the screen. By default we have 252 tiles, that use about 35% less resources.

That is true, but I see no reason why drawing an item, and drawing a creature, should have a 70-80% fps difference. (even once removing names and health bars).

It is still drawing one sprite.

The comparisons I made in the video, were to show the difference between different things.

Large Lighting Effects have a much bigger cost than small lighting effects. (The amount of lights actually isn't the main issue, its the amount of pixels effected by light)
 
That is true, but I see no reason why drawing an item, and drawing a creature, should have a 70-80% fps difference. (even once removing names and health bars).

It is still drawing one sprite.

The comparisons I made in the video, were to show the difference between different things.

Large Lighting Effects have a much bigger cost than small lighting effects. (The amount of lights actually isn't the main issue, its the amount of pixels effected by light)
Visible creatures is cached as you can see here:
https://github.com/edubart/otclient/blob/master/src/client/mapview.h#L160
Also you are playing a idle animated creature too ( that item have light source? ).
Items is also rendered in a very cheap process while creature not.
Maybe i can be wrong, but this is what i think for now.
 
i noticed that having lot of creatures on screen weren't the problem.
Problem seemed to be walking "under" the creature
 
5:35
fps dropped before walking under the creatures

Walking under the creatures is not the problem.

I also noticed something VERY strange, if you set Interface Max FPS to Max, I get an FPS Boost.

I checked out why, and it is because it stops Caching the foreground, and just re-draws it every frame.
Why would you get an FPS boost if you DON'T Cache the foreground? I thought caching would increase FPS, not decrease.

-- Double Post Merged --

Visible creatures is cached as you can see here:
https://github.com/edubart/otclient/blob/master/src/client/mapview.h#L160
Also you are playing a idle animated creature too ( that item have light source? ).
Items is also rendered in a very cheap process while creature not.
Maybe i can be wrong, but this is what i think for now.

And if this is true ^^

That it Caches creatures, then maybe the reasons creatures are so expensive is BECAUSE they are cached?
(This is coming from Trial and Error, I have no knowledge of graphics programming, etc)

**EDIT**
Nevermind, after looking into creatures and how they are cached, it is just caching the EXISTENCE of creatures, it isn't caching their texture/rendering/artwork/sprite/whatever you call it.

But for the foreground, it literally grabs your entire foreground, and creates a new texture from it.
So next time instead of drawing each individual piece, it just draws the pre-rendered foreground each frame. (still not sure why this would lower FPS)

**2nd Edit**
Actually, it appears simply the FPS Counter may be broken when you set Interface framerate limit to max.
Vertical Synch sets my FPS to 60 when checked, but I get 120 if I set my Interface Framerate Limit to max.

This OTClient is destroying my brain.
 
Last edited by a moderator:
And if this is true ^^

That it Caches creatures, then maybe the reasons creatures are so expensive is BECAUSE they are cached?
(This is coming from Trial and Error, I have no knowledge of graphics programming, etc)

**EDIT**
Nevermind, after looking into creatures and how they are cached, it is just caching the EXISTENCE of creatures, it isn't caching their texture/rendering/artwork/sprite/whatever you call it.

But for the foreground, it literally grabs your entire foreground, and creates a new texture from it.
So next time instead of drawing each individual piece, it just draws the pre-rendered foreground each frame. (still not sure why this would lower FPS)

**2nd Edit**
Actually, it appears simply the FPS Counter may be broken when you set Interface framerate limit to max.
Vertical Synch sets my FPS to 60 when checked, but I get 120 if I set my Interface Framerate Limit to max.

This OTClient is destroying my brain.
It's not better trying something and see if that new code can boost FPS? Solution come from the trial and error, if you get a better result from it, should be good no?
 
It's not better trying something and see if that new code can boost FPS? Solution come from the trial and error, if you get a better result from it, should be good no?

I am doing trial and error. What I am saying is that the FPS Counter was misleading. It was saying I gained FPS, but I did not.
 
Is it possible that if player removes it discards all the cached information and starts again instead of moving the information x/y times to correct side.

EDIT:
This part confuses me. How can be there 3 voids with same name but all do different things. don't the last one only work?

Code:
void FrameBuffer::draw()
{
    Rect rect(0,0, getSize());
    g_painter->drawTexturedRect(rect, m_texture, rect);
}

void FrameBuffer::draw(const Rect& dest, const Rect& src)
{
    g_painter->drawTexturedRect(dest, m_texture, src);
}

void FrameBuffer::draw(const Rect& dest)
{
    g_painter->drawTexturedRect(dest, m_texture, Rect(0,0, getSize()));
}
 
Last edited:
Is it possible that if player removes it discards all the cached information and starts again instead of moving the information x/y times to correct side.

EDIT:
This part confuses me. How can be there 3 voids with same name but all do different things. don't the last one only work?

Code:
void FrameBuffer::draw()
{
    Rect rect(0,0, getSize());
    g_painter->drawTexturedRect(rect, m_texture, rect);
}

void FrameBuffer::draw(const Rect& dest, const Rect& src)
{
    g_painter->drawTexturedRect(dest, m_texture, src);
}

void FrameBuffer::draw(const Rect& dest)
{
    g_painter->drawTexturedRect(dest, m_texture, Rect(0,0, getSize()));
}

These 3 functions are used in 3 different situations.
They could have named them:

Code:
void FrameBuffer::drawDefaultFrameBuffer()
{
    Rect rect(0,0, getSize());
    g_painter->drawTexturedRect(rect, m_texture, rect);
}

void FrameBuffer::drawRectOnSourceFrameBuffer(const Rect& dest, const Rect& src)
{
    g_painter->drawTexturedRect(dest, m_texture, src);
}

void FrameBuffer::drawRectOnNewFrameBuffer(const Rect& dest)
{
    g_painter->drawTexturedRect(dest, m_texture, Rect(0,0, getSize()));
}
Outside of LUA, using 3 functions named the same thing does not cause issues. You simply use the correct variables when entering the function, and the code will pull the function that requires those variables

And I don't think they are related to drawing anything that a player actually sees.
I think these are for drawing the buffer between frames. (Each frame, the client draws a black square to erase the last frame I think)
 
Last edited:
These 3 functions are used in 3 different situations.
They could have named them:

Code:
void FrameBuffer::drawDefaultFrameBuffer()
{
    Rect rect(0,0, getSize());
    g_painter->drawTexturedRect(rect, m_texture, rect);
}

void FrameBuffer::drawRectOnSourceFrameBuffer(const Rect& dest, const Rect& src)
{
    g_painter->drawTexturedRect(dest, m_texture, src);
}

void FrameBuffer::drawRectOnNewFrameBuffer(const Rect& dest)
{
    g_painter->drawTexturedRect(dest, m_texture, Rect(0,0, getSize()));
}
Outside of LUA, using 3 functions named the same thing does not cause issues. You simply use the correct variables when entering the function, and the code will pull the function that requires those variables

And I don't think they are related to drawing anything that a player actually sees.
I think these are for drawing the buffer between frames. (Each frame, the client draws a black square to erase the last frame I think)
ah i see. Mkey, yeah these are for making the framework where pictures are going to be drawn, used similar idea when I coded the core for my Java game.

Btw had a typo last post xD

I mean if player moves. I think it discards all the cache and starts all over again.
but instead it should just draw 7 new positions and relocate the pictures compared with the position change.
Also what might be problem is the pixel rendering when moving. Hopefully its not recreating the picture 16 times per tile xD
 
ah i see. Mkey, yeah these are for making the framework where pictures are going to be drawn, used similar idea when I coded the core for my Java game.

Btw had a typo last post xD

I mean if player moves. I think it discards all the cache and starts all over again.
but instead it should just draw 7 new positions and relocate the pictures compared with the position change.
Also what might be problem is the pixel rendering when moving. Hopefully its not recreating the picture 16 times per tile xD
Yes, it's redrawing all the scene again, but tiles are cached. I think this is used in Map Editor framework.
Actually it's impossible to be done, but maybe we can achieve a better way of rendering, like others 2D engine or just optimize the OTC way and hope for better results.
 
Last edited:
Yes, it's redrawing all the scene again, but tiles are cached. I think this is used in Map Editor framework.
Actually it's impossible to be done, but maybe we can achieve a better way of rendering, like others 2D engine or just optimize the OTC way and hope for better results.

What bothers me is, on my video, I filled a screen up with items and still had 300 fps.
(I also filled a screen up with animated items, but it wasn't on the video, I lost about 20-30fps with animated items instead of non-animated items)

But when I filled the screen up with creatures, even after removing names, and health bars, I still saw a drop in 150-250 fps.
And these creatures had the outfit OF an item.

I will do a test later, where I fill one screen with items, and another screen with creatures that look like the same exact item.

If it is drawing the same sprite, shouldn't it have the same FPS?
It shouldn't matter if it is a creature or not.

**EDIT**
@Sportacus found a interesting video on youtube that I studied a bit last weekend.

Tibia apparently let people do a benchmark for their client, and it looks like tiles are drawn differently than we do on the Otclient.


If you watch the video. When teleporting to new areas, the tiles are NOT drawn in any order.
Instead, it looks like they instead loop through sprites, and check the tiles for matches.

OTClient currently draws like this: (just an simplified example)
Code:
for x = Left, Right do
  for y = Top, Bottom do
    for z = 0, 15 do
      for stackpos = 0, 255 do
       local item = getItem(x, y, z, stackpos)
       local texture = getTexture(item)
       draw(texture)
      end
     end
  end
end
But the video looks more like they are doing something like.
Code:
local texture = getTexture(0)
local loaded = true
for searchItem = 0, LAST_ITEM do
loaded = false
for x = Left, Right do
  for y = Top, Bottom do
  for z = 0, 15 do
    for stackpos = 0, 255 do
      local item = getItem(x, y, z, stackpos)
        if item == searchItem then
         if loaded = false then
          texture = getTexture(item)
          loaded = true
         end
         drawTexture(texture)
        end
      end
    end
end
The difference would be:
  1. Currently we check each tile once, but load each texture multiple times.
  2. The way it seems the video does it, is it loads each texture once, but loops through the tiles multiple times.
Does loading a texture really cost that much GPU? Would it be a large FPS boost to load a texture once, then draw it multiple times? Even if we have to loop through every tile multiple times?

I have no idea, I might actually test it out myself. It also looks like they have a way to draw a tile BEHIND objects, or at least tell the texture to skip pixels that have other pixels on top of it. (It draws trees first, then the ground under it afterwards, in some instances)
 
Last edited:
What bothers me is, on my video, I filled a screen up with items and still had 300 fps.
(I also filled a screen up with animated items, but it wasn't on the video, I lost about 20-30fps with animated items instead of non-animated items)

But when I filled the screen up with creatures, even after removing names, and health bars, I still saw a drop in 150-250 fps.
And these creatures had the outfit OF an item.

I will do a test later, where I fill one screen with items, and another screen with creatures that look like the same exact item.

If it is drawing the same sprite, shouldn't it have the same FPS?
It shouldn't matter if it is a creature or not.
It's a process cost not sprite, creature item mimic is only putting a item frame instead outfit to be rendered.
Creatures is by far more complex than items is and that is why you get a lot more of resources to be used when you have a lot of that in screen.
I don't know if the code is inefficient and surely it can be improved, but it's unlikely to have so much creatures to be drawn then it's not so bad.

edit:
@Flatlander I don't know too, but it should be better than loading every time, right?
Can you try caching creatures ( outfit ) texture and see if something changes? You can check if we have that creature cached, if yes then load the texture from cache instead getting a new one.
 
Last edited:
Status
Not open for further replies.
Back
Top