Doom8088: Doom on a 286 / 8088

[Frenkel]

On 8/30/2023 at 2:30 PM, viti95 said:

The IDE port light blinks like there is no tomorrow

 

I've tried Doom8088 on the slowest computer I have that has a VGA card. It has a 386SX processor running at 20 MHz and a 100 MB hard disk.

For every lump the game read the directory in the WAD file and then jumped to the lump's filepos. So the hard disk head had a lot of work to do.

 

Those loading times aren't fun. So now Doom8088 caches everything.

[slowfade]

That screenshot looks so good! I say this without sarcasm, I really mean it. What kind of fps are you getting with that?

[Frenkel]

A few frames per second.

 

 

Actually, it has a cheat that changes the ammo counter into a frames per second counter. Too bad the status bar isn't rendered. :D

[slowfade]

So it's already just as fast as some of those console ports! Keep us updated and good luck. Do you have plans what you're going to optimize / make faster next?

[Darkcrafter07]

You know the ideas guy here. If 8088 platform is from the same age as NES, maybe it also can be optimized the same way? I mean NES has something called "Patterns", some tiny parts of the picture that the whole screen consists of?

[slowfade]

I think they're close in age but the hardware differences are vast. I think NES has a slower processor but it can still pump a steady 60 fps because its drawing methods for television are so different.

[viti95]

NES and IBM XT are different in every aspect, so the optimization techniques are totally different. Also NES hardware is designed for 2D games, with hardware tiles and such stuff, while XTs have no acceleration for graphics at all (there are a few tricks though). The idea here is to focus on make the high level code as efficient as possible, and then optimize it in ASM (https://www2.math.uni-wuppertal.de/~fpf/Uebungen/GdR-SS02/opcode_i.html)

[Frenkel]

There are a couple of things I want to do:

* Try different compilers. According to dccb Microsoft C/C++ and Digital Mars C/C++ produce faster code than Watcom (if you run it in DOSBox. So only the number of instructions is benchmarked.) I also want to try gcc-ia16, but as far as I can see it doesn't support the large memory model. So first I'll have to rewrite the code so it runs in the medium memory model.

* Optimize the WAD by using some ideas of WADptr.

* Replace variables of type int32_t in r_draw.c by int16_t or int8_t.

 

I also want to replace functions in r_draw.c by assembly routines.

And I want to replace the back buffer by Mode X style page flipping. And EGA, Tandy, CGA...

[viti95]

22 hours ago, Frenkel said:

* Optimize the WAD by using some ideas of WADptr.

 

I've been trying Ultimate Doom IWAD compression and it's size it's reduced up to 14%, so compression techniques work. The downside is that WADptr source code is a bit hard to work with. Also RP2040-Doom has a very good explanation on what can be optimized and compressed even further (https://kilograham.github.io/rp2040-doom/flash.html).

 

22 hours ago, Frenkel said:

I also want to replace functions in r_draw.c by assembly routines. 

 

Will the textured column and visplane rendering come back? Maybe fast 286s can deal with this on low resolutions.

 

22 hours ago, Frenkel said:

And I want to replace the back buffer by Mode X style page flipping. And EGA, Tandy, CGA... 

 

Non-VGA modes will likely require a backbuffer, because multiple pixels are stored in a single VRAM byte. Also as there are no multiple video pages available, not having a backbuffer causes flickering. The main issue is that rendering a column requires a read before write for each pixel, which is very slow. Visplane rendering doesn't have this problem though (only at the start and the end of each line). There are a few exceptions where pixels are stored in a single byte, have multiple video pages and can avoid using a backbuffer:

 

- CGA text modes 80x25 and 40x25, and EGA text mode 80x43. The main issue here is that CGA has the snow problem on the 80x25 resolution.

- EGA mode E, using planar tricks. 80x200 resolution. This mode is quite fast, works exactly the same way as VGA Mode X.

 

 

About EGA... there are no good ways to make it behave like it has a chunky VRAM layout for full resolution, only the "80x200" video mode is fast. This mode is really a 640x200 mode, so it's possible to render the HUD in "high" detail, but requires conversion of the graphics to make better use of the planar VRAM layout.

Edited September 15, 2023 by viti95

[viti95]

Another idea that may help. Use VGA Mode Q as basis. It has a resolution of 256x256 pixels and it uses the whole 64kb window. The best part is that pixel addressing is much easier, just set AH register for Y and AL register for X, no need for any multiplication.

[Frenkel]

The code is still there for textured column and visplane rendering, and sky and status bar rendering. It's just disabled, see macros FLAT_WALL, FLAT_SPAN, FLAT_SKY and DISABLE_STATUS_BAR.

 

Digital Mars C/C++ doesn't support int64_t, so that compiler is out for now, or I'll have to rewrite FixedDiv and FixedMul now to not use int64_t. These functions probably will be rewritten anyway, in assembly.

[Frenkel]

I got gcc-ia16 to compile Doom8088. In DOSBox at 50000 it gets 50 fps, Watcom 40.

On a real computer it looks like this:

 

 

[Plerb]

I like how it looks with solid colored walls. It reminds me of pre-Doom 3D PC games, like LHX and Stunts.

[Frenkel]

To celebrate 40 years of PCjr, here's a quick hack of Doom8088 with 160x200 16 color PCjr graphics.

It's running in DOSBox with machine=pcjr and cycles=3000.

 

 

[Dark Pulse]

5 hours ago, Frenkel said:

To celebrate 40 years of PCjr, here's a quick hack of Doom8088 with 160x200 16 color PCjr graphics.

It's running in DOSBox with machine=pcjr and cycles=3000.

 

 

Nice to see Lilith.pk3 is supported!

[Frenkel]

I've decreased the horizontal resolution from 120 to 60 pixels and I've made some performance improvements, but now it crashes sometimes because it's trying to divide by zero.

 

Here are two videos of Doom8088 running in 86box emulating a 286 @ 25 MHz.

 

 

 

[slowfade]

Impressive! Congratulations, it really does run at playable speed on 286 now -- and I assume the work isn't done yet... Hope you'll find the zero divide error.

 

Out of curiosity, can you estimate how many cpu cycles it takes getting a color value from a texture's data? Compared to drawing a monocolor pixel just associated to the texture?

[Frenkel]

The zero divide error has been fixed in the mean time.

 

I get almost 11 frames per second in timedemo 3 in 86box with the Mode X version and these colors. The version in which every wall is texture mapped with the same texture everywhere gets 7.5 frames per second. There are still some calculations in  R_DrawColumn that use 32-bit variables and I want to replace those with 16-bit variables.

[slowfade]

Cool. I guess it's not far-fetched to think it'll eventually run as fast as it does now but with textures instead of colors.

 

By the way, have you told "the demoscene" about this project? Those people have written perhaps the most optimized gfx code ever made for computers; they might have good/new ideas for all kinds of optimizations, from rendering to data storage. Might be worth investigating at some point.

[Frenkel]

Texture mapped walls, and the color of the floors and ceilings is based on the texture of the floors and ceilings.

E1M1 is playable, sort of. E1M2 is a slideshow.

 

 

I've made a topic about Doom8088 on the Vintage Computer Federation Forums. There are demosceners there, right?

I haven't made a topic on Vogons yet. There are still some features I want to add first.

[,,,]

What was the reason for basing this on GBADoom rather than something like FastDoom? Isn't GBADoom based on PrBoom? Surely that adds a lot of extra bloat.

[slowfade]

As far as I know it's because GBADoom is the most optimized port in terms of low-end hardware performance, cramming the game data into a very small memory space and running on a slow processor -- both aspects that matter a lot on 286. I think FastDoom doesn't try to get the memory footprint as small as possible nor even tries to work on 286 but aims to work as fast as possible on 386/486.

 

Frenkel: I don't actually know what the best place might be. I was thinking of pouet.net but there might be better venues out there, its BBS looks a bit chaotic.

 

Video looks cool by the way!

[Frenkel]

This is actually my fourth attempt at a 16-bit Doom port. My first attempt came after viti95 mentioned doomgeneric. My second attempt came when the source code of Vanilla Doom was reconstructed. Both attempts failed because the executables would require too much memory.
Then I came across nRF52840 Doom, a Doom port that needs far less memory. That attempt failed because the code was full of platform specific code. nRF52840 Doom is based on GBADoom. So for my fourth attempt I used GBADoom. GBADoom comes with a port for Windows. I was really surprised to see how easy it was to port that code to 32-bit DOS. That code is now the basis for Doom8088.

 

"Although it is based on prBoom, most of the engine enhancements (dehacked, limit removing etc) have been reverted back to Vanilla. This is either for memory or performance reasons." It's too bad GBADoom has removed multiplayer support and demo compatibility is broken.

 

FastDoom replaced lots of C code by 386 assembly code written in Watcom's dialect. Rewriting that to support a 286 would take a lot of time.

[Julia Nechaevskaya]

Maybe it is worth to try to generate composite textures while level precaching? An example from Crispy Doom may be handy. This should fix notable hicups upon first time entering areas with non-generated composites (notable example is computer room behind the first door on E1M1), but from another hand, this will require some extra memory and will increase level loading time.

[Frenkel]

To celebrate Doom's 30th anniversary, here's a version of Doom8088 with PC speaker sound effects.

 

 

 

Did you have a 286 with a sound card 30 years ago?

[deathz0r]

On 12/11/2023 at 3:50 AM, Frenkel said:

To celebrate Doom's 30th anniversary, here's a version of Doom8088 with PC speaker sound effects.

Hah, you uploaded that new build quite literally hours after I did another playthrough with the latest git commit at the time I was streaming this:

https://www.twitch.tv/videos/2001911133

 

compdj.bat is an absolute crime though - it really should be a makefile as COMMAND.COM has a limit of 127 characters, I had to compile with Open Watcom 2.0 instead. A clean makefile you could probably use as a template is the one included with the DETH 4.24 source code.

On 12/11/2023 at 3:50 AM, Frenkel said:

Did you have a 286 with a sound card 30 years ago?

My family received a hand-me-down 286 @ 16Mhz in 1996 from a great-uncle which I recall him owning back in 1993, which ended up being the first time we had two PCs at the same time and I ended up using it 90% of the time - that 286 had both VGA and a Sound Blaster-compatible card, I don't recall the specific details but since it outputted the PC speaker through external speakers it would have been a sound card that had PC speaker input passthrough. I played through all of Spear of Destiny with a reduced screen size on that thing!

Edited December 12, 2023 by deathz0r

[Frenkel]

3 hours ago, deathz0r said:

Hah, you uploaded that new build quite literally hours after I did another playthrough with the latest git commit at the time I was streaming this:

https://www.twitch.tv/videos/2001911133

 

"I like to see you modern speedrunners attempt to do that at 3 fps." LOL

 

If you could change the keyboard keys, which keys would you use?

 

It looks like there's still some code that tries to divide by zero. That needs fixing.

I'm working on getting E1M6 to run by reducing it's file size.

 

 

3 hours ago, deathz0r said:

compdj.bat is an absolute crime though - it really should be a makefile as COMMAND.COM has a limit of 127 characters, I had to compile with Open Watcom 2.0 instead. A clean makefile you could probably use as a template is the one included with the DETH 4.24 source code.

 

compdj.bat is for building a 32-bit version with DJGPP. I use this build of DJGPP and that one doesn't come with make.

 

It's nice to see the Watcom version running on a 286 with an SSD. The executable is smaller than the gcc-ia16 version, which means the Watcom version has about 45 kB more free memory to store the graphics. I use an old 100 MB hard disk and it really slows the game down. When there's not enough free memory for a texture a single color is used instead. When the sky texture is replaced by a single color, I like to think it's thunder and lightning. So it's actually a feature. :P

[deathz0r]

18 hours ago, Frenkel said:

If you could change the keyboard keys, which keys would you use?

I'm the least qualified person to be asking for keyboard setup, since I normally use a variation of Sedlo's config that I've been using since the end of 2001 :)

 

Before that, I simply used the vanilla default keys so I have little problem re-adapting to it - the main problem I had with the playthrough was with the weapon switching setup, which I can tell is ported from GBADoom. Having the original 1-7 setup would be fine for me, I imagine everyone else would like to redefine the keys to at least the same way that is possible with vanilla.

 

18 hours ago, Frenkel said:

compdj.bat is for building a 32-bit version with DJGPP. I use this build of DJGPP and that one doesn't come with make.

 

It's nice to see the Watcom version running on a 286 with an SSD. The executable is smaller than the gcc-ia16 version, which means the Watcom version has about 45 kB more free memory to store the graphics. I use an old 100 MB hard disk and it really slows the game down. When there's not enough free memory for a texture a single color is used instead. When the sky texture is replaced by a single color, I like to think it's thunder and lightning. So it's actually a feature. :P

Ah, fair enough. I didn't try cross-compiling since I didn't have a gcc-ia16 build environment like that set up and didn't want to get sidetracked for >=half a hour at 11PM on a Sunday night, and my quick attempt within DOSbox on my Win7 PC had failed hard. I'll take a look into the makefile when I get some spare time.

 

I wasn't aware that the Watcom build had a smaller memory footprint, that makes for an interesting comparison for texture loading - I'll have to do another playthrough soon.

 

[Frenkel]

Adding new features while keeping the memory usage down is becoming a balancing act. That's why I'm holding off redefinable keys for now. But hardcoding new keys is doable. For example, I could add WASD if there is demand for it.

BTW, Changing the switching weapons keys is on the to-do list.

 

I get a higher score in timedemo 3 in 86box when compiling with gcc-ia16 optimized for size than for speed. All because of the memory footprint. And with the Watcom 16-bit build I get random freezes.

[Frenkel]

Mode Y is now supported.

 

In 86Box emulating a 286 @ 25 MHz running timedemo 3, I get 5.940 frames per second with Mode 13h and 7.991 with Mode Y.

 

The keys for weapon switching are now [ and ].

IDDQD, IDKFA, etc. are supported. IDRATE shows the current frames per second and IDROCKET gives every enemy a rocket launcher.

Edited December 22, 2023 by Frenkel