OPENING (incompatible) DEMO's

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Postby HotWax » Sun Oct 12, 2003 2:24 pm

Hirogen2 wrote:Hm, I don't get it 100%. The demo format stayed pretty the same between (Doom2) 1.7 and 1.9 I guess, that is 35 actions per sec, and those also stayed the same, 0x1 for move and/or such. So the only thing which can desync and fux0r up a demo would be more execution in the main (renderer, AI, etc.) code. Is it? Then again I believe no since then, the whole game (non-demo) would also play faster/slower.


Look at it this way. Let's say someone records a demo in v1.7, and that demo will playback just fine in v1.7. This is because the demo stores the keys the player pressed while he was recording. When it plays back, it starts at the same point and then pretends that the player is playing it, using the keystrokes stored in the file. The engine is still computing all the physics, AI, sector actions, and other things that make the game run. None of that is stored in the demo.

Now let's say that at a certain point in the demo, the player is riding a tall lift down and shooting at enemies. He manages to kill off two imps on his way down, and then kills the rest at the bottom, walks over their corpses to hit a switch, and goes on his merry way.

Now pretend that in v1.8, a bug was fixed that caused platforms to move 1 extra unit per second. Obviously an extremely minor change, but still a change. Now you play the demo back. The player reaches the lift, but it's going marginally slower. Because of this, he fails to kill one of the two imps on the way down. However, the demo has no way of adapting, as it doesn't know it was supposed to succeed in killing the imp, so it just keeps playing along like everything is okay. The player jumps off the lift a little early, and fires at some of the enemies on the ground (maybe it even kills one "on accident") but that pesky imp that should be dead is still alive. Regardless, the player didn't shoot after this point so he walks toward the switch. However, the imp gets in his way and delays him, doing some damage in the process. By the time the virtual controls recorded in the demo hit the use button, the player hasn't reached the switch. Then the player turns around and goes on his merry way, perhaps straight into a closed door that would have been opened had he hit the switch. The demo still doesn't know the door was supposed to be open, so the player just runs headlong into the wall and continues moving in seemingly random directions like a moron, trapped wherever he ended up, shooting at nothing, and being shot at by the imp he failed to kill.

That's why demos go out of synch. One seemingly innocent change can screw up every future action made by the player in the demo.
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby Enjay » Sun Oct 12, 2003 3:04 pm

Also, I assume if Randy did rewrite the demo stuff to the new über format, then that would only be compatible with demos from this point on, unless there was also a converter built in to read which version a demo was recorded with and was then able to take all the recorded keystrokes or whatever is saved, and convert them to the new format. For that to work, Zdoom would presumably have to have some sort of table of values for each and every version up to this point.

@Ty A demo is basically a single player network game eh? That I did not know. Interesting.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Postby HotWax » Sun Oct 12, 2003 7:39 pm

Enjay wrote:Also, I assume if Randy did rewrite the demo stuff to the new über format, then that would only be compatible with demos from this point on, unless there was also a converter built in to read which version a demo was recorded with and was then able to take all the recorded keystrokes or whatever is saved, and convert them to the new format. For that to work, Zdoom would presumably have to have some sort of table of values for each and every version up to this point.


Actually it's worse than that. ZDoom would need the entire engine from every previous version.
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby Graf Zahl » Mon Oct 13, 2003 1:55 am

HotWax wrote:
Enjay wrote:Also, I assume if Randy did rewrite the demo stuff to the new über format, then that would only be compatible with demos from this point on, unless there was also a converter built in to read which version a demo was recorded with and was then able to take all the recorded keystrokes or whatever is saved, and convert them to the new format. For that to work, Zdoom would presumably have to have some sort of table of values for each and every version up to this point.


Actually it's worse than that. ZDoom would need the entire engine from every previous version.



And if you look at the changes the code has gone through it's obvious that it is a futile effort.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Hirogen2 » Mon Oct 13, 2003 7:58 am

Now pretend that in v1.8, a bug was fixed that caused platforms to move 1 extra unit per second.

So If I would record a demo of E1M1 now and try to play it back with 2.0.48 (in future heh), will it play back in sync? No, as you say. In E1M1 I do not need to use any lift, and I can not think of anything of such, in E1M1 you just need to walk, open some doors (you can wait a tic longer there to be sure). What bugfixes done so far since 2.0.47i would "kill" the demo when played back in 2.0.48?
Or the same, when I recorded fb6-hirogen2.lmp (unavailable anymore) with 2.0.47, it desynced with 47i, which changes did that? I think the 1 extra unit was fixed a long time ago :D
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby Graf Zahl » Mon Oct 13, 2003 10:30 am

It's everything which gets executed that matters. The lift thing is just one obvious example. Even the slightest change to any routine that performs critical calculations (e.g. collision detection, AI, player movement) can cause the player or a monster to be slightly off the location during recording. If then something is in the way so a move is blocked the demo de-syncs. Even truly trivial things no one would think about can (as in: doesn't need to do so in every case!) cause problems.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Nanami » Mon Oct 13, 2003 11:01 am

Just think of it this way. Already some vanilla demos won't playback in PrBoom or Eternity.

Now imagine you completely rewrite PrBoom's rendering engine, and then try to get all those vanilla demos to play.
User avatar
Nanami
Natdhipytadd
 
Joined: 15 Jul 2003
Location: That little island pritch created.

Postby Zell » Mon Oct 13, 2003 1:32 pm

who cares about demos anyway? i mean, its trivial. We do not need to push back 2.08/2.0 becuase of demos. Titlepidc and etc will be fine for now :D
User avatar
Zell
:O ALIVE[again]
 
Joined: 24 Jul 2003
Location: IN A GODDAMN BOX[In Erie.]

Postby Graf Zahl » Mon Oct 13, 2003 2:25 pm

Nanami wrote:Just think of it this way. Already some vanilla demos won't playback in PrBoom or Eternity.

Now imagine you completely rewrite PrBoom's rendering engine, and then try to get all those vanilla demos to play.



If you just rewrite the renderer it won't matter. It it were so PrBoom's GL version would not be able to play back demos. The rendering code does not contain anything that changes game data. It's probably the only code that doesn't affect demo playback. On the other hand, if you change some of the game code to add cool features, it is almost absolutely certain that it will break demo sync.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Nanami » Mon Oct 13, 2003 2:59 pm

Oops. My mistake.

-rendering
User avatar
Nanami
Natdhipytadd
 
Joined: 15 Jul 2003
Location: That little island pritch created.

Postby HotWax » Mon Oct 13, 2003 3:34 pm

Hirogen2 wrote:So If I would record a demo of E1M1 now and try to play it back with 2.0.48 (in future heh), will it play back in sync? No, as you say. In E1M1 I do not need to use any lift, and I can not think of anything of such, in E1M1 you just need to walk, open some doors (you can wait a tic longer there to be sure). What bugfixes done so far since 2.0.47i would "kill" the demo when played back in 2.0.48?
Or the same, when I recorded fb6-hirogen2.lmp (unavailable anymore) with 2.0.47, it desynced with 47i, which changes did that? I think the 1 extra unit was fixed a long time ago :D


You're completely missing the point. The example I came up with was just conjecture; to my knowledge there was never a fix affecting lift speed. The point is, one tiny seemingly insignificant change can alter things just slightly. And then those alterations can alter more things, until the demo is completely out of synch and things unfold quite differently than they were recorded... It's much like time travel, actually. :roll:
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby randi » Mon Oct 13, 2003 4:25 pm

Here is one example of a real problem that effected playback of demos with the same version of ZDoom they were recorded with. I don't remember what version I fixed this in, but it was a demo recorded on one of the early ZooM maps.

The map contains a quicksave command. When this was executed while recording, the game was saved and due to an oversight on my part, all the slopes in the level were recalculated. This should not be a problem, except they were not recalculated in exactly the same manner as they were calculated when the level loaded. When the demo was played back, the quicksave was not executed, so some of the slopes could be off by as much as .00002 units compared to what they were when the demos was recorded. So once the player walked on a slope, the demo got out of sync.

This has been fixed, so you don't have to worry about saving while recording a demo anymore. It's just an example of how even unobvious things can make demos go out of sync.
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Postby Nanami » Mon Oct 13, 2003 11:16 pm

Woohoo, a ZooM mention. =D Even if it's not the best mention. =P

We're working on releasing the demo by the way, it should be out in a week or two. I know we said that once before but this time we actually ripped apart the wad and added a bunch of things and just need some music and a little scripting on my part.

So any of you that care about ZooM can be happy now, I guess, heh.
User avatar
Nanami
Natdhipytadd
 
Joined: 15 Jul 2003
Location: That little island pritch created.

Previous

Return to General

Who is online

Users browsing this forum: No registered users and 6 guests