Any documentation about Lara's original movement system?

[bangclash]

I'm creating an original Tomb Raider influenced indie game. The level design stuff I have a handle on. Lara's grid-based movement I'm having some issues with. I know Lara movements is all based on grid amounts (she can jump two cells...). I'm running into edge cases I'm not sure how to handle. I want to make the movement as close to the original Tomb Raider as possible. I have a great fondness for that game. Are there any tech docs on this grid-based movements and how they handled some edge cases?

[XProger]

hi, Tomb Raider was data oriented, i.e. all states, switches between them and their animations, speed, acceleration etc. are right in the level data, so Lara jumps on the edge just because running state allows switching state to jump only in the specific frames range. OpenLara uses it, but the original game uses animation/state switches almost directly... idk why, but the differences are minor in most cases :)
The documentation that I used to implement is there http://xproger.info/projects/OpenLara/trs.html#_mesh_construction_and_animation

for example: when you press forward button, the code start looking for state switch range to RUN state from the current IDLE state animation, then if the current frame in the required range then Lara state switch to RUN and new animation (start running) is set. This animation has acceleration and speed values that applies to the Lara's entity. Each animation has next animation id, so "start running" has next animation as "running" which has only speed and no acceleration. So after few frames of "start running" it ends and switches to just "running" with linear speed, but both have RUN as the state. That "running" animation has own ranges for state switches back to "stop" via another intermediate animation, "jump", "walk" etc. so if you press jump button while running the code start looking and checking for JUMP state switch in the current animation.

[bangclash]

thank you for that link. I will pour over it. It's interesting there doesn't seem to be a section about the actual math of Lara's movement.

Your engine is amazing. I can only hope to come up something that is 10 percent of what you have done. If I can do that it will be a success in my eyes.

[dmitshur]

That "running" animation has own ranges for state switches back to "stop" via another intermediate animation, "jump", "walk" etc. so if you press jump button while running the code start looking and checking for JUMP state switch in the current animation.

If you don't mind a followup question to this: what is intended to happen when there's no direct bridge animation from current state to another desired state? For example, starting with "running animation", if one suddenly tries to enter walking backwards state (state number 16, eventually leading to animation number 40) directly, naively Lara'll be stuck running forward and never get to the desired "walk backwards" state. What I found so far is to always fall back to "stop" state (number 2) whenever there's no direct bridge animation to goal state from current state. It seems to work so far, but I wanted to confirm that this is expected. In the TRosettaStone doc it says "If such an AnimDispatch is found, the animation and the frame are changed to those listed in it." but I didn't see it called out what happens when it's not found. Thanks!

[XProger]

@dmitshur you're right, each animation state has own collision and state routines, so in the case above it fallback into STOP animation before walk backwards
https://github.com/XProger/OpenLara/blob/master/src/fixed/lara.h#L647