Yeah it did ;) DOOM kicked out for any kind of unusual situation whatsoever. Visplanes are a great example, too. Even with the static limit intact, id could have more responsibly checked for overflow during rendering and simply stopped creating visplanes, resulting in floor/ceiling HOM where the missing spans were. A fleeting visual artifact would be far preferable to "R_FindPlane: no more visplanes!"

I've been eliminating a lot of fatal errors in Eternity, although some are stubborn. During level loading for example, there's a point beyond which it is more difficult to simply drop to console and display an error there. That's why my "no nodes" check still boots the program out. Maybe I can fix that eventually, though ;)

Normally, but I also tested in prboom.exe (and missed this, for the reason described). Also some things in wotdoom3 (water effects) don't currently look quite right with glboom.exe, which provides another reason why one might want to use software mode for this wad.

I have a problem, I recorded a scythe2 demo and during the record I loaded a savegame. When I'm playing the record, and the engine reaches the time it needs to open the savegame, I get the following error: "M_ReadFile: Couldn't read file C:\prboom-plus-win32/demosav0.dsg". The name of the savegame file is prbmsav0.dsg and prboom.exe tries to load demosav0.dsg. If I rename the file from prbmsav0.dsg to demosav0.dsg everything works just fine. My question is, why does prboom.exe tries to load demosav0.dsg while the name of the file is prbmsav0.dsg?

I was testing this with some demos that ought to play back with -complevel 7 ("boom compatibility" compatibility): the ones in icuvlmps.zip that are described as not playing back with Doom2.exe, but playing back with Boom 2.02 (ic22uv.lmp, ic25uv.lmp, ic27uv.lmp, ic28uv.lmp, ic31uv.lmp). They play back fine with Prboom 2.02. So logically, these demos should play back with -complevel 7:glboom icarus ic28uv.lmp -complevel 7

The regular Prboom 2.2.6 always tries to play ic28uv.lmp with Doom2.exe compatibility (and it desyncs - this demo desyncs in Doom2.exe too). As I understand it, in 2.2.6, putting a complevel in the command line for demo playback has no effect.

Prboom 2.02 plays ic28uv.lmp using the closest thing it has got to Doom2.exe compatibility - its "Doom compatibility" mode. This plays it back OK.

My basic point is that if Prboom 2.02 can play back a demo, then Prboom-plus should also be able to play back that demo using either -complevel 7 or -complevel 9. That makes sense, doesn't it?

I now notice that when using glboom icarus ic28uv.lmp -complevel 7 the demo doesn't even desync in the same way each time. Does this suggest that -complevel 7 is not being understood at all, and leading to the program getting some random data from somewhere?

Edit (based on a bit more testing): It seems that if -complevel 7 is used when attempting to play back a Doom2.exe-format demo, the behaviour is to some extent random.

These demos are not boom demos. The boom demos have the signature "boom" in the beginning of a file. Your demos have the signature "m". Hence the level of compatibility of your demos can be one of: doom2_19_compatibility, ultdoom_compatibility, finaldoom_compatibility or dosdoom_compatibility. Really your demos are DosDoom-compatible demos.

Now that PrBoom+ supports Deus Vult would it be possible for someone to fix the bugs in map05 that were caused by ZDoom-only testing and upload a fixed version?

The most serious one is the hanging corpses that screw up the cathedral monster teleport destinations.

Another thing: it's very easy to miss waking up the demons+archviles monster teleporter (the one that has destinations in the cathedral courtyard), as there is only one place where it is possible (the last section of the colored tunnels).

The last thing is not exactly a bug, more like a minor annoyance: one trap in the cathedral (the barons that rise up from the floor on the high ledge with the supercharge) requires the compat option 'use exactly Doom's linedef trigger model' to be set to 'no'. AFAICT this is the only thing that forces using Boom compatibility. Could this be changed?

Belial: "Doom Marine" is the guy to contact about this, and I'm sure that if you give him a nice clear list of what the issues are, he'll be happy to amend them and rerelease. It might also be worth mentioning this to hawkwind (or hawkwind2 as he is known at Newdoom). He's a map/compatibility tester for Risen3D, which should also be able to play maps of this size (it handles dmdjm02 OK). However, there is an issue with the nodebuilding which is possibly solvable, but may require some changes in the map. I agree that if there is just one linedef that requires Boom compatibility, then it should be amended. This means you can dispense with the annoying "live monsters can be knocked off ledges" behaviour (very annoying in some Maxes), and also that it should work in jDoom (if/when the appropriate limits are extended). Edit: There's also this issue mentioned by entryway (a texture with an empty name instead of '-') that is certainly worth fixing.

entryway: So, -complevel 7 will only play back demos that have the same binary format as demos that were recorded with Boom. I had been presuming that it would also be able to play Doom2.exe format demos but apply Boom's "compatibility" behaviour to them (like the original Boom 2.02 did). OK then, so it is working correctly, but just not in such a wide range of situations as I had expected.

While I hate to drag up something really old, I thought I'd note here that I determined this compatibility bug was introduced by Lee Killough in MBF when adding friendly monster support. The bug was NOT in BOOM itself, but was absorbed into prboom later, and has always been in SMMU and Eternity.

One problem I'm having is I don't see the smart totals, like in this screenshot. Yes, I have it set to "on".

The other problem is the Fix Turn-Snapping Issue option does cause the snap to not occur when I wait a little bit, but if I try to make movements before the game actually starts for quicker starts, the bug still occurs; I also start firing when this happens. Building the first several tics and joining from there takes care of this problem, but that takes time.

I know Smooth Movement removes the 35 fps limit making your movements look smoother, but does it affect gameplay?

I know Smooth Movement removes the 35 fps limit making your movements look smoother, but does it affect gameplay?

No - as Andrey has stressed, all these optional features are without losing compatibility, since it is an absolute priority for this port. It is just a visual effect, interpolating as many frames as it can in between the "real" ones. The engine still calculates the positions and states of everything at 1/35 second intervals.

ultdoomer said:The other problem is the Fix Turn-Snapping Issue option does cause the snap to not occur when I wait a little bit, but if I try to make movements before the game actually starts for quicker starts, the bug still occurs; I also start firing when this happens.

I could turn early now without the snap, but I still start firing with it continuing until I press the right mouse-button (fire). This happens when I press a mouse button early to start going forward or to fire right away.

I can't see your screenshots, but I'll guess you need to press F5 again, or several more times. It cycles through the various layouts.

DaniJ: I tried DV map05 in jDoom 1.9.0-beta3, but couldn't get it to work whether I built the nodes externally (using glbsp 2.20) or left it to the internal node builder. Is there a way to get it to work at present, or does it require an as-yet unreleased version?