ReBOOM 2.07um (Updated February 24th 2022)

[Gibbon]

So, first I'd like to thank @Nikku4211 for suggesting it, that it would be nice to have a modern and painfully authentic BOOM source port that is portable and usable on modern systems.

 

That is where ReBOOM comes in, there is so far no release, but it is coming along nicely.  I'm following a rather strict methodology for getting it 'right'.  That is a 6 way comparison between BOOM, MBF, WinMBF, PRBoom 2.02, LinBOOM and Pooch, while only adding those differences for 64bit, SDL2 and other changes required for modern compilers.

 

So far, it compiles and runs and is stable (a few bugs here and there), it is not yet fully 'BOOM', but still, a good chunk of it is.  I have 2 branches, one for testing code on a stable base (Pooch with significant BOOM backports) and another that will become the final release (ported BOOM code itself).  I'll also do a 64bit port of the assembler (porting the PRBoom 2.02 nasm), purely for historic reasons, not for usage.

 

I'm pretty confident it will be ressurected soon.

 

https://github.com/atsb/ReBOOM

Edited February 24, 2022 by Gibbon
new release 207um

[Redneckerz]

@Gibbon So, this is basically PrBoom 2.02 but for the modern age? Because then ReBoom sounds more conservative than Pooch.

[Gibbon]

1 hour ago, Redneckerz said:

@Gibbon So, this is basically PrBoom 2.02 but for the modern age? Because then ReBoom sounds more conservative than Pooch.

ReBOOM is going to be as conservative as possible.  Yes, essentially it will be PrBOOM 2.02 without assembler.  I'm having to leave some refactored code from Lee (ticks, saving) but I'm aiming for this to be honest and authentic.  Since we are sadly devoid of any source port that did not keep Boom as it was (even PrBoom+ is more MBF than Boom nowadays).  I'm testing it on the THT wad, to ensure Boom compatibility is 100% on point.

[Redneckerz]

5 minutes ago, Gibbon said:

ReBOOM is going to be as conservative as possible.  Yes, essentially it will be PrBOOM 2.02 without assembler.  I'm having to leave some refactored code from Lee (ticks, saving) but I'm aiming for this to be honest and authentic.  Since we are sadly devoid of any source port that did not keep Boom as it was (even PrBoom+ is more MBF than Boom nowadays).  I'm testing it on the THT wad, to ensure Boom compatibility is 100% on point.

Alright, humor me. PrBoom 2.02 (The literal port of Boom to Windows) also runs on W10. So ReBoom (ReBoom 2.02) is pretty much a 64 bit, clean version of that, correct?

I could see the interest in that as a nice base port purely from a features point of view. Perhaps support for modern monitor resolutions, if that makes sense?

Personally i'd love a barebones Boom port that just does Boom but is clean enough to run on 64 bit.

[Gibbon]

42 minutes ago, Redneckerz said:

Alright, humor me. PrBoom 2.02 (The literal port of Boom to Windows) also runs on W10. So ReBoom (ReBoom 2.02) is pretty much a 64 bit, clean version of that, correct?

I could see the interest in that as a nice base port purely from a features point of view. Perhaps support for modern monitor resolutions, if that makes sense?

Personally i'd love a barebones Boom port that just does Boom but is clean enough to run on 64 bit.

Yes it runs on windows but nothing else (unless you use Wine).  ReBOOM will be a

clean base port yes, something that others could fork or test on etc..  without being tied to Windows.  It definitely can be improved on with widescreen support, selectable frame rates etc but the first release will be a replacement for that 21 year old binary.

[Nikku4211]

2 hours ago, Gibbon said:

ReBOOM is going to be as conservative as possible.  Yes, essentially it will be PrBOOM 2.02 without assembler.  I'm having to leave some refactored code from Lee (ticks, saving) but I'm aiming for this to be honest and authentic.  Since we are sadly devoid of any source port that did not keep Boom as it was (even PrBoom+ is more MBF than Boom nowadays).  I'm testing it on the THT wad, to ensure Boom compatibility is 100% on point.

Awesome.

 

Isn't THT made for PrBoom+, though? I mean, its levels use MBF sky transfers despite being made for -complevel 9.

 

What do you also think about emulating different versions of Boom? In the OG Boom 2.02, generalised crushers don't work, and I'm sure you want to preserve that.

[Gibbon]

48 minutes ago, Nikku4211 said:

Awesome.

 

Isn't THT made for PrBoom+, though? I mean, its levels use MBF sky transfers despite being made for -complevel 9.

 

What do you also think about emulating different versions of Boom? In the OG Boom 2.02, generalised crushers don't work, and I'm sure you want to preserve that.

Compatibility settings are a little different between MBF and Boom, so I'm basically ripping it all out, getting compat to work as it did in Boom 2.02 then adding back additional compatibility after.  THT is supposedly 'Boom compatible' so I'm using it for friction, underwater stuff, teleporters and the treadmill effect :)

[Nikku4211]

1 minute ago, Gibbon said:

Compatibility settings are a little different between MBF and Boom, so I'm basically ripping it all out, getting compat to work as it did in Boom 2.02 then adding back additional compatibility after.

Yeah, that's a good process.

2 minutes ago, Gibbon said:

THT is supposedly 'Boom compatible' so I'm using it for friction, underwater stuff, teleporters and the treadmill effect :)

The sad reality is that most maps that are called 'Boom-compatible' aren't actually 100% compatible with DOS Boom. The term is generally used more for PrBoom+-tested maps that may or may not rely on PrBoom+'s subtle extensions to Boom mapping.

 

Hopefully, ReBoom can allow people to easily test their Boom-format maps in a way that makes 'Boom-compatible' actually mean compatible with DOS Boom.

 

Also, by treadmill effect, do you mean the pusher and puller sprites or door lighting or...?

[Gibbon]

19 minutes ago, Nikku4211 said:

Yeah, that's a good process.

The sad reality is that most maps that are called 'Boom-compatible' aren't actually 100% compatible with DOS Boom. The term is generally used more for PrBoom+-tested maps that may or may not rely on PrBoom+'s subtle extensions to Boom mapping.

 

Hopefully, ReBoom can allow people to easily test their Boom-format maps in a way that makes 'Boom-compatible' actually mean compatible with DOS Boom.

 

Also, by treadmill effect, do you mean the pusher and puller sprites or door lighting or...?

The pusher puller stuff.  Boom never had door lighting according to the DOS code so that isn't there (well lighttags in p_doors.c at least). And yes, I agree testing with Boom compatible maps should mean they work on actual Boom, otherwise call it PrBoom compatible.

Edited August 20, 2021 by Gibbon

[Nikku4211]

37 minutes ago, Gibbon said:

Boom never had door lighting according to the DOS code so that isn't there (well lighttags in p_doors.c at least).

It never had door lighting?

 

I could have sworn that BoomEdit.wad had an entire room to show off door lighting:

 

I could have sworn that a few seconds ago when I used DOS Boom (2.02) to play BoomEdit.wad, the door lighting actually worked as intended.

[SilverMiner]

5 hours ago, Gibbon said:

The pusher puller stuff.  Boom never had door lighting according to the DOS code so that isn't there (well lighttags in p_doors.c at least). And yes, I agree testing with Boom compatible maps should mean they work on actual Boom, otherwise call it PrBoom compatible.

Erm, Boom HAS door lighting. I know it cuz my Boggy Region maps use this feature and in early days of its development I used Boom 2.02 to test it out.

[Gibbon]

5 hours ago, Nikku4211 said:

It never had door lighting?

 

I could have sworn that BoomEdit.wad had an entire room to show off door lighting:

 

I could have sworn that a few seconds ago when I used DOS Boom (2.02) to play BoomEdit.wad, the door lighting actually worked as intended.

I took another look, yes while I was removing the door lighttags for MBF I overlooked the original lighting that I did not diff against.

 

And thanks for the WAD!  I'll use that too.  I have PrBOOM 2.02 ported and running on my machine and this will help test it

[fabian]

From MBF.txt:

Tagged DR doors' lighting effects made gradual, instead of totally on/off

 

[Gibbon]

19 minutes ago, fabian said:

From MBF.txt:

Tagged DR doors' lighting effects made gradual, instead of totally on/off

 

Yep that is what I had, I mistakenly took it as door lighting instead of the gradual lighting.

[maxmanium]

This is excellent, I'm glad someone is finally tackling it. Will this support embedded DEHACKED lumps or is that too much?

Edited August 20, 2021 by maxmanium

[Gibbon]

2 hours ago, maxmanium said:

This is excellent, I'm glad someone is finally tackling it. Will this support embedded DEHACKED lumps or is that too much?

Appreciate it, the first release I will have as a clean base port, I will be adding lots of QoL stuff into it afterwards, same as I'm doing with Pooch but without affecting either of their historical quirks.  But as I have kept the DEH/BEX code unchanged from Pooch, it has dehacked lumps already as it came with MBF.  I thought it is better to keep it.

 

It is nearly finished though, a few windows bugs (automap crashes) but that is all really, mostly it is now ripping out MBF compatibility and adding back the BOOM compat stuff (with plenty of testing and demo watching).

Edited August 20, 2021 by Gibbon

[maxmanium]

29 minutes ago, Gibbon said:

Appreciate it, the first release I will have as a clean base port, I will be adding lots of QoL stuff into it afterwards, same as I'm doing with Pooch but without affecting either of their historical quirks.  But as I have kept the DEH/BEX code unchanged from Pooch, it has dehacked lumps already as it came with MBF.  I thought it is better to keep it.

 

It is nearly finished though, a few windows bugs (automap crashes) but that is all really, mostly it is now ripping out MBF compatibility and adding back the BOOM compat stuff (with plenty of testing and demo watching).

 

I'm happy to hear you're keeping that feature in -- definitely understandable why one might want it left out, but if you really wanted to be boom.exe compatible you had to include your .bex patch outside of the wad, which I imagine could be confusing if people don't know every other port out there loads the internal lump. Really nice to have a pure Boom port that does this now.

[Gibbon]

Yep, I hear you, there should always be benefits to small amounts of modern functionality (this is one of those benefits). Boom probably would have added it if it did not stop being developed.  TeamTNT were not absolute purists.

Edited August 20, 2021 by Gibbon

[Redneckerz]

6 hours ago, SilverMiner said:

Erm, Boom HAS door lighting. I know it cuz my Boggy Region maps use this feature and in early days of its development I used Boom 2.02 to test it out.

You should have mentioned your Bogreg executable hack! The features you added in might be useful for ReBoom! :)

6 hours ago, Gibbon said:

I took another look, yes while I was removing the door lighttags for MBF I overlooked the original lighting that I did not diff against.

 

And thanks for the WAD!  I'll use that too.  I have PrBOOM 2.02 ported and running on my machine and this will help test it

If you are going to do that, please add the following for testing your port:

• The Last Sanctuary is a interesting one because it simulates a day-night system using a stock Boom effect. 
• There is also the Boom computer, a example wad simulating a computer (adder/subtractor).
• There is also a binary counter, two versions.
• TRANMAP-FX is a package that shows what is possible through manipulation of the TRANMAP lump present in Boom. A underutilized lump, TRANMAP can be abused to produce new visual effects, though its purely done in software.

1 hour ago, Gibbon said:

Yep, I hear you, there should always be benefits to small amounts of modern functionality (this is one of those benefits). Boom probably would have added it if it did not stop being developed.  TeamTNT were not absolute purists.

That's what i thought more of ReBoom first and formost. All in the spirit of Boom but being very classic to it.

Edited August 20, 2021 by Redneckerz

[Gibbon]

As it has been coming along, I have felt that is a more suitable theme for ReBOOM.  Not being stuck but more of a 'BOOM the way TNT did' ;) kind of thing.

[SilverMiner]

46 minutes ago, Redneckerz said:

You should have mentioned your Bogreg executable hack! The features you added in might be useful for ReBoom! :)

Sadly these features were just like: make map19 end with text screen, map20 have sky3 instead of sky2, the things with doomed nums 84 and 75 drop rockets and shotguns respectively and the game ends at map24 (also there could be a secret exit at map13) iirc. All this can be easily made with mapinfo and decorate.

[Nikku4211]

7 hours ago, Gibbon said:

But as I have kept the DEH/BEX code unchanged from Pooch, it has dehacked lumps already as it came with MBF.  I thought it is better to keep it.

Oh cool. Chocolate Doom also supports DeHackEd lumps if you run with -dehlump, so this is a good idea for a ReBoom.

 

Speaking of which, I have realised that DOS Boom actually comes with a setup executable, though it's really just the generic Allegro setup executable. What do you think of ReBoom having a setup executable like Chocolate Doom does (with its own extra .cfg, of course) to let you toggle things like fullscreen and sound options?

[Gibbon]

17 minutes ago, Nikku4211 said:

Oh cool. Chocolate Doom also supports DeHackEd lumps if you run with -dehlump, so this is a good idea for a ReBoom.

 

Speaking of which, I have realised that DOS Boom actually comes with a setup executable, though it's really just the generic Allegro setup executable. What do you think of ReBoom having a setup executable like Chocolate Doom does (with its own extra .cfg, of course) to let you toggle things like fullscreen and sound options?

It should not be a big problem.

[Gibbon]

So the port is done.  
 

It is identical to DOS BOOM 2.02 in (almost) every way.  I am still testing it on the boomedit wad and a few others and fixing a few bugs that were in my ported code.

 

some things I have kept:

DeHacked lump support

old Boom demo compatibility

 

I have obviously had to keep code for video, memory allocation, wad loading and sound/net due to SDL2 and the changing from pointer to struct (for 64bit), it is about as pure a port since prboom 2.02.

 

I also ported the SDL2 ENDBOOM lump from the ENDOOM lump from Chocolate Doom (thanks Fraggle).

 

I'll do a first release tonight (CET).

Edited August 22, 2021 by Gibbon

[Redneckerz]

2 hours ago, Gibbon said:

So the port is done.  
 

It is identical to DOS BOOM 2.02 in (almost) every way.  I am still testing it on the boomedit wad and a few others and fixing a few bugs that were in my ported code.

 

some things I have kept:

DeHacked lump support

old Boom demo compatibility

 

I have obviously had to keep code for video, memory allocation, wad loading and sound/net due to SDL2 and the changing from pointer to struct (for 64bit), it is about as pure a port since prboom 2.02.

 

I also ported the SDL2 ENDBOOM lump from the ENDOOM lump from Chocolate Doom (thanks Fraggle).

 

I'll do a first release tonight (CET).

Excellent. A PrBoom 2.02 with small QoL improvements is a good base for modders alike. I assume you also have a logo? :)

[Gibbon]

19 minutes ago, Redneckerz said:

Excellent. A PrBoom 2.02 with small QoL improvements is a good base for modders alike. I assume you also have a logo? :)

I'll add a tasteful logo at release time, one that nicely updates but keeps the original recognisable.

 

I have some nice plans for the future too, things that I think TNT would have approved of.

[Redneckerz]

43 minutes ago, Gibbon said:

I'll add a tasteful logo at release time, one that nicely updates but keeps the original recognisable.

 

I have some nice plans for the future too, things that I think TNT would have approved of.

Perfect. Ill pop up a page as long as its clear what this is for and what users can/should expect.

[Gibbon]

You can count on it.  The idea is pretty solid, it will be a nice change to do some modernisation whereas Pooch is more 'maintenance' rather than more development.

[Dusty_Rhodes]

Just to be clear this a Boom equivalent of Woof? Very cool idea, I'm excited to try it out.

[Gibbon]

Yes it is.  The first release will be 95% accurate to Boom 2.02 (some configs had to go as we don't use DOS sound configs anymore).  But I plan to tastefully modernise it in releases afterwards.

Edited August 22, 2021 by Gibbon