VOGONS


Duke Nukem 3D on a i80386

Topic actions

Reply 20 of 34, by zbyszek_krok

User metadata
Rank Newbie
Rank
Newbie
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

Reply 21 of 34, by elianda

User metadata
Rank l33t
Rank
l33t

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.

Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool

Reply 22 of 34, by 386SX

User metadata
Rank l33t
Rank
l33t

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

Reply 23 of 34, by rmay635703

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 24 of 34, by darry

User metadata
Rank l33t++
Rank
l33t++
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

Reply 25 of 34, by 386_junkie

User metadata
Rank Oldbie
Rank
Oldbie

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!

Compaq Systempro; EISA Dual 386 ¦ Compaq Junkiepro; EISA Dual 386 ¦ ALR Powerpro; EISA Dual 386

EISA Graphic Cards ¦ EISA Graphic Card Benchmarks

Reply 26 of 34, by 386_junkie

User metadata
Rank Oldbie
Rank
Oldbie
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.

Compaq Systempro; EISA Dual 386 ¦ Compaq Junkiepro; EISA Dual 386 ¦ ALR Powerpro; EISA Dual 386

EISA Graphic Cards ¦ EISA Graphic Card Benchmarks

Reply 27 of 34, by 386SX

User metadata
Rank l33t
Rank
l33t
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".

Reply 28 of 34, by Am386DX-40

User metadata
Rank Member
Rank
Member

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?

Reply 30 of 34, by Am386DX-40

User metadata
Rank Member
Rank
Member
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 !!

Reply 31 of 34, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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. 😀

apsosig.png
long live PCem

Reply 32 of 34, by rasz_pl

User metadata
Rank l33t
Rank
l33t

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

AT&T Globalyst/FIC 486-GAC-2 Cache Module reproduction
Zenith Data Systems (ZDS) ZBIOS 'MFM-300 Monitor' reverse engineering

Reply 33 of 34, by Marco

User metadata
Rank Member
Rank
Member

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

1) VLSI SCAMP 311 | 386SX25@30 | 16MB | CL-GD5428 | CT2830| SCC-1 | MT32 | Fast-SCSI AHA 1542CF + BlueSCSI v2/15k U320
2) SIS486 | 486DX/2 66(@80) | 32MB | TGUI9440 | LAPC-I

Reply 34 of 34, by rmay635703

User metadata
Rank Oldbie
Rank
Oldbie
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