"Runworthiness" of the linuxdoom code?

fawtytoo said:

Why does Final Doom: Plutonia demo3 go out of sync?


I'd like to know that too ;-)

The only demos that Mocha Doom plays correctly -to my knowledge- are DEMO2, DEMO3 and DEMO4 from Ultimate Doom, and maybe one or two from TNT or Plutonia.

Considering how it's also a straight derivative of the linuxdoom code, perhaps what's plaguing you right now might help me understand what's going on in general.

However, there are significative differences between the .exes used in UDoom/Plutonia/TNT, enough to cause desync on their own (and they are not codified in the linuxdoom code. Hell, not even the Episode 4 switch textures are!)

Share this post


Link to post

I had the same issue with a port I made. I even had DEMO1 of DOOM2 de-syncing

Share this post


Link to post

I'd suggest first looking if these demos desync as well in PrBoom+ and/or Chocolate Doom (pretty sure they don't), then looking at the source code from these ports, grepping through them for compatibility code.

Share this post


Link to post

A lot of the basic sync fixes are from early PrBoom, so you could look through changes in that for some tips.

Share this post


Link to post
Maes said:

I'd like to know that too ;-)

The only demos that Mocha Doom plays correctly -to my knowledge- are DEMO2, DEMO3 and DEMO4 from Ultimate Doom, and maybe one or two from TNT or Plutonia.

Considering how it's also a straight derivative of the linuxdoom code, perhaps what's plaguing you right now might help me understand what's going on in general.

However, there are significative differences between the .exes used in UDoom/Plutonia/TNT, enough to cause desync on their own (and they are not codified in the linuxdoom code. Hell, not even the Episode 4 switch textures are!)

Only demo3 from Plutonia desync's with me. When I first compiled linuxdoom and enabled the demos, it's the only demo that had problems. Not sure why yours is worse.

Share this post


Link to post

It's also the only demo that gives me this error:

Sector with more than 20 adjoining sectors
... and quite few times before the games quits. And I mean it quits properly.
Related?

Share this post


Link to post
fawtytoo said:

It's also the only demo that gives me this error:

Sector with more than 20 adjoining sectors
... and quite few times before the games quits. And I mean it quits properly.
Related?

I found that problem, and seemingly unrelated.

Share this post


Link to post

YEAH I remember that error. Did vanilla final doom give off that same error?

Share this post


Link to post
Gez said:

I'd suggest first looking if these demos desync as well in PrBoom+ and/or Chocolate Doom (pretty sure they don't), then looking at the source code from these ports, grepping through them for compatibility code.

Already doing/did that. A lot to grep through. Neither CD or PrBoom have that problem, but comparing code with CD shows nothing obvious. It's strange how demo1 & demo2 are ok.

Share this post


Link to post

Demo sync is so bad on DoomLegacy that currently not even our own demo files will stay in sync. (Because I work on correcting demo play back, or in spite of it, I do not know anymore)
1. Errors are accumulative, the slightest bit difference eventually will be an effective disruption.
2. Random number generator
3. Extra uses of the random number generators.
4. Movement calculations, roundoff differences.
5. Application of friction.

The Demo file system is nearly useless across ports and needs to be
replaced with something that is robust. It is only the id games demos
and important WADS with demos that keep us trying to rescue this
system.

I have seriously been considering a self-correcting demo playback.
Of course this won't really work, but have been considering what
it would take.
1. Shooting: Player direction would be corrected for errors to hit the closest target.
2. Pushing a button or door would correct the player direction.
3. Dying in a demo would end the demo.
5. Allow user choice of raw demo or corrected demo playback.

Share this post


Link to post

I now have my own "maintained" version of LinuxDoom. It's not live yet as there's still plenty of stuff to fix. I'm also keeping it written in C.

I have 2 questions:

1. Currently, it uses an 8bit GC with an X window which requires dropping the display to 8bit also. What would be the "simplest" (for want of a word) way to have it display in 24bit? I tried a function to convert the colour indexes to 24bit colour using the palette. That worked, but only if you used the screen size multiplier (-2 -3 -4). At normal (320x200) size, some of the display was garbled (HUD, wipe).

2. How to deal with midi (or maybe audio in general)? I've dropped the sound server as it adds complications such as playing the correct sound from the correct wad. The internal sound seems to cope ok, albeit with a fast enough system. But I've not got any midi playback as yet.

I'm just looking for heaps of suggestions even if I have to write it myself.

Share this post


Link to post
wesleyjohnson said:

The Demo file system is nearly useless across ports and needs to be
replaced with something that is robust. It is only the id games demos
and important WADS with demos that keep us trying to rescue this
system.

I have seriously been considering a self-correcting demo playback.
Of course this won't really work, but have been considering what
it would take.
1. Shooting: Player direction would be corrected for errors to hit the closest target.
2. Pushing a button or door would correct the player direction.
3. Dying in a demo would end the demo.
5. Allow user choice of raw demo or corrected demo playback.

Option 3 here is viable and something I will implement. But what was option 4?

Share this post


Link to post
fawtytoo said:

I'm just looking for heaps of suggestions even if I have to write it myself.

Even if you don't want to use a recent version of Chocolate Doom you're probably still best off basing your code on a really old version - go back to something like v0.0.4 and you should get something with the basics fixed but still fairly close to the original linuxdoom code. If you don't want to even do that, you might find this helpful - it's the log of the first changes I made. Go through and cherry-pick the things you want for your own port.

If you want to do demo playback testing, you might want to look at statcheck, the automated testing system I wrote for Chocolate Doom that uses statdump.exe to compare the statistics output to the behavior from Vanilla Doom.

Share this post


Link to post

Cheers fraggle. I'm going to read your change logs. Weirdly though, demo3 of Plutonia now plays in sync. Not sure what I did, but the 2 changes I made since having that problem seem unrelated.

Share this post


Link to post
Gez said:

I'd suggest first looking if these demos desync as well in PrBoom+ and/or Chocolate Doom (pretty sure they don't), then looking at the source code from these ports, grepping through them for compatibility code.

I'm not convinced that compatibility is the cause.

I have a wad compiled using the Master Levels and included a demo lump for NESSUS. If I let the demo play normally as part of the Doom Loop, it goes out of sync. If I play the demo using -playdemo, it plays IN sync. If I have that demo as demo2 with another demo as demo1, the NESSUS demo is IN sync within Doom Loop too, but the other demo is... You get my drift.
This same scenario also goes out of sync with Chocolate Doom but IN sync with PrBoom.

I think it's more a question of timing.

Share this post


Link to post
fawtytoo said:

I'm not convinced that compatibility is the cause.

I have a wad compiled using the Master Levels and included a demo lump for NESSUS. If I let the demo play normally as part of the Doom Loop, it goes out of sync. If I play the demo using -playdemo, it plays IN sync. If I have that demo as demo2 with another demo as demo1, the NESSUS demo is IN sync within Doom Loop too, but the other demo is... You get my drift.
This same scenario also goes out of sync with Chocolate Doom but IN sync with PrBoom.

I think it's more a question of timing.

Because of the implementation of the revenant tracer code (and maybe other places, can't remember now), and it's dependence on gametic, your demos must be started at the proper gametic. That's why -playdemo works, but it fails in the demo loop. TITLEPIC timing is also an area to check, because it also affects gametic, as does the pause key. Boom was the first codebase to attempt to address these things. Look for 'basegametic' (SP?) in Boom source to see how to begin to solve these tricky issues.

Basically, the fix involves "tricking" the game engine, so it believes that each demo is starting at the proper gametic (170 tics for Doom titlepic, 385 for Doom II).

Share this post


Link to post
kb1 said:

Because of the implementation of the revenant tracer code (and maybe other places, can't remember now), and it's dependence on gametic, your demos must be started at the proper gametic. That's why -playdemo works, but it fails in the demo loop. TITLEPIC timing is also an area to check, because it also affects gametic, as does the pause key. Boom was the first codebase to attempt to address these things. Look for 'basegametic' (SP?) in Boom source to see how to begin to solve these tricky issues.

Basically, the fix involves "tricking" the game engine, so it believes that each demo is starting at the proper gametic (170 tics for Doom titlepic, 385 for Doom II).


The pagetic for TITLEPIC (Doom II) shows as TICRATE * 11 (35 * 11 = 385). After some trial and error TICRATE * 9 makes my Master Level demo run in sync perfectly (TICRATE * 1 also works).

Share this post


Link to post
fawtytoo said:

The pagetic for TITLEPIC (Doom II) shows as TICRATE * 11 (35 * 11 = 385). After some trial and error TICRATE * 9 makes my Master Level demo run in sync perfectly (TICRATE * 1 also works).

Heh, try (TICRATE * 9) - 4 and see if that stays in sync too.

Share this post


Link to post

fawtytwo, I have some really good system interface code with X11 and some midi playing code that I never really did test due to the failures of my system. If you would like I could send it to you... The only difference being that it was written for Hexen, but it is otherwise compatible

Share this post


Link to post
kb1 said:

Heh, try (TICRATE * 9) - 4 and see if that stays in sync too.

In fact, the only ones that work are 1, 5, 9, 13, & 17. There is a definite pattern there.

Share this post


Link to post

The revenant tracer code is basically dependent on gametic%4. See explanation here; this page is valid for vanilla too.

Share this post


Link to post
fawtytoo said:

In fact, the only ones that work are 1, 5, 9, 13, & 17. There is a definite pattern there.

Yep, as Gez says. So, back to the TITLEPIC thing, that timing has to be done correctly. Make sure you're detecting Doom vs. Doom II TITLEPIC timing, as it sounds like you've got them reversed. That would explain why -playdemo works, but waiting for the demo at startup does not. Can't remember now, but I recall that there was something flakey about the code that made it get the TITLEPIC timing wrong in a lot of cases. Hope that helps.

Share this post


Link to post
fraggle said:

If you want to do demo playback testing, you might want to look at statcheck, the automated testing system I wrote for Chocolate Doom that uses statdump.exe to compare the statistics output to the behavior from Vanilla Doom.

Is there a Linux version? I don't use Windows.

Share this post


Link to post

It's not a Windows program, it's a DOS one intended to be used in conjunction with vanilla Doom. You can run it inside DOSBox.

Share this post


Link to post
chungy said:

It's not a Windows program, it's a DOS one intended to be used in conjunction with vanilla Doom. You can run it inside DOSBox.

But I can't run my port in DOSBox. I've written it for Linux.

Although, thinking about it, I could write my own seeing as I program.

I guess -statcopy is passed a memory location where the stats will be copied to. Yes?

Share this post


Link to post

In the code, Plutonia & TNT are only referred to twice: for map name strings & title name strings. Are there any differences between Doom2 and Final Doom in the game engine?

Share this post


Link to post
fawtytoo said:

In the code, Plutonia & TNT are only referred to twice: for map name strings & title name strings. Are there any differences between Doom2 and Final Doom in the game engine?


Except for Lost Soul bounciness it quasi identical as far as I "know".

p.s.: forgot about the teleport behavior being different.

Share this post


Link to post
_bruce_ said:

Except for Lost Soul bounciness it quasi identical as far as I "know".

p.s.: forgot about the teleport behavior being different.

The Lost Souls behaviour was fixed in the released code.

But otherwise these are both bugs/errors and not differences, that is, not intentional.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now