-
Notifications
You must be signed in to change notification settings - Fork 782
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADL: Decouple positioning while walking from game logic #1987
Conversation
This really plays and feels fantastic, grate work. One funny thing is that since this is a gradual process you get to see the monsters move around at the lower update rate, it feels like they are stuck on old hardware :D We might should also consider updating the light positions as a result of the render event rather then game ticks, but I think that can happen via another PR, not necessarily tied to ADL changes. |
Thanks for the feedback. This is really motivating. 😊
🤣 The monsters will get faster too! Prepare yourself! 🗡️🛡️
The lightning part would be interesting. But i never looked at the logic. |
This feels incredible. It might be the most impactful change to the game thus far in terms of smoothness in my opinion along with the 60FPS cursor movement. Fantastic work @obligaron ! |
Really fantastic graphical revolution.
|
They will 😉 |
With this change the position of the player is now calculated independent from the game logic.
The already present information from
AnimationInfo
(ADL) is used for this.Restriction
Before this pr the player and camera position was updated 8 times for each walked tile.
With ADL we can calculate the offset relative to the animation fraction (0.0 to 1.0).
As this is a floating variable this can calculate many small steps and so positions updates.
But currently the rendering logic restricts this.
The current game logic operates on the pixel definitions of the original resolution.
For example the walking offset from one tile to another (to the east) are 64 pixels in x-axis.
As the current rendering logic is based on the game logic it's interface is also based on pixel basis.
That mean's currently we can calculate that we would be on pixel 8.4 but can't pass it to the rendering.
We have to squeeze the value in an integer and lose the precision.
This lose of precision is not dramatic if you walk in direct lines. cause we still have 64 pixels and means we have 64 different update positions. That's enough for smooth scrolling.
But in case of diagonal walking we only have 16 pixels at the y-axis. Compared to the original it's twice as much (8 -> 16) and better but still visible (see examples).
To lift this restriction the rendering logic must be adjusted to pass more fine granular positions.
The good thing is, this can happen at separate independent steps.
Example Videos
Walk in dungeon (25% game speed)
Version 1.21x
WalkDungeonOrg.mp4
PR
WalkDungeonPR.mp4
Running in town (25% game speed)
Version 1.21x
WalkTownOrg.mp4
PR
WalkTownPR.mp4