viti95

Wolfenstein 3D uses lot's of clever tricks to make it playable on 286 machines, which are not usable on Doom's engine. For example there are no heights, no visplanes and only 90 degree walls that makes computations way faster. It's very fast on high detail as sprites and walls are precompiled on each level, making scaling really fast on VGA cards (multiple columns are rendered in a single pass, see Game Engine Black Book: Wolfenstein 3D by Fabien Sanglard). Also "AI" from enemies in Wolf3D is much simpler compared to Doom. All in all the 386 doesn't have the required power to move Doom properly without doing some serious cutdowns.

New release, FastDoom 0.9.9e! Changelog: * Fixed diminished lightning issues on high resolution VESA modes * Fixed some 2D status bar and menus misalignements * Fixed rendering corruption on VESA 386SX codepath * Fixed MS-DOS 7 crash #187 * New fonts for 320x100 resultion modes (half height) * Optimizations (C) https://github.com/viti95/FastDoom/releases/download/0.9.9e/FastDoom_0.9.9e.zip

Sorry for necrobumping this, but I'm having this same issue in FastDoom on HighRes modes. How did you fixed it? Thanks!

OpenWatcom doesn't generate really good asm code. There are even some worse things like the same instruction repeated twice without doing anything relevant. For example: Sometimes I use GodBolt to generate chunks of code in ASM with better compilers like GCC, and then integrate that into my code. Not ideal, but much faster than having to do everything by hand.

Fdoom13h is a bit faster sometimes on full detail mode, because drawing columns and spans don't require to change between planes using OUT instructions, and the ASM code from Heretic uses better the x86 register set (no "scratchpad" memory is used). Also it has two different ways to copy the backbuffer to the VRAM. First one is using 32-bit REP MOVS (fast bus speed option), which is good on the 386. The slow option does a differential copy, updating only required pixels (this option works fine with fast cpu's and very slow 8-bit ISA bus). Yep, the double pixel (or the potato quad pixel) VGA optimization works really well here, as the ISA bus is very slow and bottlenecks quite easily. The less you use it, the better. I think FDoomH is a bit slower is due to the number of OUT instructions used per frame to change between planes, at least 320 are required for FDoomH while Fdoom half detail only requires 160.

I've found what was causing the diminished lightning issue, so the fix will be available on the next release.

New release! FastDoom 0.9.9d: https://github.com/viti95/FastDoom/releases/tag/0.9.9d Changelog: * VESA 400x300 modes support * Fixed issue #181 (FastDoom crashes on exit when using AWE32 music device + SoftMPU). Thanks @TheElf01 for finding this issue. * Multiple optimizations (C) * New VGA 320x100 executable. Uses same direct rendering method as vanilla Doom, but with half height resolution. High detail resolution is 320x100, low detail 160x100 and potato detail 80x100. Recommended for slow 386 cpu's with VGA cards. 2D elements also have half height resolution, so text is pretty much unreadable (unless someone creates a WAD with optimized fonts for this mode) * Fixed issue #192 (Save game buffer overflow). Now saving on MAP24 of Hell Revealed doesn't crash. Thanks @deat322 for finding this issue. * Added debug to file support for debugging (only for developers)

I think it's crashing because the sound engine has failed on initialization, and that causes memory corruption, later or sooner it ends up crashing. I'm still trying to fix all sound engine bugs.

Mmmmm interesting, didn't know that the MAXSEGS limit is not enough for Doom II. I'll do some testing myself on FastDoom. EDIT: I've done some debugging on FastDoom, and I wasn't able to get any errors due to using more solidsegs than 32, even in Plutonia or TNT. The maximum I got has been 28 solidsegs using IDCLIP cheat on Ultimate Doom E4M8 going outside the map. On Doom II MAP15 I got 25 maximum solidsegs. So I guess the error comes from elsewhere maybe? EDIT 2: There is a way to check rendering limits in realtime thanks to @Julia Nechaevskaya CRL (https://github.com/JNechaevsky/CRL). I'm thinking of raising rendering limits a bit to avoid crashes on FastDoom, for example E4M8 can crash if you clipp outside the map: EDIT 3: Yep, It crashes FastDoom xD

Yep, R_DrawSpan function takes a lot of CPU time, that's why rendering flat visplanes is much faster. This video shows a very good comparison of a 386SX with and without cache. Even with a small amount of 64Kb the difference is huge.

I'd say a very fast 286 (Harris 20/25 MHz) would require at least visplanes to be disabled to run at decent speeds. Even with that some maps like E4M2 would be very hard to play. It's a shame there are no 286 boards with any kind of cache, that would help a lot. 386SX boards with cache handle Doom much better.

Aaaaand another small release! FastDoom 0.9.9c: https://github.com/viti95/FastDoom/releases/tag/0.9.9c Changelog: Serial MIDI support (fixed baudrate 38400, COM1 through COM4 selectable) Fixed 512x384 VESA modes

New bugfixing release! FastDoom 0.9.9b: https://github.com/viti95/FastDoom/releases/tag/0.9.9b Changelog: Hercules InColor support Mode-X 320x240 mode support (great for old laptops without VESA support and 640x480 display) Fixed MDA debug, now text don't blink all the time Fixed issue #183, random crashes on low-res executables Fixed issue #62, videocards with more than 8Mb crashed on VESA modes Removed "-singletics" commandline parameter. It was only used for debugging purposes. Upgraded build scripts Removed MS-DOS/Windows build scripts. Those were pretty much outdated, and all tooling now is Linux based. It's possible to build FastDoom on Windows using WSL2.

Autorun key is F12. In which config do you have slowdowns on OPL cards? Seems a bit strange to me, I've tried on very slow 386 cpu's and music seems to play fine (maybe my ears are not trained on this topic 😅). What I've found issues is on some Sound Blaster clones with fast CPUs, but those issues also happened on other games. Yeah MT-32 is still missing support, I do have one so I can try to support it better. As for hardware mixing, I think it's possible to support this very well on AWE cards, lot's of memory are available for samples (up to 28Mb). On the GUS this is a bit harder, memory is limited to 1Mb, and it's used close to 100%. But not all is lost on GUS cards, since old revisions of the Apogee Sound System did support multichannel sound hardware mixing. It was later removed in order to simplify the library. One of the things I wanted to do was to remove external dependencies on AWE and GUS cards, right now both are using external libraries for it's support. Again, DOS sound code is hard as f*ck, so any help here is very welcome. Low color modes benefit a lot from higher resolutions + dithering, the main issue here is the ISA 8-bit bus bandwidth. It's extremely slow. That's why I had to remove "high resolution" modes like EGA 640x200 or ATI 640x200. Even with optimizations those modes run at 12 fps at best on time period hardware. Also we are not using direct rendering for low color modes, as this is only possible with a chunky pixel layout. I think this it's not very effective to render directly with 16 colors or less on the backbuffer, It's is better to render on 256 colors and use better/faster algorithms to reduce color depth.

I'll take a look, haven't tested any of my FX cards yet. Adding an OPL emulator is a bit of out of the main goal of the project, as now SBEMU works really well and support is much better. Also, we are much closer to a "1.0" release, and I was thinking about what a "1.0" release should have. For now, I've added support for Mode-X (320x240), very useful on laptops without VESA support and 640x480 screens, and the Hercules InColor support. What do you think the next release should have?