PrBoom-Plus, ver. 2.5.1.4

[Quasar]

Umm. You want to support vanilla DOOM demos right? Those are the only ones that suffer from spechits overflows. Vanilla DOOM is a DOS program. The deal is, you cannot tell what OS somebody was running when they recorded the demo. Assuming one way or the other may be wrong.

My point was that the OS the *user watching the demo playback* is using shouldn't make a lick of difference, right? If you disagree, please explain why watching the demo under different OSes would need different values for the magic number. People in this thread seem to be suggesting stuff like this, and it makes no sense. That's what I meant by voodoo. You can't rely on that, only on logic.

[entryway]

Quasar said:

If you disagree, please explain why watching the demo under different OSes would need different values for the magic number.

It not so. PrBoom-Plus behaves equally on any systems of course, but vanilla behaves ambiguously and I should choose priority system.

EDIT: You have two demos. The first one works correctly with DOOM2.EXE only from DOS, the second one - only from Windows. Only the second should work correctly with PrBoom-Plus without -spechit X param

[RjY]

Quasar said:

please explain why watching the demo under different OSes would need different values for the magic number

Isn't the magic number a constant for a given demo, depending only on the OS on which the demo is recorded? As opposed to the OS on which the demo is being watched.

(In fact, isn't it just the value of the pointer (line_t *)lines when the demo was recorded?)

[entryway]

RjY said:

Isn't the magic number a constant for a given demo, depending only on the OS on which the demo is recorded? As opposed to the OS on which the demo is being watched.

Yes, but the buffer is overflowed at viewing too (in vanilla), therefore the demos can be played differently on different OS (on identical too, but with much smaller probability)

(In fact, isn't it just the value of the pointer (line_t *)lines when the demo was recorded?)

Yes, but there is no dependence on exact value. Overflow changes the tmbbox variable.

[Quasar]

tmbbox affects clipping operations on the current object being clipped, however, so it is possible under just the right circumstances that the exact value in it does matter. If there are still any demos that can't be made to sync with the spechits emulation, this could have something to do with it.

Of course, you have to keep this in mind: tmbbox does not store raw fixed-point coordinates. It stores blockmap indices, and so any pointer value written into tmbbox will, 99% of the time, be out of range. This means that the ultimate effect would be to totally cancel the current clipping operation (the engine does tight range-checking on all blockmap indices). This *may* be why it doesn't seem to matter in some cases.

Anyways I hope that you haven't been reading me wrong. I encourage you to keep working on this and make it great, I'm just concerned when people come in here and rattle off weird stuff that doesn't make sense to me. We just have to make sure that metaphysical ideas are not implemented into the code :)

Rest assured that when I get the chance, I will be making sweeps of the various PrBoom versions to try to catch compatibility fixes that I don't have yet. You seem to think that I don't care about it when in fact I do and always have. My attention has just been focused elsewhere for a time.

[myk]

Quasar said:
The deal is, you cannot tell what OS somebody was running when they recorded the demo. Assuming one way or the other may be wrong.

That's what most of this testing is about, and we're using Windows 98 to narrow it down. None of us are using DOS proper (v5.0, etc.), so pure DOS overflows can't be guaranteed to be supported to a high degree (at least currently). But fully supporting Windows 9x demos should be important because tons of demos were recorded like that (it's been possible for 11 years or so), and some DOOM demo recording fans still do it today anyway (even if anyone thinks we are insane).

If there are still any demos that can't be made to sync with the spechits emulation, this could have something to do with it.

It's hard to say if in any demos the value would be very exact, but in one tough example, HR2 beta Map32, there was an issue with a line causing desynchs, in addition to a spechit overflow. So in some cases continued desynchs could also depend on other factors.

[entryway]

http://sourceforge.net/projects/prboom-plus/

2.4.6.1

[!] Updated to the latest prboom 2.4.6 (SVN build).
[+] Mac specific: OpenGL version is available for Mac too.
[+] Holding down SHIFT during start-up to bring the launcher up even if you disable it in settings.
[+] Option to disable "doubleclick as use" behaviour.
[+] Option "Max View Pitch" for restriction of the maximal looking up/down angle. (0-90)
[+] [-spechit X] command-line switch allows the user to provide a spechits magic number, overriding the program's default value.
[+] Compatibility with common mapping errors: "Pad a too short reject with zeros".
[+] Autodetect of unconverted tasdoom.exe demos.
[+] Options for showing progress bar during demo playback and demotime/totaldemotime style as alternative.
[+] New Screen Multiple system (like in chocolate-doom) and Interlaced Scanning for this. (emulators and TV style)
[+] New [-videodriver name] command-line switch (sdl_videodriver variable in config) for setting up the videodriver name that SDL will use. The "windib" video driver is the default now, to prevent problems with certain laptops, 64-bit Windows, and Windows Vista. The "directx" video driver is forced by PrBoom-Plus only for software rendering on Win9x systems to prevent some problems on out-of-date systems. Also, you can use the "default" value to force PrBoom-Plus behavior by default.
[+] Possibility to enable/disable the Launcher from its window.
[+] Launcher: iwads are now shown in the files list so that they can be used as pwads

POSIX specific: Name of the dot directory was changed from .prboom+ to .prboom-plus

Default key for taking over the controls with resume recording feature is changed to 'q'. Default key for switching between chasecam/walkcam/normal views is changed to 'KeyPad0'.

[-playdemo demo -warp X -skipsec Y] will skip Y seconds on X level.

Reconfigurations in settings. Most of the PrBoom-Plus settings are moved to General.

Config entry for "uncapped framerate" is renamed from "movement_smooth" to "uncapped_framerate" as in upcoming PrBoom.

[-net1] command-line option renamed to [-solo-net] as in PrBoom.

Uncapped framerate: speed update up for HUD on slow systems.

Forcing "directx" video driver for software rendering in Win9x.

Alt mouse handling: Do not grab mouse if the application has no keyboard focus.

Alt mouse handling: Disabled for win9x at full screen modes.

Alt mouse handling: reconfigured as a "Mouse handling" option, with the name "Win32". The relevant config variable is "mouse_handler" (0=SDL; 1=Win32).
[-] Mac specific: Mouse did not work with "alt mouse handling". Disable this feature for non-windows platforms.
[-] Fix a crash after pressing the walkcam key at the intermission screen, the game final animation, or a demo.
[-] IDRATE cheat shows correct FPS with uncapped framerate.
[-] Fix for incorrect chasecam/walkcam sight after loading of the next level.
[-] Fixed crash with newest sdl_mixer.dll after skipping level during playdemo.
[-] GLBoom: Correction of display (HOM) of the textures with holes (MIDBARSX, MIDGRATES, etc.) on one-side walls in OpenGL. fenris.wad is an example.
[-] PrBoom bug: Fixed crash with zero-size BLOCKMAP lumps.
[-] PrBoom bug: Fix compatibility issue with building stairs. There is no more desync on icarus.wad/ic29uv.lmp
[-] PrBoom bug: Fix a compatibility issue that was introduced by Lee Killough a long time ago. There is no more synch :) on dv.wad/dv04-423.lmp. Added switch to force old behaviour with demo_compatibility: [-force_remove_slime_trails]. It is relevant for viewing doom-compatible demos recorded with old versions of prboom (<2.4.6) or prboom-plus (< 2.4.6.1) in cases of desyncs.
[-] PrBoom bug: Fix another compatibility issue. It corrects half of the incompatibility shown by Wotdoom3/w303-115.lmp.
[-] Boom dehacked support: Correction of wrong processing of "Respawn frame" entry. Highly relevant to wads such as Wotdoom3 and any others that change this setting. There is no more synch (again) on Wotdoom3/w303-115.lmp.
[-] PrBoom bug: Fix compatibility issue with buggy MBF behavior (3-key door works with only 2 keys). There is no more desync on 10sector.wad/ts27-137.lmp.
[-] PrBoom bug: Wrong scaling of status bar at some resolutions. Strongly noticeably on ARMS section at 320x240.
[-] Alt mouse handling: Ungrabbing of mouse was not being done before a quit in some cases.
[-] PrBoom bug: Fixed a tasdoom incompatibility. There is no more desync on ddt-tas.zip/e4tux231.lmp. Nowhere no hide. All demos from the original TAS site now play back with PrBoom-plus.
[-] PrBoom bug: Conflicting command-line parameters could cause the engine to be confused in some cases. Added checks to prevent this. Example: glboom-plus.exe -record mydemo -playdemo demoname
[-] Launcher: Fake iwads could be in the game list. Added a check for "IWAD" signature to prevent this.

[Grazza]

heh, nice long changelog. :)

Note that there are quite a number of new options and changes in settings in this version, so even if (as I assume most people do) you just use your existing cfg files, it would make sense to leaf through the menus to check that everything is the way you want it (e.g. uncapped framerate).

This release fixes the last desyncs with demos from the old TAS site, so all the demos listed here play back with this new version. I therefore thought I'd release some batch files to watch them all. These are based on the ones I created for testing purposes.

TAS_BAT.zip

This should be useful if you have never watched these demos before, or had problems getting them to work or just found it too fiddly having to use a variety of exes. In any case, it should save some effort having all the command lines to watch each demo ready-made.

The text file included should cover most points. Obviously you need to have all the demos on your hard disk (and in the same directory as the batch files and the Prboom-plus 2.4.6.1 files), and all the pwads used too (the HR2 beta is here - the rest you should have or be able to get easily enough). You will need to edit the batch files if your file locations don't match mine, and will doubtless want to to chop them up into smaller pieces if you don't want marathon demo-watching sessions. On some operating systems you may need to do more than that, like putting pauses between them or something.

I noticed something interesting when doing this testing: almost all Dosdoom .47 demos play back OK using Ultimate Doom compatibility. In other words, you can probably play them back using Ultimate Doom's Doom.exe or Chocolate-Doom with "-gameversion ultimate". The only exceptions I have found so far are those with spechits overflows.

[myk]

Grazza said:
I noticed something interesting when doing this testing: almost all Dosdoom .47 demos play back OK using Ultimate Doom compatibility.

That's because DOSDoom 0.47 is a rather straight port of the released source, and it behaves in all relevant matters like Doom95 and The Ultimate DOOM's Doom.

[Hobbs]

A bit of a belated omg yay, but here it is.

OMG YAY!

[Quasar]

To be somewhat helpful, I did some research into why spechit overflows between 15 and 20 in size seem to have no effect and don't need to be emulated. This is because all of the variables bombspot, bombsource, usething, bombdamage, attackdamage, and la_damage are indeed always overwritten with valid values before being used again. This is because these statics are used to pass data down to callback functions executed via P_BlockThingsIterator, from P_RadiusAttack, P_LineAttack, and the player line using traversal. The static globals only exist because PIT_ functions have a fixed prototype and thus you can't pass data down to them on the stack :)

BTW, I'm preparing to implement the various overflow emulations as options in EE ;)

[entryway]

Practically we do not need to emulate the spechit overflows more than 12 in the size, because numspechit could not become more than 12 (spechit+tmbbox). You can experiment with it.

[Quasar]

Yes, as the number of specials increases it becomes less likely that the player can cross them all in one move. Even still, this is good information because if an overflow of size 15-20 is possible in some contrived example, it still won't matter since overwriting any of those variables has no effect ^_^

I really just wanted to understand and verify the whys and hows of that ;)

[fraggle]

Grazza said:

I noticed something interesting when doing this testing: almost all Dosdoom .47 demos play back OK using Ultimate Doom compatibility. In other words, you can probably play them back using Ultimate Doom's Doom.exe or Chocolate-Doom with "-gameversion ultimate". The only exceptions I have found so far are those with spechits overflows.

You will probably get even better playback results using -gameversion final. The Doom source release was based on the Final Doom source, and there are some minor differences between Final Doom, Ultimate Doom and the "original" 1.9 executable.

[Quasar]

Are you sure about that? It doesn't seem to be the case to me now. I had thought at one time that Linux Doom 1.10 was based on Final Doom, but if it was, why then was it missing the code to make teleporters work like they do in Final (they stick you up into the air if the floor height at the destination is less than that at the starting pad)?

[VinceDSS]

entryway said:

Windows 98 is awful and thankfully dead operational system. People do not use Windows 98 for a long time. People use WinXP and PrBoom (context of this topic). Hence overflowed demos should be played equally in PrBoom at WinXP and 'vanilla' at WinXP. Isn't it?

Please don't ditch win98 compatibility, lots of people are probably still using it. I still have older computers with win98...

[entryway]

VinceDSS, I was not going to ditch already working things there, but support win98 for new features is a pain sometimes.

[Quasar]

I have a question about the spechit emulation. The overflow of the array actually starts when numspechit == 8, not 9. The array is declared with size 8 and is thus normally indexable from 0 to 7. Is there simply no variable at index 8, or a variable that is of no consequence like some of the others, or is this a genuine mistake that I've noticed? It warrants some attention I think.

[entryway]

PrBoom-Plus\src\p_map.c

      // e6y: Spechits overrun emulation code
      if (numspechit > 8 && demo_compatibility)
        SpechitOverrun(ld);

PrBoom\src\p_map.c

      // e6y: Spechits overrun emulation code
      if (numspechit >= 8 && demo_compatibility)
        SpechitOverrun(ld);
      ...
      case 8: break; /* e6y: strange cph's code */

Ask cph the reasons of changing that, because it has no sense.

[Quasar]

So, are you saying you don't know? Who did the original reverse engineering to determine what variables are overwritten during an overflow? Surely they can go back and check to see if they missed something here. The overflow does start when numspechit == 8, that's for sure. The question of whether that's at all important is unanswered.

[entryway]

Quasar said:

So, are you saying you don't know? Who did the original reverse engineering to determine what variables are overwritten during an overflow?

haha?

You should look at the source more closely. Also, I recommend to look only in the prboom-plus's source for such things for avoidance of misunderstanding (I do not answer completely for PrBoom's sources). In any cases, there are all correctly there and there, but PrBoom does a one dummy superfluous call of SpechitOverrun() function. Only this difference. What is the question?

EDIT:

The overflow of the array actually starts when numspechit == 8, not 9. The array is declared with size 8 and is thus normally indexable from 0 to 7.

And? numspechit changes from 1 up to 8 accordingly:

      spechit[numspechit++] = ld;
      // e6y: Spechits overrun emulation code
      if (numspechit > 8 && demo_compatibility)
        SpechitOverrun(ld);

[fraggle]

Quasar said:

Are you sure about that? It doesn't seem to be the case to me now. I had thought at one time that Linux Doom 1.10 was based on Final Doom, but if it was, why then was it missing the code to make teleporters work like they do in Final (they stick you up into the air if the floor height at the destination is less than that at the starting pad)?

This is the behavior of the released source code. See p_telept.c. The source release is clearly based on Final Doom.

[Quasar]

entryway said:

haha?

hmm, maybe you should look at the source more closely. Also, I recommend to look only in the prboom-plus's source for such things for avoidance of misunderstanding (I do not answer completely for PrBoom's sources). In any cases, there are all correctly there and there, but PrBoom does a one dummy superfluous call of SpechitOverrun() function. Only this difference. What is the question?

EDIT:
And? numspechit changes from 1 up to 8 accordingly:

      spechit[numspechit++] = ld;
      // e6y: Spechits overrun emulation code
      if (numspechit > 8 && demo_compatibility)
        SpechitOverrun(ld);

My apologies. It seems this has changed since the code that was posted on the forums here:
http://www.doomworld.com/vb/showthread.php?s=&postid=591521&highlight=spechits#post591521
as well as the code that is currently prsent in the Chocolate Doom port (I could not find a link to your current SVN so I used Chocolate Doom as a source). So this is a mixup here. Fraggle, your code is out of date :P

Also, fraggle, that is interesting. I'm assuming somebody in DosDOOM or BOOM must have reverted that "fix" back out of the source code then. Either that, or this is one of the hidden consequences of them using parts of that secret DOS source that Carmack sent them...

[entryway]

nothing was changed. only tasdoom/dosdoom compatibility was added. because I disassembled their sources too (but only in the needed places as distinct from doom2/doom95)

[Grazza]

[myk]

fraggle said:
This is the behavior of the released source code. See p_telept.c. The source release is clearly based on Final Doom.

What cph says is that a line that is in Doom v1.10 was missing in Doom v1.9f:

Given this lead, I quickly spotted an interesting comment in p_telept.c: thing->z = thing->floorz; // fixme: not needed?. It turns out that this line was removed in Final Doom, with the result that teleports don't set the Z-coordinate of an object that is teleported; this is very noticable when you know what to look for.

And prboom says:

if (compatibility_level != finaldoom_compatibility)
            thing->z = thing->floorz;

Isn't that saying "use this when it's not v1.9f"?

[ultdoomer]

This might sound trivial, but on all of the resolutions I tried, the Boom HUD text looks distorted, making it hard to read. I just thought I would mention it so maybe it could be fixed for the next version.

[entryway]

It happens in software rendering because all of hud's items are resizing (quakes do not do it with fonts for example) and thin letters cannot be resized correctly with used method on software rendering at most of resolutions (looks good at 640x400). We should resize the hud fonts only on multiple sizes 2x, 3x, etc or should not resize they at all.

[entryway]

What do you think about "all-in-one" additional win32 release of prboom-plus? It will be one file (about 1.5 mb) and you will require only it for start.

[Use]

entryway said:

(-) original prboom: prboom uses monster_avoid_hazards setting from the cfg file when you are using -complevel 0 or -complevel 1.

I don't understand the need/use of this feature. What hazards aside from crushing ceilings do monsters have to avoid? What use is this?