Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
scifista42

Updating Z position while standing on a moving floor?

Recommended Posts

I'd like to know if there is always a 1-tic delay before player's Z position (and viewheight) is updated to match the moving floor's height, or if they should be perfectly synchronized at all times, or if this is source port dependant. I'm curious if my calculation and depiction of when exactly to fire a rocket to hit IOS's brain is either off by 4 map units (or another amount of them?), correct, or dependant on the source port, respectively.

Share this post


Link to post

The player thinkers appear to always be run before all the rest of the thinkers, so the player's position ought to always be set according to the last tic's floor value.

Share this post


Link to post

Okay, thanks, and does there also apply any view drop, like when the player's view briefly drops down after he falls onto the ground from a non-negligible height? In any case, assuming the player is standing still on a lift that moves upwards by 4 units per tic, will his eyes be exactly at (41 - 4) map units above the lift's floor at any moment during the lift's movement, or are there other factors to consider?

Share this post


Link to post

Yes. Any change on view height during the normal thinking process will only be visible one frame later.

If you dig through ZDoom's changelog you will find that I recently changed that because it produced some not so nice problems with view interpolation.

Share this post


Link to post
Graf Zahl said:

I recently changed that

Just the viewheight, or wholy updating the player's position? If the latter, then the moment when a player should optimally fire a rocket against IOS according to what he can see at the moment should be the same in the newest ZDoom as in vanilla, but if the former, it would be one tic different, right?

Share this post


Link to post

The floor movers always update the actual z-position. It's just the viewheight that is done later.

How this will relate to thr IOS I cannot say, but with ZDoom the problem that the view was squatting down while moving up an elevator was quite pronounced when the game wasn't capped to 35 fps. Since I haven't played with 35 fps in a long time I really can't say.

Share this post


Link to post
Graf Zahl said:

The floor movers always update the actual z-position. It's just the viewheight that is done later.

Well, this once again changes the situation. Thanks, I'll try to consider that in regards to the IOS.

Share this post


Link to post

Yeah, whoops. As with most things in the Doom engine it's more convoluted than it first appears. My initial thought was "it updates the player thinkers first, end of story" but then of course later in the tic when it runs the moving floor thinker, it checks the blockmap and does P_ThingHeightClip for all things in the vicinity, thereby changing the player's z-position anyway (I assume?). So I guess the game sets player->viewz when doing the player thinker, but then doesn't think to update it later if it's changing a player's height.

However, a rocket is spawned during P_PlayerThink() which is called before P_RunThinkers (). So it seems that a player's rocket will be fired according to his position the previous tic, even though the player's z-position gets updated later in the current tic anyway.

So I think what this ends up meaning is:

* If you're on a rising floor, your viewpoint is going to show a view 4 units (or whatever) lower than your "real" z-height for that tic
* However, a rocket you fire will also be 4 units (or whatever) lower than your "real" z-height for that tic
* Therefore, a rocket is always fired in correlation to your viewpoint, not your actual position?

Share this post


Link to post

OK, but in order for the input key to take effect on the weapon's Ready codepointer (handled by the player's thinker), it has to be already pressed when the player's thinker gets processed in the tic that only gives you that view after it ends. So, the fire button has to be pressed during the tic before seeing that view anyway? I've figured that the ideal moment for pressing the key would be the exact moment when the previous tic's view gets updated.

I've attempted a tic-by-tic analysis, posted it here and made conclusions - feel free to check if I got it right.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×