Night Wolf
I don't bite.
- Joined
- Feb 10, 2008
- Messages
- 582
- Solutions
- 8
- Reaction score
- 929
- Location
- Spain
- GitHub
- andersonfaaria
Very good progress Renato, keep it up!
Very good progress Renato, keep it up!
Very nice, keep it up.
Btw, this my friend would make my day: 3- Possible True OTML, using HTML and CSS writing. (Maybe I won't have time for this)
Also I really like initiative,
With his skill, speed and knowledge, soon this will be better than paid to otcv8
Nice to see git done right - a proper fork!
But since your commits go straight into master, you should consider having another branch that represents upstream edubart/otclient master. Which shows where you are (in terms of being in sync with edubart) and has no changes.
So when you sync with another repo in the otclient network:
mehah/upstream -> merge edubart/master (fast forward)
mehah/master -> merge mehah/upstream (resolve potential git conflicts etc and keep your optimizations up to date with edubart)
You can also do cool stuff like
git checkout mehah/upstream (point your fork at "base")
git checkout -b single_optimization_update (take this base and make a new branch)
git cherry-pick <commit# single optimization update from mehah/master> (add selected updates to this branch)
git push mehah single_optimization_update (push this branch to github)
And send PR's by visiting edubart/otclient
Also some github tips, you can go into settings and enable issue tracker and wiki. So people can report bugs directly to your repo, write custom wiki guides etc.
There's an issue that I think is the most critical in otclient and even otcv8 has it. There's something wrong in the logic if an item should be reachable or not based on if it's covered or not. I'm currently at work right now but I can show you more details later.
[10.98] Not able to use some items near walls with borders on top · Issue #46 · otland/otclient
Describe the bug You cannot use chests nor some items if they are near walls with borders on top. For some unknown reason entering the wall allow you to use the item. The problem seems to be relate...github.com
Map::checkSightLine
and its part of going through floors:Guys, I have great news, I just made a change to take advantage of the rendering cache, the tiles and lights will only be recalculated if there is a change in the screen, there was an increase of more than 400% of fps depending on the situation, of course it still needs to be improved , if put too many monsters on the screen, doing too many actions, the fps will drop a lot.
It is still far from good, but it is a start.
if put too many monsters on the screen, doing too many actions, the fps will drop a lot.
). You are basically disguising fps numbers when player stands still and nothing is happening on the screen. The moment anything happens it drops back to real value when the framebuffer is being re-drawn. Having countless of fps in a truly static environment (no animations, no movement, no nothing) is meaningless. The whole game experience might be even worse with those changes due to all the jittering going on as it is much better to have stable 60 fps than jumping between 600-60 all the time.I doubt this is related to OTClient in general, I mean it could behave differently, but that wouldn't solve the core issue. That being said, there is a function within OTServ and TFS I wrote about 10 years ago and it wasn't changed since then. That function isMap::checkSightLine
and its part of going through floors:
forgottenserver/src/map.cpp at db4e8cc1fbf98a448bf91a009fc625e5dd8230f9 · otland/forgottenserver
A free and open-source MMORPG server emulator written in C++ - otland/forgottenservergithub.com
If a tile contains any item (e.g. border) it simply returns false. The solution here is rather simple - iterate through all items on that tile and check if this object can be ignored (e.g. border) and if so, just continue and let it return true.
As much as I admire people attempt to optimize stuff, this is not a correct way and you have already noticed it (quote:if put too many monsters on the screen, doing too many actions, the fps will drop a lot.
). You are basically disguising fps numbers when player stands still and nothing is happening on the screen. The moment anything happens it drops back to real value when the framebuffer is being re-drawn. Having countless of fps in a truly static environment (no animations, no movement, no nothing) is meaningless. The whole game experience might be even worse with those changes due to all the jittering going on as it is much better to have stable 60 fps than jumping between 600-60 all the time.
That being said, there is much more advanced technique to approach this problem and that's dirty rectangles, but it is also quite difficult to implement. You basically re-drawn only parts of the screen which did change. For example UI can be optimized much with such approach as it is rarely being re-drawn and is mostly taking more space that the game's framebuffer. The framebuffer itself can be even further optimized with dirty rectangles and scrolling technique (as walking is just area scrolling and we rarely need to re-drawn any part of the current framebuffer).
You can read about it here:
Flip model, dirty rectangles, scrolled areas - Win32 apps
Describes the benefits of using the new flip-model swap chain and of optimizing presentation by specifying dirty rectangles and scrolled areas.docs.microsoft.com
If a tile contains any item (e.g. border) it simply returns false. The solution here is rather simple - iterate through all items on that tile and check if this object can be ignored (e.g. border) and if so, just continue and let it return true.
as you already noticed, basically i am reducing the redrawing of the tiles, and yes, i intend to improve by putting to draw only what has been modified, but the question, what is causing the fps to drop so much, are creatures names and lifebar , which are redraw all time.
this is what happens when you turn off, along with the changes I made.:
From what I coul test, this only applies for this particular border so I don't know what is that it has of difference (perhaps the BLOCK_PROJECTILE part?)
I'm not saying this impact every otclient out of nowhere, I have tested it extensively. In fact I could only reproduce in this particular area of my map, but there could be way more bordes with that same problem. I wouldn't assume this is one time thing.
It's strange, because even in Cip's client you have some "not standard behaviors", when an item it's partially hidden by the vision of a house second floor, for instance, it can be clicked without problems but there are situations where it cannot and I wasn't been able to make a connection to which defines being clickable or not.
@Iryont I am currently testing Mehah solutions. At the moment, I think that this optimization of drawing request is worth attention, because even if these "real" FPSs will not jump up, there is a reduction in CPU consumption at the same amount of FPS so for the machine it seems like a reasonable solution unless we set FPS without limit.
Impossible otcv8 is a really ahead so much there is no reason to use his otc at this pointWith his skill, speed and knowledge, soon this will be better than paid to otcv8
#Edit
However, seeing some of your other commits I just realized you did perform your "tests" in a very specific case when you do not draw any lights from all the effects due to ambient lighting being at full power. In such case I can only assume that the performance will drop a lot when lights will be actually drawn like in 95% cases during playtime.
@Mehah
Might be a little offtop, but have you thought about looking into path-finding and moving in general in terms of ping/packets?
Impossible otcv8 is a really ahead so much there is no reason to use his otc at this point
I'm not sure if it is my fault, but when going up I have bad drawing:
View attachment 46825
and good when going down:
View attachment 46826
Not sure if fragment below should be changed in order to recover proper drawing:
View attachment 46827
if (!viewport.isValid(tile, cameraPosition)) continue;
Your change is not helping, but change below fixed the issue:remove line 129 in "mapview.cpp", and see if it solves your problem.
thisLua:if (!viewport.isValid(tile, cameraPosition)) continue;
mehah/otclient (https://github.com/mehah/otclient/blob/62e2ae8d00ff05029d340118eba4745910d025ef/src/client/mapview.cpp#L129)
why buy when kondra released its source for free already? xDI would buy otv8, but 5k for us Brazilians, it's 28k.
They are not usable at all.why buy when kondra released its source for free already? xD
not sure if sarcastic or just ignored completely the page 1 commentswhy buy when kondra released its source for free already? xD