marxveix wrote on Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 17:10:

Darkcrafter07 wrote on Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Today, 03:33:

Darkcrafter07 wrote on Yesterday, 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.