OPENING (incompatible) DEMO's

Post by **Enjay** » Sat Oct 11, 2003 4:50 am

HotWax wrote:Is this really worth it?

My £0.02 (which is worth more than $0.02 ($0.0332860 at the time of writing))

Is it worth it? No.

Post by **Graf Zahl** » Sat Oct 11, 2003 12:10 pm

Chris wrote: That's ultimately up to Randy and how he thinks to implement such a change. Given enough knowlegde of the ZDoom source, it would be something I would at least look into.

It's either new features or demo compatibility. If you want to maintain demo sync with old versions you simply must not change anything that alters the gameplay in even the slightest way (this includes bug fixes!) Look at the source ports that maintain demo sync. None of those has really good editing features and if the programmers want to change something they often have to hack around because they cannot make the changes without breaking demo compatiblity. I'd take better features any time.

Hirogen2 · Post by **Hirogen2** » Sat Oct 11, 2003 1:23 pm

randy wrote:
Nanami wrote:I imagine 48 will break 47 demos because of all the major changes
Indeed it will. Very badly, in fact.

So it is because there is more (or less) code to execute than before, so that takes up 1/(10^10) of a second each tic more?

This happens already. A checksum of loaded wads at record time would obviously be the ideal choice.

Already and would do not mix, either it does or it should do.
However, this is already done for savegames, so if you are missing (forgot to give it to -file) a PWAD, you will not be able to play the savegame.

Post by **Chris** » Sat Oct 11, 2003 2:36 pm

It's either new features or demo compatibility.

I'm not sure you're understanding what I'm saying. I'm suggesting to store more data in the demo lump so when it plays back, it's much less reliant on engine behavior.

Take for example, the recently fixed flying barrels of death(MDK'ing a barrel). Normally, the demo lump would contain just enough information to recreate this. Basically: "Turn right; execute MDK;" It would then rely on the engine to (im)properly thrust the barrel towards you. But because it's fixed, it won't work right anymore. What I'm proposing for the demo lump is to store more, like: "Turn right; animate barrel death; offset barrel x y; wait; offset barrel x y; animate player death; lower view to floor; wait; offset barrel x y;ect" so the barrel's movement, and subsequent actions, is stored in the demo and better gauranteed to playback properly, instead of hoping the game engine will properly behave. This would also have the added benefit of demos recorded in ZDoom x.y.z to work in ZDoomGL x.y.z, or any other engine that can recreate this scripted behavior.

Now things brings to mind a question.. how stable is current demo playback? Like, if I record a demo in 47i, how likely is it to go out of sync when played back in 47i? If it is stable, and will be stable in 2.1 I suppose I can understand why you'd not want to attempt it, but I'd like to be able to record a demo in 2.1 and have it play back in later versions..

Zell · Post by **Zell** » Sat Oct 11, 2003 2:46 pm

well, that will most likely be possible after randy irons out the major bugs and/or updates.

Post by **Graf Zahl** » Sat Oct 11, 2003 5:24 pm

Chris wrote:
It's either new features or demo compatibility.
I'm not sure you're understanding what I'm saying. I'm suggesting to store more data in the demo lump so when it plays back, it's much less reliant on engine behavior

To store sufficient data to make demo playback safe enough would mean to blow the whole thing out of proportion.

Not only the amount of data to be stored would be affected. You would have to insert a huge amount of pieces of code into the game to save, trace and maintain all this stuff. Anyway, the amount of work required to make this work is in absolutely no relation with to the result. It would be total overkill with little to no benefit for the user.

HotWax · Post by **HotWax** » Sat Oct 11, 2003 8:05 pm

Come on, Chris, we're talking about demos. Arguably the most insignificant feature of the Doom engine. What you're asking is a completely new way of recording demos and, as Graf points out, a whole new section of code JUST to make demo playback possible. I have to ask again, do you *honestly* think this is worth the hassle?

Post by **randi** » Sat Oct 11, 2003 8:14 pm

What Chris is advocating is basically writing half of client/server Doom. I don't think it's worth it just for demos.

Demos recorded with one version should always be able to play back with the same version and possibly with successive versions.

Hirogen2 wrote:So it is because there is more (or less) code to execute than before, so that takes up 1/(10^10) of a second each tic more?

IMO, keeping old code around for the sole purpose of maintaining demo compatibility makes for harder to maintain code. Nor is it always obvious what needs to be kept around. Even seemingly minor changes can have a big impact on the outcome of a demo. It's much easier just to forget about supporting demos from one version indefinitely. Remember, not even the original Doom maintained demo compatibility between versions.

HotWax · Post by **HotWax** » Sat Oct 11, 2003 8:30 pm

And the most recent id Software game, Quake 3, doesn't either.

Post by **Chris** » Sat Oct 11, 2003 10:14 pm

*shrugs* it was just an idea I had to fix the problem of demo incompatiblity. Yes, I realize they're "just demos", and I'm not going to be losing any sleep over it. It just sounded like a good idea at the time, and if it is that hard to do, I can understand.

I still think the basic idea should be looked into though. Store more data to help keep the demos in sync. If what I proposed was overkill, maybe there's a better balance between ease-of-implementation, demo size, and demo version compatibility. But I really don't know what the demo lumps store in the latest versions of ZDoom to know if much more can be stored without changing things past such a balance threshold.

Post by **Graf Zahl** » Sun Oct 12, 2003 1:28 am

Chris wrote:*shrugs* it was just an idea I had to fix the problem of demo incompatiblity. Yes, I realize they're "just demos", and I'm not going to be losing any sleep over it. It just sounded like a good idea at the time, and if it is that hard to do, I can understand.

I still think the basic idea should be looked into though. Store more data to help keep the demos in sync. If what I proposed was overkill, maybe there's a better balance between ease-of-implementation, demo size, and demo version compatibility. But I really don't know what the demo lumps store in the latest versions of ZDoom to know if much more can be stored without changing things past such a balance threshold.

As Randy already pointed out, it is not just a question of data stored in a demo. Every single change in the code might affect demo playback in a very unpredictable way. It's either circumventing the game logic completely and store every position change of every object, sector and wall in the game (creating excessively huge demo files which are obviously useless) or exploding the code to unmanageable proportions to keep track of all the alterations between different versions of the code. Every single bug fix, new feature or improvement would have to be optioned for demo playback. It will make changing the code nearly impossible without limiting yourself to rudimentary changes.
No programmer would do that if it wasn't absolutely necessary. And in this case it clearly isn't.

Post by **Enjay** » Sun Oct 12, 2003 4:30 am

randy wrote:IMO, keeping old code around for the sole purpose of maintaining demo compatibility makes for harder to maintain code.

Nor is it fully working code anyway. The original Doom2.exe was pretty good at recording demos, but I regularly used to find things going out of synch if I ever recorded a demo where I encountered a Revenant which fired a homing rocket.

And Doom demos weren't compatible from one version to the next either.

HotWax · Post by **HotWax** » Sun Oct 12, 2003 4:55 am

Chris wrote:*shrugs* it was just an idea I had to fix the problem of demo incompatiblity. Yes, I realize they're "just demos", and I'm not going to be losing any sleep over it. It just sounded like a good idea at the time, and if it is that hard to do, I can understand.

I still think the basic idea should be looked into though. Store more data to help keep the demos in sync. If what I proposed was overkill, maybe there's a better balance between ease-of-implementation, demo size, and demo version compatibility. But I really don't know what the demo lumps store in the latest versions of ZDoom to know if much more can be stored without changing things past such a balance threshold.

The idea's sound, and if someone was bound and determined to implement cross-version compatible demos I guess that's their business. I didn't mean to rain on your parade, just suggesting this is not what ZDoom's really about. ... Besides, it'd just delay 2.1.0 longer.

Post by **Ty Halderman** » Sun Oct 12, 2003 9:17 am

Demos are really a recording of what would be sent over the network during a net game (just keystrokes and mouse movements, and I suppose joystick if that's not recorded as mouse). Playback was trivial because it was like handling a one-person network game. There wasn't anything special about it being a demo, really, other than deep inside network code.

The sync problems always are because the engine playing the demo and the engine that recorded it don't agree on what happened next after one of those pseudo-network actions. Same as during a real network game when it goes out of sync. Difference is that in a demo it can even be the same machine on both ends of the demo and still lose sync. In DOOM (such as with the Revenant rocket in particular due to it being a random chance) it could get out of sync because of random number variations. We added a few things in Boom to help there (more rng values for various purposes, mostly), but it never was intended to handle different versions.

This is why Randy's statement ...is basically writing half of client/server Doom is because there isn't a demo per se--it's one-player network.

Hirogen2 · Post by **Hirogen2** » Sun Oct 12, 2003 10:12 am

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.