ReBOOM 2.07um (Updated February 24th 2022)

[Gibbon]

So here it is, after 7 days of porting and after 21 years, a new release directly ported from BOOM 2.02 is done:

 

https://github.com/atsb/ReBOOM/releases/tag/2.03

 

ReBOOM is an 'almost' completely faithful direct port of BOOM 2.02

 

What is new:

 

* DeHacked embedded lump support (from MBF)

* Old Boom demo compatibility

* Windowing, Sound, Video, Memory allocation, Wad stuff, DEH/BEX code is updated to be 64bit compatible and using SDL2

* A new cheat code (legend)

 

Everything else (bar a few missing configs) is the same as you will remember.  Versioning begins at 2.03 to signal the continuation albeit, with a new name.

 

ReBOOM will continue to be developed tastefully, in the spirit of TeamTNT. Expect awesome modernisations to come in future releases.

 

Binaries for Windows, Linux and Mac (Intel).  ReBOOM runs on M1 Macs and a binary will be done later.

 

Enjoy it :)

 

[Redneckerz]

41 minutes ago, Gibbon said:

So here it is, after 7 days of porting and after 21 years, a new release directly ported from BOOM 2.02 is done:

 

https://github.com/atsb/ReBOOM/releases/tag/2.03

 

ReBOOM is an 'almost' completely faithful direct port of BOOM 2.02

 

What is new:

 

* DeHacked embedded lump support (from MBF)

* Old Boom demo compatibility

* Windowing, Sound, Video, Memory allocation, Wad stuff, DEH/BEX code is updated to be 64bit compatible and using SDL2

* A new cheat code (legend)

 

Everything else (bar a few missing configs) is the same as you will remember.  Versioning begins at 2.03 to signal the continuation albeit, with a new name.

 

ReBOOM will continue to be developed tastefully, in the spirit of TeamTNT. Expect awesome modernisations to come in future releases.

 

Binaries for Windows, Linux and Mac (Intel).  ReBOOM runs on M1 Macs and a binary will be done later.

 

Enjoy it :)

 

Congrats on yet another port ! :) Ill be testing this out.

 

The cross-platform releases are a nice addition!

By the way, and just to tease you, there was already a Boom 2.03 ;)

 

Spoiler

It was unofficial, though. And it was/is unreleased. Its by the same guy that made MBF 2.04 (Gerwin).

EDIT: See follow up post. This release has some nooks and crannies.

Edited August 22, 2021 by Redneckerz

[Gibbon]

1 minute ago, Redneckerz said:

Congrats on yet another port ! :) Ill be testing this out.

By the way, and just to tease you, there was already a Boom 2.03 ;)

 

  Hide contents

It was unofficial, though. And it was/is unreleased. Its by the same guy that made MBF 2.04 (Gerwin).

 

Good thing it was unofficial is the source available?  I'll want to compare and see what things he added.

[Redneckerz]

1 minute ago, Gibbon said:

Good thing it was unofficial is the source available?  I'll want to compare and see what things he added.

Very. Very minor things. Send me a Private Message for that. Also see original post for the issue.

[Redneckerz]

EDIT: Okay, the release is not going according to expectations:

Reporting an issue - SDL2_mixer.dll is not found nor present in the release, so for the moment the zip expects that users have this.

 

After that it complains SDL2.dll is not found.

 

And after that, SDL2_net.dll. I have to pull the zips from each before ReBoom would start.

 

Now with these 3 DLL's added, ReBoom crashes upon start with 0xc0000007b error.

 

My system:

Core i5-4590T
16 GB DDR3

Windows 10 21H1

Intel HD 4600

[Gibbon]

Attached them just now.  I totally forgot to include those!

 

We also have the same system :)

[Redneckerz]

18 minutes ago, Gibbon said:

Attached them just now.  I totally forgot to include those!

 

We also have the same system :)

Well call that ironic ;) Or maybe it ws meant to be :) Thanks! It works.

 

Some first impressions:

• Starts in 320x200, which is just so tiny (But as expected!)
• Clicking the expand button brings it up almost fullscreen, but not quite
• 35 fps is pretty much maxed here
• Adjusting width and height does not seem to work, even when using the console. PrBoom 2.02 allowed up to 1600x1200 to be defined, but ReBoom does not seem to do this: It just launches in 320x200 instead.
• The executable bears no icon (I am just nitpicking here) :P

Other than that, it plays rather stable, full sound and all.

[Gibbon]

13 minutes ago, Redneckerz said:

Well call that ironic ;) Or maybe it ws meant to be :) Thanks! It works.

 

Some first impressions:

• Starts in 320x200, which is just so tiny (But as expected!)
• Clicking the expand button brings it up almost fullscreen, but not quite
• 35 fps is pretty much maxed here
• Adjusting width and height does not seem to work, even when using the console. PrBoom 2.02 allowed up to 1600x1200 to be defined, but ReBoom does not seem to do this: It just launches in 320x200 instead.
• The executable bears no icon (I am just nitpicking here) :P

Other than that, it plays rather stable, full sound and all.

I did not add 1600x1200 as that was an addition done by the person who ported it to windows, while I used the DOS version as my guide.  However I will be using that 1600x1200 for the next release (as well as uncapping the framerate).

 

Yeah, no icon.  I'm not a visual studio pro and Windows for me is a 'build, release and go back to Linux'.  I don't use it as my main OS.  But I'll be happy to accept advice how to do it.

[maxmanium]

Also for Windows support (though I assume it's not an exclusive thing) it'd be nice to have DOOMWADDIR and DOOMWADPATH support. :)

[Gibbon]

Good stuff, I'll add it to my list

[Redneckerz]

1 hour ago, Gibbon said:

I did not add 1600x1200 as that was an addition done by the person who ported it to windows, while I used the DOS version as my guide.  However I will be using that 1600x1200 for the next release (as well as uncapping the framerate).

For gigglew, native res for me also does not work 1280*1024. I guess also not part of og Dos?

1 hour ago, Gibbon said:

 

Yeah, no icon.  I'm not a visual studio pro and Windows for me is a 'build, release and go back to Linux'.  I don't use it as my main OS.  But I'll be happy to accept advice how to do it.

Perhaps @Charlie Love can help as he cooked up a logo for his port FDWL.

[Gibbon]

1 minute ago, Redneckerz said:

For gigglew, native res for me also does not work 1280*1024. I guess also not part of og Dos?

Perhaps @Charlie Love can help as he cooked up a logo for his port FDWL.

Correct.  Nothing except 320x200 initially (to have a clean base).

 

Maybe he can, it would be nice to have a little logo.

[Charlie Love]

2 hours ago, Gibbon said:

Correct.  Nothing except 320x200 initially (to have a clean base).

 

Maybe he can, it would be nice to have a little logo.

Something kind of like this?

 

(I'm not really an artist; it's merely a means to an end)

reboomv1.zip

[Gibbon]

It is more about the compiling the icon into the executable.  No idea how to set it up in visual studio..  I know its resource files but thats about it :)

[Giomancer]

Just to make sure I got all this clear:

 

I want to target Boom, I use ReBoom.

I want to target MBF, I use Pooch.

I want Boom with extras, I target PrBoom+.

I want MBF with extras, I target Woof!.

 

I'm cool with this. I'll have to update my target list, though.

[Gibbon]

That is correct yes

[Charlie Love]

8 hours ago, Gibbon said:

It is more about the compiling the icon into the executable.  No idea how to set it up in visual studio..  I know its resource files but thats about it :)

Well, that's what I get for skimming haha. I was able to get the icon changed by changing dsda-doom.ico references to fdwl.ico (and clearing my build folder). In your case, since you're using visual studio you appear to have a much easier solution.

[Gibbon]

Thanks, I will take a look.  

[Gibbon]

So 2 modern commits today:

 

https://github.com/atsb/ReBOOM/commits/main

 

Contains:

 

1. Adding hardware acceleration via page flipping and adding vsync (smooths out the 35fps cap).  Both are hardcoded to be permanently on.

 

2. Hires is implemented as a permanent increase of the renderer.  320x200 is removed completely.  I am experimenting with doubling that too, 640X400 is not really hires is it..

 

Edit: I have also removed the static limits.  I went a bit bananas and raised them to astronomical levels (effectively removing them).  It loads SIGIL but cannot start the episode.

 

Final thing for today, I ported the -pistolstart argument from FDWL and fixed a bug with doors and zombies

Edited August 23, 2021 by Gibbon

[maxmanium]

So, is this gonna be more like a Crispy Boom?

 

Also, when I try to change the mouse binds in the key binding menu the game crashes.

[Gibbon]

1 minute ago, maxmanium said:

So, is this gonna be more like a Crispy Boom?

 

Also, when I try to change the mouse binds in the key binding menu the game crashes.

Something like that yes, but I consider it a continuation.  I mean really, apart from historic stuff, there is no reason to keep 320X200 around, so off it goes.

 

Thanks for that, I was fiddling with the menus during the porting and I never checked the mouse as I use the keyboard.  I will have that fixed.

[Gibbon]

Today I have a few things planned.  
 

1. SIGIL support (Sigil's dehacked compat patch does not work with actual Boom, I doubt Romero thought anyone would port 21 year old code).  So I will port a cleaner dehacked from crispy or woof and I will also add 'hopefully today' MAPINFO support too.

2. I am working on an unlimited framerate but the porting I have done destroys the framebuffer, so things like r_draw and v_video need significant refactoring to support it

3. Freedoom will be added to the list of standard WAD files

[Gibbon]

So I got at least 2 things done today:

 

https://github.com/atsb/ReBOOM

 

1. SIGIL support is done (MBF21 and DeHacked Extended support).  Initial deh.c was taken from Woof but the functions themselves were taken from DSDA (with a few changes), so thanks to both of those great projects.

2. Freedoom 1 and 2 are now first class citizens and are added to the default list of wads to be played by default if found.

3. m_menu.c was refactored to fix bugs with window scaling and keybindings

4. Code cleanups to reduce warnings

 

A few bugs remain but these will be ironed out in the next few days.

 

I have a preview hotfix release (windows only):

https://github.com/atsb/ReBOOM/releases/tag/2.03.1

 

phew!

[RedHelix]

Hey thanks gibbon for your hard work, I love using these old source ports and I'm going to start using ReBoom as my main one now, I played through the first few levels on tnt and didnt notice any major bugs at all. One question though, is why do the imps fireballs look different? Is that a boom specific thing? They're like redder and kind of see through.

[Gibbon]

45 minutes ago, RedHelix said:

Hey thanks gibbon for your hard work, I love using these old source ports and I'm going to start using ReBoom as my main one now, I played through the first few levels on tnt and didnt notice any major bugs at all. One question though, is why do the imps fireballs look different? Is that a boom specific thing? They're like redder and kind of see through.

Thanks, I love these old engines too.  Modern doesn't always mean better.

 

That was one of the bugs that I am trying to track down.  It looks worse on SIGIL.  One of the banes of heavy development.  I'm getting it to be rock solid now though, then onto widescreen support.

[Nikku4211]

I've tried the release version of ReBoom and I tried to change the options in the settings, but for some reason ReBoom didn't save the config, so every time I start the application, it always resets to the default configuration.

 

This also means I can't set the horizontal mouse sensitivity value to a high enough value, since even the maximum value is not sensitive enough for me, and doesn't feel as sensitive as when I run the original Boom under DOSBox with the same mouse sensitivity settings.

 

I've tried running ReBoom with my primary monitor set to different resolutions, but even then, I could not tell if my resolution was impacting the mouse sensitivity or not.

 

Specs:

- Core i5-4460S at 2.9 GHz

- 8 GB RAM

- Intel HD Graphics 4600

- Windows 10 20H2

On 8/23/2021 at 4:41 PM, maxmanium said:

So, is this gonna be more like a Crispy Boom?

 

On 8/23/2021 at 4:46 PM, Gibbon said:

Something like that yes, but I consider it a continuation.  I mean really, apart from historic stuff, there is no reason to keep 320X200 around, so off it goes.

Wait, I thought ReBoom was going to be a Chocolate Boom like I was trying to suggest earlier. PrBoom+'s -cl 9 already feels like a Crispy Boom to me.

 

Also, it would be nice if you had the option to switch between 320x200 and other resolutions. When I play Crispy Doom, Pooch, Woof, and PrBoom+, I have them set to 320x200, even though the ports support higher resolutions.

 

320x200 is an aesthetic that some people (like me) are into.

On 8/23/2021 at 9:50 AM, Gibbon said:

Edit: I have also removed the static limits.  I went a bit bananas and raised them to astronomical levels (effectively removing them).  It loads SIGIL but cannot start the episode.

What do you think about having a compatibility mode that temporarily reinstates those limits?

14 hours ago, Gibbon said:

Modern doesn't always mean better.

I agree, modern doesn't always mean better.

[Gibbon]

2 hours ago, Nikku4211 said:

I've tried the release version of ReBoom and I tried to change the options in the settings, but for some reason ReBoom didn't save the config, so every time I start the application, it always resets to the default configuration.

 

This also means I can't set the horizontal mouse sensitivity value to a high enough value, since even the maximum value is not sensitive enough for me, and doesn't feel as sensitive as when I run the original Boom under DOSBox with the same mouse sensitivity settings.

 

I've tried running ReBoom with my primary monitor set to different resolutions, but even then, I could not tell if my resolution was impacting the mouse sensitivity or not.

 

Specs:

- Core i5-4460S at 2.9 GHz

- 8 GB RAM

- Intel HD Graphics 4600

- Windows 10 20H2

 

Wait, I thought ReBoom was going to be a Chocolate Boom like I was trying to suggest earlier. PrBoom+'s -cl 9 already feels like a Crispy Boom to me.

 

Also, it would be nice if you had the option to switch between 320x200 and other resolutions. When I play Crispy Doom, Pooch, Woof, and PrBoom+, I have them set to 320x200, even though the ports support higher resolutions.

 

320x200 is an aesthetic that some people (like me) are into.

What do you think about having a compatibility mode that temporarily reinstates those limits?

I agree, modern doesn't always mean better.

Thanks fir the feedback.  Yes ReBoom is to stay 'unbloated' but still developed within reason (adding things I believe would have been added if it was never abandoned).

 

This bug is on Windows?  I test on Linux as it is my main machine and there were no issues.  I will take a look.

 

I can add the resolution back as a choice no problem.

 

As far as I am aware, static limits do not hamper compatibility.  ReBoom will only ever be compatible with other Boom (not prboom) demo's so if those are unaffected then the limits will remain.  The static limits are C preprocessor macros and are not easily transferred to a switchable configuration.

 

EDIT: I will experiment with setting them as integers and adding some configurable values to the config file, however it would mean people would need to know the static values and input them as integers.  For most I think this is unreasonable.

 

Also, what do you think about widescreen and 60/120/144hz rendering?  Yay or nay?

 

Really appreciate the feedback too.

Edited August 25, 2021 by Gibbon

[Gibbon]

On 8/23/2021 at 10:41 PM, maxmanium said:

So, is this gonna be more like a Crispy Boom?

 

Also, when I try to change the mouse binds in the key binding menu the game crashes.

Fixed that now in the latest commit. Thanks!

[Nikku4211]

3 hours ago, Gibbon said:

Also, what do you think about widescreen and 60/120/144hz rendering?  Yay or nay?

 

I'm kind of a purist so I wouldn't really use them, but I'm sure a lot of people would like support for all of them in a Crispy Boom.

 

3 hours ago, Gibbon said:

As far as I am aware, static limits do not hamper compatibility.  ReBoom will only ever be compatible with other Boom (not prboom) demo's so if those are unaffected then the limits will remain.

It's just that without static limits in ReBoom, you'd have to set up a weird configuration with DOSBox every time you want to run your level in OG Boom from the level editor and guarantee DOS Boom compatibility. That was part of why Chocolate Doom/ChocoRenderLimits was necessary in the first place. Setting paths for DOS Boom using both DOSBox's configurations and the level editor(in my case Ultimate Doom Builder)'s configurations would be pretty inconvenient.

[Gibbon]

1 hour ago, Nikku4211 said:

I'm kind of a purist so I wouldn't really use them, but I'm sure a lot of people would like support for all of them in a Crispy Boom.

 

It's just that without static limits in ReBoom, you'd have to set up a weird configuration with DOSBox every time you want to run your level in OG Boom from the level editor and guarantee DOS Boom compatibility. That was part of why Chocolate Doom/ChocoRenderLimits was necessary in the first place. Setting paths for DOS Boom using both DOSBox's configurations and the level editor(in my case Ultimate Doom Builder)'s configurations would be pretty inconvenient.

Understood that, I will work on something nice.