PrBoom-Plus, ver. 2.5.1.4

[Grazza]

myk said:

PS to entryway: These fixes in PrBoom+ should automatically be disabled when using previous compatibility levels (if they aren't already).

If you mean the "compatibility with common mapping errors" settings, then these are always disabled for recording and playback, and when playing with a vanilla complevel.

If you mean the texture compositor changes, then if I undertstand RjY correctly, 2.4.6 (and 2.4.6.x) will emulate vanilla's handling of negative y-offsets in pretty much all cases (if that's not right, please correct me).

[Doom Marine]

myk said:

Doom Marine, if your wad is "Boom compatible", it should look and work right in Boom, first and foremost.

I know, I know. I've been using ZDoom for the majority of the past testings and recently started to test my wad at compatibility level 9 on PrBoom. I use ZDoom as a double-checker.

Sometimes when stuff doesn't display or function properly on PrBoom, I ask myself whether I should report it and wait for the next version of PrBoom, or fix it myself to accommodate for PrBoom.

In the scrolling sector case, I'll just have to accommodate for PrBoom.

--- --- ---

I'm having problems taking screenshots with PrBoom-Plus 2.4.6.1. I tried different key bindings for screenshots but nothing is generated. Any idea?

[myk]

Doom Marine said:
Sometimes when stuff doesn't display or function properly on PrBoom, I ask myself whether I should report it and wait for the next version of PrBoom, or fix it myself to accommodate for PrBoom.

If you try your map in Boom(.exe) or PrBoom v2.02 (a plain Windows port of Boom) it'll display or perform things like PrBoom does. That's what I mean; or if it doesn't do that in comp level 9 then indeed there's an issue. Accomodating a map to somewhat different engines (Boom and ZDoom, in this case) can take additional work, but Boom's behavior will never change, while ZDoom's may be different in some way tomorrow if people find something they consider a fixable bug, or change something to add some feature of get rid of some limitation.

I'm having problems taking screenshots with PrBoom-Plus 2.4.6.1. I tried different key bindings for screenshots but nothing is generated. Any idea?

Did you try binding the key from the menu? It's in the second screen of the Key bindings menu. When it's working you should hear the talk sound each time you take a screen shot. I have it bound to F5 and it works fine, but I'm not using that particular version yet.

[Doom Marine]

Cool! Screenshots worked, thanks.

IDDT doesn't work for me in PrBoom-Plus 2.4.6.1. My movement keys are in the WASD configuration, I tried unbinding the D-key, but IDDT still doesn't work.

[entryway]

screenshots doesn't work.
IDDT doesn't work.

Doom Marine, stop posting nonsense here please. Don't do a laughing-stock of the port.

[Doom Marine]

I'm trying to work with the latest version of PrBoom and making my wad compatible with it. I hope you understand that I'm not trying to mock your port.

Is this the right thread to discuss the issues that I've been bringing up in the previous posts? I'm trying to be constructive here.

To clarify: Maybe IDDT works for the latest version but I wasn't able to do it. Without IDDT, I wasn't able to locate unkilled monsters and other discrepancies when running PrBoom. That's why I felt it necessary to point it out.

[Grazza]

I'm not aware of any issues with IDDT, and the fact that D is used as a movement key shouldn't affect it. (I have been using 2.4.6.1 for a while now, have a WASD set-up and use IDDT moderately often, esp. when watching demos.)

Check that:
1. You're not playing in a game mode where cheat codes are disabled (multiplayer, net1, NM).
2. That you're not using a deh patch that changes the cheat codes.

And remember that in general, if Prboom+ is handling something in the way Boom does (or vanilla, or MBF, depending on comp settings), then it is not a bug. (Unless it's a specific Prboom+ feature that isn't working as intended.) If you desperately think that Prboom+ should implement Zdoom's way of handling a Boom effect and report this as a bug, I am sure Andrey will label it "invalid". You could try making a feature request for it to be incorporated as an option along the lines of "compatibility with common mapping errors", but so far this has been restricted to very common problems that simply make a map unplayable (and that are fixable by editing the wad). It would be preferable to make your wad genuinely Boom compatible. Or else abandon that idea and make it Zdoom-only if you can't achieve the effects you want that way (that would be a shame though, and I doubt it is necessary).

[entryway]

Grazza said:

If you desperately think that Prboom+ should implement Zdoom's way of handling a Boom effect and report this as a bug, I am sure Andrey will label it "invalid". You could try making a feature request for it to be incorporated as an option along the lines of "compatibility with common mapping errors", but so far this has been restricted to very common problems that simply make a map unplayable (and that are fixable by editing the wad).

I can do it if it make sense. How many wads are using this impertinent interference in boom's standards?

[entryway]

2 Doom Marine
I really love and respect your work. I am assured that your wad will be a wad of year or more and you have chosen a correct place for reporting, but sorry your categorical bug-reports for one of the most stable doom-ports cause laughter. Really you have thought that anybody did not notice IDDT bug earlier? Or it does not work only with 2.4.6.1? Send me your cfg in this case.

[Doom Marine]

My PrBoom-Plus 2.6.4.1 configuration

Grazza said:

And remember that in general, if Prboom+ is handling something in the way Boom does (or vanilla, or MBF, depending on comp settings), then it is not a bug. (Unless it's a specific Prboom+ feature that isn't working as intended.) If you desperately think that Prboom+ should implement Zdoom's way of handling a Boom effect and report this as a bug, I am sure Andrey will label it "invalid". You could try making a feature request for it to be incorporated as an option along the lines of "compatibility with common mapping errors", but so far this has been restricted to very common problems that simply make a map unplayable (and that are fixable by editing the wad). It would be preferable to make your wad genuinely Boom compatible. Or else abandon that idea and make it Zdoom-only if you can't achieve the effects you want that way (that would be a shame though, and I doubt it is necessary).

I guess I've mistaken differences in source port behaviors as bugs many times and reported it as such.

In any case, demo recording is of most importance in my wad, that's why being Boom-compatible has become a priority for me. The source ports inclusiveness of Boom-compatibility is also a good reason to go Boom instead of ZDoom as well.

My level is now almost in sync with PrBoom; I just need to verify that all monsters teleported out of their waiting rooms and if the dummy players did their job.

[entryway]

Doom Marine said:

My PrBoom-Plus 2.6.4.1 configuration

you should rebind "Key Binds\Chatting\Enter" to <Enter> for example

[Doom Marine]

Everything worked. Thanks!

[fraggle]

entryway said:

But emulation still may not work with multi-level demos. Because for each level the magic number will differ (and patched doom will put all of them in e6y file), but you cannot set the list of these numbers for current PrBoom-Plus

Hey, I had a thought here. With the '-spechit' parameter you're basically providing the address of the 'lines' array, which is dynamically allocated when the level loads. Looking at the level loading code in p_setup.c, the address of 'lines' is going to be dependent on the blockmap size, number of vertexes, sectors and sidedefs for the level. It's a bit of a long shot, but maybe we can do some calculations from these values and predict the 'lines' address automatically?

Another thing: the default value you're using is "0x00C09C98", which I believe you previously told me was from Doom95. Most of the doom2.exe ones being used for the sci2/scythe demos are in the 0x84xxxxxx range which suggests DOS Doom has its heap at a higher memory area. Perhaps it would be sensible to use something in this higher range as a default?

EDIT: I just played through the SCI2 demos (in Chocolate Doom) using the base address that myk found for scythe2.wad, and had no desyncs. I think that absolute precision of this kind probably isn't always necessary, as long as the base address is in the right general range. I'd really recommend changing it: I think it will probably catch 90% (at least) of the common cases.

[entryway]

Maybe, maybe. I never test the 0x84xxxxxx for common compatibility (I can't find the all demos from Grazza's list) If you have tested that, it's only necessary to change the magic.

[Grazza]

entryway said:

I can't find the all demos from Grazza's list

Which ones do you need? Some of them are in larger zips with different names, so you might be able to find them by copying your demo collection into one place, and executing "pkunzip *.zip" a couple of times.

BTW, another one that needs a magic number is sf304509.lmp, an "egg" demo hidden in the Scythe demopack (sc_lmps.zip: sc15-nm.lmp -> rename as zip, and extract contents).

[entryway]

I have these demos for testing overflow:
spechit.lst

a,2,doom2.wad,hr18-348.lmp,HR.WAD,-,
b,5,doom2.wad,HR181329.LMP,HR.WAD,-,
c,5,doom2.wad,HF181430.LMP,HR.WAD,-,
d,2,doom2.wad,ET312225.LMP,ETERNAL.WAD,-,
e,5,doom2.wad,IC09UV.LMP  ,ICARUS.WAD,-,
f,2,doom2.wad,rq31s115.lmp,REQUIEM.WAD,-,
g,2,doom2.wad,rq21-636.lmp,REQUIEM.WAD req21fix.wad,-,
h,2,doom2.wad,av15-248.lmp,AV.WAD,-,
i,2,doom2.wad,av15-252.lmp,AV.WAD,-,
j,2,doom2.wad,AV05-227.LMP,AV.WAD,-,
k,2,doom2.wad,STR07-UV.LMP,STRAIN.WAD,STRAIN.DEH,
l,2,doom2.wad,STR06-UV.LMP,STRAIN.WAD,STRAIN.DEH,
m,2,doom2.wad,STR14-UV.LMP,STRAIN.WAD,STRAIN.DEH,
n,2,doom2.wad,30mm8356.lmp,MM.WAD,-,
o,2,doom2.wad,s202-207.lmp,scythe2.wad,-,
p,2,doom2.wad,s210-053.lmp,scythe2.wad,-,
q,2,doom2.wad,s210-245.lmp,scythe2.wad,-,
r,5,doom.wad ,fod3uv.lmp  ,FLSOFDTH.WAD,-,

All these demos are desynch without emulation.

[Grazza]

entryway said:

All these demos are desynch without emulation.

That's odd. rq31s115.lmp, rq21-636.lmp, av15-248.lmp, av15-252.lmp, AV05-227.LMP, STR06-UV.LMP, STR14-UV.LMP, 30mm8356.lmp, s202-207.lmp, s210-053.lmp and s210-245.lmp all play back OK for me with emulation turned off.

[Schneelocke]

Grazza said:

BTW, another one that needs a magic number is sf304509.lmp, an "egg" demo hidden in the Scythe demopack (sc_lmps.zip: sc15-nm.lmp -> reaname as zip, and extract contents).

This one plays back fine for me in PrBoom 2.3.1 (without emulation, naturally :)).

[entryway]

Grazza said:

That's odd. ... all play back OK for me with emulation turned off.

I was wrong. I thought my list have only the desynchronized demos. Sorry.

BTW, another one that needs a magic number is sf304509.lmp, an "egg" demo hidden in the Scythe demopack (sc_lmps.zip: sc15-nm.lmp -> reaname as zip, and extract contents).

Works with 0x84000000 (2214592512 in decimal system) spechit param.

Grazza, can you send me the absent demos?

[entryway]

Schneelocke said:

This one plays back fine for me in PrBoom 2.3.1 (without emulation, naturally :)).

This demo is worked in prboom(+) without emulation too. Continue to use the buggy and unsupported version.

[Grazza]

entryway said:

Grazza, can you send me the absent demos?

Have just done so.

[entryway]

fraggle said:

Hey, I had a thought here. With the '-spechit' parameter you're basically providing the address of the 'lines' array, which is dynamically allocated when the level loads. Looking at the level loading code in p_setup.c, the address of 'lines' is going to be dependent on the blockmap size, number of vertexes, sectors and sidedefs for the level. It's a bit of a long shot, but maybe we can do some calculations from these values and predict the 'lines' address automatically?

It is much easier for making in Chocolate-Doom than in PrBoom-Plus (the changed sizes of many structures, another memory manager, etc.), but there is no sense to do it automatically

Another thing: the default value you're using is "0x00C09C98", which I believe you previously told me was from Doom95.

Currently I not use "0x00C09C98" because with this magic I have no desync with Xit's demos, but they are desync with 'vanilla' on my WinXP. I use the old "0x01C09C98"

Most of the doom2.exe ones being used for the sci2/scythe demos are in the 0x84xxxxxx range which suggests DOS Doom has its heap at a higher memory area. Perhaps it would be sensible to use something in this higher range as a default?

It depends on OS which was used for recording. Is there anybody use DOS for recording? People use Win98 or WinXP in most cases. WinXP has the greatest priority for me.

I'd really recommend changing it: I think it will probably catch 90% (at least) of the common cases.

List of all demos with spechit overflow:

;format
;state(d-desync;s-sync),complevel,iwad,demoname,wads,dehs,params,comments
;"-" for no entry

;Alien Vendetta
s,2,doom2.wad,AV05-227.LMP,AV.WAD,-,-,-,
s,2,doom2.wad,av15-248.lmp,AV.WAD,-,-,-,
s,2,doom2.wad,av15-252.lmp,AV.WAD,-,-,-,
d,2,doom2.wad,av15-612.lmp,AV.wad,-,-spechit 2230937832,-,

;Operation : BIOWAR
s,2,doom2.wad,bw131304.lmp,biowar.wad,-,-,-,

;Darkening
s,2,doom2.wad,DARKEN08.LMP,DARKEN.WAD RESOURCE.WAD,-,-,-,

;Dystopia3: Re-Birth of Anarchy
s,2,doom2.wad,DYST3-08.LMP,DYST3LEV.WAD DYST3TEX.WAD,-,-,-,

;Eternal III
s,2,doom2.wad,ET122614.LMP,ETERNAL.WAD,-,-,-,
s,2,doom2.wad,ET252031.LMP,ETERNAL.WAD,-,-,-,
d,2,doom2.wad,ET312225.LMP,ETERNAL.WAD,-,-,-,

;HacX Hurt Me Plenty
s,2,doom2.wad,HX04-724.LMP,HACX.WAD,HACX_F.DEH,-,-,
s,2,doom2.wad,HX09-847.LMP,HACX.WAD,HACX_F.DEH,-,-,

;Hell Revealed
d,2,doom2.wad,hr18-348.lmp,HR.WAD,-,-,-,
d,5,doom2.wad,HR181329.LMP,HR.WAD,-,-,-,
d,5,doom2.wad,HF181430.LMP,HR.WAD,-,-,-,

;Hell Revealed II
s,2,doom2.wad,hr2-lv31.lmp,hr2final.wad,-,-,*should* desync,

;Icarus: Alien Vanguard
d,5,doom2.wad,IC09UV.LMP  ,ICARUS.WAD,-,-,-,
d,5,doom2.wad,IC09UVGB.LMP,ICARUS.WAD,-,-,-,

;Kama Sutra
s,2,doom2.wad,ks23-201.lmp,ksutra.wad,-,-,-,
s,2,doom2.wad,ks181235.lmp,ksutra.wad,-,-,-,

;Memento Mori
s,2,doom2.wad,mm08-119.lmp,MM.WAD,-,-,-,
s,2,doom2.wad,30mm8356.lmp,MM.WAD,-,-,-,

;Requiem
s,2,doom2.wad,rq03-136.lmp,REQUIEM.WAD,-,-,-,
s,2,doom2.wad,rq21-636.lmp,REQUIEM.WAD req21fix.wad,-,-,-,
s,2,doom2.wad,rq31s115.lmp,REQUIEM.WAD,-,-,-,

;Scythe
s,2,doom2.wad,sc18-sp.lmp ,scythe.wad,-,-,-,
s,2,doom2.wad,sc30-uv.lmp ,scythe.wad,-,-,-,
s,2,doom2.wad,sf304509.lmp,scythe.wad,-,-spechit 2230937832,-,

;Scythe 2
s,2,doom2.wad,s202-207.lmp,scythe2.wad,-,-spechit 2230937832,-,
s,2,doom2.wad,s210-053.lmp,scythe2.wad,-,-,-,
s,2,doom2.wad,s210-245.lmp,scythe2.wad,-,-,-,
s,2,doom2.wad,s218-428.lmp,scythe2.wad,-,-,-,

;Scientist 2
d,2,doom2.wad,S203n245.lmp,SCI2.wad,-,-nodeh,-,
d,2,doom2.wad,S205n546.lmp,SCI2.wad,-,-nodeh -spechit 2230937832,-,
d,2,doom2.wad,S207n516.lmp,SCI2.wad,-,-nodeh -spechit 2230937832,-,
d,2,doom2.wad,S216n241.lmp,SCI2.wad,-,-nodeh,-,

;STRAIN
s,2,doom2.wad,STR06-UV.LMP,STRAIN.WAD,STRAIN.DEH,-,-,
d,2,doom2.wad,STR07-UV.LMP,STRAIN.WAD,STRAIN.DEH,-,-,
d,2,doom2.wad,ST07-237.LMP,STRAIN.WAD,STRAIN.DEH,-,-,
s,2,doom2.wad,STR14-UV.LMP,STRAIN.WAD,STRAIN.DEH,-,-,
s,2,doom2.wad,ST14-832.LMP,STRAIN.WAD,STRAIN.DEH,-,-,

;Squadron 417
s,2,doom2.wad,SQ417-01.LMP,SQUADRON.WAD,-,-,-,

;H2H-Xmas
s,2,doom2.wad,XM26-313.lmp,H2H-XMAS.WAD,-,-,-,

;1024 Congestion
s,2,doom2.wad,2423-301.lmp,1024.wad,-,-,-,

;1024x1024 & 2 sectors contest wad
s,2,doom2.wad,2s01-030.lmp,2sectors.wad,-,-,-,

;others
d,5,doom.wad ,fod3uv.lmp  ,FLSOFDTH.WAD,-,-,-,

You can see that only 5 from 46 require the "-spechit" command line parameter and the "2230937832" spechit magic works in all five cases.

If you have WinXP, you can download this testset from here. Extract it in your PrBoom-Plus's folder and start .\testset\spechit.bat. You should have all necessary WADs and DEHs in PrBoom-Plus or %DOOMWADDIR% folder. Use the <END> key for fast rewind to EndScreen. If you don't see it the demo was desync.

[myk]

entryway said:
People use Win98 or WinXP in most cases. WinXP has the greatest priority for me.

In most cases people use Windows 98. Maybe some people use Doom on Windows XP sometimes, but I doubt they record much. If they record they use PrBoom or PrBoom+ (I don't recall any Chocolate Doom demos yet.)

[entryway]

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?

[Grazza]

If I understand you correctly, you're trying to choose the default magic number so that it works in as many cases as possible, so that in practice people will need to use the -spechits command-line option in as few cases as possible.

Thus, if you set it so that it is a typical "XP" value, demos recorded in XP with either Doom2.exe or with Prboom+ (with emulation) should all be OK, but a few demos recorded under DOS or Win98 (those that do not play back with Doom2.exe under XP) may need a magic number to be specified in the command line to play back correctly. And vice versa.

Overall, I propose that empirical testing with the demos that are known to be affected by these issues should be uppermost in determining this. What "candidate default magic numbers" are you considering? Are there any in addition to "0x00C09C98" and "0x01C09C98"?

Another possibility might be to set the default magic number at program start-up so that it is the one most in line with the user's OS. This could still be overriden via the command line, but would mean prboom+ was most accurately emulating Doom2.exe running on each user's own OS.

BTW, one of the demos in your list, et252031.lmp, won't play back for me with anything at all (I noted this in the batch file in the stuff I sent to you) - I have tried different OSes, exes and versions of the wad, all with no luck. So until it can be established what this demo needs in order to play back OK (assuming you haven't already done so), no conclusions should be drawn from desyncs with this demo.

Note for anyone bewildered by all this technical stuff: Be assured that this issue only affects an absolutely minuscule proportion of demos. The ones in Andrey's list above were culled from testing thousands of demos, and only in a small proportion of those is playback affected by the fine-tuning of the magic number. Specifically, we're talking about those in which playback with Doom2.exe is different under differing operating systems.

[entryway]

myk said:

It runs, but now it generates a small DOOM screen surrounded by a thick black border (it's not resizing it to fill the entire screen.)

I should know. Does it happen only for software rendering? With new SDL and without set SDL_VIDEODRIVER=directx.

P.S.
I want to add:

  //Forcing "directx" video driver for Win9x.
#ifdef _WIN32
  if ((int)GetVersion() < 0 ) // win9x
    SDL_putenv("SDL_VIDEODRIVER=directx");
#endif

[myk]

entryway said:
Does it happen only for software rendering? With new SDL and without set SDL_VIDEODRIVER=directx.

Yes.

Grazza said:
Another possibility might be to set the default magic number at program start-up so that it is the one most in line with the user's OS. This could still be overriden via the command line, but would mean prboom+ was most accurately emulating Doom2.exe running on each user's own OS.

Actually, I heard the spechit is used per level, so might it not be possible to make it something that could be changed though the menus? A compatibility option. Does this only affect spechit or is it the same for all overflows? There could be an emulation/compatibility option that says "emulate overflows as if running on Windows 98". Setting that on would use the Windows 98 friendly number (unless overridden on the command line as usual). Or maybe even a 0, 1, 2 set of options if we find a different number that is better for pure DOS, as well.

[entryway]

Grazza said:

Another possibility might be to set the default magic number at program start-up so that it is the one most in line with the user's OS. This could still be overriden via the command line, but would mean prboom+ was most accurately emulating Doom2.exe running on each user's own OS.

I think it will not help anything, but will introduce additional mishmash and unnecessary incompatibility.

[Quasar]

I *might* be a total moron who knows nothing about programming, but if you wanted a demo to act like it did under Vanilla Doom, wouldn't it make the most sense to be writing the values used by Vanilla Doom into the overflowed array?

This should not vary depending on the USER's OS. It might have varied depending on the OS that the demo was recorded under, but that information is not retrievable, and is DOS in 99% of the cases at least.

Programs are deterministic. DOOM's demos are only possible because DOOM is (almost entirely) a deterministic system. There's nothing going on here that shouldn't be completely explainable by examining the source code or the runtime state of the system. The amount of voodoo seemingly surrounding some of this is why I've not yet implemented it in Eternity.

[entryway]

You have not implemented in Eternity too much simple compatibility things which does not require voodoo. AFAIUI, you do not care of that now.

EDIT: There is no sense to force PrBoom to record demos which will correctly work only in DOS. Nobody uses DOS now.

This should not vary depending on the USER's OS. It might have varied depending on the OS that the demo was recorded under, but that information is not retrievable, and is DOS in 99% of the cases at least.

In this case you should stop (and to stop the others) to record demos under Win9x\WinNT. It's a way of incompatibility. Wrong way. Other people never can see your demos (with vanilla), because they have no DOS.