[ixfd64]

In vanilla Duke Nukem 3D, there are official demos that play after the game loads.

However, the demos do not play in EDuke32 for me. I've seen a few video of other people using EDuke32, and the demos don't load in those either. So are the original demos incompatible with this source port? If not, how do I enable the demos?

Thanks.

[Lunick]

Each demo is made for a specific version of the game in mind. You'd only be able to play those demos through the original exes in DOSBox I suppose.

[Micky C]

You'd think eduke32, being a port, would strive to support everything the original game supports. Why aren't the original demos compatible?

[Lunick]

Micky C, on 15 April 2014 - 08:42 PM, said:

You'd think eduke32, being a port, would strive to support everything the original game supports. Why aren't the original demos compatible?

1.3d demos are not compatible with 1.4 or 1.5 versions of the game. It's just how the engine works.

[Plagman]

More importantly, I believe 1.5 demos from the original DOS release never replayed properly with builds from the 2003 source code release.

[MusicallyInspired]

That's because the source code is based on 1.4, right? I thought I read somewhere that the 1.5 source was unavailable.

[t800]

Hmm, but then what about source port Rancidmeat - Duke3d_w32 and its derivatives (surely well known to modern dukematchers) xDuke and hDuke? I tried them only with full Atomic version of DUKE3D.GRP but in-built demos played back fine for me. So maybe problem isnt source code? But in my mind I dont mind it that much, for me Eduke32 is sort of parallel to ZDoom among Doom source ports.

[Hendricks266]

The v1.5 demos play in xDuke but they go out of sync. The player dies during them which isn't supposed to happen.

The v1.4 demos also play, and they don't go out of sync as far as I could see.

[Danukem]

Would it be a good idea to make new demos that were included with EDuke32?

[Hendricks266]

No, because our demos use a completely different format based on savegames.

I would rather put work into bringing back the original demos. Maybe it would only take a little REing of the the 1.5 EXE to find the difference.

[Danukem]

Hendricks266, on 16 April 2014 - 12:31 PM, said:

No, because our demos use a completely different format based on savegames.

So we have a shitty format? I don't see the problem.

[Hendricks266]

The original format was the shitty one: just input logs that recreate the game. Our format uses proper deltas that save the actual game state.

[ixfd64]

I figured the demos somehow weren't compatible with EDuke32. I'm glad it wasn't a misconfiguration on my part.

[Helixhorned]

It's not just about the format but about assuring determinism. As mentioned, the original demo format is just a sequence of input events. Basically, even minor differences between code that got executed when the demo was made and the program playing it back can lead to a desync in that setting. And well, EDuke32 has accumulated a lot of differences. Starting with the fact that the the krand() pseudo-random generator (which is a linear congruental generator) uses different values, for example...
Bottom line: reproducing Duke3D 1.5 demos is infeasible without a lot of archaeological work.

[Fox]

Hendricks266, on 16 April 2014 - 08:58 AM, said:

The v1.5 demos play in xDuke but they go out of sync. The player dies during them which isn't supposed to happen.

While it's far from being ideal, it wouldn't be so bad if Eduke32 could read the "input logs" from v1.4 or v1.5 demos.

[The Commander]

Hendricks266, on 16 April 2014 - 01:53 PM, said:

The original format was the shitty one: just input logs that recreate the game. Our format uses proper deltas that save the actual game state.

I believe what Hendricks is saying is that in the old version of Duke, if you edited the of map E1L1 to block off the vent on the roof, the player would end up running around the roof top like an idiot.
Where as in eduke it would use the data from a save state which would also include the map.
At least this is the way I interpreted it and it would make sense if the data included the map so that you could share the demo files even easier without needing the original map.

[Helixhorned]

Fox, on 17 April 2014 - 02:43 PM, said:

While it's far from being ideal, it wouldn't be so bad if Eduke32 could read the "input logs" from v1.4 or v1.5 demos.

Please read what I said above (emphasis added):

Quote

Basically, even minor differences between code that got executed when the demo was made and the program playing it back can lead to a desync in that setting.

"Code" here refers to that which is significant for the evolution of the game state. This includes C and CON game logic, as well as engine functions such as those effecting movement of an object.

Attempting to make Duke3D 1.5 demos run properly[*] under EDuke32 would require an overwhelming amount of mostly boring work, basically tracking down every difference that has the potential to alter game state evolution. The result would not be pretty.
[*] meaning, not desyncing after the first seconds of playback. Surely you wouldn't care for such an "input log reading" functionality, would you?

The Commander, on 18 April 2014 - 01:11 AM, said:

At least this is the way I interpreted it and it would make sense if the data included the map so that you could share the demo files even easier without needing the original map.

This is pretty much what EDuke32's demo format does. In fact, it primarily is a savegame: you can rename a demo to *.esv and load it just fine. Besides the initial state, the modern demo format can record diffs of that state at constant intervals (such as every 30th tic), which can be re-applied at playback time to combat minor cases of desync.

[Chris12]

If you make an eduke demo, will the demo play automatically when you leave the game idle?

[Danukem]

So I guess the reason for not including demos in the new format with EDukee32 is that the files are too big (since they are essentially save game files)?

[Fox]

I think it's because it can only be used in the version it was recorded with.

[Helixhorned]

Chris12, on 18 April 2014 - 06:00 AM, said:

If you make an eduke demo, will the demo play automatically when you leave the game idle?

I'm not sure I understand the question. When you leave a started game idle, Duke will crack his knuckles at certain intervals and say "What are you waiting for, christmas?".

Trooper Dan, on 18 April 2014 - 07:22 AM, said:

So I guess the reason for not including demos in the new format with EDukee32 is that the files are too big (since they are essentially save game files)?

Distribution-wise, yes, I think packaging recorded demos with EDuke32 wouldn't be a good idea; that's not in the scope of the project and they would have to be updated from time to time. There are two reasons demos become unplayable with time. One is the mentioned code changes which make playback degrade incrementally and may desync a demo "catastrophically" when not "nudged into place" again by applying the diffs. The other is that occasionally, C structures that are also written to disk change, and as a consequence old savegames/demos become unreadable unless conversion functionality were to be written. (Not worth the effort, IMO.)

[TheZombieKiller]

Would it be possible that you could get all the old demos working and then record to the EDuke32 format while the demo is running?
For example you could import EDuke32's recording code into an older version of the engine and ultimately convert the demos.

[Helixhorned]

TheZombieKiller, on 18 April 2014 - 11:59 PM, said:

Would it be possible that you could get all the old demos working and then record to the EDuke32 format while the demo is running?

This amounts to the same thing as playing back the old demos on EDuke32. They would desync badly in a matter of seconds to minutes.

Quote

For example you could import EDuke32's recording code into an older version of the engine and ultimately convert the demos.

I doubt anyone has the motivation to backport modern code into ancient EDuke32 versions, sorry.

Again: the hard part is not the format. It's the fact that minor discrepancies between the game state evolution in the recorded game and played back demo can have an "avalanche" effect rendering all playback from the first desync nonsensical.