GooberMan

Y'all motherfuckers need Jesus Leonard Cohen.

It's not a constant. The original flat renderer basically does lookups at 16-bit resolution instead of 32-bit resolution, and in a very cheating way by sticking X and Y in one 32-bit integer to do the texel lookup calculations (so it overflows and loses accuracy very easily). And as visplanes render left-to-right by row, what you get as you get closer to the right hand side of the screen is those kinds of inaccuracies. You should be able to notice how much those pixels swim when you rotate your view. Even increasing the resolution to 32-bit isn't quite good enough as you go higher and higher with your resolutions. But hey, this is FastDoom. That original code is very fast for the fidelity levels it targets. I'd say fixing that for higher resolutions is outside of the scope of the project, but it also isn't my project.

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.

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. 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.

Me being a noob and using code callbacks before WADs are initialised. Fixed. 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. 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.

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. 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.