Frenkel

Awesome, it's always great to hear it runs on real hardware. I'm pretty sure it's impossible to use real XMS on anything lower than a 286. But I guess it's possible to create a program that runs on an 8088 and that implements parts of the eXtended Memory Specification by using files instead of extended memory. Doom8088 only uses three XMS functions: at start up it (1) allocates one big memory block to load the WAD into, and at the end it (2) frees this memory block. During gameplay it (3) reads lumps from extended memory. So basically XMS is used as one file that can be read very fast. I guess similar performance can be achieved by using an SSD instead of a hard disk. For now no XMS Upper Memory Blocks are used. Instead EMS is used as one Upper Memory Block of 64 kB, no bank switching. It's possible to load the WAD into EMS, but with all the bank switching it won't be as easy to implement as using XMS. Though I've put this on the to-do list. I don't think Mode 13h would be faster than Mode Y. In Mode Y writing 1 byte sets 4 pixels at once and it uses double buffering and page flipping. Mode 13h needs to write 4 bytes to set 4 pixels and at the end of every frame it needs to copy 240*160 bytes from the back buffer to video memory. Mode 13h is mainly for computers with MCGA graphics, which don't support Mode Y. Mode 13h is useful for printf() debugging. Mode 13h's back buffer approach can also be used for 640x200 2 color, 320x200 4 color and other modes that can't do page flipping.

In Doom8088 the screen melt is done the same way as in nRF52840 Doom and GBA Doom. quote source wipe_shittyColMajorXform() isn't needed.

Since this previous release some code is written in assembly and in the latest release the whole WAD file is loaded into XMS memory. In 86Box emulating a 286 @ 25 MHz running timedemo 3, I get 8.580 frames per second with Mode 13h and 10.395 with Mode Y.

A video that debunks the myth that Duke Nukem Forever became Alien Rampage would be great.

Awesome. Is the code for the textured floors and ceilings the same as in Blake Stone and/or Super 3D Noah's Ark?

Doom8088 got a nice size improvement by compiling with -mnewlib-nano-stdio. When optimized for size the Watcom executable is about 5 kB smaller than the GCC executable.

Exit Level cheat: LEFT,R, LEFT, L, B, LEFT, RIGHT, A

https://www.doomworld.com/forum/post/1301624

I use some assembly in Doom8088, but it doesn't speed up the game that much compared to the gcc-ia16 generated code. In most cases FixedDiv(a, b) can be replaced by FixedMul(a, FixedDiv(0x10000, b)) or actually FixedMul(a, 0xffffffff / b). (Except for P_InterceptVector() which needs FixedDiv() to keep demo 3 in sync.) To calculate the reciprocal of a fixed_t value gcc-ia16 generates generic code that divides two int32_t values. To calculate the reciprocal one of the input values is always 0xffffffff, so I made my own reciprocal specific assembly code. I got a speed boost of 4% by programming the loop in R_DrawColumn() in assembly. Then I noticed it could be faster if the segment registers could be set once at the start of the loop, instead of switching during every iteration between pointing to the texture source, video memory destination and the colormap. So I put the colormap in near memory. This change also sped up the C code variant, so now the assembly version is only 0.8% faster. :|

Watching @deathz0r playing my Doom port Doom8088 for the first time.

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.

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.

"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. 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

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?

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.