Doom v0.99 demo support. #1207

SmileTheory · 2019-10-19T12:18:57Z

This one is like #1205 , but for v0.99.

Note that v1.1 demos very much don't work.

Yet.

fabiangreffrath

Impressive! Where did you get all this from?

SmileTheory · 2019-10-19T23:09:25Z

A decompiler (http://derevenets.com/ ), a hex editor, a memory dump from dosbox, and a whole lot of reading and comparing code. :)

fabiangreffrath

Have these probably been float value in v1.0? I find the 900 denominator a bit irritating.

SmileTheory · 2019-10-20T09:36:32Z

Without the 900 denominator they're the exact values, pulled straight out of my memory dump from dosbox, no floats involved.

If you used them directly, they'd be encoded inaccurately when recording a demo. The original 1.0/1.1 divided movement values by 900 when writing a demo and multiplied by 900 when reading them.

To be honest I haven't actually tested recording demos, though.

SmileTheory · 2019-10-21T08:23:27Z

Bleh, I managed to record a v1.0 video that plays out differently in the original exe and in chocolate doom.

Attached, also still trying to figure out why that imp at the end moves differently.

1.zip

SmileTheory · 2019-10-21T10:10:05Z

fa7bcca appears to fix the demo.

Also fix a comment.

fabiangreffrath · 2019-10-29T10:35:14Z

src/doom/d_main.c

+                gameversion = exe_doom_1_1;
+
+                // detect v1.0 from length of demo1 lump
+                if (demo1 && W_LumpLength(demo1) < 10 * 1024)


This should probably be if (demo1 > -1

Fixed in fb10e90 .

src/doom/d_main.c

Using smaller delta tables instead of huge full-sized ones

fabiangreffrath · 2019-10-30T08:09:22Z

src/doom/d_main.c

@@ -1094,7 +1094,7 @@ static void InitGameVersion(void)
                gameversion = exe_doom_1_1;

                // detect v1.0 from length of demo1 lump
-                if (demo1 && W_LumpLength(demo1) < 10 * 1024)
+                if (demo1 > -1 && W_LumpLength(demo1) < 10 * 1024)


As the checks in InitGameVersion() become more and more complex, we should probably consider moving all this away from doom/d_main.c into a separate file?

Yes, +1 on this. This is my main beef with this PR as it currently stands.

The changes necessary to support v1.0 can be broadly categorized as follows:

Patch some of the normal tables and constants to match v1.0.

Change some of the game logic to match v1.0 (with if (gameversion...) {...}

The problem with (2) is that it can introduce a lot of complexity to the code if we're not careful. So we should try to avoid doing this as much as possible. What can be rearchitected here to put things into the (1) category instead of (2)? Try to get as few new if statements as possible.

My immediate suggestions for how to proceed on this PR are as follows:

Make a new file - maybe named something like d_oldversion.c - and try to isolate as much as possible to that file. That includes the "Version-specific differences" switch statement below, and the alternative versions of the trig tables, so we move those out of tables.c.

It should be possible to patch the forwardmove[] and sidemove[] tables from the new file too, so we avoid adding that complexity.

Define new functions named eg. D_CoarserSine and D_CoarserCosine that will either look up into the coarsesine[] table or the finesine[] table depending on the version.

Done in d8f6bcf .

SmileTheory · 2019-10-30T09:49:58Z

As an aside, I figured out how the various trig tables are calculated for Doom v1.0 and versions after, and put code for them into https://gist.github.com/SmileTheory/02e6a13bc615efa3b6c31decc0ea049a .

fragglet · 2019-11-03T20:45:13Z

src/d_mode.h

@@ -56,7 +56,9 @@ typedef enum

 typedef enum
 {
-    exe_doom_1_2,    // Doom 1.2: shareware and registered
+    exe_doom_1_0,    // Doom 1.0: shareware


As mentioned in previous PR - this probably affects network protocol compatibility. That doesn't mean I'm against merging this PR, but we probably need to "fork" this enum into a separate net_game_version_t that will preserve the ordering.

Done in d8f6bcf .

fragglet · 2019-11-03T20:48:39Z

src/doom/d_main.c

+                gameversion = exe_doom_1_1;
+
+                // detect v1.0 from length of demo1 lump
+                if (demo1 > -1 && W_LumpLength(demo1) < 10 * 1024)


The comparison here (length < 10 * 1024) seems oddly magic. I'd be in favour of making this more specific: can we do this based on a SHA1 hash of the demo contents for example? w_checksum.c already has some code for checksumming lumps.

Done in d8f6bcf .

fragglet · 2019-11-03T20:52:03Z

src/tables.c

@@ -2225,3 +2233,192 @@ const byte gammatable[5][256] =
    }
 };

+const fixed_t coarsesine[320] =


This means the tables will be included in all games, not just the chocolate-doom binary.

Moved into d_compat.c in d8f6bcf .

fragglet · 2019-11-03T20:53:12Z

src/doom/d_main.c

+                if (demo1 > -1 && W_LumpLength(demo1) < 10 * 1024)
+                    gameversion = exe_doom_1_0;
+            }
+


Please remove spurious whitespace.

Removed in d8f6bcf .

fragglet · 2019-11-03T21:00:25Z

src/doom/d_main.c

+            mobjinfo[MT_MISC7].flags &= ~MF_NOTDMATCH;
+            mobjinfo[MT_MISC8].flags &= ~MF_NOTDMATCH;
+            mobjinfo[MT_MISC9].flags &= ~MF_NOTDMATCH;
+


Where a switch() {...} fallthrough is intentional, please add a comment that says something like // fallthrough - otherwise this looks like a mistake.

Moved to d_compat.c and changed in d8f6bcf .

fragglet · 2019-11-03T21:04:07Z

src/tables.c

+    for (i = 0; i < 66; i += 2)
+        finesine1_2[finesineto1_0[i]] += finesineto1_0[i+1];
+
+    for(i = 0, j = 0, count = 1; count; j += count)


Some of the formatting here is sloppy. Please try to match the style described in HACKING and please also don't introduce new tab characters.

Done in d8f6bcf .

fragglet · 2019-11-03T21:11:03Z

src/tables.c

+const fixed_t *coarsecosine = &coarsesine[64];
+
+const short finesineto1_0[] = {
+    455,-1,1080,-1,2268,1,3212,-1,3324,-1,3640,-1,3822,1,4147,1,


Would this be better expressed as something like this?

const struct { unsigned short index; short value; } finesine_to_1_0[] = { {455, -1}, .... };

Done in d8f6bcf .

fragglet · 2019-11-03T21:15:51Z

src/doom/d_main.c

@@ -1094,7 +1094,7 @@ static void InitGameVersion(void)
                gameversion = exe_doom_1_1;

                // detect v1.0 from length of demo1 lump
-                if (demo1 && W_LumpLength(demo1) < 10 * 1024)
+                if (demo1 > -1 && W_LumpLength(demo1) < 10 * 1024)


Yes, +1 on this. This is my main beef with this PR as it currently stands.

The changes necessary to support v1.0 can be broadly categorized as follows:

Patch some of the normal tables and constants to match v1.0.

Change some of the game logic to match v1.0 (with if (gameversion...) {...}

The problem with (2) is that it can introduce a lot of complexity to the code if we're not careful. So we should try to avoid doing this as much as possible. What can be rearchitected here to put things into the (1) category instead of (2)? Try to get as few new if statements as possible.

My immediate suggestions for how to proceed on this PR are as follows:

Make a new file - maybe named something like d_oldversion.c - and try to isolate as much as possible to that file. That includes the "Version-specific differences" switch statement below, and the alternative versions of the trig tables, so we move those out of tables.c.

It should be possible to patch the forwardmove[] and sidemove[] tables from the new file too, so we avoid adding that complexity.

Define new functions named eg. D_CoarserSine and D_CoarserCosine that will either look up into the coarsesine[] table or the finesine[] table depending on the version.

drfrag666 · 2019-11-04T11:27:06Z

"In versions of Doom 1.2 and earlier, armor percentage was not limited to 200."
https://doomwiki.org/wiki/Armor_percentage_rollover

SmileTheory · 2019-11-04T14:29:42Z

"In versions of Doom 1.2 and earlier, armor percentage was not limited to 200."
https://doomwiki.org/wiki/Armor_percentage_rollover

This was in the old pull request:

9eae89d#diff-79f9cf84b40c123971d3775511e0a3e3R385

If that's too hard to read, here's a comment:

0e72254#diff-79f9cf84b40c123971d3775511e0a3e3R385

drfrag666 · 2019-11-04T15:38:38Z

Someone commented it at doomworld and i was not aware it was already in.

drfrag666 · 2019-11-24T13:47:48Z

Are 1.1 demos supported already?

SmileTheory · 2019-11-25T08:36:18Z

Are 1.1 demos supported already?

The demos in the Doom 1.1 shareware wad work, but beyond that I haven't tested too much.

SmileTheory · 2019-11-26T14:14:25Z

Are 1.1 demos supported already?

The demos in the Doom 1.1 shareware wad work, but beyond that I haven't tested too much.

Only in Shareware? They don't work in the registered/full version?

In 1.1 registered, DEMO1 and DEMO2 work, but DEMO3 desynchs a bit after getting the chainsaw.

It doesn't seem chainsaw related though, comparing with the original 1.1 exe shows that the cacos on the left are in slightly different positions, and the lost soul that actually causes the desynch takes a few tics longer to attack on the 1.1 exe than with this patch.

I've been investigating this for a while but I haven't been able to figure it out yet.

Fixes Doom 1.1 registered DEMO3.

drfrag666 · 2019-11-27T12:49:59Z

You rule! :)

SmileTheory · 2019-11-27T13:58:49Z

"Wallrunning doesn't work in Doom v1.1 (North-South and East-West walls), except for some diagonal walls for which it's the same as Doom v1.9."

I'd guess that this is a consequence of the half step movement code not being implemented until Doom v1.2. (https://github.com/chocolate-doom/chocolate-doom/pull/1207/files#diff-9b3d1e95726cd7eaef62f94a3d6caf92R158 )

More info at https://doomwiki.org/wiki/Wallrunning#Technical .

drfrag666 · 2019-12-02T14:47:30Z

Okay i've merged this and done some testing. For me it's broken after "Requested changes". You can't start a new game until the first demo plays, the game quits inmediately or after the wipe hence you can't play demo2 or demo3 with playdemo. Besides after the demo ends the wipe is shown twice.
That is with the 1.1 iwad. Does it work for you?

SmileTheory · 2019-12-02T20:37:54Z

Okay i've merged this and done some testing. For me it's broken after "Requested changes". You can't start a new game until the first demo plays, the game quits inmediately or after the wipe hence you can't play demo2 or demo3 with playdemo. Besides after the demo ends the wipe is shown twice.
That is with the 1.1 iwad. Does it work for you?

It works fine with 1.1 registered and 1.1 shareware for me. Leaving it to run moves on to demo2 as normal instead of quitting, and I can start a game at any point.

Are you using cmake to build? I haven't tested cmake since I can never get the thing to work properly. :)

Otherwise, did the branch merge cleanly? The only other thing I can think of is some conflict, unless you're using a clean version of chocolate doom.

drfrag666 · 2019-12-02T22:50:16Z

Sorry, it was a bad merge of "Fix inaccurate v1.0/v1.1/v1.2 sight calculations". Now it works, BTW i've lost my internet connection.

drfrag666 · 2019-12-04T13:43:04Z

I've released a test build with this PR in order to help with old demos here:
https://github.com/drfrag666/chocolate-doom/releases/tag/2.5.0a

chocolate-doom#1223

drfrag666 · 2019-12-07T10:34:39Z

Uploaded another test build with the latest changes:
https://github.com/drfrag666/chocolate-doom/releases/download/2.5.0b/RUDE-2.5.0b-win32.zip

tpoppins · 2019-12-14T18:39:18Z

Thank you for the test build, Dr. Frag666!

Here is a set of demos recorded on E2 and E3 of the registered v1.1 in February-March '94: VDOOM2_3.ZIP. It doesn't include a demo for E3M9, and the E3M6 one terminates prematurely due to reaching the default demo size. Of the other 16 demos all but three play to the end with RUDE v2.5.0b.

The desyncing demos are those for E3M1, E3M5 and E3M7. Vanilla v1.1 plays these successfully (i.e. the player reaches the exit and exits the level).

This set should provide some extra testing material.

drfrag666 · 2019-12-14T19:49:19Z

Thanks. These are useful. E3M1 desyncs becouse the door-lift closes too early. E3M5 becouse the bfg doesn't kill a demon near the end. E3M7 becouse the bridge is missing apparently. We'll know more when SmileTheory tries them with his build.

This fixes http://cd.textfiles.com/ccbcurrsh2/DOOM/VDOOM2_3.ZIP 3_1.LMP

This fixes http://cd.textfiles.com/ccbcurrsh2/DOOM/VDOOM2_3.ZIP 3_7.LMP

This fixes http://cd.textfiles.com/ccbcurrsh2/DOOM/VDOOM2_3.ZIP 3_5.LMP

drfrag666 · 2019-12-17T11:48:02Z

I've released a new test build with the latest changes.
https://github.com/drfrag666/chocolate-doom/releases/tag/2.5.0c

tpoppins · 2019-12-17T20:10:30Z

Good job, SmileTheory: all three demos mentioned above complete successfully now in RUDE Doom 2.5.0c!

@drfrag666: thank you for the bins. Would you email me (tpoppins at juno dot com) please, I can't compile your fork in either CodeBlocks or MSYS2.

drfrag666 · 2019-12-18T12:55:12Z

I've enabled issues, post your problem there and i'll reply ASAP.

drfrag666 · 2020-02-03T20:27:47Z

Any issue left here?

tpoppins · 2022-11-16T20:37:30Z

Yes, there are still a few issues.

"-fast" should be disabled for v1.2 and older because "-fast" was first introduced in v1.4 beta leak (Apr 8 1994). I just submitted a PR that corrects this. Note to self: Prboom-plus incorrectly allows fast monsters with v1.2 compat as well, subject to another PR.
Additionally, there are no "-respawn" and "-nomonsters" in versions 0.99/1.0 and 1.1.
Support for forcing "-respawn" and "-nomonsters" on command line for playback of v1.2 demos is missing. That should be fixed by another PR I just submitted.
The biggest issue for last: not all plats stayed active in v1.2 and older. Apparently it's wrong to lump together raiseAndChange and raiseToNearestAndChange as commit 3fe7123 does.

The following demo on ANTHELL4, recorded with vanilla v1.2, desyncs in the latest RUDE (which incorporates the changes from that commit) because of that.
ANTHELL4-v12-test.zip

Linedef 898 has action special 67 (SR Floor Raise by 32 and Change), which is raiseAndChange. In vanilla v1.2 (and v1.1 and v1.9u) you can activate this switch multiple times; with that commit applied - only once. Separating the raiseAndChange case like this:

		  case raiseAndChange:
	        P_RemoveActivePlat(plat);
		    break;

allows the demo to play back correctly to the end. Latest Choco autobuild plays back the demo properly since it doesn't incorporate that commit's changes.

And then there's that issue with CHURCH.WAD mentioned above.

tpoppins · 2022-12-23T10:46:37Z

The CHURCH.WAD internal demo desync's cause has been identified: sector special 17 (random flicker) was not a valid special until the official v1.4 beta.

Meanwhile, a v0.99/1.0 demo that desyncs with this PR has been found: LEVEL7.LMP in DOOMLVL7.ZIP.

It's a 11:49 UV demo of the IWAD E1M7 that plays back properly to the exit in vanilla. The desync becomes evident around 3:20-3:25. In case it could be relevant, there's a three-second pause at 2:35; removing it doesn't make a difference.

edit: removing the pause (manually, or with LMPCm) makes vanilla desync the same way at the same spot. Some more experimenting followed:

recorded a UV Max in vanilla without using pause and it played back fine in my Choco
did same thing, this time pausing briefly after taking the yellow key, and the demo desyncs in Choco before you get to the red key
same issue with v1.1
unable to reproduce in v1.2

So using pause during recording is definitely a factor.

Doom v0.99 demo support.

1a1d2ac

fabiangreffrath reviewed Oct 19, 2019

View reviewed changes

Doom v1.1 demo support.

b47d8f9

Use more accurate movement values in Doom 1.0 mode

2050234

fabiangreffrath reviewed Oct 20, 2019

View reviewed changes

Replace all trig tables in Doom 1.0 mode.

fa7bcca

SmileTheory added 5 commits October 22, 2019 02:39

Add Doom 1.0/1.1 to valid_versions.

e04afa2

Also fix a comment.

Clean up and add version-specific differences

a65b3fb

Remove duplicate version difference.

26ba1f6

Powerups and boss spider not fullbright in v1.2

d11e221

Doom 1.2 and below have 199 max health

4b8218c

fabiangreffrath reviewed Oct 29, 2019

View reviewed changes

src/doom/d_main.c Outdated Show resolved Hide resolved

SmileTheory added 2 commits October 29, 2019 11:21

Alter trig tables in-place for Doom v1.0

bd44f7d

Using smaller delta tables instead of huge full-sized ones

Fix demo1 check

fb10e90

fabiangreffrath reviewed Oct 30, 2019

View reviewed changes

SmileTheory added 2 commits November 1, 2019 22:48

Comments for some gameversion differences

0e72254

Disable nightmare difficulty in Doom v1.0/v1.1

adb1c30

fragglet requested changes Nov 3, 2019

View reviewed changes

SmileTheory added 2 commits November 3, 2019 23:42

Requested changes.

d8f6bcf

Replace coarse functions with pointers to arrays

eb1e1bb

Cleanup and refactoring.

d039813

Fix Doom v1.0 weapon bob

eac9066

SmileTheory requested a review from fragglet November 20, 2019 09:49

Fix inaccurate v1.0/v1.1/v1.2 sight calculations.

eebc685

Fixes Doom 1.1 registered DEMO3.

Emulate buggy P_FindNextHighestFloor() in <= v1.2

5b4f916

chocolate-doom#1223

SmileTheory added 3 commits December 15, 2019 00:05

Emulate pre-v1.25 lowerAndChange behavior.

046ae69

This fixes http://cd.textfiles.com/ccbcurrsh2/DOOM/VDOOM2_3.ZIP 3_1.LMP

Emulate pre-v1.25 always active plats.

3fe7123

This fixes http://cd.textfiles.com/ccbcurrsh2/DOOM/VDOOM2_3.ZIP 3_7.LMP

Emulate pre-v1.2 teleports.

832fe9b

This fixes http://cd.textfiles.com/ccbcurrsh2/DOOM/VDOOM2_3.ZIP 3_5.LMP

Moving floors don't make stop sounds in v1.2

ea3b89b

tpoppins mentioned this pull request Dec 18, 2019

v1.2 compat incomplete coelckers/prboom-plus#32

Closed

This was referenced Dec 24, 2021

Desync on JCM2-16 E2M8 v1.2 demo coelckers/prboom-plus#441

Closed

Do not remove active plats in v1.2 compat coelckers/prboom-plus#442

Closed

tpoppins mentioned this pull request Oct 29, 2022

v1.2 DEMO1@CHURCH.WAD desync #1529

Closed

Doom v0.99 demo support. #1207

Are you sure you want to change the base?

Doom v0.99 demo support. #1207

Conversation

SmileTheory commented Oct 19, 2019

fabiangreffrath left a comment

Choose a reason for hiding this comment

SmileTheory commented Oct 19, 2019

fabiangreffrath left a comment

Choose a reason for hiding this comment

SmileTheory commented Oct 20, 2019

SmileTheory commented Oct 21, 2019

SmileTheory commented Oct 21, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fragglet Nov 3, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SmileTheory commented Oct 30, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fragglet Nov 3, 2019 • edited

Choose a reason for hiding this comment

drfrag666 commented Nov 4, 2019

SmileTheory commented Nov 4, 2019

drfrag666 commented Nov 4, 2019

drfrag666 commented Nov 24, 2019

SmileTheory commented Nov 25, 2019

SmileTheory commented Nov 26, 2019 • edited

drfrag666 commented Nov 27, 2019

SmileTheory commented Nov 27, 2019

drfrag666 commented Dec 2, 2019

SmileTheory commented Dec 2, 2019

drfrag666 commented Dec 2, 2019

drfrag666 commented Dec 4, 2019

drfrag666 commented Dec 7, 2019

tpoppins commented Dec 14, 2019

drfrag666 commented Dec 14, 2019

drfrag666 commented Dec 17, 2019

tpoppins commented Dec 17, 2019

drfrag666 commented Dec 18, 2019

drfrag666 commented Feb 3, 2020

tpoppins commented Nov 16, 2022 • edited

tpoppins commented Dec 23, 2022 • edited

fragglet Nov 3, 2019 •

edited

fragglet Nov 3, 2019 •

edited

SmileTheory commented Nov 26, 2019 •

edited

tpoppins commented Nov 16, 2022 •

edited

tpoppins commented Dec 23, 2022 •

edited