Speed of Doom TAS movie - Eternity demo sync issue

[Quasar]

Can you describe to me what is supposed to happen on MAP11? The more details, the more useful. This demo currently desyncs in EE on MAP11 (in the current trunk SVN revision). I've been trying to improve EE's 2.02 demo sync for a long time ;)

What currently happens in EE is the player takes a sudden dive into a nukage river, ends up by some blue key bars, and then injures himself a lot with the rocket launcher. This does not kill him however. He dies shortly thereafter and ends up respawning in the same level :/

[dew]

Quasar said:

Can you describe to me what is supposed to happen on MAP11?
...
What currently happens in EE is the player takes a sudden dive into a nukage river

that's where an archvile jump is supposed to play out, i land on top of the wall around the RK pen to bypass most of the level. it's the start archie that attacks me, that's why i open the secret with the berserk - so he sees me at the upper switch. this sounds like a desync due to monsters behaving differently.

[Quasar]

dew said:

that's where an archvile jump is supposed to play out, i land on top of the wall around the RK pen to bypass most of the level. it's the start archie that attacks me, that's why i open the secret with the berserk - so he sees me at the upper switch. this sounds like a desync due to monsters behaving differently.

Quite possible, although so far I haven't found any incompatibilities in the AI logic - rather, they seem to always end up being in the clipping code (Okuplok's SoD MAP33 demo desynced due to Lee Killough munging up the v2.00 - v2.02 dropoff code in MBF). When it's the clipping code, debugging it is insanely difficult and requires manual comparison of ~900 MB+ log files generated from the position of every mobj on every tic x_x

I'll see if I can't get around to investigating it more thoroughly after I finish converting to C++.

[4mer]

Nice movie.

I had a look at the desync problems with Eternity today here is what I found (sorry for long post / if wrong place):

1. from p_mobj.c : P_SpawnPlayerMissile
A problem with different value for slope when autoaim fails.

//slope = finetangent[(ANG90 - source->player->pitch)>>ANGLETOFINESHIFT];
slope = 0;

2. from p_enemy.c : P_LookForPlayers
A problem with different reference counts causing thinker removal to happen differently.

//P_SetTarget(&actor->target, actor->lastenemy);
//P_SetTarget(&actor->lastenemy, NULL);
actor->target = actor->lastenemy;
actor->lastenemy = NULL;

3. from p_sight.c : P_CheckSight
A problem with demo compatibility check possibly?

//if(!demo_compatibility && !t1->subsector->polyList && t1->subsector == t2->subsector)
//	return true;
if(demo_version >= 203)
{
	if(!demo_compatibility && !t1->subsector->polyList && t1->subsector == t2->subsector)
		return true;
}

4. from p_map.c : P_SkullHit / PIT_CheckThing

When a skull hits a monster that is asleep, the thing that is woken will change to its see state i.e. A_Chase from which the woken monster will then try to chase after the damage inflictor (skull) with P_NewChaseDir. Eventually the monster will try to move and end up calling P_CheckPosition. In Doom / Boom P_CheckPosition overwrites tmthing which is the variable that was referencing the skull originally. So later when everything returns to PIT_CheckThing the tmthing at that point will have been overwritten :) (the momentum is cleared for the thing the skull hit instead of the skull).

Demo sync can be restored by replacing tmthing in P_SkullHit with clip.thing.

[Quasar]

4mer said:

*snip*

Wow that's fantastic, how'd you nail it down so fast?

However, #2 is problematic. IIRC I changed that deliberately because in PrBoom-Plus it's incorrect. That code as it is in PrBoom-Plus *could* cause spurious access violations by corrupting the objects' reference counts. While I suppose I could let this slide during 202 demo playback and pray it doesn't crash, it's the kind of thing I really hate to have to do :(

[4mer]

To find the tick of interest and reduce log file size you can use a CRC / Hash function.
So for example in p_tick.c : P_RunThinkers you could add something like:

int index, crc;
index = 0;

...

if(currentthinker->function)
{
	currentthinker->function(currentthinker);

	if(currentthinker->function == P_MobjThinker)
	{
		mobj_t *mobj = (mobj_t *) currentthinker;

		// Add whatever data you want to monitor
		crc = UpdateCRC(crc, mobj->x);
		crc = UpdateCRC(crc, mobj->y);
		crc = UpdateCRC(crc, mobj->z);
		...

		if(verbose)
			fprintf(logfile, "%d %d\n", index, crc);
	}
	index++;
}

Then record the value of the CRC at the end of each tick to the log file. Some other values you might want to include are the state of the players random number generator and the number of active thinkers.
Then add the same code to some other port that replays the demo successfully (prBoom+) and compare the output.
Once you know the desync tick you can then enable the more verbose logging and find out which thing is different (i.e. log each change of the crc after each thing for that tick).
Then just set up a breakpoint at the point of interest (i.e. tick == x && index == y) and after it is hit step through both ports looking for the problem.
You can also use -timedemo -nodrawers -nosound etc. to speed up demo playback.

[Quasar]

4mer said:

To find the tick of interest and reduce log file size you can use a CRC / Hash function.

I had an idea a bit similar the other night about using a checksum of some type... looks like a good way to do it. I'll see about building something of the sort into EE on a permanent basis if it proves practical. Thanks for your help!