marxveix wrote on 2025-08-07, 13:30:

Menu loading also faster but Duke07 starts as v1.4 and Duke3d.exe as v1.5 and v1.5 has demoscene background.

IIRC, demo playback was commented out in the original Duke3D source, because compiling the EXE with it somehow made it unstable, and most ports, however vanilla, have not bothered bringing it back, save for Rednukem and that one much more obscure port that has other issues (forgot what it's called).

MrFlibble wrote on 2025-08-07, 14:44:

IIRC, demo playback was commented out in the original Duke3D source, because compiling the EXE with it somehow made it unstable, and most ports, however vanilla, have not bothered bringing it back, save for Rednukem and that one much more obscure port that has other issues (forgot what it's called).

That's some interesting info!

marxveix wrote on 2025-08-07, 13:30:

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!

Nice, don't worry about v1.4 on intro, it's still v1.5 as source says: "Duke Nukem 3D (v1.5 CD Version) Source Code Release - April 1, 2003".

Strangely enough, I have no real clue why is it faster than original Duke3D.exe? nofpu flag blurs slopes so that it runs on systems without FPU (you know those digits with points old CPU couldn't process without special fpu emulators, well Duke3D has an emulator hooked up if FPU isn't found). Especially for 386sx and 486sx CPU (DX systems a have built-in FPU). There was also a NexGen 686 CPU that had an FPU but really weak one so this nofpu feature may serve it well too.

Maybe it's because it removes a played animation from RAM and stops all sounds?

The issue I'm worried about is bugs on some mirrors like on E2M6 so that if I get too close to it it swtiches to showing the above (ROR) sector with ventiliation shaft, they appear as soon as I add "use_fpu" condition to "drawalls" function in engine.c

Now i also use dos32awe. exe. This utility also assists the VIA's Sound Blaster emulation (VIAFMTSR) that uses VIA chipset south bridges for protected mode games otherwise they hang, fail or sound choppy. This choppy sound and slowdowns i experienced, now way better with duke07.
DOS32AWE - DOS/4G compatible DOS Extender with Sound Blaster AWEUTIL MIDI synthesizer support for Protected mode,VIASB

you can use 4gbind.exe that you can find in my attachments in "source" directory to unbind dos4g extenders of all the versions so that's gonna produce a clean exe file without one. Here's how you do it: "4gbind duke3d.exe clean.exe". As soon as it's done, you can use any extender of your choice.

Darkcrafter07 wrote on 2025-08-07, 17:06:

you can use 4gbind.exe that you can find in my attachments in "source" directory to unbind dos4g extenders of all the versions so that's gonna produce a clean exe file without one. Here's how you do it: "4gbind duke3d.exe clean.exe". As soon as it's done, you can use any extender of your choice.

.bat file also works for me, i may do it later, thank you. 😀

marxveix wrote on 2025-08-07, 17:10:

Darkcrafter07 wrote on 2025-08-07, 17:06:

you can use 4gbind.exe that you can find in my attachments in "source" directory to unbind dos4g extenders of all the versions so that's gonna produce a clean exe file without one. Here's how you do it: "4gbind duke3d.exe clean.exe". As soon as it's done, you can use any extender of your choice.

.bat file also works for me, i may do it later, thank you. 😀

You're welcome, btw, I prefer 640x400, open duke3d.cfg and change resolution with a notepad, it's going to get rid you of jaggied pixelated look as duke3d actually one of the few dos games that does aspect ratio correction. It performs it via nearest-neighbor filtering for sure. It's gonna get you the same dimensions 320x200 gives but 4 times crisper image (320x200=64000, 640x400=256000, 256000/64000=4). It could also get you some slight 20% performance boost. Interestingly enough, it works with 512x384 resolution too but hud looks really sawed.

Darkcrafter07 wrote on 2025-06-20, 02:10:

Duke07 is perhaps my source port of Duke Nukem 3D for MS-DOS.

I came up with an idea to make this port accidentally after messing around original Duke Nukem 3D source code.
I'm a beginner at coding and after some more or less "successful" attempts to modify the original engine I realized it could be stacked all together.

Well this is quite an ambitious place to start with if you are a beginner. I haven't looked at the code myself, but I have heard that it is rather hard to understand due to the structure and naming convensions used. Ken was basically a genius to produce this, as a self taught teenager when he made it. But that doesnt necesarily make for very maintainable or portable code.

Much respect to you for attempting it. Even more praise for having some success.

RetroPCCupboard wrote on 2025-08-07, 18:45:

Well this is quite an ambitious place to start with if you are a beginner. I haven't looked at the code myself, but I have heard that it is rather hard to understand due to the structure and naming convensions used. Ken was basically a genius to produce this, as a self taught teenager when he made it. But that doesnt necesarily make for very maintainable or portable code.

Much respect to you for attempting it. Even more praise for having some success.

Thanks. Ken indeed is a genius, especially considering the fact he made it while being a teen. I know it doesn't but I wanted to have specificaly an MS-DOS port. There's XDuke, EDuke32 and JFDuke and Raze ports that run on other platforms natively. EDuke32 and Raze code base differ from the original way too much. There's even a DOS version of EDuke32 but it requires 128MB RAM which I think is waaay too much, as I had 64MB at best back in the day.

The original source code structure is also something I prefer to EDuke32, seems more logical, straightforward and intuitive to me than huge pile of stuff spread around different files, headers and etc.

Darkcrafter07 wrote on 2025-08-07, 19:00:

I know it doesn't but I wanted to have specificaly an MS-DOS port. There's XDuke, EDuke32 and JFDuke and Raze ports that run on other platforms natively. EDuke32 and Raze code base differ from the original way too much. There's even a DOS version of EDuke32 but it requires 128MB RAM which I think is waaay too much, as I had 64MB at best back in the day.

The original source code structure is also something I prefer to EDuke32, seems more logical, straightforward and intuitive to me than huge pile of stuff spread around different files, headers and etc.

I am not sure what you mean when you say you are making an MSDOS port. The original game was MSDOS, so if you are editing that code are you not enhancing it rather than porting it? Or are you rewriting the code to work in a different compiler? Sorry if you said that earlier and I missed it.

RetroPCCupboard wrote on 2025-08-07, 19:41:

I am not sure what you mean when you say you are making an MSDOS port. The original game was MSDOS, so if you are editing that code are you not enhancing it rather than porting it? Or are you rewriting the code to work in a different compiler? Sorry if you said that earlier and I missed it.

A "source port" is largely a term for anything based of some sources, be it a fork for the same platform or another. Even though Duke07 can be considered a fork of the original game, it also can be called a "source port".

I used to think a lot on how software is written and had some really spicy discussions on doomworld. There are people telling quite interesting opinions on it and look back how we all enjoyed stuff then vs now.

This game is interested to work with from the technical stand point.
Once I stumbled across performance issues when mapping for Doom I started to learn on optimization techniques.

I said AI was used here but not too much, yet it allows to discover amazing details about the code, it's such a nice opportunity I had to compare codes of Doom, Duke3D, Quake, Descent and even Tomb Raider as these are disclosed, how things are working etc...

So one of the main problems of 90's 3D games were rendering optimization. All 4 games approached the subject differently.
Doom was the pioneer, the simplest and perhaps most efficient approach, raycast the scene, draw vertical spans (scanlines).

Duke3D went further - even though it introduced raycasted walls just like Doom, it took it further allowing for different texture colorations, scaling, flipping and coded in SIMD-alike approach (MMX, SSE and etc) when those instructions did not exist and worked on a 486. The latest version detects whether MMX instructions or other Pentiums 1, pro and 2 are present and applies a special optimization on TOP of that too. Duke3D also introduced vertical and horizontal sprites with varying transparencies, colors, angles, scales etc... but not just that - slopes. Slopes in Duke3D are drawn almost like perspective correct polygons 1/z fashion, just like quake but much faster as they set them up with entirely integer code and do inverse reciprocal multiplication on FPU which were becoming super-affordable with latest tech the 1996 game went out on (DX2-66, DX4-100, Pentiums), it was some sort of multithreading of 90's use both CPU and FPU to provide for crisper and smoother image. The bitter side of Duke3D is caching mechanism which I think adds some bit of lags but the game may play animation which makes it more "alive".

Doom, Duke and Descent would run and play on a 486-66MHz machines while Quake wouldn't, even on a DX4-100 it remained largely unplayable because it was coded specifically for 586. It was supposed to do a similar "multithreading" stuff similar to Duke3D but using FPU way more almost everywhere. The best optimization they did is that "d_subdiv16" that allows to increase performance by 10% when on, so division only occurs each 16th pixel of the screen and rest are interpolated. 586's FPU was really fast and float divisions were finished almost immediately and mixed to the integers but on a 486 it introduced stalls, so it had to wait while it was finished, making it slower. It supported CD music but didn't support general midi and opl which I think is a major disatvantage, didn't play animations too.

Descent texture mapper used an entirely integer approach doing perspective correct 1/z with sub-pixel shifting. It's just like quake but for earlier computers (386SX, 486SX), still works faster than Quake even on Pentiums. Descent also did real-time lighting and supported polygons with transparent textures (masked). All sorts of music playback, 6 degrees of freedom, turn arounds is nice, considering that it runs of shit.

There was another interesting game called "Terminal Velocity" - similar to Descent but taking place in big open worlds and in PCem it runs and plays quite nicely on a 486SX2-66 and as soon as there are no source codes we can't find this out very soon. But in 640x400 I can recognize similar "wavish" artifacts on steep surfaces just like those I see in Duke3D on slopes, maybe as soon as it's also the title released by 3D Realms they used something similar to Duke? This thing needs to get reverse engineered.

The summ of that is how much these guys could pull out from the hardware of the time.

Darkcrafter07 wrote on 2025-08-07, 20:53:

A "source port" is largely a term for anything based of some sources, be it a fork for the same platform or another. Even though Duke07 can be considered a fork of the original game, it also can be called a "source port".

Not sure I agree with your definition. To me, a fork seems a more accurate term for this than source port. But I guess it doesnt matter.

The summ of that is how much these guys could pull out from the hardware of the time.

Yes, what these early game devs did with the hardware available was incredible. Modern games seem very poorly optimised in comparison.

Darkcrafter07 wrote on 2025-08-07, 17:16:

You're welcome, btw, I prefer 640x400, open duke3d.cfg and change resolution with a notepad, it's going to get rid you of jaggied pixelated look as duke3d actually one of the few dos games that does aspect ratio correction. It performs it via nearest-neighbor filtering for sure. It's gonna get you the same dimensions 320x200 gives but 4 times crisper image (320x200=64000, 640x400=256000, 256000/64000=4). It could also get you some slight 20% performance boost. Interestingly enough, it works with 512x384 resolution too but hud looks really sawed.

Does this native aspect ratio correction also apply to 16:9 VESA modes like 1366x768 and 1920x1080? I can change to those VESA modes in the .cfg file, and the game happily accepts them and renders in those resolutions. But it doesn't look like aspect ratio correction is applied.

zyzzle wrote on 2025-08-08, 03:33:

Darkcrafter07 wrote on 2025-08-07, 17:16:

You're welcome, btw, I prefer 640x400, open duke3d.cfg and change resolution with a notepad, it's going to get rid you of jaggied pixelated look as duke3d actually one of the few dos games that does aspect ratio correction. It performs it via nearest-neighbor filtering for sure. It's gonna get you the same dimensions 320x200 gives but 4 times crisper image (320x200=64000, 640x400=256000, 256000/64000=4). It could also get you some slight 20% performance boost. Interestingly enough, it works with 512x384 resolution too but hud looks really sawed.

Does this native aspect ratio correction also apply to 16:9 VESA modes like 1366x768 and 1920x1080? I can change to those VESA modes in the .cfg file, and the game happily accepts them and renders in those resolutions. But it doesn't look like aspect ratio correction is applied.

You hit the spot, in 640x400 aspect correction is NOT applied, it looks exactly like 320x200 but crisper. Must be looking good on a CRT or else, you must do it by configuring DOSBox (aspect=true) or PCem (output stretch mode 4:3). Because Duke3D's built-in aspect correction looks sawwy due to nearest-neighbor interpolation.

Btw, I can see in Build.h that max resolution is 1600x1200 which I haven't tried to change yet.

Strange, but 1920x1080 seems to work, but aspect ratio correction doesn't seem to be applied. I need to modify the Duke.cfg file by manually writing this resolution, of course.

I'm running your Duke07 port in baremetal DOS, not DOSBOX. It seems to accept any VESA resolution in the lookup table for each specific video card, from 640x400 all the way to 1920x1080 on the newer Intel GPU onboard laptop graphics in 5th-8th gen Intel Core CPUs.

zyzzle wrote on 2025-08-08, 22:00:

Strange, but 1920x1080 seems to work, but aspect ratio correction doesn't seem to be applied. I need to modify the Duke.cfg file by manually writing this resolution, of course.

I'm running your Duke07 port in baremetal DOS, not DOSBOX. It seems to accept any VESA resolution in the lookup table for each specific video card, from 640x400 all the way to 1920x1080 on the newer Intel GPU onboard laptop graphics in 5th-8th gen Intel Core CPUs.

That's some interesting info, maybe I'll try to get more modes in there later but for now here's v0.16:
- further enhancements of low detail mode, especially "drawsprite" function
doesn't introduce unwanted bending to the farthest bounds of a sprite,
e.g. no more crooked-mirror effect. Depth sorting issues and infinitely
tall repeating on sprites are now fixed, thus "trasmach4" pixel
duplicating asm function is now on. Transparent wall sprites aren't yet
rendered.
- The diagonal mouse movement slowdown fixed. File mact386.lib
was patched with "Build Engine Mouse Fix v1.1" exe tool. No more need
to patch it when exe's are built because the mact386.lib itself changed.
The tool is made by "CTPAX" (fear, RUS.):
email inside ctpax-cheater.losthost.org

Duke07_src_n_exe_v016

From "HowToMake.txt" file: "6. To build for 386, run file "Make386.bat"", "11. Run file "Make386.bat"". I see no "Make386.bat" files in both "D07_SRC" and "D07_source" folders. Maybe it's time for some help/doc update.

analog_programmer wrote on 2025-08-11, 05:31:

From "HowToMake.txt" file: "6. To build for 386, run file "Make386.bat"", "11. Run file "Make386.bat"". I see no "Make386.bat" files in both "D07_SRC" and "D07_source" folders. Maybe it's time for some help/doc update.

I just downloaded Duke07_src_n_exe_v016 package and there are 2 exe files inside D07_EXE folder (DUKE07 and D07LQ2X).

marxveix wrote on 2025-08-11, 09:18:

I just downloaded Duke07_src_n_exe_v016 package and there are 2 exe files inside D07_EXE folder (DUKE07 and D07LQ2X).

Yeah, but what if someone wants a custom executables build?

analog_programmer wrote on 2025-08-11, 05:31:

From "HowToMake.txt" file: "6. To build for 386, run file "Make386.bat"", "11. Run file "Make386.bat"". I see no "Make386.bat" files in both "D07_SRC" and "D07_source" folders. Maybe it's time for some help/doc update.

Oh yes, make386.bat stands for makelq2.bat and makelq3.bat, they're both for 386. So make.bat is your regular duke07.exe for 486 and higher while makelq2.bat and makelq3.bat - are for 386.
Makelq3.bat is pretty much pointless as it doesn't increase performance but it's still there for an extra case. Before compiling makelq3 edit eng386.c with a notepad, find a word "ydetail" and set it to 3, save and compile.

Darkcrafter07 wrote on 2025-08-11, 18:36:

Oh yes, make386.bat stands for makelq2.bat and makelq3.bat, they're both for 386. So make.bat is your regular duke07.exe for 486 and higher while makelq2.bat and makelq3.bat - are for 386.
Makelq3.bat is pretty much pointless as it doesn't increase performance but it's still there for an extra case. Before compiling makelq3 edit eng386.c with a notepad, find a word "ydetail" and set it to 3, save and compile.

Thanks for the clarification! If I understand correctly, when "ydetail" variable in "ENG386.C" is set to 3, the produced executable will be for even lower details.

I have a suggestion. For easier compiling and linking of different executable versions you can separate make-files and altered .C and .H files in separate folders like "D07_SRC", "D07_SRC_LQ2" and "D07_SRC_LQ3".