Are dos boom ports meant to be 100% compatible with latest boom wads?

Sunlust and ancient aliens crash when running them under boom 2.02 ports. Not sure what's causing this since the wads are designed for boom 2.02, albeit for prboom and such. Do they not work in the same way?

Even if those ports are nominally limit-removing, they might have never been actually stressed to the degree that those mapsets do.

A lot of things could have gone wrong e.g. from the limit-removal not being 100% complete, to simply hitting an actual memory limit under DOS (depends on the protected mode and memory extenders used, and can be as little as 64 MB, regardless of how much physical RAM one has installed). Just the REJECT table in some of those maps can be enormous.

Edit: my bad there, there's actually no REJECT in Ancient Aliens at least and most of Sunlust's maps don't have one, either, and I don't know how well those old ports actually handle its being missing. There are also a lot of BLOCKMAP lumps that are over 128 KB long and thus useless, which rely on being internally auto-generated on-load by modern ports, again not something I'm sure that Boom 2.02 actually did back then.

Edit2: In SUNLUST.WAD I noticed other irregularities, such as some maps e.g. MAP28 and MAP30 not having the SSEGS and SSECTORS lumps. TBQH, I don't know how that's even supposed to work, but if Boom uses the old vanilla-style loader which relies on all lumps being present in a specific order (rather than looking for them by name), things could get ugly.

Ancient Aliens at least exceeds the sidedef limit (unless they were compressed which right now I cannot check) on some maps and requires a strong limit removing port, i.e. allow more than 32768 objects of each type. Boom never went that far, as far as I know ('sidenum' is a signed short in Boom 2.02.) That'd mean that declaring it 'Boom compatible' is not entirely accurate. This mod definitely needs a more modern port

The term "Boom-compatible" drifted to actually mean PrBoom+-compatible at some point.

I was curious about how AA does the music change on the first level. I assume that's a PrBoom+-specific feature too?

fraggle said:

I was curious about how AA does the music change on the first level. I assume that's a PrBoom+-specific feature too?

IIRC it was a MUSINFO lump.

It uses the MUSINFO lump which is supported by all relevant ports.

Graf Zahl said:

Signed 32K vs Unsigned 64K limit

Can you recally which port actually introduced this particular enhancement? MBF or SMMU? Or even prBoom and afterwards? Edit: OK, apparently prBoom

Some enhancements like e.g. the built-in blockmap builder actually were introduced by MBF, so the correct compatibility level for maps with blockmaps > 128 KB should be "MBF compatible", and there probably are other such important milestones as well, which apparently none really bothered writing down.

This was done independently by various ports long after Boom and MBF went extinct. Today all major ports have extended these limits.

Graf Zahl said:

It uses the MUSINFO lump which is supported by all relevant ports.

Except Eternity (in any case it's a feature EE should support).

I guess "Boom compatible" nowadays merely means "doesn't care for VISPLANE limits, uses extended linedefs".

printz said:

Except Eternity (in any case it's a feature EE should support).

I actually thought it did support it. But this isn't too hard to implement anyway. Since both PrBoom+ and ZDoom implement it it might make sense for Eternity, too, essentially becoming a part of an 'extended Boom' standard.

fabian said:

I guess "Boom compatible" nowadays merely means "doesn't care for VISPLANE limits, uses extended linedefs".

That's what "limit-removing" stands for. "Boom compatible" nowadays means "may be using any features described in boomref.txt + MBF sky transfers, and may NOT be using any ZDoom-specific features or be relying on zdoomisms".

Graf Zahl said:

I actually thought it did support it. But this isn't too hard to implement anyway. Since both PrBoom+ and ZDoom implement it it might make sense for Eternity, too, essentially becoming a part of an 'extended Boom' standard.

It was 99% finished when I realized I needed to do the line and sector special refactoring first so that we could utilize such things for ZDoom-style sector activations (of which the music info changer is a special case of "on enter sector"). I completed those, and then those were the last major things I was able to do for EE before all my time started getting eaten up with outside projects. So it could and probably should be finished after the current massive projects get merged in by the other coders.

I take Boom compatible, these days, to mean "does not support ZDoom or Eternity Engine-specific features"

mdmenzel said:

I take Boom compatible, these days, to mean "does not support ZDoom or Eternity Engine-specific features"

Don't you mean 'does not USE...'?

mdmenzel said:

I take Boom compatible, these days, to mean "does not support ZDoom or Eternity Engine-specific features"

Ancient Aliens features use some ZDoom- and EE-exclusive features (ACS, MAPINFO), actually.

The verb you want is "require", because it can still work without them.

But can it run on vanilla Boom or MBF?

Danfun64 said:

But can it run on vanilla Boom or MBF?

Unlikely, considering the size of some of the maps.

hello guyz, i always wonder if its possible to port new versions of prboom and eternity back to dos, especially since eternity had dos version till v3.31.
i guess the major difference between win32 and dos is video and audio handling, for example prboom is sdl based. is it possible to simply connect the game logic and memory management of prboom to the video/audio part of mbf or eternity-dos?

At this point, it will also depend on the state of available compilers. Even assuming that they are all entirely written in a GCC-friendly C/C++, it's not a given that DJGPP will support them out-of-the-box without major rewriting/restructuring. Even if the port is successful, under DOS, there will always be less total addressable RAM available (256MB tops, with some extenders, maybe even less, like 128MB or 64MB), so large or graphics-heavy maps might still not run.

The main question should be: Why should anyone do that? The reason for migrating to Windows, aside from not being able to run DOS programs natively on modern windows systems was to get the better hardware abstraction.

Considering the existing DOS backends, they all had their share of problems and none worked reliably across all existing hardware.

All that nonwithstanding, you'd still have to do a lot of work connecting the high level code with some mostly incompatible low level code and make it all work. There's nothing 'simple' here.

While DJGPP was finally updated again last year, I cannot find any information about what version of GCC it is now using. The previous build was on GCC v2, which is a compiler from 1998. Eternity, at least, requires GCC 4.x because it uses C++11 features. So unless DJ has ported a significantly newer compiler, there's no chance even if you took full advantage of EE's HAL architecture to write a DOS backend for it.

noshutdown said:

hello guyz, i always wonder if its possible to port new versions of prboom and eternity back to dos, especially since eternity had dos version till v3.31.

Possible? Sure. Good luck find anyone willing to spend time on such a project.

Quasar said:

While DJGPP was finally updated again last year, I cannot find any information about what version of GCC it is now using. The previous build was on GCC v2, which is a compiler from 1998. Eternity, at least, requires GCC 4.x because it uses C++11 features. So unless DJ has ported a significantly newer compiler, there's no chance even if you took full advantage of EE's HAL architecture to write a DOS backend for it.

It appears to be GCC 6.1. https://sourceforge.net/p/freedos/news/2016/05/gcc-610-current-djgpp-205/

cardboard42 said:

It appears to be GCC 6.1. https://sourceforge.net/p/freedos/news/2016/05/gcc-610-current-djgpp-205/

So...any takers ?

honestly, it would be a better endeavor to produce a DOS port that can switch between boom and mbf (3keydoorfix optional) complevels that doesn't require dealing with seglimits. Even better would be something like a Crispy Boom and or Crispy MBF, but the likelyhood of that happening is never...

edit: for those wondering why i mention these things... my obsession with multiplayer demos. prboom-plus is, atm, a horrible port for online play. Eternity isn't much better, and i doubt it can even record boom and mbf demos at this present moment. Odamex is beta software and appears to be unmaintained. ZDaemon is closed source and has no video dump feature. Zandronum shares ZDoom 2.X flaws of demo recordings being incompatible with even other versions of the software. JDoom 1.8.6 is a dead codebase, insecure, and is limit removing only. Newer versions of JDoom don't have any demo capabilities. Crispy Doom is awesome, and demos can be played back in prboom-plus, but is only limit removing (very limited boom functionality, but...). Boom and MBF under Dosbox again can have demos played on PrBoom-Plus, but the Dosbox overhead combined with minor features missing from modern source ports, even some included in crispy doom, make them less then ideal.

Danfun64 said:

edit: for those wondering why i mention these things... my obsession with multiplayer demos...

So you're looking for a multiplayer port with good limit-removing capabilities, that maintains demo compatibility with older port versions (and/or itself). And, this port needs to do internet multiplayer well (vs. LAN multiplayer)?

I guess the last point is the biggest issue. To do smooth internet play, you need a port that does player prediction. This feature provides everyone with a smooth experience, even during poor network performance. Instead of reading the player's actions from a network packet, the game guesses what the laggy player did, based on what he did during the previous few frames. When a packet finally arrives, the game has to correct the mistakes it may while it was guessing.

If the game is also recording a demo, it would also have to correct the demo file, in a way that playing back the demo would produce the exact result as if no packet loss occurred. Tricky.

I've been working on my port for many years now. It plays a mean LAN game, and writes flawless demos. I've spent a lot of time and energy striving for perfect vanilla demo playback, as well as perfect demo playback with all my ports extended features. But, no prediction, so you'd need a very fast reliable internet connection.

PrBoom+ doesn't have good networking? That surprises me. I know it doesn't do the prediction. And, Odamex is not being maintained? That surprises me even more - I would have suggested Odamex first. That's a shame, cause I know they were striving for an experience closestly matching vanilla.

I've been considering working on some prediction stuff of my own, ,but that's far in the future. Good luck.

I take back odamex not being maintained...but it didn't have any updates in the svn log for a long time, so i assumed it still wasn't maintained. There's a gap between 2015-08-15 and 2016-07-14 for when there weren't any engine related commits. Even so, the recent changes in the odamex trunk aren't that major, the demo protocol isn't "stable" enough atm, coop support isn't "stable" enough atm, odamex lacks prboom-plus viddump feature, and im not 100% sure that odamex supports freecam while playing back demos.

Crispy Doom, of course, doesn't have any prediction, but I found coop with extratics 3 dup 2 to be fairly smooth, and I assume the same is true with vanilla, boom, and mbf under dosbox.

PrBoom-Plus's networking code is so bad that not even its main dev recommends using it for online multiplayer purposes.

Danfun64 said:

Even better would be something like a Crispy Boom and or Crispy MBF, but the likelyhood of that happening is never...

I wouldn't say that. There's a few of us interested in doing it, and we even set up a repo to host it, but haven't started coding yet.