OTCi - OTClient improvement project


Pro OpenTibia Developer
Premium User
Jul 27, 2013
Reaction score
Hi guys, I am working with two very experienced programmers to help me solve the problem. After three weeks of examining the project, they have determined that all graphic management is a real disaster. It uses prehistoric methods and almost completely obsolete. Use the version of openGL 3.0, which is very old! They tell me that it would be faster to directly change the graphic engine of the game, which is a huge job, of more than a year which entails a very high economic investment. Repair the current graphic engine is patching a code badly worked, very messy and patched. It is patching the patched. In short, otclient is not viable. I hope you understand my bad English.
Did you come from the future?

Buttface Donkey

Godly Donkey
Premium User
Dec 14, 2009
Reaction score
Use the version of openGL 3.0, which is very old!
There is a reason for that
Copy paste from https://www.reddit.com/r/gamedev/comments/1dkjdt "The data says that around 90% of your audience has access to version 2.1 or above, 60% has access to 3.0 or above, and only 20% has access to 4.0 or above. As such, unless you really need tessellation or instancing or something, you should probably target version 2.1."

Although the post is 5 years old, a decent amount of people who play tibia today still use toasters.
With that in mind I wouldn't recommend upgrading the code with anything newer than OpenGL 3.3

Dual Core

New Member
Oct 25, 2018
Reaction score
OpenGL 3.0 uses very primitive functions. If we want to do something right, the worst we can think of is going back in time, technology advances. There are much more powerful and viable engines and above all much easier to manipulate, such as Vulkan or Unity. You could also optimize the current version 3.0, but believe me, that the current Otclient code is a real disaster. Very bad organization and really bad and feasible logics to generate future problems difficult to find and repair.


Intermediate OT User
May 1, 2009
Reaction score
nvm, dont like it
Last edited:


Oct 30, 2007
Reaction score
I would be intrigued by this. I could make a donation myself, however here is the issues I foresee..

1 The files not being shared.
2 You taking the money and running.
3 Is the guys doing the job as good as we have here.
4 Who's to say they don't require a larger amount in the end.
5 If and when you release it are you going to release all of the files and not sell the fixed ones.

These are just a couple things I see going side ways. However they all could be cleared up by introducing your contact from this company, along with a agreement between them and you/us.

If you could provide me enough accurate, and solid facts with some sort of guaranteed agreement I would pay the remaining balance in full once it is completed. You already have many people willing to back you with more reputation than me... So what's the hold up in providing proof of what's happening?


Veteran OT User
Jun 5, 2013
Reaction score
hello 4drik u said u working on fixing animations too
ninja uploaded fix for idle animations and it works good so dont need working on this
i compiled and tested this client (otland/otclient (https://github.com/otland/otclient/tree/WalkAnimation))
he also uploaded some changes to walking animations. i think his walking animations are better than the default ones but they are way too quick (player moves feet very quickly when moving)
so some further improvements could be done on this, since regular tibia client still feels better in this. but this is a nice start.


Sep 8, 2016
Reaction score
About OpenGL - yeah it sucks it uses a lot more CPU than Direct3D especially on amd drivers + I'm hate the approach with extensions which in some cases is a lottery to have them.
Here's a little example on a client that I'm working whenever I have time(not OTClient):
OpenGL -
Vulkan -

As you can see the Vulkan is about 75% faster because of better CPU utilization(It's my first attempt with Vulkan while I worked with OpenGL for some time) and at this moment the OpenGL code part are much more optimized than Vulkan(Direct3D is about 40-50% faster than OpenGL - just to say I'm talking about the same optimization level, it's not that the corporations are bought by Microsoft to make games for Directx it just that it's better and not talking about emulating Directx via Angle because it'll always be much slower).

About performance issue with monsters on battle list is probably how the "outfits" are drawing on the list - "outfitBuffer->resize(Size(frameSize, frameSize));" the framebuffer most likely will get resized multiple time per frame which is taking some time because it need to recreate texture and reattach the fbo with checking for success - glCheckFramebufferStatus is taking a lot of time for checking if the fbo gets attached successfully.

About the Edubart's points:
-"1. Drawing Less Tiles " - of course it will reduce the time rendering takes but there are somethings to consider - when moving you still need to draw these extra tiles + what if there're some things that takes more than 1x1 tile? It most likely will result in some kinds of "glitches".
-"2. Drawing Even Less Tiles " - like before it can result in glitches because the function "isCompletelyCovered" does not check for objects that takes more tiles + this function probably will be much more costly than simple drawcall unless you use really-really crappy old GPU.
-"5. Reduce Texture Binding" - you should consider this point the most because from my experience texture atlas gives you about 40% performance boost on OpenGL and even to 70% on Direct3D.

And please don't ask me to take part in this because I'll decline just because I don't like the OTClient itself.