ReBOOM 2.07um (Updated February 24th 2022)

[Nikku4211]

1 minute ago, Gibbon said:

Understood that, I will work on something nice.

Oh cool, thanks.

[Gibbon]

Latest commit does the following:

 

Keeps some new things (pistol start, page flipping, vsync and bug fixes for menus).  Vsync and page flipping are now config enabled so it is user selectable (thanks again to Woof for more code snippets).

 

I have reverted the static limit change, the MBF21 and Dehacked EX support and the hires change.  The memory allocation was not quite there for these changes on a largely 21 year old codebase and it introduced a whole truckload of render issues and segfaults on memory.  At least the history is there on 'how to add MBF21 to BOOM' :)

 

This commit is now largely stable and differs only slightly from DOS Boom (compatibility remains intact).

 

Known bugs:

Changing the screen size results in a segfault.

 

I will now work on refactoring the code to be up to modern standards.  For me, a large part of what makes source ports amazing is the code sharing that goes around between them, the collaboration.  This is not possible due to the limitations of the port (it is literally BOOM code).  So this will be done to ensure an amazing future for it, without sacrificing DOS Boom compatibility.

 

I have added a new zip in the same hotfix release link as yesterday with 'no_mbf21' in the filename.  Windows only.

 

[Nikku4211]

 

So apparently, the application is trying to read 'r/reboom.cfg' instead of just 'reboom.cfg'.

 

What is this r/ supposed to be? I am not familiar with Linux.

 

I think this is why ReBoom fails to load its cfg file on Windows.

[P41R47]

any chance to keep the 320x200 resolution?

Its the original resolution, and would be cool to have it at least.

Since the hardware resolution is hardcoded, i suppose there will be no software version, right?

Not only me, but there are a lot of members that plays on, and prefer, the software renderer.
Just a suggestion as to make it more appealing to the general public.

[Gibbon]

59 minutes ago, Nikku4211 said:

 

So apparently, the application is trying to read 'r/reboom.cfg' instead of just 'reboom.cfg'.

 

What is this r/ supposed to be? I am not familiar with Linux.

 

I think this is why ReBoom fails to load its cfg file on Windows.

Beautiful..  I love windows.  I'll take care of that

[Gibbon]

48 minutes ago, P41R47 said:

any chance to keep the 320x200 resolution?

Its the original resolution, and would be cool to have it at least.

Since the hardware resolution is hardcoded, i suppose there will be no software version, right?

Not only me, but there are a lot of members that plays on, and prefer, the software renderer.
Just a suggestion as to make it more appealing to the general public.

The page flipping is only making the software renderer be used by the gpu so it runs smoother.

 

I can tell you, I'll never change the doom software renderer, it is how Doom is meant to be.  I am probably OpenGL's number one hater, but that is for another thread ;) Boom is in safe hands.

[Nikku4211]

29 minutes ago, Gibbon said:

I can tell you, I'll never change the doom software renderer, it is how Doom is meant to be.

Yeah, all those TRANMAP tricks are simply not possible on a typical hardware renderer, unless you mess with shaders.

Spoiler

 

 

[Gibbon]

Transmaps are just beautiful!

 

So the issue is due this this:

Quote

sprintf(basedefault, "%s/%s.cfg", D_DoomExeDir(), D_DoomExeName());

Apparently it would seem Windows is not correctly adding a ./ to the current dir as it is in DoomExeDir.  It is adding some erroneous junk.  I'll just hardcode it and remove that.  Easiest way to please every platform.

 

EDIT: Fixed it with a better implementation.  Windows needs a %s<name> instead of %s/%s<name>.  Pushed a new binary with the same zip name.

 

Thanks for the bug!

Edited August 25, 2021 by Gibbon

[Redneckerz]

1 hour ago, Nikku4211 said:

Yeah, all those TRANMAP tricks are simply not possible on a typical hardware renderer, unless you mess with shaders.

  Hide contents

 

 

 

What in the devils horns name is that WAD from because that effect is just so good. Basically TRANMAP abuse is like writing a shader for the software renderer. Because that looks sick.

[Nikku4211]

3 minutes ago, Redneckerz said:

What in the devils horns name is that WAD from because that effect is just so good. Basically TRANMAP abuse is like writing a shader for the software renderer. Because that looks sick.

The TRANMAP effect is TRANSADD from Essel's TRANMAP-FX.

 

The WAD in the image is a new version of my 2015 Doom 2 map pack BoomHor I'm currently working on that tries to clean up some things while trying to preserve what 12-year old me wanted.

[Gibbon]

7 minutes ago, Nikku4211 said:

The TRANMAP effect is TRANSADD from Essel's TRANMAP-FX.

 

The WAD in the image is a new version of my 2015 Doom 2 map pack BoomHor I'm currently working on that tries to clean up some things while trying to preserve what 12-year old me wanted.

Now I feel old :)

[Redneckerz]

2 hours ago, Nikku4211 said:

The TRANMAP effect is TRANSADD from Essel's TRANMAP-FX.

 

The WAD in the image is a new version of my 2015 Doom 2 map pack BoomHor I'm currently working on that tries to clean up some things while trying to preserve what 12-year old me wanted.

Hah, nice. I am glad that WAD works the way it does, when i uploaded it, i couldn't test if it even worked, so im glad it does.!

[Gibbon]

28 minutes ago, Redneckerz said:

Hah, nice. I am glad that WAD works the way it does, when i uploaded it, i couldn't test if it even worked, so im glad it does.!

The tranmap stuff was the best stuff to port, I did not have to change anything, was right out of 2.02.

 

Speaking of which, I spent the last 2 hours rewriting some parts of r_draw to fix the resizing and background bugs and I ported the memory management from prboom+.  I am in Love with the memory overlay in-game while debugging it.  Just beautiful.  I also restructured some parts to more easily port changes from the prboom family (dsda and fdwl).

 

Every known bug is fixed except the mouse binding which reports 'junk' (unless you use the config file).

 

I'll now play through tnt, some wads and watch a ton of demo's before a good solid release candidate is done.

[Nikku4211]

14 hours ago, Gibbon said:

The tranmap stuff was the best stuff to port, I did not have to change anything, was right out of 2.02.

I agree, Tranmap really does allow you to do clever stuff, thanks to the way the TNT team coded it.

 

14 hours ago, Gibbon said:

Every known bug is fixed except the mouse binding which reports 'junk' (unless you use the config file).

 

I'll now play through tnt, some wads and watch a ton of demo's before a good solid release candidate is done.

I know you prefer to play with only the keyboard(I used to be like that too), but have you tried playing these classic non-mouselook ports with a mouse too?

 

In Boom, if you set the vertical speed to the lowest, that lowest value is 0, which is effectively a built-in novert, allowing you to look around at a more controllable pace without moving.

[Gibbon]

2 hours ago, Nikku4211 said:

I agree, Tranmap really does allow you to do clever stuff, thanks to the way the TNT team coded it.

 

I know you prefer to play with only the keyboard(I used to be like that too), but have you tried playing these classic non-mouselook ports with a mouse too?

 

In Boom, if you set the vertical speed to the lowest, that lowest value is 0, which is effectively a built-in novert, allowing you to look around at a more controllable pace without moving.

I do use it, I also adjust and test the sliders to ensure good sensitivity.  I do make the vertical sensitivity 0 because otherwise it is annoying as hell :) 

[Gibbon]

First hotfix for ReBOOM:

 

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

 

This fixes all the bugs from the previous release and removes the hires, static limit increase and MBF21 support due to severe issues.

ReBOOM can now be used as a replacement for BOOM.EXE

 

Known bugs:

1. WAD loading (-file <name>) on Windows will result in some transparency issues with projectiles.  Issue is unknown.  This does not happen on Linux.

 

This is the first release to be built for Windows on MingW32.

 

ReBOOM will now undergo a future proofing phase to refactor the code in order to better accommodate future additions and improve maintenance and reliability (it will never sacrifice DOS BOOM compatibility).  Updates for this can be seen on the github repository, for those who would be curious.

 

Have fun with it, I now have a certain Pooch to give some attention too :)

[Nikku4211]

4 hours ago, Gibbon said:

First hotfix for ReBOOM:

 

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

 

This fixes all the bugs from the previous release and removes the hires, static limit increase and MBF21 support due to severe issues.

ReBOOM can now be used as a replacement for BOOM.EXE

I'm still experiencing issues with my configurations not saving. :(

 

The gamma level I set it to doesn't save, the mouselook range is still not like it was on DOSBox, and I keep changing the use button but it doesn't save that either.

 

EDIT: The issue seems to have fixed itself after I ran the application as administrator once. After that, the next time I ran as a non-administrator, the issue no longer occurs.

Edited August 26, 2021 by Nikku4211

[Gibbon]

14 minutes ago, Nikku4211 said:

I'm still experiencing issues with my configurations not saving. :(

 

The gamma level I set it to doesn't save, the mouselook range is still not like it was on DOSBox, and I keep changing the use button but it doesn't save that either.

 

EDIT: The issue seems to have fixed itself after I ran the application as administrator once. After that, the next time I ran as a non-administrator, the issue no longer occurs.

I only run Windows as complete administrator. I must have spent an hour making sure every configuration saves :)

[Nikku4211]

10 minutes ago, Gibbon said:

I only run Windows as complete administrator. I must have spent an hour making sure every configuration saves :)

 

Oh, okay then.

 

Still, that means people who are on someone else's computer who want to play ReBoom but don't have admin privileges will have problems playing.

 

Anyways, when I lower the music volume, it also lowers sound effect volume. Can this be fixed?

[Gibbon]

11 minutes ago, Nikku4211 said:

 

Oh, okay then.

 

Still, that means people who are on someone else's computer who want to play ReBoom but don't have admin privileges will have problems playing.

 

Anyways, when I lower the music volume, it also lowers sound effect volume. Can this be fixed?

I'll take a look yes.  I will also work on those privileges.

[Nikku4211]

Okay, new problem. I'm working on a WAD with a telefrag death trap.

 

Complain all you want about telefrag death traps, but the thing is, they don't work in ReBoom, but they do work in DOS Boom.

 

Is that another oversight, or an intentional change?

[Gibbon]

11 minutes ago, Nikku4211 said:

Okay, new problem. I'm working on a WAD with a telefrag death trap.

 

Complain all you want about telefrag death traps, but the thing is, they don't work in ReBoom, but they do work in DOS Boom.

 

Is that another oversight, or an intentional change?

Voodoo dolls right?  I tested voodoo dolls on the first community chest wad as it has quite a few of them, did not do any telefragging though.  This is probably a switch case issue.

[Nikku4211]

9 minutes ago, Gibbon said:

Voodoo dolls right?  I tested voodoo dolls on the first community chest wad as it has quite a few of them, did not do any telefragging though.  This is probably a switch case issue.

Actually, the voodoo dolls in general were fine, but telefragging voodoo dolls didn't work.

 

In fact, the same issue occurs even without voodoo dolls. I've tested a map where you are supposed to telefrag an enemy, except that you can't use the teleporter at all because telefragging doesn't work at all.

[Gibbon]

12 hours ago, Nikku4211 said:

Actually, the voodoo dolls in general were fine, but telefragging voodoo dolls didn't work.

 

In fact, the same issue occurs even without voodoo dolls. I've tested a map where you are supposed to telefrag an enemy, except that you can't use the teleporter at all because telefragging doesn't work at all.

It does.  I have my own wad I use for testing.  Telefragging has no issues when the source port is set to use boom (I use eureka).

[Nikku4211]

8 hours ago, Gibbon said:

It does.  I have my own wad I use for testing.  Telefragging has no issues when the source port is set to use boom (I use eureka).

Source port is set to use Boom? What do you mean? How do I set ReBoom to 'use Boom'? Also, what do you mean by eureka?

 

I tested it with MAP08 and MAP13 of this.

BoomHorv11beta1.7z

 

MAP08 has the voodoo trap, and MAP13 has the required enemy telefrag.

 

The version of ReBoom I'm currently using is the 2.03.1 hotfix, by the way, same Windows 10 version as before.

[Gibbon]

22 minutes ago, Nikku4211 said:

Source port is set to use Boom? What do you mean? How do I set ReBoom to 'use Boom'? Also, what do you mean by eureka?

 

I tested it with MAP08 and MAP13 of this.

BoomHorv11beta1.7z

 

MAP08 has the voodoo trap, and MAP13 has the required enemy telefrag.

 

The version of ReBoom I'm currently using is the 2.03.1 hotfix, by the way, same Windows 10 version as before.

In the map editor when making a wad you can set the source port to base your wad on (zdoom, mbf, boom) so you can use those features for the source port.  Eureka (map editor) has an option for Boom and so I made a map with a telefragger and it worked no issues).

 

I'll check that wad though.

[Nikku4211]

4 minutes ago, Gibbon said:

In the map editor when making a wad you can set the source port to base your wad on (zdoom, mbf, boom) so you can use those features for the source port.  Eureka (map editor) has an option for Boom and so I made a map with a telefragger and it worked no issues).

 

I'll check that wad though.

Oh, you meant that you made your own WAD using Eureka and it worked fine.

 

Probably good to test on a Windows 10 installation too for good measure.

 

Anyways, thanks for planning to check out my beta WAD.

 

I have actually just recorded a demo with it in DOS Boom.

BHDEMOB1.7z

 

On 8/26/2021 at 11:08 AM, Gibbon said:

Known bugs:

1. WAD loading (-file <name>) on Windows will result in some transparency issues with projectiles.  Issue is unknown.  This does not happen on Linux.

Actually, I've played the original Doom 2 on map 11 without loading any WADs in Windows 10, and I noticed some transparency issues there, too, with the archvile flames especially. You sure it's not a TRANMAP-related problem?

[Gibbon]

So I tried it out, I think there is a slight difference between DOS and Windows.  It did not work because I landed right next to the teleporter trap player start rather than on it.  I modified the map and changed it so I would land on it from a teleporter and it worked.  Does it work also on prboom 2.02?  I'm curious.

 

And thanks for the barbie girl midi..  '97 is stuck in my head again

[Gibbon]

I also tried MAP13 (Evanescence midi..  really :))

 

I could not find the monster telefragger so I modified the map and stuck a monster over a teleport exit and that was fine, no issues.

[P41R47]

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.