viti95

Maybe a VAXstation 3100 could run Doom with the GPX color graphics board

There is an easier way to compile Doom from scratch, just take a look at DoomGeneric: https://github.com/ozkl/doomgeneric

https://x.com/viti95/status/1812065740133920798?t=Q8s0Rihq8t0skCN2U-Em9Q&s=19 This is a test on my 386sx-33, still far from being playable with decent graphics lol

New dev updates. I've added untextured column rendering, it's faster but crimples gameplay a lot: Untextured walls: Untextured walls + no diminished lightning As a side effect, also sprites can be rendered untextured: This will be available on the next release

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.