OTClient Graphics Discussion (Anyone out there more knowledgeable than me?)

[whitevo]

it would be the extra network usage of literally streaming all the textures to the client.

that's the point. you don't stream the texture. You just say to client what is the pixel color. It will have no idea what kind of tile object its coloring.
Client should be program what displays the state of game for each individual player. You literally loose player/client sided lag if the client purpose is kept minimal.

 

[Marcelo Druida]

that's the point. you don't stream the texture. You just say to client what is the pixel color. It will have no idea what kind of tile object its coloring.
Client should be program what displays the state of game for each individual player. You literally loose player/client sided lag if the client purpose is kept minimal.

if life were simple like the simplicity you think that these things works, I would already be rich

there is no problem in how OTC works but how it was coded

 

[whitevo]

if life were simple like the simplicity you think that these things works, I would already be rich

If it's not yet simple then it should have been made so simple in first place.

 

[Marcelo Druida]

If it's not yet simple then it should have been made so simple in first place.

we just need a stronger algorithm to make things work properly

 

[Yamaken]

The issue with your idea isn't the extra ram usage of TFS, it would be the extra network usage of literally streaming all the textures to the client. (we should keep network usage as low as possible, so you can have as many players as possible)

Also, I agree with your multithread issue. Drawing would be much faster, and the client would be much smoother if it was multithreaded.
The client just needs to be fixed. If CIP's tibia client can do it, so can the OTClient.

if life were simple like the simplicity you think that these things works, I would already be rich

there is no problem in how OTC works but how it was coded

We don't need multithreading,we need a smart way of rendering the game window/map view.

 

[Sportacus]

For what it is worth, on the new tibia beta client I only get 30 fps..

 

[Marcelo Druida]

For what it is worth, on the new tibia beta client I only get 30 fps..

if you dont notice any fps drop its fairly enough

 

[Yamaken]

For what it is worth, on the new tibia beta client I only get 30 fps..

How much it differs from Old C++ Client from cipsoft? OpenGL and DirectX.

@topic

A general problem in OTClient drawing code is it does too much texture binds/too much opengl calls.
Each time it draw a object(ground, item, outfit, effect, project tile, etc) it will take the object texture, do a texture bind and then it will draw it to the back buffer. Texture binds are expensive, if there is a lot of objects inside a Tile/Sqm there will be one texture bind per object draw.
I have done a small code to prevent texture bind to test how much textures binds was costing in terms of FPS. I have test it with a tibia scene which all the Tiles use the same ground and have the same items. Which means the Client will only use two textures: one for the ground and another for the item.
The code just draw all the grounds first then it will draw all the items. It means it will bind the ground texture ONE time and then do all the drawing. The same for the item.
The code:

            //draw grounds first
            while(it != end) {
                const TilePtr& tile = *it;
                Position tilePos = tile->getPosition();
                if(tilePos.z != z)
                    break;
                else
                    ++it;

                if (g_map.isCovered(tilePos, m_cachedFirstVisibleFloor))
                    tile->draw(transformPositionTo2D(tilePos, cameraPosition), scaleFactor, Otc::DrawGround);
                else
                    tile->draw(transformPositionTo2D(tilePos, cameraPosition), scaleFactor, Otc::DrawGround, m_lightView.get());
            }

            it = m_cachedVisibleTiles.begin();
            //draw the rest
            while (it != end) {
                const TilePtr& tile = *it;
                Position tilePos = tile->getPosition();
                if (tilePos.z != z)
                    break;
                else
                    ++it;

                if (g_map.isCovered(tilePos, m_cachedFirstVisibleFloor))
                    tile->draw(transformPositionTo2D(tilePos, cameraPosition), scaleFactor, drawFlags);
                else
                    tile->draw(transformPositionTo2D(tilePos, cameraPosition), scaleFactor, drawFlags, m_lightView.get());
            }

            if(drawFlags & Otc::DrawMissiles) {
                for(const MissilePtr& missile : g_map.getFloorMissiles(z)) {
                    missile->draw(transformPositionTo2D(missile->getPosition(), cameraPosition), scaleFactor, drawFlags & Otc::DrawAnimations, m_lightView.get());
                }
            }
        }

the results:

Without the code:

With the code:

+- 150 FPS gain.

 

[Nothxbye]

I see some problems with drawing when you go highter floors, after this fix

 

[Yamaken]

I see some problems with drawing when you go highter floors, after this fix

Its not a fix, it was a code to get proof that texture binds are making OTClient slower/less fps.

 

[Flatlander]

Its not a fix, it was a code to get proof that texture binds are making OTClient slower/less fps.

I wonder how many items are repeated on a screen though.

Real tibia doesn't have all ground tiles the same, and all items the same on screen. A better test would be have 4 different ground tiles, and 20 different items, would generally be a typical tibia screen. (sometimes more, sometimes less)

 

[Marcelo Druida]

A better test would be have 4 different ground tiles, and 20 different items, would generally be a typical tibia screen. (sometimes more, sometimes less)

LOL if we get a fps decrease in the scene you are proposing then we got the solution
you did not understood the issue.

 

[Flatlander]

LOL if we get a fps decrease in the scene you are proposing then we got the solution
you did not understood the issue.

I did understand the situation.

The Hypothesis is that the otclient makes too many texture bind switches. It basically has to switch texture binds each time it draws a new item. The test was to have it draw an entire screen of 1 ground tile and 1 armor item with it only texture-bind switching twice (once for ground, and once for armor).

But, if it still needs to bind a texture each time it draws a different item, then in a real-world situation where there are 20 different ground tile sprites and 60 different item sprites and 5 different character sprites, it will have to switch texture binds 85 times.

**Edit** Now, 85 might be better than what it does now, which is texture bind a minimum of 192 times (probably normally around 300 times).

But pretending that we can realistically go from 300 texture binds down to 2, is insane. Most likely we will reduce texture binds by 50%-70%, not 99%.

So lets say, going from 300 to 2 gives you a 50 fps bonus when you normally have 500 fps, so you go from 500 to 550. In a normal situation that would increase your 500 fps to like 520.

The otclient needs a change that would increase the fps from 500fps to 1500fps. (I use such high fps because I do all my testing on my computer which generally gets 1300+ fps when maxed out and just ground tiles, and around 300-500 fps when there are items all over the screen.

 

[Marcelo Druida]

ok, whatever you want.

The most promising modification would upgrade OTC's ogl to version 3 to be able to use Texture Arrays so we can bind multiples textures.

We could also build a atlas so we can bind a single texture containing multiples sprites.

 

[Yamaken]

I did understand the situation.

The Hypothesis is that the otclient makes too many texture bind switches. It basically has to switch texture binds each time it draws a new item. The test was to have it draw an entire screen of 1 ground tile and 1 armor item with it only texture-bind switching twice (once for ground, and once for armor).

But, if it still needs to bind a texture each time it draws a different item, then in a real-world situation where there are 20 different ground tile sprites and 60 different item sprites and 5 different character sprites, it will have to switch texture binds 85 times.

**Edit** Now, 85 might be better than what it does now, which is texture bind a minimum of 192 times (probably normally around 300 times).

But pretending that we can realistically go from 300 texture binds down to 2, is insane. Most likely we will reduce texture binds by 50%-70%, not 99%.

So lets say, going from 300 to 2 gives you a 50 fps bonus when you normally have 500 fps, so you go from 500 to 550. In a normal situation that would increase your 500 fps to like 520.

The otclient needs a change that would increase the fps from 500fps to 1500fps. (I use such high fps because I do all my testing on my computer which generally gets 1300+ fps when maxed out and just ground tiles, and around 300-500 fps when there are items all over the screen.

I think you are being a bit delusional. With this test i have got 150 fps improvement, so going from 300 texture binds to 2 will not give 50 fps bonus, it will give even more(which is good for us).
We need to keep studying and we should try to get the best performance we can, but there is limits. Its not a about "The otclient needs a change that would increase the fps from 500fps to 1500fps." Maybe its not even possible to get that performance. Rendering a scene where tiles got multiples objects will always be more cost than rendering a simple scene with just ground sprites/textures. What we can do is improve our sprite batching, our rendering method to get the best we can from the gpu/cpu. The goal is too improve fps count so on low end computers players can get a bit more fps making their gameplay better. Our aim is not to make otclient to run on any shit 2005~ computer. Of course we would dream of a client that would run good in any computer but i don't believe its possible. Lets improve what we got with the possibilities we have.

 

[Flatlander]

I think you are being a bit delusional. With this test i have got 150 fps improvement, so going from 300 texture binds to 2 will not give 50 fps bonus, it will give even more(which is good for us).
We need to keep studying and we should try to get the best performance we can, but there is limits. Its not a about "The otclient needs a change that would increase the fps from 500fps to 1500fps." Maybe its not even possible to get that performance. Rendering a scene where tiles got multiples objects will always be more cost than rendering a simple scene with just ground sprites/textures. What we can do is improve our sprite batching, our rendering method to get the best we can from the gpu/cpu. The goal is too improve fps count so on low end computers players can get a bit more fps making their gameplay better. Our aim is not to make otclient to run on any shit 2005~ computer. Of course we would dream of a client that would run good in any computer but i don't believe its possible. Lets improve what we got with the possibilities we have.

I agree, sorry for sounding negative, every change that increases FPS is a good change.

I am still working on the battle-list issue, (Has nothing to do with graphics so it is something I can handle).
Once I have a fix I will post it.

 

[margoh]

I agree, sorry for sounding negative, every change that increases FPS is a good change.

I am still working on the battle-list issue, (Has nothing to do with graphics so it is something I can handle).
Once I have a fix I will post it.

I have checked that module, the fps drops is caused by sorting function and hide function. I made full screen of rats and tried to hide monsters on list. It jumps from 200-240FPS to 350-370FPS. Also when triggering some(all) of those functions it drops to 50-70FPS.

+ Amount of opened modules decreases FPS or moving module through the screen(fast moving module window).

 

[Flatlander]

I have checked that module, the fps drops is caused by sorting function and hide function. I made full screen of rats and tried to hide monsters on list. It jumps from 200-240FPS to 350-370FPS. Also when triggering some(all) of those functions it drops to 50-70FPS.

+ Amount of opened modules decreases FPS or moving module through the screen(fast moving module window).

I figured it was due to sorting.

I don't want to limit the amount of creatures that can appear on the battle list, so my only option is to make the sorting faster and better.

 

[Crazy OtLover]

I didn't read everything but wouldn't it be easier to just load the map to lets say into an array and then render the array as an image but for animations it would stack on top of the image only have the screen redraw when the player moves which would update the screen.

You could still use the grid system for position & collision but loading each tile on to the map seems kind of pointless, although I don't really know how the screen is rendered.

 

[tarjei]

Hello there, I read your comments and I would like to join the brain storm, although I have not evry much experience using openGL. Someone mentioned the Texture arrays which is probably nice thing to look into, although I was wondering to make a proof of concept using texture atlases. I believe we could create only few big textures, store coordinates to sprites (or even calculate them on the fly) and clip the texture to 32x32 size. I guess that would reduce the amount of texture bindings. However I would like to implement that first on my own, if that leads somewhere I will share the code.