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.

Duke07, v0.12 update:
- finally an "interpolated" way to do slopes with /nofpu flag.
Ken's unfinished "slopevlin2" approach now renamed to #0.
"slopevlin" duplicated and now is #2 approach, has its own
precision parameters, and most importantly, simulateneous pixel writes
to the sides, allowing to "interpolate" only those columns that were
requested in grouscan_nonfpu function in engine.c, frame parity removed
for a while but the file is still there if you will - engaltgs.c.
The a.asm changes:

; we now add this thing above
mov [ebp-1], al ; Pixel to the left - 1
;the original line below:
mov [ebp], al ; Center Pixel
; we now add this thing beneath
mov [ebp+1], al ; Pixel to the right + 1

you can iterate more to fill in the gaps

I tried using just integers in slopes calculations, both Ken's #2 approach crashes and so does mine. All original game slopes calculations seem to be done in integers fixed point only but FPU is used to load the variables in its own stack to cover for some strange and bad things happening like racing conditions or registers conflicts. Is this right or I'm missing something? I disassembled both standard and integer approach to see whether slopmach offsets are wrong but they're correct so far?

Maybe we have assembly experts here?

Here's some news. An attempt was made to compile Duke07 entirely for 386 but unlike the previous attempt made here a while ago, all the code refactored to compile, from C files to A.ASM - mostly thanks to the asm instruction line with "bswap" changed to these 3:
"ror eax, 16",\
"xchg ah, al",\
"xchg dh, dl",\

and all occurences of "Nice try" removed from eng386.c. It has two compilation "paths" now - make.bat and make386.bat, read "HowToMake.txt" to find out more. Unfortunately, I don't have a real 386 and can't confirm whether it runs there or not but under PCem it does. Btw, special thakns to sqpat for pointing at the subject with duke386.

An attempt was also made to impelement low detail mode in Doom fashion, just like on slopes with /nofpu flag: calling functions to draw less often in an interleaved way and fill in the unprocessed fields with info from the processed ones.
Currently, only walls and skies are made properly and all the rest stuff like sprites, floors and ceilings are in the experimental phase. This looks wrong but works a bit faster. Btw, I couldn't find a way to enable this mode on the fly from the game's menu as the game will crash. Even though I came up with "A.ASM" with "LQ2X" suffix on all labes and compiling and running correctly, as soon as paired up with original "A.ASM" will crash. Also it's very mirror unfriendly.

Darkcrafter07 wrote on 2025-07-19, 23:29:

Here's some news. An attempt was made to compile Duke07 entirely for 386 but unlike the previous attempt made here a while ago, […]
Show full quote

Here's some news. An attempt was made to compile Duke07 entirely for 386 but unlike the previous attempt made here a while ago, all the code refactored to compile, from C files to A.ASM - mostly thanks to the asm instruction line with "bswap" changed to these 3:
"ror eax, 16",\
"xchg ah, al",\
"xchg dh, dl",\

I'm confused, that does not achieve the same thing as bswap.

jmarsh wrote on 2025-07-20, 01:16:

Darkcrafter07 wrote on 2025-07-19, 23:29:

Here's some news. An attempt was made to compile Duke07 entirely for 386 but unlike the previous attempt made here a while ago, […]
Show full quote

Here's some news. An attempt was made to compile Duke07 entirely for 386 but unlike the previous attempt made here a while ago, all the code refactored to compile, from C files to A.ASM - mostly thanks to the asm instruction line with "bswap" changed to these 3:
"ror eax, 16",\
"xchg ah, al",\
"xchg dh, dl",\

I'm confused, that does not achieve the same thing as bswap.

hmm that could explain why it starts to behave like nuts when mirrors are encountered, it was a bit rushed attempt, I'll try something different next time.

Well, yes, the work on low detail mode is on and it looks crisper than the original one already. There are artifacts but it actually makes the game to perform faster with smaller window sizes.

Is my attachment space restricted?
I wouldn't want to create a GitHub page yet so I decided to stick to external file storages for the moment?

Duke07, v0.14, exe an sources download

v0.14 features:
- further enhancements on LQ2X mode, a lot has been done but there's
a room for improvements. Now that it works just as fast as ingame low
detail mode it looks crisper and much faster when window size is shrunk.
Unfortunately, the old default ingame mode is ineffective on little
windows size because it always renders a larger 160x100 view and then
stretches up or down the rendered view onto 320x200 screen and does
double job which makes the game perform slower.
- correct "bswap" 386 asm instructions by Tronix, so mirrors are ok
- the way to fill unprocessed fields in asm has been found and unlike
left (-1, -2 etc.) or right (+1, +2 etc.) writes, there's a need to know
screen width in pixels. It could be done by loading "_xdim" variable in
asm functions but it's out of scope for the moment and "320" constant is
hardcoded. Read ALQ2X.ASM for details. Enabling transmach4 pixel doubling
logic brings the light on "drawsprite_LQ2X" function issues in eng386.c.
There's a need to polish it further.
- flat vertical sprites with transparency don't render yet.

There's not that much going on with the source port:

v0.15 features:
- the original game comes with its own y-parallax scrolling defined as
"parallaxyscale" in engine.c in "parascan" function and premap.c
"setupbackdrop" function. Setting it to 65535 does the trick, thus
I set my approach parallax scroll speed to 0 to disable it. So we have
nice original smooth parallax effect and height tracking parallax
per player. Also, my approach wasn't properly reset per level so that
I added "g_skyycuroffs" variable, initialized it to 0 and assigned
all sky cases offsets in premap.c. Each time a level is loaded, the
offset resets to those defined in premap.c per "g_skyycuroffs" value.
- an attempt to implement LQ3X mode was made. It looks even worse and
there's no speed gain unlike LQ2X mode, thus not compiled. Set "ydetail"
variable to "3" in eng386.c, run "MakeLQ3.bat".

Duke07_exe_n_src_v015_download

Thank you! I have to try this with my old HP terminal t5300 some day, if i tested Duke3D in dos long time ago then audio had stutterings.

Only instructions it has is MMX and its 533Mhz Transmeta Crusoe CPU. 😀
https://www.parkytowers.me.uk/thin/hp/t5300/

marxveix wrote on 2025-08-06, 21:42:

Thank you! I have to try this with my old HP terminal t5300 some day, if i tested Duke3D in dos long time ago then audio had stutterings.

Only instructions it has is MMX and its 533Mhz Transmeta Crusoe CPU. 😀
https://www.parkytowers.me.uk/thin/hp/t5300/

This must be a super computer for Duke Nukem 3D actually, the game requires at least a system with a 486 at 66Mhz, and yours is about 10 times faster.
The problem with your PC is that it doesn't have a proper sound card like Sound Blaster 16, that's the biggest issue and issue #2 is Windows CE.
I'm really not sure whether you could install a Windows 98SE in there and I would NOT do that in the first place.

Maybe you could try a different source port made purely for Windows like eduke32 ?

Darkcrafter07 wrote on Yesterday, 09:07:

This must be a super computer for Duke Nukem 3D actually, the game requires at least a system with a 486 at 66Mhz, and yours is […]
Show full quote

marxveix wrote on 2025-08-06, 21:42:

Thank you! I have to try this with my old HP terminal t5300 some day, if i tested Duke3D in dos long time ago then audio had stutterings.

Only instructions it has is MMX and its 533Mhz Transmeta Crusoe CPU. 😀
https://www.parkytowers.me.uk/thin/hp/t5300/

This must be a super computer for Duke Nukem 3D actually, the game requires at least a system with a 486 at 66Mhz, and yours is about 10 times faster.
The problem with your PC is that it doesn't have a proper sound card like Sound Blaster 16, that's the biggest issue and issue #2 is Windows CE.
I'm really not sure whether you could install a Windows 98SE in there and I would NOT do that in the first place.

Maybe you could try a different source port made purely for Windows like eduke32 ?

I can say its sounds fast, but it its not that fast, feels like AMD K6 200-300Mhz. Win9x works well and dos sound works with viasbcfg and probably sbemu also. VIASBCFG - VIA SBPro configuration tool for VIA VT8231 & VT82C686/A/B chipsets (v0.12d)

Duke Nukem 3D port with DirectX6/7 or OpenGL 1.1 would help with Windows and ATi Rage graphics.
I would like it to be playable well @ DOS also, not only Windows.

Even AMD K6-200 is a good machine for Duke3D in 320x200. Back in the day I had AMD K5 PR133 (100MHz), ESS Audio 1686 WDM (SB and OPL3 compatible), 1MB Cirrus-Logic, 16MB RAM and a 800MB (later 2GB) HDD machine and never had any issues with Duke3D, it was blazingly fast in 320x200, it started to slow down in 640x480 but that's probably a relatively weak video card, not the CPU.

Btw, isn't SBEMU too slow for your system? It uses CPU to emulate FM-Synthesis playback.

I tested it with 640x480 and i can say that Duke07.exe works better for me than original Duke3d.exe with Transmeta cpu, no audio lag any more in dos, /nofpu makes some places blurry, i use it without. Menu loading also faster but Duke07 starts as v1.4 and Duke3d.exe as v1.5 and v1.5 has demoscene background. Ingame audio lag seems gone with Duke07, thats good news for me. 😀

I was using viasbcfg and viafmtsr, Thank you!