Rum and Raisin Doom - Haha software render go BRRRRR! (0.3.1-pre.8 bugfix release - I'm back! FOV sliders ahoy! STILL works with KDiKDiZD!)

[viti95]

Another bug I've found, I cannot start Run and Raisin on my Windows 10 laptop, this is the error message:

 

 

Edit: Installing Visual C++ Redistributable actually fixed the error, maybe it's important to add it to the readme

Edited November 28, 2022 by viti95

[GooberMan]

6 hours ago, viti95 said:

Installing Visual C++ Redistributable actually fixed the error, maybe it's important to add it to the readme

 

Wow, that's bad. It used to tell you a DLL is missing, not give you an error saying it can't resolve a function from a library. I consider that a regression from Windows there.

 

Aaaaaaaaaand it could also explain why there's unexplained errors popping up in the frontend. Either the MSVC runtime or the UCRT not having correct versions installed and resolving functions from those libraries would bring up those kinds of errors.

If you're not running Windows 10, UCRT needs to be installed. You'll also need the MSVC runtime regardless of Windows version.

[marver0PS]

If you try to load D2TWID without manually loading the external dehacked file, the internal DEH lump isn't loaded properly.

 

Map 31 crashes and the dopefish in map 32 is bugged. Even with manually applying the the dehacked file, the enemies in map 31 don't have collision.

[GooberMan]

Aha, exactly the kind of bug I've been looking for to test with. Thank you.

 

Short story: The DEHACKED lump masquerades as a valid DeHackEd 3 file but looks like it has some BEX elements. I've set R&R to always look for lumps and the only way to short circuit that right now is to go in to non-limit-removing mode. Relying on just the lump with D2TWID results in a stack overflow on MAP31; and adding the (correctly formed) external DEH on top results in the no collision being observed.

 

I think I'll just have to go ahead and make BEX support a thing for the next version.

[GooberMan]

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.4

 

And there's that BEX support. The INCLUDE directive is unsupported, but everything else is working with the limited set of WADs I've tested with.

 

Unsure how to handle adding -deh files on the command line in cases like D2TWID, since multiple DeHackEd files is perfectly kromulent and you'd basically need to parse every file to detect multiple files modifying the same bit of data to highlight potential errors. For ease of use/convenience, the idgames browser will straight up not add .deh files to the selected files list if there is a DEHACKED lump inside any WADs found in the archive. I don't believe any WAD will break because of this, but note that you'll find the .deh inside the "Change selected files" dialogue anyway if you want to manually add it.

[GooberMan]

Quick update.

I'm still settling in to my new job at World's Edge. Yeah, I've switched from shooters to the other genre that was big in my teens - RTS. Wait until I'm 50 and I decide to get in to making adventure games.

It does mean that I've ignored Rum and Raisin for a few weeks now. The next version I push out will be 0.3.2, which is basically pending getting Raspberry Pi back up and running. Dear Imgui decided to change how they handle OpenGL, and because version reporting is broken on Pi 4 its own internal loader decides that the version isn't high enough and quits. Works just fine if you remove that version check, but as I'm directly linking to the relevant versions of cimgui/Dear Imgui and not copying and maintaining my own branch then that basically leaves me with statically linking GL libraries on Raspberry Pi only. Some annoying fiddly config stuff needs to be done there, and I just couldn't be fucked over the last few weeks.

Either way, if there's any small requests or annoying bugs you've seen. Now's the time to let me know. Once 0.3.2 comes out, there will be very little public progress on this port for a few months as I'll be going in to silent mode for a feature or two.

[GooberMan]

Where have I been?

Well, I've been focused on Rise of the Triad: Ludicrous Edition. I was tapped to help the team optimise the renderer. It uses code I wrote for Rum and Raisin Doom, specifically the floor renderer. And then because I could, I implemented the idea I had for lightmapping. Knocked out the initial implementation in about an hour, spent about five or six more polishing and refining it. The image quality of the game is immensely improved as a result, I'm fairly pleased with how it turned out.

 

I've also got seven levels in the new campaign, The HUNT Continues. That was a creative outlet I didn't know I needed at the time, but it turns out ROTT still has a ton of design space to explore. It was a blast working out which way the game would bend and still be a cohesive experience.

 

Now that it's out and my work will naturally be winding down, Rum and Raisin is in my sights again.

[Xenolith]

What are the odds that this would compile and run on an IBM Power9 CPU running Fedora 38? I’m not able to kick the tires here at work but am super eager to give it a try in the next few days.

[GooberMan]

It requires OpenGL3 support (the Dashboard is hardware rendered, and the palette decompression for final display is done on the GPU), so if that actually exists for your hardware then cool. However, I've made next to no effort to maintain big endian support. Confidence isn't high.

[Blzut3]

6 hours ago, GooberMan said:

However, I've made next to no effort to maintain big endian support.

POWER9 is little endian (at least in any serious use).  Big endian is pretty much just retro computing and some embedded devices these days.

[GooberMan]

Oh nice, I haven't had to deal with PowerPC since the 360/PS3/Wii days so I completely missed that. In that case, assuming GL3 support is good then it "should" run.

[Blzut3]

Fun fact, PowerPC/POWER have always been bi-endian.  Windows NT4 for PowerPC ran little endian.  Granted bi-endian support did vary between microarchitectures so I've heard LE support is not present in those consoles (and it seems 64-bit chips initially heavily favored big endian).  Since POWER8 (circa 2015) though IBM has been pushing little endian to lower the barrier to adopting POWER.  The reason POWER9 (2017) got brought up is because a company made those chips widely available through a DIY enthusiast workstation platform.  They use standard AMD GPUs running the same open source drivers as x86, so yeah full OpenGL/Vulkan support.

[Xenolith]

On 8/2/2023 at 4:05 PM, GooberMan said:

It requires OpenGL3 support (the Dashboard is hardware rendered, and the palette decompression for final display is done on the GPU), so if that actually exists for your hardware then cool. However, I've made next to no effort to maintain big endian support. Confidence isn't high.

Big-endian would be a no-go for Rum & Raisin because Terascale Radeons - the most recent cards with big-endian support at all - max out at OpenGL 3.2 when running in that mode. Nobody's apparently gone through and fully bug-fixed all extensions for endian issues in 3.3+. The things you learn trying to cram Void Linux onto a dual G5 Power Mac a few years back...

 

But yeah, as Blzut3 said, nobody's doing big-endian on Power outside of legacy support aside from BSD projects. Even Fedora dropped big-endian quite a while back. I'll give Rum & Raisin a spin soon... I suspect an RX 6600 can probably manage.

 

Incidentally ECWolf runs quite well at 1440p, and north of 30 fps at 4K on the Power9. Great work, Blzut3.

Edited August 9, 2023 by Xenolith

[Xenolith]

Update: compilation in Fedora 38 bombs out with this error:

 

deh_thing.c:107:23: error: call to undeclared library function 'strcmp' with type 'int (const char *, const char *)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        if( deh_allow_bex && strcmp( variable_name, "Bits" ) == 0 && !isdigit( value[ 0 ] ) )
                             ^
deh_thing.c:107:23: note: include the header <string.h> or explicitly provide a declaration for 'strcmp'

 

However, I seem to remember the same error biting me when I was trying to compile R&R Doom on my Ubuntu 23.04 machine, which is running on a Core i9-11900F. Suggestions - other than "run it on Windows" - are welcome.

Edited August 10, 2023 by Xenolith

[GooberMan]

Ah yeah, I don't think I got around to compiling again on Linux/Raspberry Pi after I made that change due to ImGui shenanigans that I hadn't sorted out. That's just #include bullshit. Follow its instructions and jam the following up the top of the file after the last line to start with #include:

 

#include <string.h>

 

That'll get ya going until I do the change myself and push to github.

[GooberMan]

Did you miss me?

 

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.5

 

Shortlist of user-facing features:

• 1:1 square pixels!
• FOV slider!
• Reduced memory consumption because I killed colormap-expanded textures!
• Sigil 2 maps sit in the correct episode number!
• Improved fuzz for pinkies!

 

So something I've been wanting to do since I had to grok the math completely for Rise of the Triad was implement square pixels. And while I was there, an FOV slider is fairly trivial. Short story: there's a table in the Doom renderer called yslope that I didn't understand for a while. It looked like a screen space algorithm, but the bit shifts were throwing me off. Eventually I realised it was actually doing a trigonometric calculation: the tan value of the viewpoint angle at that Y screen coordinate. Armed with that knowledge, you need to do two things: change the pixel height the algorithm uses depending on if you're going old school or 1:1; and calculate the perspective values correctly for your updated FOV instead of the original 74 degree vertical FOV.

 

Let me tell you, that was a ton less painful than updating ROTT's codebase. All I had to do was change that one area where the values were calculated and everything worked fine. Carmack's renderer was absolutely way more sophisticated in every way once he went 32-bit.

 

Anyway. That's not even the thing in this update that requires the most explanation. Just why did I kill the colormap-expanded textures? Weren't they one of the things that made the renderer go fast?

 

Well, yes. Back when I started this entire thing. It was a pretty substantial speed bump back then and totally worth doing. But now I'm working on other features for the renderer that require colormap lookups to be a thing. So I decided to be empirical about it. You know what I found? Using colormap lookups increased render times by a grand total of 3-4%. That's it. With my test spot on Planisphere 2, that was the difference between 8.6 and 8.9 milliseconds. More than acceptable for what it's doing under the hood.

 

tl;dr - Rum and Raisin's renderer is now 100% Boom, MBF, and MBF21 compatible. Which by default makes this the fastest software renderer for those standards.

 

Of course, the game code isn't there yet. But the rendering support is in. Translucency was easy. Transfer skies took a good bit of rejigging a few things to make work properly. Transfer heights, well, now that there is the reason colormap support came back. And then trying to understand transfer heights based on all the documentation, well, that's like trying to pull out rusty nails with your mouth immediately after you've had every tooth extracted and without stitches.

 

Would you believe I changed nothing in the core rendering loop to support transfer heights?

 

I realised that I could actually implement it as a function of the interpolator. My renderer operates on instanced data of sectors instead of the sectors themselves. So all I needed to do was cook the correct values at frame presentation time. It always defaults to rendering in real space; if the viewpoint is in ceiling space then cook values for that; else if viewpoint is in underwater space then cook values for that. And everything just works, 100% accurate to Boom. HOMs work as intended, as does painting over them with upper and lower textures. No branching anywhere else, just set the renderer up with data and turn on all your threads and bam now you've got a lighting fast Rum and Raisin renderer that will handle Eviternity 2 just fine.

 

 

None of this is really testable by anyone right now. So don't get exited. This is still only a limit-removing port. Even if the code can do more, you just plain can't load up Boom maps in it. You will be disappointed if you try.

 

But hey, I heard you kids like FOV sliders and let me tell you 90 degree FOV is a really good FOV to play Doom at.

Edited January 24 by GooberMan

[realjohnmadden]

Wanted to try this out, and uh.. yikes.

[GooberMan]

Well, that's probably the bug Codename_Delta was getting. But he never gave a callstack like that after the functionality was added.

 

Anyway, turns out the initialisation order for the text-mode error screen is wrong. So that particular error will be fixed in the next release. It is, however, getting to that point because it's trying to display a previous error. My guess is that it's found no IWADs and is having an issue with it. Put an IWAD in the same folder if you haven't already done so and I suspect the error will go away.

[realjohnmadden]

1 minute ago, GooberMan said:

Well, that's probably the bug Codename_Delta was getting. But he never gave a callstack like that after the functionality was added.

 

Anyway, turns out the initialisation order for the text-mode error screen is wrong. So that particular error will be fixed in the next release. It is, however, getting to that point because it's trying to display a previous error. My guess is that it's found no IWADs and is having an issue with it. Put an IWAD in the same folder if you haven't already done so and I suspect the error will go away.

It actually has found IWADs - it's dumped a bunch of info JSONs in the Users/(username)/Saved Games/ folder, of all things.

DOOM.WAD's folder has this:

Attempting to switch the disk icon to CD-ROM also causes an error, but doesn't give a callstack. Instead, it just stops responding and brightens up.

And if I try putting the IWADs in the same folder as the EXE, it still crashes:

[GooberMan]

I'll upload a new build in a few hours, which will result in the correct error message popping up. But for now, the -iwad command line parameter still works and will skip going in to the launcher there.

[GooberMan]

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.6

 

There, that should actually tell you why the launcher is unhappy now.

[realjohnmadden]

On 1/25/2024 at 6:18 AM, GooberMan said:

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.6

 

There, that should actually tell you why the launcher is unhappy now.

This is the launcher error:

Spoiler

And the -iwad parameter gives me this lovely error as well:

Spoiler

[GooberMan]

6 hours ago, realjohnmadden said:

This is the launcher error

Crashing on a render TITLEPIC function. Which would mean it's encountering a WAD with a non-standard TITLEPIC format - a ZDoom mapset? ZDoom WADs in general are unsupported, this is a Chocolate Doom branch and still fairly close to vanilla. I have put some sanity checking in there now (the launcher will render a white titlepic for the WAD now), but needless to say you must only store vanilla WADs in the same folder as Rum and Raisin.

 

6 hours ago, realjohnmadden said:

And the -iwad parameter gives me this lovely error as well

That one's a complete mystery. It's saying the config dir - ie that folder you found in the Saved Games area - is not set internally. It should never get to that point without setting the variable the path is stored in. So more sanity checking is in place.

 

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.7

 

This new build has the mentioned sanity checking.

[realjohnmadden]

Selecting the CD-ROM option gives me this error:

HEXDD.WAD crashes the launcher. Apparently it's missing a titlepic..even though it has one, under the lump name of TITLE.

I also still get the error I got with -iwad when I start any game.

[GooberMan]

3 hours ago, realjohnmadden said:

Selecting the CD-ROM option gives me this error

Me being a noob and using code callbacks before WADs are initialised. Fixed.

 

3 hours ago, realjohnmadden said:

HEXDD.WAD crashes the launcher. Apparently it's missing a titlepic..even though it has one, under the lump name of TITLE.

So extend what I said about ZDoom wads to Heretic and Hexen WADs. Still, it's fairly common for everyone to have every Doom-engine IWAD in one place. So I've updated the launcher to properly detect non-Doom IWADs. It won't show them in the launcher, but I did also update the code to correctly locate the titlepic. With caveats:

 

HEXDD.WAD requires looking up the PLAYPAL from HEXEN.WAD, and that's a step too far for me to implement right now. So I'm keeping showing non-Doom IWADs in the launcher disabled for now.

 

3 hours ago, realjohnmadden said:

I also still get the error I got with -iwad when I start any game

Turns out I was a massive noob and didn't terminate a function call handling the path with NULL. And for some reason it hasn't crashed for me in the two+ years I've had that code running. Fixed now.

 

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.8

 

New build with above fixes.

[realjohnmadden]

Hell yeah, it actually works! Played some Hacx, and it worked perfectly (though, keyboard turning with frame interpolation is still weird.) Plutonia crashes (missing TRANMAP error, but Final Doom executable setting fixed it). Maximizing the window also crops off the bottom, presumably because it's too big.

Note how you can see a bit of the taskbar in the screenshot.

I like this port, it's like vanilla without limits and with vanilla bugs intact.

[GooberMan]

Yeah, I've fucked something up with my recent optimisation work. Check out the Harmony IWAD from the commercial Unity Doom port:

 

 

That status bar ain't right. (EDIT: Turns out that asking Boom 2.02 for its resources dumps STBAR, and my in-progress WAD handling for that means it stomps over any IWAD entry lul. So that's just a data problem.)

 

So here's another thing I did in this current build.

 

On 1/24/2024 at 4:11 AM, GooberMan said:

You know what I found? Using colormap lookups increased render times by a grand total of 3-4%

 

I got back 5-25% of my render times depending on how your scene is set up.

 

Every other port that uses software rendering approaches it with the decisions made 20-some years ago. Because they use the same code. But I've been using effectively a vanilla basis for my work (any "but" and "gotcha" counterpoints will be addressed by the end of the year). And I'm very very good at low level optimisations.

 

Did I tell y'all I met Carmack at Quakecon? Everyone says he's a robot in human flesh clothing. But I got a really human moment out of him. I told him I'd optimised his code to run at 4K on a Raspberry Pi. And he laughed. Can you imagine how many people in his life have told him "I optimised your code"? That's proof of human existence right there. And straight up that is 100% the point of this port. Carmack made the correct calls for a 386. I'm making the correct calls for a modern processor that doesn't want to try to render literally everything on the GPU. I don't need to explain that to Carmack. He gets it. He's a fellow engineer.

 

Back to the point from two paragraphs ago. tl;dr is that instead of creating one function that tries to handle all cases, I create several specialised functions through metaprogramming. I realised that my previous approach of a single do-everything function was a fucking mistake a few days ago, and set about fixing it. Every texture in this port now gets its own function pointers that correspond to the correct rendering routine for walls and floors (because I support any texture on any surface). End result? That 3-4% I mentioned in the above quote was eliminated. I save 5% to 25% on any given scene just by putting a couple of extra pointers in every texture's data structure.

 

And because I'm an edgelord and started this thread saying I'm disproving lies that have perpetuated in this community for literally decades. I made my code faster by increasing the executable size. Anyone that claims a smaller executable size is better is welcome to fuck off and die. Love, GooberMan.

Edited January 29 by GooberMan
data problem