Duke Nukem 3D for Mac question

[Lightning92]

Could Duke Nukem 3D run on a Macintosh LC 475?

[Nacho]

Not certain... I do however know that a Mac version of Duke Nukem 3D was released a long time ago.

[Lightning92]

Originally Posted by Nacho

Not certain... I do however know that a Mac version of Duke Nukem 3D was released a long time ago.

And so was the LC 475. Hence why I asked, lol.

[Gigabite]

Duke will run on an LC 475, but it will be painfully slow at even the lowest resolution it will run at. You need at least 8 MB of free RAM for Duke 3D, using virtual memory will make it even slower.

The LC 475 has a 68LC040 @ 25 MHz (the 68LC040 is a 68040 without a FPU) and duke at minimum wants a full 68040 @ 33 MHz (it would still be very slow, a PowerPC CPU @ 75 MHz is recommended.) I've gotten duke to run on my Performa 600CD and LCIII (68030s at 32 and 25 MHz with FPUs), but Duke runs like slideshows on them on all but the smallest levels.

Duke 3D on mac is far better than on DOS, but aside from being nostalgic, you're better off Playing Jonathan Fowlers Windows Duke3D port.

[The Commander]

Originally Posted by Gigabite

Duke 3D on mac is far better than on DOS, but aside from being nostalgic, you're better off Playing Richard Gobeille, Multiple OS, EDuke32 port.

Fixed that for you.

[Gigabite]

Originally Posted by The Commander

Fixed that for you.

Eduke has too many bugs, changed the game/engine too much and has too much bloat, I'll pass on it. I will give you ground on multi-OS, *nix can do everything Windows can except run Steam natively, which is why I still haven't switched completely.

[TerminX]

EDuke32 doesn't change the game itself at all and still manages to run faster than other Duke ports due to the heavy optimizations done when gutting the code. It's perfectly possible to just run EDuke32 in software mode and forgo all of the new rendering stuff (and everything else), leaving you with a pretty basic Duke experience. You can turn off the enhanced HUD, activate the menu option to restore the classic DOS control layout and more or less disable everything that diverges from the original Duke experience if you want.

The thing is really kind of like what a fleshed out JFDuke3D could have been if JonoF hadn't more or less stopped working on it (save for a few things here and there) 5 years ago. Oh yeah, and it's the only port that runs all of those mods that have been keeping the Duke3D scene alive for the past 6 years.

[Dopefish7590]

Eduke32 is far better, it's far from bloated, and runs eons faster than Gigabite makes it out to, but I'm sure there is no version for Mac Classic... There is freely available source code however.

[Gigabite]

Originally Posted by TerminX

EDuke32 doesn't change the game itself at all and still manages to run faster than other Duke ports due to the heavy optimizations done when gutting the code. It's perfectly possible to just run EDuke32 in software mode and forgo all of the new rendering stuff (and everything else), leaving you with a pretty basic Duke experience. You can turn off the enhanced HUD, activate the menu option to restore the classic DOS control layout and more or less disable everything that diverges from the original Duke experience if you want.

The thing is really kind of like what a fleshed out JFDuke3D could have been if JonoF hadn't more or less stopped working on it (save for a few things here and there) 5 years ago. Oh yeah, and it's the only port that runs all of those mods that have been keeping the Duke3D scene alive for the past 6 years.

My motto is "if it ain't broke, don't fix it." JFDuke3D is a lightweight port, and even though it hasn't been maintained in 5 years, it works fine for my purposes.

EDuke32 has irritating bugs like you can't alt+tab out of the game or the mouse will disappear, the tilde ~ key is locked to the console and can't be rebound to quick kick like it used to be, and several other issues.

Mods like Duke Plus have more irritating bugs (like "PRESS ALTFIRE TO RELOAD OR DO THIS ACTION", yet there is no such bound key or keybinding called ALTFIRE.

Originally Posted by Dopefish7590

Eduke32 is far better, it's far from bloated, and runs eons faster than Gigabite makes it out to, but I'm sure there is no version for Mac Classic... There is freely available source code however.

Where did I say it was slow? I said it was buggy/bloated.

Classic Mac hardware (680x0 era) doesn't have enough horsepower to run EDuke32 with all of its fancy effects, it can barely run the Macsoft port at a decent speed.

Eduke may run on PowerPC 60x hardware, but my PowerPC Macs still struggle to run D3D at anything above 800x600.

[Dopefish7590]

Originally Posted by Gigabite

Where did I say it was slow? I said it was buggy/bloated.

Bloated means something has a lot of uneeded stuff that makes it slow.

Classic Mac hardware (680x0 era) doesn't have enough horsepower to run EDuke32 with all of its fancy effects, it can barely run the Macsoft port at a decent speed.

Eduke may run on PowerPC 60x hardware, but my PowerPC Macs still struggle to run D3D at anything above 800x600.

Who said you need all of these effects? You can literally make EDuke32 act the exact same way the original DOS version functioned. If anything is incapable of running that, chances are they would be unable to use the original binary... I have an old Powerbook (25 MHz), and there is literally no way Duke 3D, port or not, would run on it.

[Gigabite]

Originally Posted by Dopefish7590

Who said you need all of these effects? You can literally make EDuke32 act the exact same way the original DOS version functioned. If anything is incapable of running that, chances are they would be unable to use the original binary... I have an old Powerbook (25 MHz), and there is literally no way Duke 3D, port or not, would run on it.

You may be able to make Eduke 'act' like the DOS version, but the underlying code is very different and requires much more CPU processing power to work.

The DOS version of the BUILD engine had parts of it written in assembler, which is much faster and requires much less overhead than the Windows version which is programmed in C and makes use of APIs like Direct X and OpenGL, which push up the requirements of processing power.

When Macsoft ported Duke 3D to the 680x0, they ported the x86 assembly into both 680x0 and PPC assembly and retained the speed of the DOS port to some degree.

[TerminX]

Er, this is the part of the thread where your argument falls flat on its face because you don't know what you're talking about. The underlying code in EDuke32 runs faster than the original DOS Duke3D code did in most cases because the original code was very, very poorly optimized. I would even go as far as to call it pretty much completely unoptimized. This is one of the reasons the code in EDuke32 is so different from any other Duke3D port in the first place--I'm the kind of person who will read C optimization guides hundreds of pages long just in an attempt to squeeze every last bit of performance out of something. I have personally rewritten huge chunks of the game for the sole purpose of making them faster.

The engine itself is a different matter, and again a point on which you are wrong; all of the assembly and Ken's original hardcore C optimizations are still alive and kicking in the engine today. There's a C version of all the assembly in there, but it's only used on platforms where running x86 assembly clearly isn't an option. It has to be enabled at compile time and has never been enabled in a single public EDuke32 build, ever.

Even with this C version of the assembly, the game is fast enough to be 100% playable on some very slow mobile platforms. The one that comes to mind immediately is the Dingoo A320, which has a 333 MHz MIPS processor and 32 megs of RAM.

Anyway, running the software renderer clearly doesn't require anything like OpenGL to operate, but that point still doesn't even make sense in the context of comparing the software renderer to the GL renderers since the GL renderers are so much faster.

So, what exactly were you trying to say again?

[Phayzon]

Originally Posted by TerminX

The one that comes to mind immediately is the Dingoo A320, which has a 333 MHz MIPS processor and 32 megs of RAM.

I have one of those and never even thought to look for an Eduke32 build for it

[TerminX]

EDuke32 should be pretty well supported on the Dingoo now. I even coded an extra function that allows you to perform weapon and inventory selection by holding a button and using the d-pad, as well as one that lets you hold a button to use the d-pad to look up and down.