Eh, no. "Palette flashes" as in when you get hurt, the screen turns red, except instead of using a red tint, it changes the palette. No matter how it pans out for software, that won't play well with a hardware renderer. Of course, that doesn't mean somebody can't do that sort of thing manually; it just shouldn't be an engine feature.TheDarkArchon wrote:Given you can already eye rape people with texture switching, fog switching and light switching, it's pretty much a non-issue.
On the subject of a 32-bit software renderer, I've given it a little thought over time, but that's about it. I'm now thinking that a full floating point frame buffer would be extremely convenient for such an implementation: You don't need to worry about overflow, SSE means you can work with each (16-byte!) pixel as a unit, and when you convert it to 32-bit integer RGB for display, you basically get clamping to 0-255 for free by taking advantage of how IEEE-754 numbers are stored. On the other hand, it's 16 times as much data to push around. But countering that, Doom's vertical drawing isn't particularly cache friendly, so there may be plenty of dead time already that can be used for wider pixels with minimal performance impact. Obviously, I would need to do some testing to determine if a floating point frame buffer is viable, but I've no idea when I'll do that.