FastDoom: DOS Vanilla Doom optimized for 386/486 processors

Decided to randomly do a timedemo of the MAP32 UV-Max TAS speedrun of Hell Revealed II with one of the slowest SVGA cards known to exist (Realtek RTG3102) on a 1.4Ghz Tualatin Pentium 3 and I noticed this interesting result:

Looks like there's an unsigned 16-bit integer somewhere! The real FPS should be 3.848.

I'm using fixed 16.16 math to calculate the FPS (and thus not requiring floating point support), so yeah there is an overflow somewhere in the code. I'll add this issue to github and take a look. There is also another overflow calculating FPS, if the game goes above 2500 fps it starts counting negative FPS 😅🤣

EDIT: Both issues will be fixed on the next release

I've uploaded a test release with bugfixes (among with new unfinished features). @deathz0r can you check if the FPS calculation is now correct?

FastDoom 0.9.4a

On 2/20/2023 at 7:37 AM, viti95 said:

I've uploaded a test release with bugfixes (among with new unfinished features). @deathz0r can you check if the FPS calculation is now correct?

Looks good from my end! (used a 233Mhz Pentium MMX with the Realtek RTG3102 this time around since I have that currently set up, so there isn't a performance regression)

Just another quick bug report @viti95 - Adlib FX mode only works in 0.8.15 and 0.8.16 and is broken in 0.9, confirmed with using a reproduction Adlib clone. I suspect that the OPLxLPT pull request (introduced in 0.9) had broke it somehow.

Oh thanks @deathz0r, I'll take a look. Right now I'm trying to fix a memory leak that is driving me nuts.

First off, I can confirm that commit e617882 has fixed Adlib FX playback when doing a quick test with an ESS ES1868F, so bug #135 on GitHub can be closed (unless it affects OPL2LPT/OPL3LPT, but I don't have either of those to test with)

More importantly, now that I've done a playthrough of all IWADs with the revamped EGA palette I'm happy to say that I feel that it's in a good enough state for a release! The PLAYPAL is based off the existing one in MODE16 (which is simply ega_pal.wad) and improved for a somewhat better palette translation for static graphics, while the COLORMAP is very heavily modified based off the COLORMAP from IWADs to the point where it's effectively close to being remade from scratch. There probably is some finer tweaking that can be done to both PLAYPAL and COLORMAP especially with the less common areas of the standard palette, but this should be a significant improvement over the existing non-VGA palettes. I've attached MODE16/MODETXT/MODECVBS/MODE4 in a single ZIP file. Some notes:

* I duplicated palette sheet 4 into palette sheet 3 in PLAYPAL as it seemed a bit weird that the berserk effect was fading away too quickly

* MODETXT is the same as MODE16, but with COLORMAP adjusted for how the text modes utilise the colormap

* MODECVBS is based off MODE16, but COLORMAP has transitions from dark red->dark gray->black changed to dark red->black as the dark gray is significantly brighter than dark red on my IBM old-style CGA

* MODE4 is based off MODECVBS, but has the invul colormap modified for better visibility

I will eventually get around to making a MODE4 that better utilises the limitations of CGA (mainly that it needs a better balance of red vs. brown), but it's acceptable for the time being.

An amusing side effect is that for every non-VGA mode except FDOOMV16 and the text modes, there's generally a significant performance increase (especially with FDOOMEGA) with timedemo results when the CPU bottleneck is removed, though this is highly dependent on the level, regressions are rare (DEMO2 from Ultimate Doom, DEMO2 from Doom 2 and DEMO2 from Plutonia being the only built-in examples). FDOOME uses MODE16D.WAD, which as far as I can tell is just simply PLAYPAL pulled from an IWAD without modification.

fdoompal.zip

9 hours ago, deathz0r said:

First off, I can confirm that commit e617882 has fixed Adlib FX playback when doing a quick test with an ESS ES1868F, so bug #135 on GitHub can be closed (unless it affects OPL2LPT/OPL3LPT, but I don't have either of those to test with) 

Great, it was a very stupid mistake, easily fixable. Shouldn't create issues with OPLxLPT code.

9 hours ago, deathz0r said:

More importantly, now that I've done a playthrough of all IWADs with the revamped EGA palette I'm happy to say that I feel that it's in a good enough state for a release! The PLAYPAL is based off the existing one in MODE16 (which is simply ega_pal.wad) and improved for a somewhat better palette translation for static graphics, while the COLORMAP is very heavily modified based off the COLORMAP from IWADs to the point where it's effectively close to being remade from scratch. There probably is some finer tweaking that can be done to both PLAYPAL and COLORMAP especially with the less common areas of the standard palette, but this should be a significant improvement over the existing non-VGA palettes. I've attached MODE16/MODETXT/MODECVBS/MODE4 in a single ZIP file. Some notes: 

 

* I duplicated palette sheet 4 into palette sheet 3 in PLAYPAL as it seemed a bit weird that the berserk effect was fading away too quickly

* MODETXT is the same as MODE16, but with COLORMAP adjusted for how the text modes utilise the colormap

* MODECVBS is based off MODE16, but COLORMAP has transitions from dark red->dark gray->black changed to dark red->black as the dark gray is significantly brighter than dark red on my IBM old-style CGA

* MODE4 is based off MODECVBS, but has the invul colormap modified for better visibility

 

I will eventually get around to making a MODE4 that better utilises the limitations of CGA (mainly that it needs a better balance of red vs. brown), but it's acceptable for the time being.

 

An amusing side effect is that for every non-VGA mode except FDOOMV16 and the text modes, there's generally a significant performance increase (especially with FDOOMEGA) with timedemo results when the CPU bottleneck is removed, though this is highly dependent on the level, regressions are rare (DEMO2 from Ultimate Doom, DEMO2 from Doom 2 and DEMO2 from Plutonia being the only built-in examples). FDOOME uses MODE16D.WAD, which as far as I can tell is just simply PLAYPAL pulled from an IWAD without modification.

I've tested the new PLAYPAL+COLORMAP WADs and the results are incredibly good, considering only 16-colors are available. I started with ega_pal.wad as a base and tried to tune it to get the depth field right, but I ended up abandoning the idea and using the original full brightmap as it was really hard to get it done right (that's why mode16.wad is a copy ega_pal.wad 😅)

What did work for me was modifying the PLAYPAL in MODE16D.WAD for dithered modes, I did crank up the contrast and did some color level correction to use better the available colors (originally all was grey and black):

Before (without MODE16D.WAD):

After:

And yeah, performance on non-VGA color modes is highly dependant on what's rendered on screen, because those modes use differential RAM->VRAM copies to avoid bottlenecking the 8-bit ISA bus. If there are lot's of changes between frames, the FPS dip a lot (for example when changing the palette forces the screen to fully update most of the times)

I'll add the new WADs in the next release (will be available very soon) along support for PCM music and Tandy 3-voice (SN76489) support. Huge thanks for making 16-color modes look great!

Ah, thanks for the detailed explanation of MODE16D, it was hard for me to see the differences in SLADE, but that now makes sense in context.

I also decided to take a quick look at MODE4 with FDOOMCGA -palette1, and then I noticed how awful some of the transitions from other dark shades->dark gray->black looked, so I've tweaked that a bit further and now it looks as good as I'm willing to put effort into it before I recreate it from scratch.

MODE4.ZIP

If the ISA bus is the bottle neck, would it be possible to do interlaced graphics? Update every other line at each update. What's better, 20Hz interlaced or 10Hz rock solid? It could be an algorithm that is used when the amount of screen data that need updating is more than a specific threshhold in order to avoid severe frame drops. Full screen palette changes fading in like that could work well.

Some deathmatchers used to play in low detail mode in the 90s since frame rate was more important than graphical fidelity. Always having 35Hz trumped being able to see more details.

I guess it's possible to render for example only even scanlines so the data sent to the VRAM is just half, and left odd scanlines black. In my experience interlaced rendering only works fine when fps are high (50+), with less framerate it looks horrible.

New release! FastDoom 0.9.4. Changelog:

- PCM music support. Up to 44.1 KHz, 8-bit mono music. For now PCM music is stored in RAM, so more than 16Mb is recommended
- Tandy 3-voice SN76489 sound support. Sound quality is nowhere near good, but can be improved
- Sound frequency is now selectable (from 7KHz up to 44.1KHz). Removed "-lowsound" parameter since is not needed anymore
- Updated PLAYPAL+COLORMAPS for B&W, 4-color and 16-color modes thanks to @deat322 (@Deathz0r). The image quality is much better now on non-256 color modes
- Fixed issues #95, #133, #134 and #135
- Made source code buildable again on 8.3 filesystems (DOS)
- Updated FDSetup program
- Removed "Tandy Sound Source" sound card. This was the same as Disney Sound Source, but for old Tandy with incompatible parallel port

As always, have fun. https://github.com/viti95/FastDoom/releases/tag/0.9.4

Back in the 90s there was a guy who came on IRC with a hacked doom2.exe. He had changed it to 'tic' at 70Hz, no more duplicate frames. The game therefor ran at twice the speed but the turning and moving also looked a lot more fluid. The idea was to then slow down everything in the game down to half the speed in order to maintain roughly the same gameplay, but twice the frame rate. Sadly I no longer have the executable, this was ~27 years ago, it was pre-source-release.

As far as I can remember, halving the mouse sensitivity and setting it to -turbo 50 made it feel sort of ok in a nomonster setting.

Back then the main problem would be that anything that moved at say 5 units per tic can't move at 2.5 units per tic with a quick edit, so gameplay would change a fair bit. Things would either move slightly too fast or too slow. There were probably a ton of other issues as well. Doubling the tics an animation frame lasted should be possible though.

It's probably not feasible to actually do this, and animation will still look just as choppy as it does today, but movement could look better. This is a bit outside the scope of FastDoom, but it was literally a fast Doom :). Figured I'd mention it, since it was an interesting hack and slightly in the spirit of this project. It might have been more feasible to use this in a deathmatch setting.

I wonder how many hacks and tweaks like that existed back then. Some of the first 30nm runs were recorded in slow motion.

That's an easy change, the sound code drives an interrupt of 35Hz, which is the basic tick of the game. Changing that interrupt to 70Hz effectively doubles the speed of the game, is basically a 2X overclock.

I've been thinking of adding a special mode with that 70Hz interrupt, updating graphics every tick (using interpolation in uneven frames), and updating the game logic every two ticks. This way movement should be more fluid even when the game only updates at 35fps internally.

13 hours ago, zokum said:

Back in the 90s there was a guy who came on IRC with a hacked doom2.exe. He had changed it to 'tic' at 70Hz, no more duplicate frames. The game therefor ran at twice the speed but the turning and moving also looked a lot more fluid. The idea was to then slow down everything in the game down to half the speed in order to maintain roughly the same gameplay, but twice the frame rate. Sadly I no longer have the executable, this was ~27 years ago, it was pre-source-release.

I love to hear more of this. Was it a Russian hack, by any means?

I remember Entryway's Master.exe, which is a modified Doom 1.666 that allows enhanced multiplayer, and bots. I spent some time making the bot part standalone with a conversion to Dehacked 3.0 but i doubt this is what you remember.

13 hours ago, zokum said:

I wonder how many hacks and tweaks like that existed back then. Some of the first 30nm runs were recorded in slow motion.

Luckily for you, this is my forte :) Can you point me to the slo mo runs?

Andy Kemplint used to use modified DOSDoom executables, called LMPCheat and Timer, to enhance their speedruns. Adam Hegyi modified DOSDoom (D2DQ and DdQSTATS) for their Doom Done Quick series, enabling virtual cameras and were called source modifications.

If you know any more oldskool Doon2 hacks tho im all ears :)

Most of the oldschool hacks are cheats. I did have a doom2.exe where q was remapped to another key so that it was harder to accidentally quit recording demos. Hacks tend to fall into a few categories.

* Executable hacks, usually only usable in singeplayer.

* Wad lump hacks: Change colors and remove brightness levels, greatly reduce red haze

* Sprite editing: Add crosshair-like graphics, change player sprites in dm to see players more easily, reduce the size of some sprites, color code directions on rockets etc.

* Texture changes: Make players stand out more against the background / floor.

* DEH stuff like making spectres visible.

* Sound changes to make silent BFG less effective and other effects more noticeable.

* Edit segs to make it possible to see through walls / corners etc. VERY handy on map01 due to the way it contains many small 64 pixel wide segments.

The first NM30 runs of Doom 2 are in slow motion.

19 hours ago, viti95 said:

That's an easy change, the sound code drives an interrupt of 35Hz, which is the basic tick of the game. Changing that interrupt to 70Hz effectively doubles the speed of the game, is basically a 2X overclock.

 

I've been thinking of adding a special mode with that 70Hz interrupt, updating graphics every tick (using interpolation in uneven frames), and updating the game logic every two ticks. This way movement should be more fluid even when the game only updates at 35fps internally.

An easy change if you know what you are doing :). My old CRT monitor could easily reach 140Hz in lower resolutions. I guess you would need vesa for setting it up to render that often in a dos app. The monitor was an Eixo F930, I think the best it could do was 200Hz. The recommended resolution was 1600*1200 @ 100Hz. I had two of these at uni, and I threw away the most worn out one when I left uni.

On 3/17/2023 at 10:06 AM, zokum said:

Most of the oldschool hacks are cheats. I did have a doom2.exe where q was remapped to another key so that it was harder to accidentally quit recording demos. Hacks tend to fall into a few categories.

* Executable hacks, usually only usable in singeplayer.

* Wad lump hacks: Change colors and remove brightness levels, greatly reduce red haze

* Sprite editing: Add crosshair-like graphics, change player sprites in dm to see players more easily, reduce the size of some sprites, color code directions on rockets etc.

* Texture changes: Make players stand out more against the background / floor.

* DEH stuff like making spectres visible.

* Sound changes to make silent BFG less effective and other effects more noticeable.

* Edit segs to make it possible to see through walls / corners etc. VERY handy on map01 due to the way it contains many small 64 pixel wide segments.

I love to know if you have anything backed up of any of these hacks. From my diggings in the past i came across aimbots in the shape of a .COM file that altered the mouse, but i am not very aware of a lot of the examples you mention (Sans the executable hacks, ofcourse and things like NOVERT).

Quote

The first NM30 runs of Doom 2 are in slow motion.

I suppose you refer to this by Adam Hegyi?

Updates to the palette WADs:

* All RGB values used in all palette sheets are now 100% accurate to EGA/CGA values

* MODE16/CVBS/TXT has fixed up the COLORMAP for the palette range largely used for Hell Knight torsos, fixed the lower end of orange palette range (I forgot that 232-235 was an extension of 208-223) and several minor tweaks here and there, including smoothing curves in the COLORMAP and increasing the brightness of the bottom-end a bit and tweaking the COLORMAP of 3/248/249/255 relative to their nearby RGB values from IWAD PLAYPALs

* MODE4 finally uses its own PLAYPAL - blues are now greens instead of a mess of brown and black - with a COLORMAP based on the included MODE16 with all dark colour shade->dark gray->black transitions removed, a different transition for the bright red and flesh palette ranges to mid ranges, and a couple of other tweaks including the low blues transitioning to black sooner than MODE16

I also included a few extra WADs, mainly the result of HxD search & replace :) though that's more for a future stand-alone release - something that might be a better idea would be to change the intensity/palette with F11 for FDOOMCGA seeing as gamma correction does nothing with that EXE.

EDIT: updated with a minor change to MODE16/CVBS/TXT to make the small numbers in the HUD use yellow instead of white, and a small tweak to COLORMAP to reflect that change

fdoompal.zip

On 3/18/2023 at 11:36 PM, Redneckerz said:

I love to know if you have anything backed up of any of these hacks. From my diggings in the past i came across aimbots in the shape of a .COM file that altered the mouse, but i am not very aware of a lot of the examples you mention (Sans the executable hacks, ofcourse and things like NOVERT).

I suppose you refer to this by Adam Hegyi?

No, a 30 map run by Winterfeldt if I'm not mistaken. Take a look here: https://www.doomworld.com/10years/demos/demos07.php

Long demos are an excellent source for testing Doom source port compatibility and tools. If you make some sort of optimization or change and demos do not desync, it is most likely a good optimization if things go faster. Long demos also give you a decent idea about whether it was a faster approach or not.

One important thing, which I did write a bit about in my master thesis on collision detection, was that in most cases you don't want a good average frame rate, you want one that doesn't go too low. An average of 30fps that never goes below 22fps is better than an average of 32fps that goes down to 18fps, at least in my book.

This often happens when one algorithm gives you the right answer very quickly in 95% of the cases, and the rest take a quite long time, compared to another algorithm that takes longer but always takes the same amount of time.

That's why optimizing an engine like Doom and optimizing node builders can be so hard. You might think you improved the code, but it may turn out your worse case scenario is worse. A good example of this is vis planes. It is of no use that the average vis plane count goes down if you got a few spots where it hits the limit. An algorithm that built a map that never got above 125 would be preferable.

What you generally want in an optimization is to find something that is just as good as the current implementation, and better in some or many cases.

Edit: I personally think now that reducing vis planes is the #1 concern for all vanilla engine mappers. Secondary is the size of the blockmap, and then the amount of seg splits. The two first ones abort game play, either through an error message or a crash. The last one gives us minor graphical corruption in complicated scenes, and that isn't all that important. On all but ancient hardware the performance is more than good enough when it comes to the balancing of the nodes tree.

For FastDoom speed will probably be of importance for some of the target audience. There are some optimizations that can be done that would benefit 386/486 users and users of machines with 4 megabytes of ram or less. Ideally a good algorithm would create trees that are as fast as possible, without creating too many vis planes. That's a very hard goal, and realistically, I think the very best we can hope for is a rough approximation, if anything.

I have considered making a final compression step in the code. It would go through the code and perform the various known safe compression and improvement steps. The idea would be that this piece of code would not change game play, and could be executed on existing maps without breaking compatibility in any way. Thus you could speed up id's maps and less optimized pwads. Kinda like dshrink already does, but better.

Edit 2: Ideally the code would be separate enough so that others could use that bit in their source ports if they wanted to. I have received questions about including ZokumBSP as the internal node builder in ports, which I am all in favor of, it shouldn't be too hard to do. Having it as some sort of "library" to include and invoke would be really nice. It would mean making the code more modular in several key places, which to be honest isn't a bad idea. The code is a nightmare to read for new people, and I could probably comment better to let people better explain wtf is going on, and help them find bugs. Fast Doom will probably be one of the ports I occasionally test new things against, alongside chocolate doom and doom2.exe. The vast majority of testing is done on chocolate doom.

Anyone got a guide on setting this up for DOSBox? I wanna have it on hand just for the nostalgia factor.

On 3/15/2023 at 7:25 AM, viti95 said:

(for example when changing the palette forces the screen to fully update most of the times) 

Here's an idea for when palette changes are too painful for certain hardwares, perhaps an alternate mode that draws the item/pain flashes as just a solid border on the 3d view? Or maybe even a solid but dithered with holes overlay if just the border is too cheaty.

SBEmu (https://github.com/crazii/SBEMU) adds Soundblaster emulation in Dos for the following sound cards / chip sets:

• Intel ICH / nForce
• Intel High Definition Audio
• VIA VT82C686 & VT8233
• SB Live/Audigy.

Hopefully Fast Doom works well with this emulation driver, but you could also implement support for these cards in Fast Doom. That's another four more sound cards you could support! This way you could run Doom natively on a lot of newer hardware than the classic DOS era machines. I have a few machines where I reckon this would be a nice option. If more cards are added to SBEmu, it shouldn't be too hard to port these as well.

On 4/22/2023 at 9:54 AM, Tarvis said:

Here's an idea for when palette changes are too painful for certain hardwares, perhaps an alternate mode that draws the item/pain flashes as just a solid border on the 3d view? Or maybe even a solid but dithered with holes overlay if just the border is too cheaty.

One similar idea is to modify background screen color, some devices like CGA or EGA can change that value and simulate this way palette changes on the overscan area of the screen.

1 hour ago, zokum said:

SBEmu (https://github.com/crazii/SBEMU) adds Soundblaster emulation in Dos for the following sound cards / chip sets:

• Intel ICH / nForce
• Intel High Definition Audio
• VIA VT82C686 & VT8233
• SB Live/Audigy.

Hopefully Fast Doom works well with this emulation driver, but you could also implement support for these cards in Fast Doom. That's another four more sound cards you could support! This way you could run Doom natively on a lot of newer hardware than the classic DOS era machines. I have a few machines where I reckon this would be a nice option. If more cards are added to SBEmu, it shouldn't be too hard to port these as well.

Yeah SBEMU is really great, I was trying to add AC-97/HDA support in FastDoom using JUDAS library code, but never got to finish it (was a bit hard for me to understand how it works). I'll take a look how SBEMU works and try to replicate it. Anyway any help with this topic is always welcome 😅

Now as faster doom version is ready it's time to invent a time machine to push the update for the users stuck in 94.

On 4/26/2023 at 5:36 PM, zokum said:

SBEmu (https://github.com/crazii/SBEMU) adds Soundblaster emulation in Dos for the following sound cards / chip sets:

• Intel ICH / nForce
• Intel High Definition Audio
• VIA VT82C686 & VT8233
• SB Live/Audigy.

Hopefully Fast Doom works well with this emulation driver, but you could also implement support for these cards in Fast Doom. That's another four more sound cards you could support! This way you could run Doom natively on a lot of newer hardware than the classic DOS era machines. I have a few machines where I reckon this would be a nice option. If more cards are added to SBEmu, it shouldn't be too hard to port these as well.

I tried to make it work with my FreeDOS install os USB, but the HDPMI fork needed is really buggy, and it can be simply said that it doesn't work even with its DMA emulation on current-era systems.

Even Impulse Tracker didn't work properly.

Time for a new release. FastDoom 0.9.5.

Changelog:
* Sigma Designs Color 400 support. 320x200 and 16 colors. Tested only in 86Box, as I cannot make my card work on my 386/486 PCs.
* Added low and potato detail for backbuffered and VBE2 direct modes
* Removed FDOOME80.EXE and FDOOMEW1.EXE, not needed with new detail modes. They were also very half-baked, HUD was basically non-readable
* Removed FDOOMV16.EXE, didn't fit properly in the project. Is a cool hack to get VGA 160x200 and 16-colors, but Doom already supports 256 color modes which also are much faster
* Removed FastDoom VGA vertical mode. Started as a joke, and I don't feel it matches the project spirit. If people want's it back, I'll reconsider it.
* Speed up CGA, EGA, Plantronics and Hercules video modes by optimizing in ASM the backbuffer->VRAM copy routines
* Better benchmarking options, now FastDoom is able to generate CSV data (easier to import in Excel)
* Added BENCH.BAT script. This script makes easier to benchmark FastDoom. How to use it:
  * bench.bat {type} {exe} {iwad} {lmp}
  * {type}: {phil, quick, normal, full}
    * {phil}: Same benchmarks as define by PhilsComputerLab DOOM benchmark
    * {quick}: Full screen + HUD, tests potato, low and high detail modes
    * {normal}: Full screen + HUD, tests potato, low and high detail modes, and different visplane rendering modes
    * {full}: Multiple screen sizes, tests all detail settings (will take a long time if the system is slow)
  * {exe}: {fdoom.exe, fdoom13h.exe, ...}
  * {iwad}: {doom1.wad, doomu.wad, doom2.wad, ...}
  * {lmp}: {demo1, demo2, ...}
  * Example: bench.bat phil fdoom.exe doom1.wad demo3
  * Results are stored in the file "bench.csv"
* New invisible object rendering mode, now it's possible to use Heretic/Hexen translucency for objects. Cached tintmap files are stored in binary .TCF files. This rendering method only looks great on 256-color modes.
* Sound FX support for OPL2LPT and OPL3LPT devices.
* Enabled Ensoniq Soundscape music and sound FX devices. Not tested as I don't have one of these devices.
* Renamed multiple command line arguments. Take a look at the README.TXT to see what has changed.
* Fixed issue #139
* Removed "-simplestatusbar" command line parameter. Performance difference was pretty much none, and looked terribly bad.
* Cleanup unused Extended MIDI support from Apogee Sound System.
* Small optimizations for rendering code

Grab it here:

https://github.com/viti95/FastDoom/releases/tag/0.9.5

Outstanding job, I got Doom 2 running at 15-35FPS in potato mode on a 386dx-33 in PCem. Not sure if it's doable if you could split rendering to two screens and render them with different detailizations, like the near field objects are rendered in low details and far field in high. Would it work? Kind of unnecessary with processors we have but just for a sake of curiosity. Maybe it could work even faster on such slow systems if split screen was introduced with potato and super-potato mode for close objects.

One thing you could perhaps do is what Id should have done in my opinion. Make the hell knight be a palette remap ala the player colors to save memory on maps with both barons and hell knights :) There are a few of those. There might also be some mirroring tricks you could employ in order to save memory. If you stored only half the graphics for the cacodemon and mirrored it when drawing, how noticeable would it be, and could you run Final Doom on 4 meg machines witch such tweaks? :)

Quake uses mipmapping to speed up rendering and reduce moire. Could some sort of tradeoff be done to improve the image quality and possibly render faster as well. Doom has a few areas where moire can look pretty ghastly. The outer walls on map15 in Doom 2 springs to mind.