Duke Nukem 3D new version for 68060

[Cosmos Amiga]

A new version of Duke Nukem 3D v0.4 is available for 68060 on my forum (the GHOAC for Good Home Of Amiga Classic) : http://www.68kforever.com/forums/showthread.php?1-New-version-is-coming

Some improvements :
- all mul & div 64 bit removed, much better for 060
- the Duke3D: assign removed
- the Duke3D: assign for AmigaSetup removed too
- added a $VER Duke Nukem 3D 0.4 by Dante, Bifat and Cosmos in the main .exe


I'm looking for good coders to optimize the mul64 routines and later the div64 if Frank agree : you are welcome !

[Cosmos Amiga]

Ok, I'll put it on Aminet !

A little video : https://www.youtube.com/watch?v=q9CHMV4JIuw

[Cosmos Amiga]

Unbelievable!, and all thanks replacing mul/div 64 bits instructions?
Good work indeed!

The video from NovaCoder seems a slower version; much different rig setup?

The Nova version is only AGA, that's why I updated the RTG Dante's version

My video show a 3dfx screen !

[Cosmos Amiga]

WOW! The difference!

I guess a problem somewhere : why I got only 1 fps with the v0.4 ?
Last 68060.library 46.16 installed with Rom2Fast...
I saw another video with this time an Apollo 1260, and Duke run fine (https://www.youtube.com/watch?v=zRdgaRoKdJc)

The next v0.5 is coming soon with a faster Smul64 routine using now the Fpu

Thanks to Matthey for this help !

[Cosmos Amiga]

Using FPU will ruin this version for Vampire owners or not? (Just curious)

Still use the v0.3 on this A600 accelerator...

Explanation : the instructions mul64 & div64 are NOT inside the 68060, so the 68060.library emulate them, and very slowly...

I replaced all of them with instructions who are really inside the 060, so no emulation anymore = big speedup... Oups, still one mul64 into the v0.4, sorry, was in the libnix... The v0.5 will fix that...

I have a new version of BlitzQuake who have the same problem but with sinus & cosinus : I get now 4 fps faster !!

[Cosmos Amiga]

I don't understand - aren't we talking C code here, or did Dante optimize the whole thing by porting parts of it to ASM? Libnix certainly is C.


That requires honoring Duke Nukem's license (GPL). I'm not sure how to do that, if you just patch other people's binaries. But at the very least, the license needs to be mentioned and you need to include an offer to provide interested parties with a way to easily duplicate what you did. I doubt that "I replaced all mul64/div64 instances with 68060 friendly opcodes" will suffice...

Edit: Your forum seems to have a minor SPAM problem: three postings from you, followed by eleven pages of spam postings...

Ok, no upload to Aminet...

There are some parts in asm into the Dante's source...

I'll see for the SPAM problem...

[Cosmos Amiga]

Dante uploaded the sources along with his binary, which is how you properly honor the license.

I'm just not sure how one would do that if you don't modify the sources but simply patch the binary (assuming that's what Cosmos did). If anybody's got an idea, I'm all ears. Like I said, uploading the file with hint that he replaced this and that wouldn't cut it, IMNSHO.

The Dante's source were compiled again with gcc 2.95.3-4 and with updated asm parts...

[Cosmos Amiga]

Why simple if it can be done the complicated way...

Because mul&div64 routines are used a lot :
1/ with a direct replacement, it will be faster than using MuRedox, each cycle is important for this case
2/ Actual integer replacement mul&div64 is a bit slow, fpu version seems even faster
3/ Another secret goal for the moment, maybe for the v0.5

Again, it's not a patch/hack, but a complete compilation with gcc 2.95.3-4

[Cosmos Amiga]

Have you measured this or are you guessing?

No precise measure, but it's used A LOT for sure !

The reason why the emulation is so slow is not because the actual replacement implementation is slow, but rather because the fpsp/isp has to go through a complete decoding cycle of the instruction, i.e. it has to figure out where the data is coming from, fetch it there, and where it is going to, all in supervisor mode with interrupts block

Of course, I know.

Inlining is always much better than your MuRedox in this case !

My routines included skip some of your code : no time lost...

Anyway, was very easy to do, maybe one hour of work...

[Cosmos Amiga]

Just tried it and got a problem, it asks this :

Using Setup file: 'DUKE3D.CFG'
STUB: CONTROL_ClearAssignments (CONTROL_ClearAssignments, Game/control.c:180)
Missing external con file(s).
COPY INTERNAL DEFAULTS TO DIRECTORY(Y/n)?

It locks duke, so I can't anser question.

What I did. I extracted lha archive to duke's game dir. It works (still do) with duke 0.3 version. Choosed "over write all", when asked. Started stteings seditor choosed correct audio / video modes,etc.

Tested with two 68k amigas wich are in my signature, bot have same problem.

Yes, I have this issue from time to time here...

The v0.5 is coming, theorically faster using an Fpu SMult64 routine...

I recompiled Duke without some gcc options, hope this bug is going away now...

[Cosmos Amiga]

I'm actually testing this new 0.5 version :

- one mul64 removed into _rand
- few render routines optimization, nothing serious
- integer SMul64 replaced with Fpu SMul64, a bit faster
- removed some (buggy ?) gcc options


==> http://www.68kforever.com/forums/showthread.php?1-New-version-is-coming&p=202&viewfull=1#post202

or here : http://warpclassic68k.blogspot.fr/p/blog-page.html

[Cosmos Amiga]

I see that there is still no source available, and no GPL license information included. It's simple. Include the original GNU.TXT distributed with the official Duke Nukem 3D source code release in the binary package, and make the source code that you are building from available. It could be on the same download page.

You have included a different license, which I guess is applicable to the original distribution of Duke Nukem 3D, but that license doesn't govern the source code or software based on it. If it was applicable to any of your work, your work would have breached the license since it maintains exclusive rights over the program.

I would love to try this if I had a faster Amiga btw. I don't say any of this to detract from the amazing work you are doing.

Why these posts ?

When NovaCoder released AmiQuake2 and AmiDuke, have you asked ?

Why me ?

Leave me alone, please...

[Cosmos Amiga]

OK nice work. It works now bot of my A1200 amigas.

It is playable with 040/AGA 320x100. Very fast with 060/RTG 320x240

Some small problems.

Priorities needs to be adjusted, trying 320x240 with 040/AGA is virtually impossible, as it doesn't wait for keyboard. Same with 060/RTG 640x400.

With my AGA, it doesn't disable mouse pointer and thats why using mouse is impossible.

After some minits playing it hangs, happened two times. Same time there is a "sound effect".

First : this new version is only for the 060 !

For the mouse pointer, I have no idea...

I never had your sound issues here. I use AHI version 6.7, and you ?

[Cosmos Amiga]

I'm actually with Cosmos on this.   Who gives a f**k if someone releases a FREE patch to a very old PC game without providing the patch source code, who is actually getting hurt by this action?   The original game developers who have probably died of old age by now?   The copyright holder?   The Amiga community?

I really don't get what all the fuss is about?

Some people obviously prefer to complain than to step up and do something productive themselves.

No fight between us : that's our ennemis want...

To be clear : I have only added some asm 060 Mul64 parts into the source, nothing more since I'm a super beginner in C, I cannot do more, sorry...

I'm looking for some good C/C++ coders to finally fix the -mreg-parm gcc option : compiled sources will be faster with that for sure !

[Cosmos Amiga]

Cosmos is known for pissing on other people's licenses and for totally ignoring Aminet's upload rules - there's a history there, you know... What do you expect me to do?

WTF ?

They block Classic with licenses since MANY YEARS (watch actually P96 for example...), so with my disassembling, I mock them...

You play with the opposite and return the situation, I don't like that, really...

The Classic are now near dead because of these big blockers (Kickstart, CyberGraphX, Workbench, hardware gerber files, .jed files...)