Archvile
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Ugly little interpolation problem
 
Author
All times are GMT. The time now is 14:40. Post New Thread    Post A Reply
Quasar
Moderator


Posts: 6037
Registered: 08-00


EE recently got interpolation (old news at this point) but last night while working on a problem that ConSiGno reported relating to voodoo dolls, I had an unfortunate revelation that it's insufficient to backup objects' positions during Mobj::Think (equiv. of P_MobjThinker in vanilla) because it's possible for objects to move before that.

Theoretical situation demonstrating the possibility:

  • A sleeping imp that is further down the thinker list is hit by a barrel explosion (it is the barrel's thinking turn and it has called P_RadiusAttack).
  • The imp transitions to its seestate in P_DamageMobj and calls the action function A_Chase
  • A_Chase moves the thing via P_SmartMove -> P_Move -> P_TryMove
  • It hasn't thought yet so, its previous position data has just been wiped out.

Given this reality, I don't see any one place in the code where mobj positions can be reliably backed up in every situation *without* the highly undesirable "solution" of iterating over the entire thinker list twice... >_>

Any ideas, or pre-existing solutions I haven't seen yet?

Last edited by Quasar on 02-12-14 at 19:15

Old Post 02-12-14 19:08 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7607
Registered: 07-00


Calculate the interpolated positions after all moves have taken place for the tic.

Old Post 02-12-14 19:15 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6037
Registered: 08-00



fraggle said:
Calculate the interpolated positions after all moves have taken place for the tic.

I have to interpolate from the previous position to the position the object has at the end of the frame. This implies needing to backup the coordinates at the start of the frame somewhere.

Old Post 02-12-14 19:17 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Member


Posts: 349
Registered: 11-06


It's kinda hard to tell what you need from your description. Are "fake-moving" the mobjs on off-tics, and then correcting the positions at the next frame? In other words, do you calculate tic 99.4 mobj x and y positions, then correct them on tic 100? Are you actually moving the mobjs to mid-tic positions in the simulation, or only for rendering? And, finally, if you are rendering tic 99.4, do you forcibly render tic 100.0, or is it possible that the next render might occur at tic 100.2, skipping tic 100.0 altogether?
In other words, you may not render tic 100.0, but you always calculate it, right?

How do you store the interim momentum for that imp, from tic 99 to tic 100? Are you actually running the simulation, and doing mobj->X = mobj->X + (delta / interp_diff)? Are you really changing the standard mobj vars by interpolated amounts, and then backing out, and calculating the actual tic with previous values?

Sorry for my ignorance, but it's interesting stuff. Without knowing the specifics, seems tome that there's still not very many places where a mobj gets moved. Even if it's more than one, is it a big cost to dup some code, call an inline func, or even a normal func? Surely you'd only need to had a few lines per movement, right? Anything is better than iterating all the mobjs per tic.

I don't suppose you could use P_SetThingPosition? That would cover the non-Mobj::Think cases, if I'm not mistaken.

Old Post 02-13-14 02:36 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2096
Registered: 08-03


Of course, all these problems disappear when one extrapolates the "future" values rather than attempting to interpolate between two previously calculated frames. Naturally this will lead to some (very) minor visual issues but these will be corrected automatically every 1/35 seconds...

Clearly one must have two game tics worth in order to interpolate, so, what does Eternity do before the "second" tic's data becomes available (e.g., at the very start of the map)? Or, maybe you always run two tics before attempting to draw the world?

Does any other DOOM port implement this using interpolation? (I don't believe so, but I may be wrong).

Old Post 02-13-14 03:54 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
MP2E
Junior Member


Posts: 157
Registered: 09-07



DaniJ said:
Does any other DOOM port implement this using interpolation? (I don't believe so, but I may be wrong).

ZDoom, GZDoom, PrBoom-Plus, Odamex, and Doom64 EX all use interpolation AFAIK.

Old Post 02-13-14 04:34 #
MP2E is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2096
Registered: 08-03


No, they use extrapolation, not interpolation.

Old Post 02-13-14 05:18 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6037
Registered: 08-00



DaniJ said:
No, they use extrapolation, not interpolation.

That would be entirely inconsistent with everything I've been told or seen to date. Particularly in the cases of Odamex and PrBoom-Plus.

Old Post 02-13-14 05:45 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2096
Registered: 08-03


I stand corrected. Best ask one of those guys, then.

Old Post 02-13-14 05:49 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7733
Registered: 01-03



Quasar said:

Given this reality, I don't see any one place in the code where mobj positions can be reliably backed up in every situation *without* the highly undesirable "solution" of iterating over the entire thinker list twice... >_>



You are correct, it can't be done without iterating over the entire thinker list again.

ZDoom doesn't handle this case at all, btw.
I personally never noticed because I always use the option NOT to interpolate any movement done by A_Chase, because I always found it looks very bad. This of course will hide the mentioned problem.

The question is, is it really such a problem to iterate the list once more? ZDoom can do this multiple times in one tic, e.g. for some ACS functions affecting multiple actors, and it was never considered a major issue.

Old Post 02-13-14 08:16 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11112
Registered: 07-07


Usually, these ACS functions aren't called every single tic, though.

Old Post 02-13-14 08:58 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6037
Registered: 08-00


From the fact no other ports worry about it, I am getting the impression that it's not a big enough problem to bother disturbing the design of the game engine to fix.

Old Post 02-13-14 16:44 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1008
Registered: 04-09


You add fields for the previous position to the mobj, and a time-stamp of when it was saved.

Before ANY update of position (including the barrel explosion example), the previous time-stamp is checked. If it is less than the global interpolation time-stamp, then the previous position is updated before moving, and the its time-stamp is updated to be the global interpolation time-stamp.

The global interpolation time-stamp provides a consistent time interval to do the later interpolation over. Otherwise you could not trust when the previous positions were saved, and moving the same object twice in a tic would fail to save previous position only once.

There is no need to iterate the list again. The overhead is a time-stamp compare, and a copy of position.

This is similar to the time-stamp used to detect if an object has been updated more than once in a tic.
DoomLegacy has interpolation, but I have not paid any attention to it.
Someone disabled it so it may be unfinished.

Old Post 02-13-14 22:27 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6037
Registered: 08-00



wesleyjohnson said:
You add fields for the previous position to the mobj, and a time-stamp of when it was saved.

Before ANY update of position<snip>


And I'm cutting you off there because it implies mass conversion of everywhere that handles mobj coordinates to a method call. The code is currently in no state for that to happen.

Old Post 02-13-14 23:01 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2096
Registered: 08-03


There is already a method/function call, though (in vanilla at least). Whenever a mobj is moved it is necessary to unlink it from structures like the blockmap and sector lists and then relink it again once the move has been completed. Can't you attach your interpolation hooks here?

Old Post 02-14-14 00:25 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Member


Posts: 349
Registered: 11-06



Quasar said:
From the fact no other ports worry about it, I am getting the impression that it's not a big enough problem to bother disturbing the design of the game engine to fix.
Why didn't you provide the brief description I asked for? Interpolation can be done a few different ways, so the method that you used matters. I haven't been able to check the source yet.

I'll make a guess:

Please tell me if this description is correct:
. You calculated frame 99 sometime in the past.
. Then, frame 100 is calculated.
. Now, it's time to render, and your time calcs tell you that you're half-way through a frame.
. You then move mobjs halfway between their frame 99 position and their frame 100 position, and render.
. Finally, you must now move the mobjs back, so your question is:
Where should I store this previous mobj position, and insure that that variable is always up-to-date?

Is that the question?

Old Post 02-14-14 02:27 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Member


Posts: 349
Registered: 11-06


So did you resolve it, and, if so, can I ask what the resolution was?

Old Post 02-19-14 03:06 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Holering
Member


Posts: 323
Registered: 01-03



Quasar said:
EE recently got interpolation (old news at this point) but last night...


I'm assuming no problems arise using 140 HZ vsync...? Can interpolation be disabled?

Old Post 02-19-14 03:40 #
Holering is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 14:40. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Ugly little interpolation problem

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.