GooberMan
-
Content count
1621 -
Joined
-
Last visited
Posts posted by 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Remember when id found the Quake 2 modding community so strong that they made a commercial release of it?
-
I buy CDs for archival/artwork/support purposes, and listen to that very music on streaming services. I own several devices capable of playing CDA, but they basically never get used anymore.
-
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.
-
Maybe it's time to confess about the secret 160x100 mode that activates when it detects signs of DK-enabled users at the keyboard?
-
It's not broken in DOSBox. You're just plain not running it with a VGA card on a CRT.
The short story is that the effect changes the colour of the "overscan" region of an analog monitor. Modern monitors do not have this region available to them. Shrinking the gameplay area in a window (fullscreen or not) to have this border visible in a meaningful manner is the definition of a bad idea. Everyone except the five people who remember that effect will think it's a bug. As a remaster, the current effect of flashing the screen red a little bit is the far better way to go.
-
-
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.
-
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.
-
-
-
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.
-
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. -
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.
-
Slightly different to the approach I was going to take.
There's a bit of a misconception about Doom, in that there's not enough static data to create static buffers and just roll with it. But the reality is that there's exactly four dynamic elements of a Doom world:
- Floor height
- Ceiling height
- Light level
- Scrolling textures
The last two are exclusively visual effects and have no relevance to anything but the end user; the first two are both a visual effect and required for culling objects.
The approach I was going to take was to bake that static mesh, but never update subregions. I was going to use constant buffers for each sector (and for scrollers) and only update those four values listed. Less to go up to the GPU that way. Then reconstruct what is required on the GPU from those constant buffers. Honestly, Doom's rendering is so simple that you're probably wasting wavefronts. There's likely a ton of processing power to spare in each wavefront, but I won't know exactly what the cost differential is until I try each method and see what the results are.It's funny though, since that could sound like the opposite approach I take to bring Rum and Raisin's times down further. Sprite clipping is a nightmare, and there's going to be more efficient ways to do it. But a large chunk of time you see in my screenshot is the renderer preparing walls. Setting up the values for the column renderer to just go for it. This can all be computed at map load time. Adding a scroll offset and projecting the required UVs for the renderer is the smallest cost, there's milliseconds in that screenshot that can be saved just from checking flags if it's upper/lower pegged etc and adjusting offsets according. On the other hand, it's virtually equivalent to setting up those static buffers with constant buffers used to update select values.
-
On 12/3/2022 at 2:03 PM, hobomaster22 said:And holy crap is Summer of Slaughter MAP32 recommended by @Blip is really cool. This map absolutely destroys other ports. I couldn't get a single port to stay above 30fps in this outside area
i7-6700HQ 2.6GHz software rendering at 1920x900. No Boom functionality in Rum and Raisin yet, so unplayable. Throwing some Ryzen cores at it should bring that render time down from my ageing machine.
Ran it on my profiling build to get an idea of where the time is actually going, and yeah good ol' fashioned setup/clipping stuff. Which I have solid plans to tackle, so expect better performance in R&R in the future on this scene. Won't be a concern with a hardware renderer, basic Z clipping will handle everything that these software routines do.
I should also say, this port is basically doing what I was going to do with Calamity. So it pleases me to see it doing as well as I expected. There have been better ways to render Doom scenes for a very long time, and no one should be discouraged from going down those paths to see what shakes out. There's some reference maps in that thread I linked in fact that will help with flat rendering issues. -
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.
-
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.
Reflections and Aspirations: MBF21 in 2024
in Doom Editing
Posted ·
I've been meaning to drop in to this thread for a while. I'm not ready to offer my suggestions, but I will offer an explanation of the standpoint I'm taking.
If you check the Rum and Raisin Doom submit logs, you will notice that the codebase is approaching MBF21+DSDHACKED compatibility. As of right now on my local machine, I can complete a few levels of Eviternity 2 in fact (with glitches and incomplete features that don't hinder progression).
What's unique here is that I've been doing this entirely from documentation and descriptions of functionality provided to be my other community members (Altazimuth, Edward850, esselfortium, Quasar, and Xaser in alphabetical order are deserving of the shoutouts here). I'm doing this for a number of reasons, most of which I won't elaborate on here. But it does highlight that from Boom onwards, documenting how a feature works has never been a priority. We have detailed specifications of many things vanilla, both from the old Doom specs text that the community started compiling in 1993 and on the Doom Wiki. This is great for clean room implementations. But there's so much that I haven't been able to ascertain just from reading documentation or observing behavior - the big one I'll never get right from Boom is friction in fact, which is regularly described to me as "magic values" by people familiar with the code. Don't get me started on MBF, that is one big hack according to those in the know. The MBF21 spec is better documented, but defers to patch/diffs of an existing implementation in an annoying number of circumstances instead of a complete description of the behavior (ie a proper spec and not just an upgrade guide).
Much of the featurebase we have is dependent on some port's implementation to make sense of what spec is written. UMAPINFO is a notorious example there, where you need a valid Doom or Doom 2 gamestate for any of its features to work. And you can easily break things with episode definitions. I got caught out by Sigil 2 support, in fact, since it's a 100% unspecced behavior (and thus implementation defined) that the episode for any given map is taken from the ExMx map format number rather than clearepisodes/episode definitions in UMAPINFO. And thanks to the very nature of UMAPINFO, any mapset that uses MAPxx format in Doom 1 or ExMx format in Doom 2 means that these assumptions you take that are implementation-defined can very easily break. Oh, and let me tell you about what happens to all of the above when you use the registered doom.wad instead of the Ultimate doom.wad and only have three episodes defined in the WAD.
Having behavior exist in a codebase somewhere is no good for people implementing things from the ground up. It's great that we can share GPL code, and I encourage people to take my GPL code too. But it's not great for anyone who chooses to start from the (recently for realsies) GPL release of linuxdoom on id Software's github.
tl;dr - Clearly describe behaviors without using code when speccing things, it's a far cleaner way forward.