Hi,

This sounds really neat, my 286 currently has a Hercules installed and connected to a monochromatic monitor, so I might try it with a HW emulator at first, but definitely try it in the future 😀.

sqpat wrote on 2026-06-28, 04:54:

RealDOOM is a port of vanilla DOOM (forked from PCDoomv2) made to run in Real Mode for x86-16 processors. The goal of RealDOOM i […]
Show full quote

RealDOOM is a port of vanilla DOOM (forked from PCDoomv2) made to run in Real Mode for x86-16 processors. The goal of RealDOOM is to maintain timedemo level compatibility and visual quality equivalent to the original game. The application has been fully rewritten in assembler and it uses EMS to use memory beyond 640kb.

RealDOOM has been worked on for a little over 3 years and is finally entering beta so I'm hoping to find people willing to play through the DOOM games in the engine to try and help find remaining bugs and compatibility issues, even if not doing so on a 286 machine or anything like that. A pentium class machine will run the engine great, just like the original. A 386 will also have a much better time running this than vanilla DOOM.

The engine is quite stable now - most of the known bugs involve some render glitches in specific situations. Random crashes do seem to happen maybe every 2-3 hours. So I hope players can expect a good time.

You can download the binaries for the beta release here and the sources are on the repo at https://github.com/sqpat/RealDOOM

Minimum System Requirements:
- Hard Disk
- 2 MB of RAM with Pageable Conventional EMS Memory
- 8088 or compatible processor
- VGA Display Adapter

Recommended System Requirements:
- 3-4 MB of RAM (for larger texture and sound caches)
- 20 MhZ or faster 286 processor

RealDOOM supports:
- PC Speaker and Sound Blaster SFX
- Adlib, Sound Blaster, and MIDI music
- Mouse (with modified input control to use only left/right and not up/down)
- RealDOOM currently supports Shareware DOOM, commercial DOOM 1&2 and Ultimate doom.

RealDOOM does not support:
- Custom WADs (but support is planned)
- Netplay
- Joystick

Notes on RealDOOM and EMS
The initial version of RealDOOM (0.10) supported using just a page frame, but current versions require pageable conventional memory. Specifically, memory from the 256kb-640kb range must be pageable in addition to the page frame. 386 and newer machines can run EMM386 to support this easily. Earlier machines need a chipset or memory card capable of paging conventional memory. The popular LoTech EMS board does not do this. Boards such as the Intel Above Board support this type of pagination. Compatible 286 chipsets supporting this include VLSI SCAMP and TOPCAT, Headland HT-18 and up, and C&T SCAT. I have also written EMS drivers to support all these chipsets.

It's possible a version in the future may eventually be built supporting running from just a page frame again, but I am not in a hurry to do that as first I'd like to finish fixing bugs and add a few features custom wad support, faster lower fidelity renderer support and FPU acceleration.

Running RealDOOM
There are several builds of RealDOOM optimized for different processors (such as 386, 286, 8088). The application might crash on startup if you run an incompatible version - especially on the 8088.
- Make sure you have your doom WAD in the same directory as the game
- Make sure you have at least 562 kb of conventional memory available.
- Make sure your EMS driver is loaded. I'd recommend SQEMM if your hardware supports it as it is lightweight and fast.
- Sound, etc configuration must be done via the default.cfg like with Vanilla DOOM. Set Sound/Music device to 3 for sound blaster, for example.
- Chipset builds currently only support page frame as D000
- The included readme.txt has some more information

Performance
A fast 25 mhz 286 machine runs RealDOOM faster than a 40 mhz 386DX runs the original DOOM in default settings. Framerate in low (not potato) detail and default screen size is around 15fps. I have played through most of the entire games on a 286. Larger levels with lots of monsters (Doom 2 MAP13 especially) can face really low framerates. A 5150 can run the game with the right hardware, but of course the result isn't really playable. Makes for a great benchmark I suppose.

In general, RealDOOM will run with 50-60% higher framerate on a 386DX than vanilla doom and 80-90% faster on a 386sx on higher graphical settings. On systems with cache on the cpu (486, pentium, even 486SLC type chips) the performance is about equal so there's not too much reason to run it, but it can still be an easier way to run the engine while getting max framerate if you are curious.

I have a spreadsheet with various benchmarks on RealDOOM on different hardware over time.

Notes on Building RealDOOM

Currently, RealDOOM uses OpenWatcom 2.0 and TASM 2.51 to build. While the main application has no C code left in it, there is a build step which packages code into a 'library' and this build step is written in C. I tend to build from DOSBOX for convenience. Install and set up your TASM 2.51 and Openwatcom 2.0 directories and then set your variables (WATCOM, INCLUDE, PATH, etc) to point to the right directories if the installers did not already do this for you.

Download the source code and run "makeall 286" to build the application for a 286, "makeall 386" to build the application for 386 targets, etc. There are targets for various chipset builds that allow EMS driverless operation where the application will hit chipset registers directly to page memory. These builds run a tiny bit faster and uses a little bit less memory. The 8088 build avoids use of 186/286 instructions and the 386 build uses 32 bit instructions in several spots to increase performance.

Some Known Issues:
- I've been made aware drive overlays steal memory from the 0x9c000 ish region from MS-DOS. This will be incompatible with RealDOOM which needs all the high pageable conventional memory regions.
- RealDOOM is a bad DOS citizen and does not ask for permission to use memory ranges. This is generally fine and it generally cleans up after itself, but if you have some other services running at the same time then I don't know if it will work out. I have seen some heavier EMS drivers which try and ask dos for memory while they are running and that is no good for example. Eventually I suppose I should communicate with the OS
- There are graphical glitches that exhibit themselves as junk vertical lines from time to time. I'm aware of this but they are fairly uncommon and I didn't think it had to prevent a beta release
- MAP30 seems to mess up the adlib engine
- There are some texture cache corruption bugs, which results in some large outdoor walls sometimes rendering incorrectly
- 22 Khz sfx mixing (namely, the super shotgun) can produce garbage sound from time to time.

Future Plans/Possibilities:
- Fix Bugs
- Support Custom WADs (but there are some size limits, so I dont think TNT/plutonia in their entireties will be possible)
- Re-implement untextured renderer
- FPU support for FixedDiv, which should be a little bit faster
- ASM rewrites of physics code to improve performance a little more.
- Maybe create a self booter and MS-DOS stub implementation to increase resources to run the game.
- EMS Page Frame Version

I'll do my best to answer questions on anything related to the project.

thanks a lot!! i always check your project every some time, i did not test 0.89 Beta Release 1 yet!!! as soon i can i wil do!!!

For reference, i think already say in vintage forums, my 286 is a Harris 25, 4mb ram, board with HT18 chipset, ems support

Love to test, im outside because work, in some days i will write back thanks

Oh, this is so cool. I don’t know why, but i like the idea of real mode Doom so much.
I wonder why 486 machines don’t benefit much from this port. Isn’t assembly code supposed to run faster?

theelf wrote on 2026-06-28, 13:28:

For reference, i think already say in vintage forums, my 286 is a Harris 25, 4mb ram, board with HT18 chipset, ems support
Love to test, im outside because work, in some days i will write back thanks

Ah shoot - I realized the release builds expect 4-5 MB of memory - let me fix that. I just added a 0.89-Over2MB.zip to the release which is better configured for machines with 3-4 MB.

I hope you give the HT18 build a try - it shouldn't require an EMS driver loaded and should run a little bit faster. I think with your specs, the entirety of doom1 and most of doom2 is pretty playable. (MAP 13 is rough. You fire one shot and the whole map worth of enemies come alive.)

Bondi wrote on 2026-06-28, 14:01:

Oh, this is so cool. I don’t know why, but i like the idea of real mode Doom so much.
I wonder why 486 machines don’t benefit much from this port. Isn’t assembly code supposed to run faster?

It mostly comes down to cache and prefetch. I'd say in a general sense, RealDOOM has more small instructions that take up less total space but Vanilla DOOM has fewer large instructions that take up more space in total.

While the 386 brought along x86-32 and x86-32 is great, the 386 is actually a pretty poor at running 32-bit code. The instructions get to be very large and choke up the prefetch queue. This results in the 386's ALU sitting around doing nothing a lot of the time (similar to the 8088/8086, though not nearly as bad.). So if an application is converted from 32-bit code to 16 bit code, it can generally result in smaller instructions and the 386 can keep itself busier running lots of smaller instructions and the 32-bit wide data bus can potentially read multiple instructions at a time.

Meanwhile while the 486 does technically still have a prefetch queue, its backed by a relatively large chip cache (kilobytes instead of 12 or 16 or 32 bytes or whatever). This mostly means that the 486's ALU is pretty busy compared to a 386 when running 32-bit code because that cache is often full of code waiting to be run. So while the original doom binary is relatively inefficiently compiled 32 bit C code, the 486 doesn't really suffer all too much from that. The 32-bit code has fewer individual instructions that each run as fast as the individual smaller 16 bit instructions.

What really makes this obvious is a 386sx vs a 486slc. A 386sx runs RealDOOM much much faster than vanilla doom for the same reasons above plus improvements in using 16 bit instead of 32 bit values, resulting in faster memory reads over a 16 bit bus. This doesn't necessarily help the 386DX which has a 32 bit bus to begin with, but its very apparent on a 386sx. So if you have one of these 486-class 386sx upgrades like a 486SLC what happens? Perhaps unexpectedly, Vanilla DOOM can still run better or nearly so. This is because the 486SLC has on chip cache, and it can keep the cpu busy running the larger 32 bit instructions. The chip actually does not have to go read from memory that often after all.

There's also a lot of self modifying code. I'm not really sure how 486, Pentium, etc cache controllers handle this and how that affects performance. It can only make performance worse and not better relative to no cache though.

This reminds me, I haven't tested RealDOOM on a 486 in a while. It's possible the renderer crashes somewhere due to self-modifying code falling within the prefetch queue of the 486. I have had this problem in the past, but my 486 machine needs a PSU replacement and I haven't gotten around to that.

Not a big deal though - FastDOOM already exists for such machines anyway.

I can’t wait to compare this against FastDoom on my Pocket386 (386sx-40).

Update-

Whoa. It plays well. On LOW quality, full screen (well with status bar), Adlib music and PC speaker sound. I’m getting 12.868 fps on -timedemo demo3.

I feel like RealDoom has edge’d out FastDoom in this particular instance- 16bit memory read/write seems like a huge boost for 386sx. Great work, I’ll be watching for updates.

Update: Confirmed FastDoom at same settings score 10.784 fps

sqpat wrote on 2026-06-28, 04:54:

RealDOOM is a port of vanilla DOOM (forked from PCDoomv2) made to run in Real Mode for x86-16 processors. The goal of RealDOOM i […]
Show full quote

RealDOOM is a port of vanilla DOOM (forked from PCDoomv2) made to run in Real Mode for x86-16 processors. The goal of RealDOOM is to maintain timedemo level compatibility and visual quality equivalent to the original game. The application has been fully rewritten in assembler and it uses EMS to use memory beyond 640kb.

RealDOOM has been worked on for a little over 3 years and is finally entering beta so I'm hoping to find people willing to play through the DOOM games in the engine to try and help find remaining bugs and compatibility issues, even if not doing so on a 286 machine or anything like that. A pentium class machine will run the engine great, just like the original. A 386 will also have a much better time running this than vanilla DOOM.

The engine is quite stable now - most of the known bugs involve some render glitches in specific situations. Random crashes do seem to happen maybe every 2-3 hours. So I hope players can expect a good time.

You can download the binaries for the beta release here and the sources are on the repo at https://github.com/sqpat/RealDOOM

Minimum System Requirements:
- Hard Disk
- 2 MB of RAM with Pageable Conventional EMS Memory
- 8088 or compatible processor
- VGA Display Adapter

Recommended System Requirements:
- 3-4 MB of RAM (for larger texture and sound caches)
- 20 MhZ or faster 286 processor

RealDOOM supports:
- PC Speaker and Sound Blaster SFX
- Adlib, Sound Blaster, and MIDI music
- Mouse (with modified input control to use only left/right and not up/down)
- RealDOOM currently supports Shareware DOOM, commercial DOOM 1&2 and Ultimate doom.

RealDOOM does not support:
- Custom WADs (but support is planned)
- Netplay
- Joystick

Notes on RealDOOM and EMS
The initial version of RealDOOM (0.10) supported using just a page frame, but current versions require pageable conventional memory. Specifically, memory from the 256kb-640kb range must be pageable in addition to the page frame. 386 and newer machines can run EMM386 to support this easily. Earlier machines need a chipset or memory card capable of paging conventional memory. The popular LoTech EMS board does not do this. Boards such as the Intel Above Board support this type of pagination. Compatible 286 chipsets supporting this include VLSI SCAMP and TOPCAT, Headland HT-18 and up, and C&T SCAT. I have also written EMS drivers to support all these chipsets.

It's possible a version in the future may eventually be built supporting running from just a page frame again, but I am not in a hurry to do that as first I'd like to finish fixing bugs and add a few features custom wad support, faster lower fidelity renderer support and FPU acceleration.

Running RealDOOM
There are several builds of RealDOOM optimized for different processors (such as 386, 286, 8088). The application might crash on startup if you run an incompatible version - especially on the 8088.
- Make sure you have your doom WAD in the same directory as the game
- Make sure you have at least 562 kb of conventional memory available.
- Make sure your EMS driver is loaded. I'd recommend SQEMM if your hardware supports it as it is lightweight and fast.
- Sound, etc configuration must be done via the default.cfg like with Vanilla DOOM. Set Sound/Music device to 3 for sound blaster, for example.
- Chipset builds currently only support page frame as D000
- The included readme.txt has some more information

Performance
A fast 25 mhz 286 machine runs RealDOOM faster than a 40 mhz 386DX runs the original DOOM in default settings. Framerate in low (not potato) detail and default screen size is around 15fps. I have played through most of the entire games on a 286. Larger levels with lots of monsters (Doom 2 MAP13 especially) can face really low framerates. A 5150 can run the game with the right hardware, but of course the result isn't really playable. Makes for a great benchmark I suppose.

In general, RealDOOM will run with 50-60% higher framerate on a 386DX than vanilla doom and 80-90% faster on a 386sx on higher graphical settings. On systems with cache on the cpu (486, pentium, even 486SLC type chips) the performance is about equal so there's not too much reason to run it, but it can still be an easier way to run the engine while getting max framerate if you are curious.

I have a spreadsheet with various benchmarks on RealDOOM on different hardware over time.

Notes on Building RealDOOM

Currently, RealDOOM uses OpenWatcom 2.0 and TASM 2.51 to build. While the main application has no C code left in it, there is a build step which packages code into a 'library' and this build step is written in C. I tend to build from DOSBOX for convenience. Install and set up your TASM 2.51 and Openwatcom 2.0 directories and then set your variables (WATCOM, INCLUDE, PATH, etc) to point to the right directories if the installers did not already do this for you.

Download the source code and run "makeall 286" to build the application for a 286, "makeall 386" to build the application for 386 targets, etc. There are targets for various chipset builds that allow EMS driverless operation where the application will hit chipset registers directly to page memory. These builds run a tiny bit faster and uses a little bit less memory. The 8088 build avoids use of 186/286 instructions and the 386 build uses 32 bit instructions in several spots to increase performance.

Some Known Issues:
- I've been made aware drive overlays steal memory from the 0x9c000 ish region from MS-DOS. This will be incompatible with RealDOOM which needs all the high pageable conventional memory regions.
- RealDOOM is a bad DOS citizen and does not ask for permission to use memory ranges. This is generally fine and it generally cleans up after itself, but if you have some other services running at the same time then I don't know if it will work out. I have seen some heavier EMS drivers which try and ask dos for memory while they are running and that is no good for example. Eventually I suppose I should communicate with the OS
- There are graphical glitches that exhibit themselves as junk vertical lines from time to time. I'm aware of this but they are fairly uncommon and I didn't think it had to prevent a beta release
- MAP30 seems to mess up the adlib engine
- There are some texture cache corruption bugs, which results in some large outdoor walls sometimes rendering incorrectly
- 22 Khz sfx mixing (namely, the super shotgun) can produce garbage sound from time to time.

Future Plans/Possibilities:
- Fix Bugs
- Support Custom WADs (but there are some size limits, so I dont think TNT/plutonia in their entireties will be possible)
- Re-implement untextured renderer
- FPU support for FixedDiv, which should be a little bit faster
- ASM rewrites of physics code to improve performance a little more.
- Maybe create a self booter and MS-DOS stub implementation to increase resources to run the game.
- EMS Page Frame Version

I'll do my best to answer questions on anything related to the project.

I tested RealDOOM on my 286.

The HT18 version does not work on my system. It loads correctly, but when I select "New Game", the hard drive keeps reading continuously and it never progresses. The floppy disk icon appears and seems to keep resetting over and over.

I also tested the regular 286 version with you ht18 ems driver sqem3 . In that case the game loads, but the sound effects are broken and produce strange noises.

Using the original Headland EMS driver, the game works much better. However, I still get some random graphical glitches, although they are fairly rare and the game is generally playable.

I am not really seeing any FPS improvement compared to previous versions. Running doom -timedemo demo3 gives me about 8.5 FPS, which is roughly what I was getting before. This is in low detail mode with the status bar enabled.

If there is any test you would like me to run, I would be happy to try it. Thanks.

sqpat wrote on 2026-06-28, 19:47:

It mostly comes down to cache and prefetch. I'd say in a general sense, RealDOOM has more small instructions that take up less total space but Vanilla DOOM has fewer large instructions that take up more space in total.

So would you say that this project is less about reducing Doom's overall computational complexity (like you see in FastDOOM) and more about repackaging the same engine to avoid performance pentalties on <=386 architechtures

What is the core optimization that makes it run faster?

It does not run faster than classic and fastdoom versions on the same hardware. The main value proposition of realdoom is that it can run on sub 386 hardware - 286 and 808x.

@sqat - thanks for announcement post!
Great stuff.

NeoG_ wrote on 2026-07-01, 01:37:

sqpat wrote on 2026-06-28, 19:47:

It mostly comes down to cache and prefetch. I'd say in a general sense, RealDOOM has more small instructions that take up less total space but Vanilla DOOM has fewer large instructions that take up more space in total.

So would you say that this project is less about reducing Doom's overall computational complexity (like you see in FastDOOM) and more about repackaging the same engine to avoid performance pentalties on <=386 architechtures

well... the miracle is that RUN on <386

pshipkov wrote on 2026-07-01, 07:03:

It does not run faster than classic and fastdoom versions on the same hardware. The main value proposition of realdoom is that it can run on sub 386 hardware - 286 and 808x.

@sqat - thanks for announcement post!
Great stuff.

But it does run faster than classic and fastdoom on my particular hardware. I would guess 386sx-40 is probably the best case scenario for this. I get +2 fps on RealDoom at same settings, which doesn't sound like much but when your are talking about 12fps and 10fps, its significant.

gsos wrote on 2026-07-01, 02:12:

What is the core optimization that makes it run faster?

From what I've read its re-written in assembly and the conversion to 16bit memory read/write - instead of 32bit memory operations.

08088/286 simply cant do 32bit, and 386sx (maybe 386dx) still do 16bit operations faster than 32bit.

theelf wrote on 2026-06-30, 19:01:

I tested RealDOOM on my 286.

The HT18 version does not work on my system. It loads correctly, but when I select "New Game", the hard drive keeps reading continuously and it never progresses. The floppy disk icon appears and seems to keep resetting over and over.

Just double checking, did you use the 2MB build? The other one needs 4 MB of ems plus conventional. (Your earlier post had reminded me to add that configuration in a second zip file.)

theelf wrote on 2026-06-30, 19:01:

I also tested the regular 286 version with you ht18 ems driver sqem3 . In that case the game loads, but the sound effects are broken and produce strange noises.

Hmm ok. Do you have any other drivers or services loaded/active? Including anything using XMS out of curiousity? When it comes to chipset xms/ems, they are coming from the same pool of memory. SQEMM is really barebones and just uses memory starting at the 1MB or 2MB mark and assumes XMS is not active.

theelf wrote on 2026-06-30, 19:01:

Using the original Headland EMS driver, the game works much better. However, I still get some random graphical glitches, although they are fairly rare and the game is generally playable.

I am not really seeing any FPS improvement compared to previous versions. Running doom -timedemo demo3 gives me about 8.5 FPS, which is roughly what I was getting before. This is in low detail mode with the status bar enabled.

If there is any test you would like me to run, I would be happy to try it. Thanks.

Yeah FPS has not really improved in the last month or two, mostly fixing sound effects and bugs and glitches. As you pointed out the glitches are present (usually some vertical lines). If they are very common graphical glitches taking up large parts of the screen, I determined that to be failing RAM in one case.

Just curious, what video card are you running and what score do you have in the topbench benchmark? My usual machine I play with runs a a score of 69-70 and gets ~9 fps on hi settings, so when I am in low I get ~14-15 fps. Usually i am running screen size 9 and not 10 though.

Anyway, I don't have access to my HT-18 board for the next month or so, so I can only theorize right now. Let me think about it for a bit, maybe I'll come up with something.

pshipkov wrote on 2026-07-01, 07:03:

It does not run faster than classic and fastdoom versions on the same hardware. The main value proposition of realdoom is that it can run on sub 386 hardware - 286 and 808x.

@sqat - thanks for announcement post!
Great stuff.

Thanks !

So it *should* run significantly faster on 386 class hardware than vanilla doom. Fastdoom it depends. The realdoom renderer is probably more optimized - especially moving pixels - but the physics is way behind. So it is starting from a deficit, and the more pixels you draw (higher settings) the faster realdoom runs. I haven't run tests recently but I would guess realdoom is generally faster in high detail and slower in potato and low detail not sure. But fastdoom has so many renderer options and I'm not sure if there are some better options possible for the 386.

gsos wrote on 2026-07-01, 02:12:

What is the core optimization that makes it run faster?

Too many to name really. The entire application is rewritten. The game spends 90% of the time in the renderer in high graphics settings, so i guess bluntly mostly its that the renderer is a lot faster. Drawing most of your pixels is 10 bytes of code in an unrolled loop in RealDOOM and in vanilla... its a loop with something like 35 bytes of code or so according to planar.asm. probably takes 3-4 times as long to put individual pixels on screen. The entire application is more or less rewritten to facilitate these fast draws, putting data where it needs to be ahead of time.

If you are really interested, I did a talk on RealDOOM last year and had some slides for a presentation - you can read thru it here:
https://docs.google.com/presentation/d/14RBug … dit?usp=sharing

I think this was right before the alpha version, but for the most part the architecture has not changed, it's just been made faster via more and more asm rework, self modifying code, etc.

sqpat wrote on 2026-07-01, 17:54:

Just double checking, did you use the 2MB build? The other one needs 4 MB of ems plus conventional. (Your earlier post had remin […]
Show full quote

theelf wrote on 2026-06-30, 19:01:

I tested RealDOOM on my 286.

The HT18 version does not work on my system. It loads correctly, but when I select "New Game", the hard drive keeps reading continuously and it never progresses. The floppy disk icon appears and seems to keep resetting over and over.

Just double checking, did you use the 2MB build? The other one needs 4 MB of ems plus conventional. (Your earlier post had reminded me to add that configuration in a second zip file.)

theelf wrote on 2026-06-30, 19:01:

I also tested the regular 286 version with you ht18 ems driver sqem3 . In that case the game loads, but the sound effects are broken and produce strange noises.

Hmm ok. Do you have any other drivers or services loaded/active? Including anything using XMS out of curiousity? When it comes to chipset xms/ems, they are coming from the same pool of memory. SQEMM is really barebones and just uses memory starting at the 1MB or 2MB mark and assumes XMS is not active.

theelf wrote on 2026-06-30, 19:01:

Using the original Headland EMS driver, the game works much better. However, I still get some random graphical glitches, although they are fairly rare and the game is generally playable.

I am not really seeing any FPS improvement compared to previous versions. Running doom -timedemo demo3 gives me about 8.5 FPS, which is roughly what I was getting before. This is in low detail mode with the status bar enabled.

If there is any test you would like me to run, I would be happy to try it. Thanks.

Yeah FPS has not really improved in the last month or two, mostly fixing sound effects and bugs and glitches. As you pointed out the glitches are present (usually some vertical lines). If they are very common graphical glitches taking up large parts of the screen, I determined that to be failing RAM in one case.

Just curious, what video card are you running and what score do you have in the topbench benchmark? My usual machine I play with runs a a score of 69-70 and gets ~9 fps on hi settings, so when I am in low I get ~14-15 fps. Usually i am running screen size 9 and not 10 though.

Anyway, I don't have access to my HT-18 board for the next month or so, so I can only theorize right now. Let me think about it for a bit, maybe I'll come up with something.

pshipkov wrote on 2026-07-01, 07:03:

It does not run faster than classic and fastdoom versions on the same hardware. The main value proposition of realdoom is that it can run on sub 386 hardware - 286 and 808x.

@sqat - thanks for announcement post!
Great stuff.

Thanks !

So it *should* run significantly faster on 386 class hardware than vanilla doom. Fastdoom it depends. The realdoom renderer is probably more optimized - especially moving pixels - but the physics is way behind. So it is starting from a deficit, and the more pixels you draw (higher settings) the faster realdoom runs. I haven't run tests recently but I would guess realdoom is generally faster in high detail and slower in potato and low detail not sure. But fastdoom has so many renderer options and I'm not sure if there are some better options possible for the 386.

gsos wrote on 2026-07-01, 02:12:

What is the core optimization that makes it run faster?

Too many to name really. The entire application is rewritten. The game spends 90% of the time in the renderer in high graphics settings, so i guess bluntly mostly its that the renderer is a lot faster. Drawing most of your pixels is 10 bytes of code in an unrolled loop in RealDOOM and in vanilla... its a loop with something like 35 bytes of code or so according to planar.asm. probably takes 3-4 times as long to put individual pixels on screen. The entire application is more or less rewritten to facilitate these fast draws, putting data where it needs to be ahead of time.

If you are really interested, I did a talk on RealDOOM last year and had some slides for a presentation - you can read thru it here:
https://docs.google.com/presentation/d/14RBug … dit?usp=sharing

I think this was right before the alpha version, but for the most part the architecture has not changed, it's just been made faster via more and more asm rework, self modifying code, etc.

Hi! about HT18 version, i use the 2mb, the 4mb i tested but complain need more EMS pages

About SQEMM, i tested without anything extra, just your driver. In fact, because realdoom is not compatible with ezdrive, i just made a 512mb CF card with only realdoom to test! jeje

The card is a Trident 8900D 0WS, is fastest i found, i use this window size and low mode. doom -timedemo demo3 just give me 8.5 more or less, with sound, without sound 8.7 not much difference

I tested too a ET4000EX, OAK and some other cards, all slower than trident. Only card that give me same performance than 8900D is a CL5422