High Resolution Backbuffer

Because these optimisations are literally pointless without it. Many source ports that start from scratch have had to deal with the same things this article goes in to detail about.

The original Doom renderer

The original code is surprisingly resilient to resolution changes. And there's a very good reason behind this - viewport shrinking. The actual world view could handle variable widths and heights. Excellent. Can't be too much work to get high resolution rendering working.

Problems encountered

Visplanes

The old visplanes thing. The 128 limit visplane actually wasn't the problem here. The problem is that visplane Y values are stored in an array of 8-bit integers. This limits you to a view height of 256 pixels off the bat. Easy enough change though, just swap out byte for your preferred integer size.

Visplanes in an 800-height buffer being squished in to 256 rows

But then you hit another problem. Carmack uses 0xff as a magic number to indicate an invalid visplane. Or, in decimal notation, 255. That's a lot less than the 800 rows in the above example. But even worse than the visual artifacts - if you happened to need to render to row 255, an error would trigger and the game would exit. The solution to that is also simple - replace 0xff with a define of your choosing. Rum and Raisin Doom does a bitwise compliment of a 0 value of the visplane Y value type, making it resilient to future changes - just change the typedef and off you go.

The sky texture

The sky texture uses the normal column rendering code. This means it needs to provide a midpoint value to the renderer. The value is defined as relative to screen height - specifically, half screen height. This works out to be 100 with the original 320x200 resolution. But, change that and it becomes much different. Using a 1280x800 backbuffer, that becomes 400. Translate that in to texture coordinates, and it starts reading from row 24 to render the sky.

You only simply need to define the midpoint in texture coordinates instead. 100 for every resolution is the correct value.

If you end up supporting tall patches for sky textures, this instead becomes 78.125% of your texture height.

Diminished lighting

Lighting values are actually calculated in screen space. The calculation is dependent on screen width. This is a fairly simple fix - scale everything according to the original render width of 320. Anywhere you find LIGHTSCALESHIFT in code will need this fix applied.

Status bar, and other UI elements

Everything is hard coded in the game to assume 320x200 render width. Many functions will directly blit textures to the back buffer with this in mind. As Rum and Raisin Doom takes a mostly-preservationist approach, keeping the scale of the original renderer while providing higher detail output for the simulation world is a priority. Thus, UI scaling was implemented.

UI elements are now given a virtual 320x200 space that they issue all their commands to. The V_ suite of functions perform the necessary scaling, translating from virtual screen space to the native backbuffer resolution.

Many other ports didn't take this step for a very long time. Even to this day, it's common to see the intermission screens tile a 64x64 flat directly to the background instead of scaling it up to the original dimensions. Rum and Raisin Doom retains the original behavior entirely by pre-scaling blitted images where appropriate.

Widescreen

Coming "when it's done". At a minimum, Doom defines its field of view horizontally. Translation functions for different horizontal aspect ratios will be required.