Does anyone here actually use ZDoom?

[Rachael]

You wouldn't actually need COLORMAP at 24bit. In fact that would just outright slow things down.

Actually, it would be needed, since the software renderer would not be able to support GZDoom's Brightmaps feature, simply dimming the light level (even with banding) would break Strife's robots.

[leileilol]

You wouldn't actually need COLORMAP at 24bit. In fact that would just outright slow things down.

Since the Doom colormap is only 32 rows, and there being the 18-bit precision of the VGA palette, it wouldn't be that bad to look up on 64x64x64x32 with two separate rendering buffers.

the software renderer would not be able to support GZDoom's Brightmaps feature

On load, convert the brightmaps to only the fullbright range in the palette, merge on top. Done.

[Sgt. Shivers]

I prefer the software renderer, but when a map suffers from not being truecolour or lacking dynamic lights / a skybox I'll use GZDoom, but even then I don't use GZDoom often because for some reason it hates D_Runnin.mid and will lag if the first stage uses it. Still don't know why...

[Blox]

You wouldn't actually need COLORMAP at 24bit. In fact that would just outright slow things down.

It would allow you to do

very fancy things.

So it's not like I wouldn't be willing to take the performance hit.

[Rachael]

I prefer the software renderer, but when a map suffers from not being truecolour or lacking dynamic lights / a skybox I'll use GZDoom, but even then I don't use GZDoom often because for some reason it hates D_Runnin.mid and will lag if the first stage uses it. Still don't know why...

Do you have framerate hiccups when starting the map?

Try adding "+set wipetype 0" to GZDoom's command line and see if it helps. (The setting is permanent, the default setting is "1" if you wish to change it back)

[edward850]

You wouldn't actually need COLORMAP at 24bit. In fact that would just outright slow things down.

It would allow you to do

very fancy things.

So it's not like I wouldn't be willing to take the performance hit.

As anything related to a 24bit renderer would require 3 times the pixel count per draw (technically same number of pixels, but 3 times the effective bandwidth), you may not actually have the choice if you want to stay above 35FPS. Odamex is the best example we have at this stage with its 24bit renderer, and it requires nothing short of a high end processor to keep above that.
That's assuming that a COLORMAP lookup would actually have a noticeable performance impact. If what leileilol says is accurate then it might not actually be a problem, however it should be noted that keeping both COLORMAP effects and 24bit rendering has been a constant problem for anybody willing to write one, and usually is the deciding factor in scrapping the idea in favor of (obscure) mod compatibility.

Which also tends to suggest there's something else to it that I'm not quite remembering.

[leileilol]

My theory applies to both GL and software btw. It's feasible in both.

32-bit rendering shouldn't be slower either (the color bandwidth issue was so 20 years ago when PCI video cards became a thing). I'd been considering to do it for Engoo. The big obstacle are palette shifting effects since that's going to need either a system-allocated buffer to work with (purely in software), or use a pixel/fragment shader on the rendering buffer to do this quickly, or (last resort) alter the host's display color control.

and of course, there's the loss of dropping Abrash's ASM, but that's something Odamex had shed for portability anyway.

[Rachael]

As anything related to a 24bit renderer would require 3 times the pixel count per draw (technically same number of pixels, but 3 times the effective bandwidth), you may not actually have the choice if you want to stay above 35FPS. Odamex is the best example we have at this stage with its 24bit renderer, and it requires nothing short of a high end processor to keep above that.
That's assuming that a COLORMAP lookup would actually have a noticeable performance impact. If what leileilol says is accurate then it might not actually be a problem, however it should be noted that keeping both COLORMAP effects and 24bit rendering has been a constant problem for anybody willing to write one, and usually is the deciding factor in scrapping the idea in favor of (obscure) mod compatibility.

Which also tends to suggest there's something else to it that I'm not quite remembering.

1) In order to even notice a performance hit, you would first need to have an older computer. And if you do, you would already notice one because ZDoom has moved from DirectDraw to Direct3D (you still have the option to switch back, however). Direct3D is by its very nature 24/32-bit, and cannot be otherwise, I believe what makes ZDoom different in this regard is it lists the "screen" as a paletted 8-bit texture and sends it to the buffer as a 2D object (I am only guessing here though, I could be wrong) - but there's nothing saying it can't send a full 32-bit texture to the buffer, instead, it would just take some reworking of the code.

2) The most taxing part of the rendering is the actual mathemetical calculations for the geometry - and if 80386 @ 33MHz CPU's could handle it at 320x200, why can't anything we use today handle it at higher resolutions? Drawing the same pixel 3 times for 3 different channels is trivial, by comparison, and only requires a color lookup, not recalculating whether it's a wall/floor/ceiling/sprite or where it belongs. GoldSRC (Half-Life) handled it just fine - as did Unreal - before 1GHz processors even came out, and their renderers were *FAR* more complex than Doom's was at the time.

The biggest problem with renderers is bloat. If you're squeezing too many switch/case and if/then scenarios into every single tiny little pixel, then yeah, things are going to slow down. That's why some modern software rasterizers use self-modifying code or multiple render paths. You simply can't execute 1000 lines of code on every pixel of a 1920x1080 image and expect the framerate to stay smooth, even if those lines are getting skipped (there's still the issue of requiring testing for the same condition on each pixel - wildly inefficient).

[Naniyue]

I use both. It just depends on the MoD and my MooD. Certain maps like a few arenas in Reelism run slowly, but then I have a comparatively weak dual core cpu.

[Graf Zahl]

As anything related to a 24bit renderer

A 24 bit] renderer would be DOA. You either go 32 bit right away or skip it.
Of course with a 32 bit lookup you do not need to draw all pixels 3 times, you still draw it only once.
Where this may cause slowdowns is when the renderer is optimized to draw multiple columns in parallel, but I guess even most of that can be taken care of with SSE/MMX assembly on an x86 CPU.

It definitely IS a bit slower but the nightmare scenarios described by Edward are of course nonsense.


All that said, I am an OpenGL guy. I find software rendering unattractive and the glitches inherent with it far more distracting than the sprite clipping issues.

[edward850]

A 24bit renderer and 32bit renderer are the same thing in this context. Reason being the surface would still be 24bit, as transparency information would mean nothing on the final blit. Probably makes more sense if you're thinking about the result, not the process.

1) In order to even notice a performance hit, you would first need to have an older computer. And if you do, you would already notice one because ZDoom has moved from DirectDraw to Direct3D (you still have the option to switch back, however). Direct3D is by its very nature 24/32-bit, and cannot be otherwise, I believe what makes ZDoom different in this regard is it lists the "screen" as a paletted 8-bit texture and sends it to the buffer as a 2D object (I am only guessing here though, I could be wrong) - but there's nothing saying it can't send a full 32-bit texture to the buffer, instead, it would just take some reworking of the code.

I did a thing a little while ago with slowing ZDoom's drawing into steps. I should have shown off the final blit without the hardware shaders.
All the D3D buffer does is take the 8bit world surface and copies it to a grayscale texture. A hardware shader then adds colour built from the palette. It's not a very good comparison to 24/32bit performance, as the entire world pipeline is still 8bit. Literally only the hardware is 32.

I actually just retested the Odamex renderer, at it pulls ~100FPS over 1080. Not as bad as I once encountered, so my previous concerns about colormap performance are pretty moot.

[Marisa the Magician]

Funny enough, I also wanted to write my own rendering library. Though it's no more than just me learning the ins and outs of how 3d rendering works.

If it actually becomes usable then that's fine. I wouldn't mind "softwarizing" GZDoom's renderer as long as the code isn't an unreadable mess.

[Hellser]

I use both ZDoom and GZDoom. I'm personally a fan of the Software limitations - as, like Wildweasel said.. it makes Doom feel more moodier. But yes, I would like to see the sprite clipping thing fixed. Maybe the guys at S:VE can spare some of their code for The Greater Good.

[Xtyfe]

I don't know about you guys. But I always wondered how Randi felt about more people using GZDoom?

[TheBadHustlex]

Only GZDoom. For quite everything. Without any filters, it still looks pixel/retro.