Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Gibbon

ReBOOM 2.07um (Updated February 24th 2022)

Recommended Posts

40 minutes ago, Redneckerz said:

I think for pure gameplay, building from latest would be fine enough

No, precisely the minotaur slam was fixed a few days ago and i think the bug most likely comes from there. But that's just an example.

There are hundreds of bugs due to the scriptification and floatification among other things, besides new features add more bugs and sometimes even the bugfixes.

And there were problems not only with monster behaviour but also with some map actions not working AFAIR (but i don't remember where that came from).

If anything i would trash it and build a commit previous to the zscript merge. BTW versions previous to the floatification don't even compile on 32 bit, there were some carcinogenic build code VS doesn't like.

The first ZDoomGL was cool back then but crashed a lot (well ZDoom already did but that one even more), the second was very slow. GZDoom was much better. Yeah certainly they are crazy ideas.

Share this post


Link to post
1 minute ago, drfrag said:

No, precisely the minotaur slam was fixed a few days ago and i think the bug most likely comes from there. But that's just an example.

There are hundreds of bugs due to the scriptification and floatification among other things, besides new features add more bugs and sometimes even the bugfixes.

And there were problems not only with monster behaviour but also with some map actions not working AFAIR (but i don't remember where that came from).

If anything i would trash it and build a commit previous to the zscript merge. BTW versions previous to the floatification don't even compile on 32 bit, there were some carcinogenic build code VS doesn't like.

I mean, there is a reason why i like your low end stuff so much, drfrag :) You know the ins and outs of these legacy systems on ZDoom better than most.
 

1 minute ago, drfrag said:

The first ZDoomGL was cool back then but crashed a lot (well ZDoom already did but that one even more), the second was very slow. GZDoom was much better. Yeah certainly they are crazy ideas.

Oh yeah. Kokak's build remains cool (Models!) but its very prone to crash, and ZDoomGL v2 was a performance hog versus the comparable GZDoom version at the time, just half as fast. But it had amazing features with its Quake 3 eseque Shader system... just a little too late.

Share this post


Link to post
58 minutes ago, Redneckerz said:

That latter one could be worthwhile to have a build of, if unmaintained. Still with truecolor, no?

I always include both, the MinGW build comes from there. With ASM and without SSE2 tough, there were problems with sky drawing without the ASM and that version also runs on older CPUs and Win98. But truecolor is faster on the SSE build. I'm mostly done with ZDoom32 BTW.

Share this post


Link to post
18 minutes ago, drfrag said:

I've just seen that the chaisaw was already fixed in the ZDoom master.

Indeed, feels alright.

 

I agree though, for sure there are an absolute ton of bugs.  ZDoom was never known for its 100 percent reliability rating, features over stability was its apparent goal.

 

I'll trust your insight however, as I do not care much for ZDoom myself (I use it to play some limit removing wads and thats about it), I made them simply because the current MacOS builds were outdated and there were none targeting big sur and 64bit exclusively.

Share this post


Link to post

Hey, ReBOOM is refusing to start now for some reason. I still think it has to do with DOOMWADDIR and/or DOOMWADPATH.

 

Also, did you remove the TNT cheats like TNTEM? They don't work anymore. KILLEM just prints "0 monsters killed".

Share this post


Link to post
3 minutes ago, maxmanium said:

Hey, ReBOOM is refusing to start now for some reason. I still think it has to do with DOOMWADDIR and/or DOOMWADPATH.

 

Also, did you remove the TNT cheats like TNTEM? They don't work anymore. KILLEM just prints "0 monsters killed".

The TNT cheats were removed some time ago as I am fixing the cheat code stuff (it is some of the worst code in Boom).  What I'll do, I will do a Windows build tomorrow from my 'reboom_next' branch.  Which, over the last day has had over 1000 fixes to various things that were wrong.  There was a segfault with the ENDBOOM window which was taking over the exiting sequence and causing a segfault on I_Quit().  I think this is what it is, on Windows it does not 'segfault' in the same way and would simply refuse to start.  It never happened to me however, so I'll quote you again here once it is up and you can take it for a spin.

 

TNT cheats are going back in also today, I'm cleaning it as we speak :)

Share this post


Link to post

There are times when development is focused on adding features and other times on fixing bugs, ZDoom was dropped and many bugs were fixed later in GZDoom.

Share this post


Link to post
2 hours ago, Gibbon said:

The TNT cheats were removed some time ago as I am fixing the cheat code stuff (it is some of the worst code in Boom).  What I'll do, I will do a Windows build tomorrow from my 'reboom_next' branch.  Which, over the last day has had over 1000 fixes to various things that were wrong.  There was a segfault with the ENDBOOM window which was taking over the exiting sequence and causing a segfault on I_Quit().  I think this is what it is, on Windows it does not 'segfault' in the same way and would simply refuse to start.  It never happened to me however, so I'll quote you again here once it is up and you can take it for a spin.

 

TNT cheats are going back in also today, I'm cleaning it as we speak :)

 

Good to know!

 

Also, I forgot to ask: could you make the "run" key invert autorun when it's on?

 

EDIT: Found a bug. Picking up the radsuit uses the wrong palette, it's one of the really bright pain palettes. Presumably this was introduced with the berserk tint thing.

Edited by maxmanium

Share this post


Link to post
7 hours ago, Gibbon said:

but obviously a codebase the size of ZDoom's needs months to learn.

the usual programmers habit of underestimating ETAs by at least a magnitude. ;-)

 

Spoiler

i mean, Vavoom took me years of full-time efforts (not joking here) to start making heads or tails of it. and mind you, Vavoom code is very clean,  modularised and readable, i've never seed Doom codebase in such a great state before Vavoom.

 

now, i'm not a fast thinker, but ZDoom code is not Vavoom too. ;-) and one retired ZDoom author is known for … let's say Strange Programming Habits. so i still think that changing monthes to years will make a more realistic estimate. ;-)

 

p.p.s.: i just came up with a forum title for you: "best friend of marine best friends". ;-)

Edited by ketmar

Share this post


Link to post
12 hours ago, maxmanium said:

 

Good to know!

 

Also, I forgot to ask: could you make the "run" key invert autorun when it's on?

 

EDIT: Found a bug. Picking up the radsuit uses the wrong palette, it's one of the really bright pain palettes. Presumably this was introduced with the berserk tint thing.

I think I know where, I'll get on that!

 

EDIT: @maxmanium

Fixed.  There was an integer overflow as I was calculating a 4 byte int and it was overflowing.  So that is fixed by casting it to a wider int (int_64_t).  As promised, I have a Windows build of the current snapshot of reboom_next branch.

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

 

As a note, I've overhauled the entire DOOMWADDIR thing and rolled my own.  I added also a BOOMWADDIR so you can set either DOOMWADDIR or that and it will auto pickup the iwad by just doing -iwad doom2 etc..

 

7 hours ago, ketmar said:

the usual programmers habit of underestimating ETAs by at least a magnitude. ;-)

 

  Hide contents

i mean, Vavoom took me years of full-time efforts (not joking here) to start making heads or tails of it. and mind you, Vavoom code is very clean,  modularised and readable, i've never seed Doom codebase in such a great state before Vavoom.

 

now, i'm not a fast thinker, but ZDoom code is not Vavoom too. ;-) and one retired ZDoom author is known for … let's say Strange Programming Habits. so i still think that changing monthes to years will make a more realistic estimate. ;-)

 

p.p.s.: i just came up with a forum title for you: "best friend of marine best friends". ;-)

 

Yeah in all honesty to really memorise it, a lot longer than months.  I was basing it more on that if you remove all those libraries it uses, it is a fairly understandable core.  I'll have to look at K8Vavoom, you've got me intrigued now about beautiful code :)

Edited by Gibbon : added link for testers

Share this post


Link to post
22 hours ago, Gibbon said:

I'll have to look at K8Vavoom, you've got me intrigued now about beautiful code :)

oh, it's not beautiful anymore. ;-) i started working on it when i had almost no understanding of what is going on there, and so there are alot of stupid things i throwed in, and never cleaned up later. still, the architecture is good, and VavoomC compiler is quite nice too (it's a real multipass AST-based compiler, with two-stage code generation, yay! ;-).

Share this post


Link to post
44 minutes ago, ketmar said:

oh, it's not beautiful anymore. ;-) i started working on it when i had almost no understanding of what is going on there, and so there are alot of stupid things i throwed in, and never cleaned up later. still, the architecture is good, and VavoomC compiler is quite nice too (it's a real multipass AST-based compiler, with two-stage code generation, yay! ;-).

Nice, syntax trees FTW! Well you can not understand something without having on it first so to do good things, you have to do crap things first :)

Share this post


Link to post

Hi Mr. Gibbon, I'm just wondering if you could compile some more binaries with your latest updates, if anything has been developed? Love this little sourceport.

Share this post


Link to post
11 hours ago, RedHelix said:

Hi Mr. Gibbon, I'm just wondering if you could compile some more binaries with your latest updates, if anything has been developed? Love this little sourceport.

Indeed I can, I will do it a few times a month.

Share this post


Link to post
25 minutes ago, Gibbon said:

As promised here is October's ReBOOM snapshot.

 

This is taken straight from:

https://repo.or.cz/reboom.git/shortlog/refs/heads/reboom_next

 

Windows 64bit:

https://github.com/atsb/ReBOOM/releases/tag/205um_rc1 (it is actually RC2)

 

Mostly stability fixes and cleanups.  Crashes are so far non-existent and it will always boot first time, every time.

 

Still doesn't launch properly for me without an absolute iwad and pwad path.

Share this post


Link to post
48 minutes ago, maxmanium said:

 

Still doesn't launch properly for me without an absolute iwad and pwad path.

If you set the variables correctly it works.  I tested it on 4 different OS's.  On Windows set REBOOMWADDIR or the standard DOOMWADDIR variable as system wide.  Finds it no issues for me.

Share this post


Link to post
On 10/22/2021 at 8:33 AM, Gibbon said:

If you set the variables correctly it works.  I tested it on 4 different OS's.  On Windows set REBOOMWADDIR or the standard DOOMWADDIR variable as system wide.  Finds it no issues for me.

 

It still doesn't work for me even with REBOOMWADDIR. I copied its entries from DOOMWADPATH. In fact it doesn't launch even with absolute paths.

Share this post


Link to post
49 minutes ago, maxmanium said:

 

It still doesn't work for me even with REBOOMWADDIR. I copied its entries from DOOMWADPATH. In fact it doesn't launch even with absolute paths.

No idea then.  It works on my Windows, Mac, Linux and FreeBSD machines.

 

You are on a 64bit machine aren't you?  That's the only thing I can think of.

 

Since I can only test it on the machines I have, we'll have to wait for others to give it a spin.  I don't exactly have a huge number of playtesters :) such is the life of a small source port.

 

EDIT: I'll do a MingW32 build and see if that works for you.  Maybe the MSVC build needs some extra dependencies that my dev machine has but you don't.  But my guess would be you may need the latest C/C++ redistributable package for Visual Studio 2019/2022

Edited by Gibbon

Share this post


Link to post
1 hour ago, Gibbon said:

No idea then.  It works on my Windows, Mac, Linux and FreeBSD machines.

 

You are on a 64bit machine aren't you?  That's the only thing I can think of.

 

Since I can only test it on the machines I have, we'll have to wait for others to give it a spin.  I don't exactly have a huge number of playtesters :) such is the life of a small source port

 

Yep, 64-bit. No idea what the problem is either.

Share this post


Link to post

I'll do a cross compilation to Windows later from Linux or Mac.  This would be one way to ensure any MSVC or Windows specific libraries aren't needed by the executable.  

Share this post


Link to post

Additionally the plans are:

 

1. Get the code 100% on par with GNU coding standards (right now it's a mess with legacy contributors and their bafflingly horrible ways at doing comments.  I'm looking at you Rand Phares)

 

2. Get all strings to be translatable using GNU gettext.  Personally I can translate it into 4 different languages but gettext is a way better alternative.

 

3. ReBOOM will join the leagues of other source ports at having its own wad file (reboom.wad).  This is to hold custom flats and lumps for background menu screens and a different colour of text (to help colour blind people).  So something along the lines of Fushia text on a grey (ish) background.

 

4. Accessibility features will be able to be toggled on or off from the menu (unlike in Pooch).

 

5. An entire documentation set will be created in texinfo format so it can be converted to any format.

 

6. Remove the text printing for the names and versions of the wads being loaded and replace them with generic ReBOOM text and the GPL licence text. - Done in reboom_next branch

 

EDIT:

I thought I added this but obviously I did not.

 

7. Moving from GPLv2 to GPLv3.  Since Boom used the GPLv2 licence that had the clause "or any later version".  I have legal (in terms of GNU/GPL) to move the project to GPLv3 (since I am now the main developer).  What does this mean?  Well, it would mean ReBOOM would be protected from DRM and from outside forces wishing to take Free Software and make it Proprietary (tivoization / restrictions of use).

 

I know many of these are Linux-first features or predominant, however, it is my main system and since I am a GNU maintainer, most of these features just 'make sense'.  In order to get it standardised and semi-clean.

Edited by Gibbon

Share this post


Link to post

Sorry for the triple post XD however I neglected to mention something that may/may not be important.

 

For ReBOOM, I am happy with how UMAPINFO is right now and have zero plans to add anything else (it is nice, small and simple, just like ReBOOM).  Considering ReBOOM is small and likely nobody would care if 'I' didn't want the spec updated, it is highly likely that I would fork the spec into BMAPINFO (Boom MapInfo).  But I will wait and see what else will be added in the near future.

Share this post


Link to post
2 hours ago, Gibbon said:

Considering ReBOOM is small and likely nobody would care if 'I' didn't want the spec updated, it is highly likely that I would fork the spec into BMAPINFO (Boom MapInfo).  But I will wait and see what else will be added in the near future.

Unless that already exists, i feel a natural restraint against this move: Your port would be the only one having this. What would the benefits be of BMAPINFO?

 

This is pretty much the same reasoning around the current standards discussion going on (DEHEXTRA/MBF21/DSDHacked).

 

I know, Eternity also has a MAPINFO fork. But separating MAPINFO into a new thing seems superfluous. Love, as always, to read your thoughts on this matter.

Share this post


Link to post
5 minutes ago, Redneckerz said:

Unless that already exists, i feel a natural restraint against this move: Your port would be the only one having this. What would the benefits be of BMAPINFO?

 

This is pretty much the same reasoning around the current standards discussion going on (DEHEXTRA/MBF21/DSDHacked).

 

I know, Eternity also has a MAPINFO fork. But separating MAPINFO into a new thing seems superfluous. Love, as always, to read your thoughts on this matter.

It would essentially be a frozen revision of my implementation up to revision 2.

 

My reasoning would be, no update should happen without unanimous consent of all source ports that implement it (since it would affect all of them equally).  I think it's perfect just the way it is and would resist any update.  The problem would then be, some will be behind, others will be ahead and then the 'standard' would simply be split.  This is my worry.

 

Sure I could stick to my custom revision.  But doing that just makes it look outdated.  Which wouldn't be doing it any favours.

 

Having a new name would not make it look outdated.  It would have new lump names etc..

 

Sure it would be the only one, but my goal isn't to please never ending user requests with modding ;)

Share this post


Link to post
39 minutes ago, Gibbon said:

It would essentially be a frozen revision of my implementation up to revision 2.

 

My reasoning would be, no update should happen without unanimous consent of all source ports that implement it (since it would affect all of them equally).  I think it's perfect just the way it is and would resist any update.  The problem would then be, some will be behind, others will be ahead and then the 'standard' would simply be split.  This is my worry.

 

Sure I could stick to my custom revision.  But doing that just makes it look outdated.  Which wouldn't be doing it any favours.

 

Having a new name would not make it look outdated.  It would have new lump names etc..

 

Sure it would be the only one, but my goal isn't to please never ending user requests with modding ;)

So UMAPINFO Rev 2 but renamed to BMAPINFO.

 

Is this something you would want to see spread to others or would it be for ReBoom only?

 

Be as it may i am not completely disagreeing with you obviously, this is your work, your philosophy counts.

 

The reason i am now taking this Why fork? approach is:

  • Regarding the aforementioned standards there has been a lot of talk on how to continue forward, but AFAIK no definitive consensus on what ports should what next
  • There is little material available taking advantage of these new standards. Luckily, just looking at WADS and MODS, new projects are starting to come up
  • Detailing. I have stamped out the new standards with their own Wiki articles so that they are visible for most, but they lack details. I am not knowledgeable enough to explain the finer workings behind each standard, and even if i were to try, i am far more likely to mess it up because i am not a modder nor a mapper (I aspire it, but writing like an automaton works best)

I much prefer the above standards be fleshed out sort to say, before another variable comes in.

 

Ofcourse, this depends on what BMAPINFO pretains to be and if needs cross-port support. If its just a frozen revision of UMAPINFO, one could make due with an addendendum.

Share this post


Link to post

Indeed, I am waiting to see what is happening for the future.  So far it is alright at the moment.  Having Rev 2 is pretty modern right now.

 

If it does come to that, I highly doubt it will need any sort of cross port support.  One of the things I like about ReBOOM is that it is small and stable.  Never ending features just for the sake of adding features will never happen, plus, for those that do use it, it would at the very least provide a base modding ability that is stable and will never change.

Share this post


Link to post

So on reboom_next branch, the 'reboom.wad' file is on its way to completion (I need a few more lumps first (ok probably a lot of lumps)) since they need to replace the custom text Boom has in 'Setup'.  All that text is using Dooms text colour, and so I'll need Fushia coloured lumps to draw in-place of the text.  But a basic 'main menu' is done, as well as a custom background screen (a slightly darkened and re-coloured FLAT19), meaning it will once again work with shareware doom.

 

Spoiler

reboom_fusia.png.1b05a3014197370591971ef06e5f146e.png

reboom_bkg.png.6c1c6c1fc4accecb6b2efc9598ec0550.png

 

EDIT: The reason I am focusing on Fuschia text is due to the three forms of colour blindness.

 

So Fuschia text will appear as a Dark blue for Protanopia, a Light blue for Deutranopia and a deep Brown / Reddish Brown for Tritanopia.  The Green and Yellow text in Doom I have deemed 'ok' since Green is Yellow (well a sort of dark Yellow / Orange colour) for Protanopia and Deutranopia and is a light pink for Tritanopia and Yellow is...  well, Yellow for everyone except Tritanopia where it is a very washed out Pink. so the palette will still look nicely contrasted against the background and general game graphics.

 

The original Red of Doom will appear as Brown for everyone except Tritanopia where it would be a retina-scolding hot pink!  Both would be badly contrasted on the menu.

 

I think it is a nice balance for those with non-colour blindness, purple text looks pretty nice actually :)

 

EDIT: So it would appear that this is scuppered now since the smaller texts in the wad will replace the coloured text throughout the game (I didn't think of that..).

So what I am doing now is going to be trying to extend the Boom text colouring throughout the game instead.  Probably won't be easy at all and will take several releases to get right.  For now I'll focus on the other updates.

 

One thing I did do (to help dyslexic users) is that I replaced the gray percent with a gold percent.  To contrast better, and it also is fine for colourblind users too.

Spoiler

doom01.png.f96352feb8cfed6789bae1e5e9ca3c87.png

 

Edited by Gibbon

Share this post


Link to post
Spoiler

doom00.png.7b9c4e5fa1810162c3f8c6cb5991beb7.pngdoom01.png.c73ef9dca032ba74baa89c9d0da71e30.png

Above are some images of the 'new' accessibility option.  It will load lumps designated 'BTCFN0XX' (also I added a BTCFN096 backslash lump) thus overriding the normal 'STCFN0XX' lumps.  I decided on Gray as it will be readable for all forms of colour-blindness.  I just have to also disable the colouring and add a better background tint to the letters.  After that, only the larger font is left and it will be much better for those who have this condition.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×