That's charming, I'd love to see this being developed further!

Have you looked at the restored code for various versions of the game? Maybe there's some interesting stuff there too.

Very nice that you enabled a no-FPU mode. Have you actually tested this on a 386? I think that official releases of Duke3D never supported 386s as an architecture. Would be neat if you could make something along the lines of FastDoom eventually.

Thanks, glad somebody finds it useful

It's pretty nice that there's lot of source code present on the web.

I also liked FastDoom projects as it's something that allows to get more out of less and here's where my interest grows from basically. There's also Doom8088 and RealDoom that I once ranted about how bad they were, it's incredible to see how the games can be optimized, not my level though yet.

There's a feature I liked so much about FastDoom that allows to render much faster except for the other is that differential screen drawing in 13h mode. I tried to do it once and it didn't work as intented. I came up with an A.asm assembly that does I_CopyLineDuke feature but instead of adding FPS, it dropped very slightly, unfortunately, must be done wrong.

Well some work is being done anyway.

MrFlibble wrote on 2025-06-22, 12:21:

Very nice that you enabled a no-FPU mode. Have you actually tested this on a 386? I think that official releases of Duke3D never supported 386s as an architecture. Would be neat if you could make something along the lines of FastDoom eventually.

I have tested it on a PCem's 386 - it works but really slow, Duke3D was made for 486 and the manuals say it btw, so it must be a really tedious task to make it work on a 386.
The approach published here actually still uses FPU but way less. I tested slopes on PCem's Cyrix 486DR2 (a faster 386 clone) and 486sx and according to "DNRATE" FPS indicator it worked almost as fast as on DX except for the awful image quality on slopes. I couldn't implement a proper horizontal interpolation so it's just where it is now.

I came up with some alternative purely integer math asm implementations of slope drawing routines. At this moment they look bad and work slower than my previous attempt, yet faster than the original FPU routines. Pretty interesting that they have an affine texture mapping routine there but I could never make it work as it crashes - might be that I made wrong declarations and pragmas in engine.c as they were never there and we can only guess how.

I have a feeling that we can speed up Duked3D on 486SX machines though, like calling those assembly wall drawing routines less often to decrease detailization or even drawing them in solid color replacing complex asm routines to simpler ones.

Maybe you could fix that really annoying bug where if you chose weapon 1 (kick with boots), whenever you pick up ammo it auto-switches to that weapon instead, like it or not.

Darkcrafter07 wrote on 2025-06-22, 21:50:

I have a feeling that we can speed up Duked3D on 486SX machines though, like calling those assembly wall drawing routines less often to decrease detailization or even drawing them in solid color replacing complex asm routines to simpler ones.

The Build editor's 3d view runs significantly faster on slower 486s where Duke3D can't be played, so there's probably con overhead at play (probably a big part of ken's 'waste of time' wrt low detail mode)

leileilol wrote on 2025-06-23, 02:24:

Darkcrafter07 wrote on 2025-06-22, 21:50:

I have a feeling that we can speed up Duked3D on 486SX machines though, like calling those assembly wall drawing routines less often to decrease detailization or even drawing them in solid color replacing complex asm routines to simpler ones.

The Build editor's 3d view runs significantly faster on slower 486s where Duke3D can't be played, so there's probably con overhead at play (probably a big part of ken's 'waste of time' wrt low detail mode)

That's some really interesting info I didn't know about. So I fed duke3d's game.c displayrooms and build's game.c drawscreen to AI and came up with the build version displayrooms for duke3d. In PCem on 486sx2-66 It doesn't have any extra bump in FPS compared to original but messed many things like sprites lighting, animation, logic and so on, maybe it's just AI.

I guess it's still better to perform less calls on asm routines to draw walls just like I did with nofpu on slopes but I need to find a way to interpolate that. Then we have to come up with a solution on how to implement Doom's fashion low end detail mode because Duke3D's simply renders screen in a small tile then stretches it up to the hires screen.

Duke07 update to v0.11:

- up to 768000 bytes MIDI playback.

- up to 10 custom 4-tile 256px width panoramic skies (defined
in DEFS.CON). Make sure for the names SKYCUSTOM1-SKYCUSTOM10
to stay the same. If you use a tile #3840, make sure you have
3 more tiles space left in your art file, e.g. #3841,3842,3843
must be free to fit remainig 3 parts of your sky.
All necessary example files included.