4drik
Advanced OT User
- Joined
- Jun 30, 2014
- Messages
- 254
- Reaction score
- 202
Hello OTLand.
OTClient changed the game on OTS.
We have many servers, that thanks to OTClient are unique, interesting, but recently we neglected OTClient.
@MagicWall reminded that OTClient needs us right now, changes are needed. Check the topic.
Everyone agreed. OTClient must be developed. Developed on a larger scale.
However, most of us do not have the time or skills to work on this great project.
Then, in the subject to which the link was given above, @Dual Core proposed to purchase development services for the purpose of developing OTClient.
Since then I have become interested in freelancers and companies.
I come with the initiative.
OTCi will be a client with fixed bugs, optimized, meeting the highest expectations.
In my opinion, I made the best choice. Here I would like to point out that the continuation will be focused on me for a moment.
I'm creating Naruto Story OTS and I use OTClient for a long time. I have modified OTClient and improved it in several aspects.
My changes can be found in Edubart's github pulls but I will quote it for you.
- Battle Fix (fixes attacking monsters after pressing button "Hide monsters")
- We also have to clean up the code, eg: here
- Fix crashes, eg when running a client on MacOS, (for now we can dodge it):
modules/client/client.lua
We know that the client has performance problems, that the FPS are not stable and they can quickly jump down.
The main creator of the project, Edubart, pointed out what should be improved so that the game's performance will increase.
I have provided this information to a company that deals with the optimization of games - Bit Hit Studio.
In response, I received information that they would take care of the project for 1000$ and the project would be ready in two months.
The price seems as affordable as the work you need, but we also anticipate additional, unexpected expenses in the amount of $500.
In total 1500$ is needed of which 300$ has already been paid by us.
I decided that we should not require a deadline but I would like to get an access to the repository on which the company will work.
The company wants to cooperate with me, everything went without a problem. We have paid the money that has started the project.
(If you are interested in who is "we", it will be explained later.)
We are also looking for solutions that are already tested on servers. Solutions, which will improve the quality of the game.
We have contacted a some major OTS project that has significantly improved OTC in order to buy improvments and publish it, however, those who answered criticized the current situation in the world of Open Tibia.
In short term: everyone wants to only get, but not give
We want to change it and we hope that, more developers will join soon.
This project will be expensive. It will cost us time and money.
Therefore, I am doing a money collection.
I will write all those who donate the project there, users:
- @4drik (100$)
- @margoh (100$)
- @Nilan (100$)
To be on a list, you can send donations by Skrill on E-mail adress: [email protected]
When you do this, please send me a private message.
If you want to donate and don't have Skrill account, you can create it here.
If you can not help, it's a pity, but you can count on us.
Remember that in the end all changes and improvments will be available to the entire community.
The project will be under supervision by @4drik (me, Naruto Story OTS author), @Nilan (Dragon Ball Legend OTS author), @margoh and Bit Hit gaming company.
We will do our best to make OTClient even more amazing.
Thank you for so many support in messages.
In this topic I will keep you informed about progress.
Optimization progress:
1. Drawing Less Tiles - FINISHED (written by Adrik, tested by Nilan):
3. Drawing creatures are not the problem
4. Lights doesn't have the best implementation
5. Reduce Texture Binding
OTClient changed the game on OTS.
We have many servers, that thanks to OTClient are unique, interesting, but recently we neglected OTClient.
@MagicWall reminded that OTClient needs us right now, changes are needed. Check the topic.
Everyone agreed. OTClient must be developed. Developed on a larger scale.
However, most of us do not have the time or skills to work on this great project.
Then, in the subject to which the link was given above, @Dual Core proposed to purchase development services for the purpose of developing OTClient.
Since then I have become interested in freelancers and companies.
I come with the initiative.
OTCi will be a client with fixed bugs, optimized, meeting the highest expectations.
In my opinion, I made the best choice. Here I would like to point out that the continuation will be focused on me for a moment.
I'm creating Naruto Story OTS and I use OTClient for a long time. I have modified OTClient and improved it in several aspects.
My changes can be found in Edubart's github pulls but I will quote it for you.
- Battle Fix (fixes attacking monsters after pressing button "Hide monsters")
- We also have to clean up the code, eg: here
- Fix crashes, eg when running a client on MacOS, (for now we can dodge it):
modules/client/client.lua
Lua:
-- If not MacOS, play startup music
if g_app.getOs() ~= "mac" and g_app.getOs() ~= "macos" then
musicChannel:enqueue(musicFilename, 3)
connect(g_game, { onGameStart = function() musicChannel:stop(3) end })
connect(g_game, { onGameEnd = function()
g_sounds.stopAll()
musicChannel:enqueue(musicFilename, 3)
end })
end
We know that the client has performance problems, that the FPS are not stable and they can quickly jump down.
The main creator of the project, Edubart, pointed out what should be improved so that the game's performance will increase.
1. Drawing Less Tiles
The current game map rendering architecture of otclient draws 18*14 = 252 tiles into a framebuffer, however only 15*11 = 165 tiles are visible on screen, so there is a great room for improvement here, 87 extra tiles are being drawn that are not visible, meaning that we could draw ~35% less. But there is a reason for it, 1 row at the top, 2 row at the bottom, 1 column at the left, 2 columns at the right of tiles first are drawn because when you walk you need to see where are you going at, but only when walking you need to see those extra tiles, they are discardable when you are not moving, even more depending on the direction of the walk you need to drawn only a row or a column, nevertheless otclient drawn all these extra rows and columns simple because nobody optimized that yet. Moreover we can't simple discard the bottom/right rows/columns without thinking the 64x64 sprites (trees, creatures 2x2). Therefore an algorithm that could discard those rows/columns of tiles and drawn them only when needed would greatly improve performance.
2. Drawing Even Less Tiles
There is more room for performance improvement, there a function in the map called isCompletelyCovered(), it's basically a function to check if a tile is being completely covered by another tile (meaning that we won't need to draw this covered tile). This function is working in average, however it's not smart enough, there are cases that is simple misses, and it doesn't even take the tiles dimensions into account.
3. Drawing creatures are not the problem
Many here saw that there is a great performance drop when drawing many creatures into the screen, indeed it really happens, however the main cause are not really creatures. The first problem is text drawing for creatures, it needs an algorithm with better caching, everytime a creature moves its name moves too and the engine needs to recalculate all the text glyphs positions, this could be improved by caching the text coords into a vertex array and just translating the vertex array instead of recalculating all again, in fact any moving text in otclient will consume more CPU, the greater the text the more you generally don't notice this because the UI text are static. The second cause is the battle list, which have some algorithms that work poorly when dealing with huge number of creatures. If you hide the creatures name and disable the battle module you will see that the FPS doesn't drop that much with many creatures.
4. Lights doesn't have the best implementation
As some noted the lights are drawn as big bubbles, meaning more lights more bubbles to draw, the bigger the light the bigger the bubble. When you have many lights the FPS will decrease a lot. This was not how I originally intended do implement lights, this algorithm was first introduced by @tarjei who sent me his idea and patch by email, in conjunction with him I adapted the algorithm to otclient, because how cool? We had lights working. However years passed and the algorithm still the same, it works. In a better world the lightning system would use vertex lightning, this would split the final drawn game map framebuffer into squares and each corner of the squares would have a color value associated with the intensity/color of light at the corner, then we would draw the framebuffer in a batch of squares with lightning colors associated with each square. This method would not decrease FPS even with huge amount of lights. Other idea would be to make per pixel lightning, for that using shaders, however would need a recent graphics card.
5. Reduce Texture Binding
As many of you was discussing, this would improved FPS. All sprites are loaded into textures, each time the client draws a sprite on the map it needs to bind the associated texture to that sprite, each binding downgrades the performance. In a perfect world if the whole game map could be drawn without texture bindings switches, even better, in a single batch, there would be a great increase in the FPS. But how to do that? This can be done with a technique called texture atlas, where all current visible and recent sprites are maintained in a few huge textures, thus much less texture switching would be needed, this would need a great refactor in how sprites are handled in otclient.
The current game map rendering architecture of otclient draws 18*14 = 252 tiles into a framebuffer, however only 15*11 = 165 tiles are visible on screen, so there is a great room for improvement here, 87 extra tiles are being drawn that are not visible, meaning that we could draw ~35% less. But there is a reason for it, 1 row at the top, 2 row at the bottom, 1 column at the left, 2 columns at the right of tiles first are drawn because when you walk you need to see where are you going at, but only when walking you need to see those extra tiles, they are discardable when you are not moving, even more depending on the direction of the walk you need to drawn only a row or a column, nevertheless otclient drawn all these extra rows and columns simple because nobody optimized that yet. Moreover we can't simple discard the bottom/right rows/columns without thinking the 64x64 sprites (trees, creatures 2x2). Therefore an algorithm that could discard those rows/columns of tiles and drawn them only when needed would greatly improve performance.
2. Drawing Even Less Tiles
There is more room for performance improvement, there a function in the map called isCompletelyCovered(), it's basically a function to check if a tile is being completely covered by another tile (meaning that we won't need to draw this covered tile). This function is working in average, however it's not smart enough, there are cases that is simple misses, and it doesn't even take the tiles dimensions into account.
3. Drawing creatures are not the problem
Many here saw that there is a great performance drop when drawing many creatures into the screen, indeed it really happens, however the main cause are not really creatures. The first problem is text drawing for creatures, it needs an algorithm with better caching, everytime a creature moves its name moves too and the engine needs to recalculate all the text glyphs positions, this could be improved by caching the text coords into a vertex array and just translating the vertex array instead of recalculating all again, in fact any moving text in otclient will consume more CPU, the greater the text the more you generally don't notice this because the UI text are static. The second cause is the battle list, which have some algorithms that work poorly when dealing with huge number of creatures. If you hide the creatures name and disable the battle module you will see that the FPS doesn't drop that much with many creatures.
4. Lights doesn't have the best implementation
As some noted the lights are drawn as big bubbles, meaning more lights more bubbles to draw, the bigger the light the bigger the bubble. When you have many lights the FPS will decrease a lot. This was not how I originally intended do implement lights, this algorithm was first introduced by @tarjei who sent me his idea and patch by email, in conjunction with him I adapted the algorithm to otclient, because how cool? We had lights working. However years passed and the algorithm still the same, it works. In a better world the lightning system would use vertex lightning, this would split the final drawn game map framebuffer into squares and each corner of the squares would have a color value associated with the intensity/color of light at the corner, then we would draw the framebuffer in a batch of squares with lightning colors associated with each square. This method would not decrease FPS even with huge amount of lights. Other idea would be to make per pixel lightning, for that using shaders, however would need a recent graphics card.
5. Reduce Texture Binding
As many of you was discussing, this would improved FPS. All sprites are loaded into textures, each time the client draws a sprite on the map it needs to bind the associated texture to that sprite, each binding downgrades the performance. In a perfect world if the whole game map could be drawn without texture bindings switches, even better, in a single batch, there would be a great increase in the FPS. But how to do that? This can be done with a technique called texture atlas, where all current visible and recent sprites are maintained in a few huge textures, thus much less texture switching would be needed, this would need a great refactor in how sprites are handled in otclient.
I have provided this information to a company that deals with the optimization of games - Bit Hit Studio.
In response, I received information that they would take care of the project for 1000$ and the project would be ready in two months.
The price seems as affordable as the work you need, but we also anticipate additional, unexpected expenses in the amount of $500.
In total 1500$ is needed of which 300$ has already been paid by us.
I decided that we should not require a deadline but I would like to get an access to the repository on which the company will work.
The company wants to cooperate with me, everything went without a problem. We have paid the money that has started the project.
(If you are interested in who is "we", it will be explained later.)
We are also looking for solutions that are already tested on servers. Solutions, which will improve the quality of the game.
We have contacted a some major OTS project that has significantly improved OTC in order to buy improvments and publish it, however, those who answered criticized the current situation in the world of Open Tibia.
In short term: everyone wants to only get, but not give
We want to change it and we hope that, more developers will join soon.
This project will be expensive. It will cost us time and money.
Therefore, I am doing a money collection.
I will write all those who donate the project there, users:
- @4drik (100$)
- @margoh (100$)
- @Nilan (100$)
To be on a list, you can send donations by Skrill on E-mail adress: [email protected]
When you do this, please send me a private message.
If you want to donate and don't have Skrill account, you can create it here.
If you can not help, it's a pity, but you can count on us.
Remember that in the end all changes and improvments will be available to the entire community.
The project will be under supervision by @4drik (me, Naruto Story OTS author), @Nilan (Dragon Ball Legend OTS author), @margoh and Bit Hit gaming company.
We will do our best to make OTClient even more amazing.
Thank you for so many support in messages.
In this topic I will keep you informed about progress.
Optimization progress:
1. Drawing Less Tiles - FINISHED (written by Adrik, tested by Nilan):
> FPS before: 450
> FPS after: 468
2. Drawing Even Less Tiles3. Drawing creatures are not the problem
4. Lights doesn't have the best implementation
5. Reduce Texture Binding