Tronix wrote:

Hello,

[...] If anyone interested, you can download my pre-compile EXE from here: Duke Nukem 3D v1.4/i386 - Atomic Edition

Hello,

Is there any possibility to download above file? Duke3d.exe recomiled for 386. On Tronix's Dropbox account it isn't available. Maybe someone of you have a copy and can put somewhere to send me ( zbyszek_krok (at) o2 (dot) pl )? I'm preparing some overclocked 386 machine and it will nice to test Duke 3D on it. Many thanks!

Best regards,

Zbyszek

It is on retronn.de: ftp://retronn.de/dos/games/Duke3D/for386_1.4/

You very likely can't overclock a 386 to the region where Duke3D is well playable.

Do anyone have GAME.CON and USER.CON errors once launched with the i386 new exe?

I played Duke 3D on an IBM Eduquest 386slc-25 with full mwave sound and it would go from quite smooth and playable to jerky

I had to disable sound because if too many sounds played I would get a hard disk crash and had to reload the OS.

I sort gave up on it after the 2nd crash even though everything seemed like it would run OK at 320x200

rmay635703 wrote on 2020-06-26, 16:14:

I played Duke 3D on an IBM Eduquest 386slc-25 with full mwave sound and it would go from quite smooth and playable to jerky

I had to disable sound because if too many sounds played I would get a hard disk crash and had to reload the OS.

I sort gave up on it after the 2nd crash even though everything seemed like it would run OK at 320x200

I am quite sure most people do not have the same definition of "smooth" as you do (did), with frame-rates likely well below 11fps at 320x200.

See download/file.php?id=81845

Recently found out that that Duke 3D was also released on the Megadrive, only in Brazil apparently as the Megadrive had a good continued run out there while everywhere else was becoming obsolete.

Though as always, it's great seeing 386's pushed... and in this case running Duke 3D at 5fps!

elianda wrote on 2017-03-15, 16:02:

It is on retronn.de: ftp://retronn.de/dos/games/Duke3D/for386_1.4/

You very likely can't overclock a 386 to the region where Duke3D is well playable.

I suppose this is subjective and dependent on a number of factors i.e. the video bus and speed i.e. ISA @ 8Mhz / VLB @ 40Mhz, and whoever is playing i.e. what their acceptable minimum FPS, i'd swap some shadows for an extra frame or two.

386_junkie wrote on 2020-07-05, 11:28:

Recently found out that that Duke 3D was also released on the Megadrive, only in Brazil apparently as the Megadrive had a good continued run out there while everywhere else was becoming obsolete.

Though as always, it's great seeing 386's pushed... and in this case running Duke 3D at 5fps!

Yes it was an interesting but far from similar version. The Mega Drive did see also a demo homebrew porting of Wolfeinstein3D that it's impressive considering probably the work is all on the Motorola 68000 cpu and if it was make back then it would have had quite some serious success.
But there're many great games with much graphic pushed in this game console. Kawasaki Superbike Challenge remains one of the best if we not consider Virtua Racing that had externally an add-on processor into the game faster than the main console cpu itself that did most of the job. And it was the most expensive game ever released on the Mega Drive obviously. Same things did the Super Nintendo with Doom and some others games using external "coprocessor".

Sorry for the necroposting, but I found running Duke3D on a 386 really interesting, and made me wonder how the game's performance would vary with and without an FPU.

Looking at the following quote:

Recently I got caught in a discussion about the behavior of the Build engine and specifically Duke Nukem 3D on 486SX processors. […]
Show full quote

Recently I got caught in a discussion about the behavior of the Build engine and specifically Duke Nukem 3D on 486SX processors. I used to have one of those in the mid-90's and while Duke 3D ran fine on it for the most part, it would turn into a right slideshow whenever I neared a sloping floor in the game. On a friend's 486DX computer the same problem did not occur.

I always assumed this was because the Build engine used some floating point calculations on sloping floors, and had to fall back on software FP emulation on the FPU-less 486SX, slowing the game down to a crawl. I read about similar experiences from other 486SX owners, which only reinforced my assumption.

Then recently I got into this discussion, where someone vehemently denied the Build engine using any floating point calculations at all. This got me doubting my own story, and curious for an official explanation, so I went looking for a reliable source. That led me to re-read your code review of the Build engine, and I noticed you also mentioned that Build uses integers exclusively ("If you search for "float" in the source code of Build you will not get a single hit"). Reading that only puzzled me more.

To get a definitive answer on why slopes are so slow on 486SX processors, I turned to the most reliable source I can think of: the original Duke 3D source code released in 2003. After looking around for slope-related code, I finally found what I was looking for: the Build engine does in fact use floating point assembly instructions in its slope rendering routines (setupslopevlin_ and slopevlin_) inside the A.ASM source file. It's just a few short simple instructions (fild, fadd, fst, fstp), hardly worth mentioning, but it's enough to bring a non-FPU processor to its knees when invoked.

I also looked into how the software floating point emulation works. Turns out it's very simple: the original Build engine source is written for the Watcom C/C++ compiler as you know, and the Watcom assembler tool (wasm.exe) used to assemble the rendering routines "by default, generates code with support for 8087 software emulation". This is mentioned in the codebase of what is now the Open Watcom project here.

Curiously enough, I did encounter an alternative implementation of the slope rendering routines that uses only integer instructions (setupslopevlin2_ and slopevlin2_), but those functions do not appear to be used anywhere in the code.

Taken from the following article https://fabiensanglard.net/duke3d/build_engine_internals.php

Has anyone tried to find a nice place where these slowdowns are evident, be it in a 486SX or in a 386 without FPU so we can test how the 387 affects the framerate?

first screen on the roof has sloped vents, then when you jump down you are facing a wall with sloped edge, FPS tanks even on fast FPUless NexGen (K6 precursor)

rasz_pl wrote on 2022-09-02, 00:53:

first screen on the roof has sloped vents, then when you jump down you are facing a wall with sloped edge, FPS tanks even on fast FPUless NexGen (K6 precursor)

Nice info !!

immediately head backwards to the teleporter in the first level of Episode 2 and you'll be greeted with a very, very slope heavy room. It's also a safe spot to compare numbers. 😀

I found my previous post: Re: A brief comparison of 386 FPUs

90MHz NexGen Nx586 drops down to 10fps on first screen with sloped roof for that very reason:
https://youtu.be/41O2bNG2qKA?t=234

over 30 fps unless there are slopes on the screen, then all the way to 10-14

Wow i just ran it on my 386sx especially overclocked here to 27,5MHz. 13MHz ISA. FPU
The Game is absolutely not playable. Below 1fps even in smallest window size. The game hardl recognizes my keyboard inputs. Strange that you get such results on a dx40. I mean double of mine would be felt 1,5fps…

PS: great exe recompiling anyway

alexanrs wrote on 2015-11-10, 10:02:

I wonder how this would perform on a blue lightning machine xD

I had an IBM 386slc-25 and honestly it ran fine with occasional lag

I would have to imagine a BL would run it as well as a low to mid range 486