ReBOOM 2.07um (Updated February 24th 2022)

[Nikku4211]

27 minutes ago, RedHelix said:

Also Nikku, if you go into hud options disable always show stats and you can get the prboom hud back.

Oh, okay.

 

But why should I have to do all that? I didn't have to do it in the previous version.

[Redneckerz]

9 minutes ago, Nikku4211 said:

Oh, okay.

 

But why should I have to do all that?

Its probably a one time action as its saved in the cfg because its a new option requested by RedHelix.

9 minutes ago, Nikku4211 said:

I didn't have to do it in the previous version.

Because it did not had that option.

 

[Gibbon]

49 minutes ago, Nikku4211 said:

What happened to the fullscreen HUD? It doesn't work anymore. Now when I press F5, nothing happens, and when I press the + button after the HUD's gone, the fullscreen HUD doesn't appear.

It is a config setting.  So the permanent config needs to be turned off in the HUD settings (setup menu).  Then it'll be back to normal.

 

It is a new default configuration setting.  Turn it off and it'll never bother you again :)

Edited September 14, 2021 by Gibbon

[Gibbon]

A small update before I start doing some things for Pooch.

 

UMAPINFO support (Rev 1.3g - g for gibbon :P)

 

It is Rev1.3g because while it implements all the spec up to 1.3 (ReBOOM doesn't support DeHackedEX so I cannot go higher) it does not implement this feature:

* If interbackdrop does not specify a valid flat, draw it as a patch instead

 

This is because ReBOOM does not have any kind of fullscreen patch function available and I did not want to add one for a single tiny feature.  I wanted to differentiate this so that it is not mixed up with 'all the way to 1.3'.

 

Autoloading - not done because I would have to pull in over 20 new functions from either Crispy or Woof and I really don't want to bloat the codebase for this.  I'll take a look at rolling my own implementation that isn't so large.

 

Anyway, enough talking, here are some screenshots of scythe using the scythe_um.wad and scythe2 / scythe2_um.wad

Spoiler

 

 

Scythe 2 Episode Selection

A small caveat, since ReBOOM is NOT a limit removing port, only wads that support umapinfo and do not require any limit removing ports will work.  Things like Fork in the Road will not work, regardless of umapinfo support.

 

I believe ReBOOM is the 'only' classic source port to implement it so far.

Edited September 17, 2021 by Gibbon
adding scythe 2

[Redneckerz]

3 hours ago, Gibbon said:

A small update before I start doing some things for Pooch.

 

UMAPINFO support (Rev 1.3g - g for gibbon :P)

 

It is Rev1.3g because while it implements all the spec up to 1.3 (ReBOOM doesn't support DeHackedEX so I cannot go higher) it does not implement this feature:

* If interbackdrop does not specify a valid flat, draw it as a patch instead

 

  Hide contents

 

 

This is excellent and exactly in the spirit of TeamTNT: A clear Q-o-L improvement without DEHEXTRA, but which is usefull all the way around. Ill make sure the wiki gets updated on this. UMAPINFO is one of those things that just makes a wholle lotta sense even in a conservative context, which is the goal of ReBoom.

 

Thank you.

[Gibbon]

12 minutes ago, Redneckerz said:

This is excellent and exactly in the spirit of TeamTNT: A clear Q-o-L improvement without DEHEXTRA, but which is usefull all the way around. Ill make sure the wiki gets updated on this. UMAPINFO is one of those things that just makes a wholle lotta sense even in a conservative context, which is the goal of ReBoom.

 

Thank you.

 

Thanks, it is also useful for those modders who want to use UMAPINFO and stay relatively vanilla (in scope at least).  Until now (well until the next release anyway) they had no way to test UMAPINFO on anything other than limit removing advanced source ports.

Edited September 17, 2021 by Gibbon

[Gibbon]

@fabian - a question actually since you would know more about it.  Since ReBOOM does not support it, if I removed the MBFHelperDog ActorName from the ReBOOM UMAPINFO implementation, would this constitute a breakaway from the standard?

 

Naturally, this is something I cannot support, since Boom never had helper dogs.

Edited September 17, 2021 by Gibbon

[maxmanium]

A few things:

 

- ReBOOM always starts in a tiny window. Can you make it always start in full screen?

- Attempting to bind right-click to a key just backs out of the current menu, and attempting to bind the middle mouse click just interprets it as "junk."

- It currently does not launch without specifying an absolute path to the iwad. Can you add support for DOOMWADDIR and DOOMWADPATH?

- Can the console output be made optional, perhaps via a command-line parameter?

- Can the ENDOOM\ENDBOOM lump be disabled via an option?

Edited September 17, 2021 by maxmanium

[Gibbon]

11 minutes ago, maxmanium said:

A few things:

 

- ReBOOM always starts in a tiny window. Can you make it always start in full screen?

- Attempting to bind right-click to a key just backs out of the current menu, and attempting to bind the middle mouse click just interprets it as "junk."

- It currently does not launch without specifying an absolute path to the iwad. Can you add support for DOOMWADDIR and DOOMWADPATH?

- Can the console output be made optional, perhaps via a command-line parameter?

- Can the ENDOOM\ENDBOOM lump be disabled via an option?

1. I can make full screen default, no issues with that.  Consider it done.

2. Known issue, I am still tracking this down.  The right mouse button is hard coded to go back but I can change this.

3. Nice thought, I'll take a look at it and see.

4. Not sure, invoking it via command line naturally will print all the data.  I'll try a few other source ports but I am sure most still print the data as it goes.

5. I can wrap it up so the popup does not show yes.

[Gibbon]

On 8/29/2021 at 10:51 PM, P41R47 said:

Hey, pal!
I didn't see it anywhere, but i didn't looked too deeply, so i will ask about it.
Is there any chance to fix the monster falling from ledges problem that boom has?
I know it was in the code to fix it, but for some reasons, it wasn't implemented by Team TNT.
I think not even MBF implemented it, but i may be wrong.
Anyway, i think that it would be a good thing to fix since it plagued boom mapsets since long.

Maybe, it is a Boom bug.  I know I intentionally ported it over to make it more authentic, because after all, fixing all the bugs Boom has would not make it useful for testing Boom compatibility.

[Redneckerz]

5 hours ago, Gibbon said:

 

Thanks, it is also useful for those modders who want to use UMAPINFO and stay relatively vanilla (in scope at least).  Until now (well until the next release anyway) they had no way to test UMAPINFO on anything other than limit removing advanced source ports.

So 2.05 will be the UMAPINFO release :) Will be great!

[Gibbon]

It will be indeed, have to iron a few bugs out for demo playback but that'll be the one.  When it's done :)

[Gibbon]

@maxmanium

Fullscreen is now default and I added a menu item for it.  In the next release it'll be there.

 

I also did some cleaning and fixing of the UMAPINFO implementation, it goes up to Rev 1.4 (Skipping Rev 1.3 as that isn't implemented).  

[Nikku4211]

11 hours ago, Gibbon said:

A small caveat, since ReBOOM is NOT a limit removing port, only wads that support umapinfo and do not require any limit removing ports will work.  Things like Fork in the Road will not work, regardless of umapinfo support.

  

 I believe ReBOOM is the 'only' classic source port to implement it so far.

I'm kind of conflicted.

 

One 1 hand, UMAPINFO does make things more convenient for mapmakers.

 

On the other hand, implementing it does make the source port feel a bit less like Boom to me, since Boom's limitations are a big part of the feel, including the map limitations. Maybe I'm just too used to DOS Boom.

 

Something like this really is the split between 'Chocolate Boom' and 'a continuation of Boom if it didn't turn into MBF'.

 

I mean, can you imagine what would happen if Chocolate Doom implemented support for UMAPINFO?

 

But whatever, it's your port, and at least it's still 99% accurate to DOS Boom.

Quote

Fullscreen is now default and I added a menu item for it.  In the next release it'll be there.

Finally. Now I don't have to constantly type '-fullscreen'.

Edited September 17, 2021 by Nikku4211

[Gibbon]

To me, it's just a format definition.  If you want 100% Boom then use -numapinfo and it will be ignored.

 

The only reason they never had it was because their development died off 20 years ago.  Choco won't have it because it isn't their goal (to be 100% vanilla).  ReBOOM could never be 100% Boom because all the input, sound, video, memory allocation and dehacked support is not 100% original and can never be.

 

It is still the most Boom-like source port in existence (that is developed).

 

And yes, that full screen thing was a long time coming :)

[Gibbon]

A few more updates today:

 

1. Fixed the mouse bug returning 'junk'.  This required a complete rewrite of all input code (all Boom input code is gone).

2. Added the CLEAR 'DEL' key from Woof in the key bindings menu

3. Removed the 'reset to defaults' button in key bindings

4. Default mouse vertical sensitivity is zero and default horizontal sensitivity is 15 (increase x3)

5. Added mouse acceleration

6. Added weapon switching using the mouse wheel

 

EDIT

7. Added option to turn off the ENDBOOM lump popup

 

About the wad dir and wad path stuff.  I'll take a look.

Edited September 18, 2021 by Gibbon

[maxmanium]

Thanks for your continued work on this!

 

I noticed that TNT's MAP02 still exhibits this bug with the music. Is it possible to fix?

[Gibbon]

11 minutes ago, maxmanium said:

Thanks for your continued work on this!

 

I noticed that TNT's MAP02 still exhibits this bug with the music. Is it possible to fix?

Since it is just MUS and isn't gameplay bugs that keep Boom compatibility, I have pushed a fix for clamping the values.  I tested it, plays fine now.

 

I also have added support for DOOMWADDIR and DOOMWADPATH too.  Apart from the command line writing, I think that is everything you listed as annoyances, fixed :)

[Gibbon]

A few new things to prepare for an awesome first umapinfo release when it is time:

 

1. More readable status colours (for the always on stats

2. Default size of the game window is now 'SUPERMAX_SCREENWIDTH/HEIGHT' -> 800x600.  This does not affect the rendering which is still 320x200.  This means you won't get a teeny weeny window anymore and have to manually resize.

3. Default window position to be more centered on the screen when starting

4. bug fix - I accidentally added zombies cannot exit levels, which Boom never prevented.  This is now removed

 

I will release for Windows, a release candidate later.  Then fine tune a few things afterwards if needed. (this post will be edited once the RC is done).

 

EDIT: Release candidate 1 of 2.05um is here:

https://github.com/atsb/ReBOOM/releases/tag/205um_rc1

 

Windows 64bit only.

Edited September 19, 2021 by Gibbon

[maxmanium]

OK, some things about the release candidate:

 

- Did you change the mouse code? No big deal, but I did have to reduce the mouse sensitivity by a factor of 5 (from 15 to 3) -- 15 is ridiculously fast now.

- The command line writing is gone, so I'm not sure if that was intentional given your previous post, but I'm not complaining.

- ReBOOM seems to get stuck or otherwise never start if I try to launch it with a -file without an absolute path -- this is presumably related to DOOMWADDIR and DOOMWADPATH. It happens with both iwads and pwads so it presumably affects both environment variables.

 

OK, it actually seems to work for pwads but not iwads. The pwad I tested first is one I'm making so there's probably something wrong with it.

 

- Although the keys themselves work fine, the defaults in the following screenshot read "junk" when they should be the function keys (F1 - F9 I believe). Print screen also reads as "junk."

 

Spoiler

 

- Speaking of screenshots, you should probably strip the code related to PCX and BMP screenshots and just make PNG's instead since the former two aren't useful nowadays for pure screenshots.

 

Sorry if it seems like I'm piling stuff on you -- just want to give helpful feedback!

Edited September 19, 2021 by maxmanium

[Gibbon]

Good stuff.

 

1. Yes it was intentional, for Windows I built it as a windows program instead of a console one.  To remove the cmd interface. And about the mouse, perfect this is what I wanted.  I have a high dpi mouse so tiny flicks is good for me, maybe not a great default.  Ill drop it down to 5.

 

2. I tested that on Mac and Linux and it works, for Windows it is stuck looking in some registry paths, steam or gog.  I might add an additional option for checking C:\Doom or something too.

 

3. Junk is when the keys are undefined.  This is because the default keys are not what they should be.  I'll fix that in the m_misc.c.  If you rebind them it'll work fine.

 

4. Yeah I thought about this, it does make a lot of sense.

 

No worries, this is why I wanted an RC.  I can test it all I want but more eyes and different styles of usage is a better test than me just going through some set things.

 

EDIT:

 

1. Mouse sensitivity is reduced to 5 and autorun is enabled by default

2. Registry paths work if you use '-iwad' lowercase doom.wad/tnt.wad etc..

3. Fixed, all keys are now displayed correctly

4. Implemented.  PCX and BMP screenshots are removed and PNG screenshots are the only possibility.  This also required adding SDL_Image as a dependency

 

You'll find an updated RC1 in the same place :)

Edited September 19, 2021 by Gibbon
bugs fixed

[maxmanium]

Looks like the DOOMWADPATH stuff isn't working for the -deh parameter. Otherwise, it works most of the time, but sometimes I have to re-enter the same command to get it to launch.

[Gibbon]

2 hours ago, maxmanium said:

Looks like the DOOMWADPATH stuff isn't working for the -deh parameter. Otherwise, it works most of the time, but sometimes I have to re-enter the same command to get it to launch.

Is it supposed to?  I don't know that much about it but the code of d_iwad.c is pretty clear.  Does crispy do it?  
 

Yeah I had to do that too, it is quite an unreliable piece of code.  I'll see about taking the one from choco instead, but they are all very similar.

Edited September 20, 2021 by Gibbon

[maxmanium]

3 minutes ago, Gibbon said:

Is it supposed to?  I don't know that much about it but the code of d_iwad.c is pretty clear.  Does crispy do it?  

 

Yessir, Crispy does it. Admittedly not all ports do tho, a fact that I skipped over when making that post. If you want to see for yourself, I tested it with Vile Flesh, which does not have the DEHACKED patch embedded within the wad.

[Gibbon]

4 hours ago, maxmanium said:

 

Yessir, Crispy does it. Admittedly not all ports do tho, a fact that I skipped over when making that post. If you want to see for yourself, I tested it with Vile Flesh, which does not have the DEHACKED patch embedded within the wad.

I'll do that.  Then I will pinch the crispy version and test again.  Thanks!

 

EDIT: No it is not possible at all to take the crispy / choco version.  The implementation is just too different, after 1 hour of merging I had ended up pulling over 3500 lines from crispy and it still was not done.  It was a real rabbit hole, so I used the latest version from Woof, which doesn't have these 'DEH_' functions in d_iwad.c.  So that is what I'm using as a baseline.

Edited September 20, 2021 by Gibbon

[Gibbon]

ReBOOM 205um is released!

 

Binaries for Windows/Linux

 

List of changes:

1. Optional UMAPINFO support (up to rev 2)
2. Cleaned up critical bugs in the code (undeclared open/close/access etc..) on Windows
3. Other optimisations improving the stability and running of ReBOOM
4. Shareware release won't work due to registered FLAT19 used for background in the setup menu
5. DOOMWADDIR is taken correctly as part of the -iwad search params
6. int_64_t and uint_64_t (taken from DSDA) now replaces long long and unsigned long long integers
7. Default compiler standard is moved to C11
8. Inline C functions replace some older static functions
9. Replaced MIN/MAX math with a better inline function equivalent
10. Windows no longer displays the console window
11. Overhauled input code to fix 'JUNK' errors on the menu
12. Added options for fullscreen and showing the ENDBOOM lump or not
13. Default config changes (run set to on, endboom lump set to off, fullscreen set to on)
14. Added the Berserk tint not changing until the level ends (from Doom Retro)

This release was tested quite significantly on Windows.

 

Sadly, this is the first release that, in order to implement the cleaning, updates and refactoring that I wanted, I had to temporarily drop MacOS support.  I changed the file handling somewhat and as I am not using Cocoa, Foundation frameworks or any native handling (as you can see in PRBoom+ for example) it was always a bit janky.  Support will return in a future release.

 

The main code repository was moved from github to repo.or.cz:

https://repo.or.cz/reboom.git

 

As part of the UMAPINFO addition, I created a test WAD so that I could ensure the implementation was correct.  See wads/umapinfo_example/BIGBADABOOM.WAD/TXT.

 

Edited September 27, 2021 by Gibbon

[xX_Lol6_Xx]

Nice. I can't wait to test it out :D

[Redneckerz]

Interesting to see UMAPINFO in, a modern feature that still would fit the TeamTNT spirit.

 

The affected wiki pages for this and Pooch will be updated accordingly. Congrats with yet another worthwhile contribution, Gibbon!

[Gibbon]

3 hours ago, Redneckerz said:

Interesting to see UMAPINFO in, a modern feature that still would fit the TeamTNT spirit.

 

The affected wiki pages for this and Pooch will be updated accordingly. Congrats with yet another worthwhile contribution, Gibbon!

I admit I was very nervous about adding it, but seeing that UMAPINFO was assumed to be only on advanced engines made me want to do it.  But I made sure it is optional and it won't affect Boom demo's if you use -numapinfo.

 

One thing I disliked about the spec was the assumption that every port has MBF features, which to me was a total 'wtf' moment.  Admittedly until now there was no 'Boom' in the historic sense and so MBF features were in every source port that wanted it.  Obviously, I turned that upside down with ReBOOM and so one thing to point out is that the MBFHelperDog actor type is removed.

 

I will also start doing monthly updates since now ReBOOM really needs to have a refactor.  I've patched it as much as I can but there is old code there that basically has to go.  I'll do this in a private branch as it will be broken for a long time I think :) but for proper cross platform portability it has to happen.  It's going to be kick ass at the end of it though, no other features just getting it 100% perfect.

[Astronomical]

I like Umapinfo because I hate MBF Sky Transfers because I can never seem to get it to actually work.  It always displays the corpse texture in map 16 as the skybox for whatever reason no matter what I set it as.