Come Get Some :)

[Racemaniac]

i got it to work, i've removed the dmo files from my grp file, used the con files and a cfg file posted in this topic, and i'm using the original gxb
NLU here
looks great, but it's gonna be hard to find a good set of controls, so many things that are "needed", so little buttons...

 

[rst]

Angel, i remember play Duke Nukem in a Intel Pentium 100 Mhz and so cool playing. I think that port is really possible with sound and all features...

 

[Sonic-NKT]

chatboard support in a later release would be nice...

 

[WhiteFalcon]

Angel, i remember play Duke Nukem in a Intel Pentium 100 Mhz and so cool playing. I think that port is really possible with sound and all features...

​

Yet you cannot directly compare a 100MHz Pentium with a gfx card and souncard to bare GP32. Besides, Duke 3D worked just fine on a 486 DX2/66MHz in 320x200.

 

[woogal]

Woogal, how you did the ASM conversion from de source of the Duke nukem to the ARM processor ?. It sounds like a so hard work !!

​

I didn't. This is a port of the SDL version done by icculus. The amount of code changed from the original icculus version is actually tiny, but because the code is such a mess it takes ages to find out what bit isn't quite working right.

looks great, but it's gonna be hard to find a good set of controls, so many things that are "needed", so little buttons...

​

I'm going to sort something out to get extra controls from the limited buttons. There's a few options I can try - shift mode, doubletap, and long hold. I'll have a play and find out the best way to code it.

 

[rygar]

When all the smoke has cleared I hope someone will write definitive readme files to go with the correct NLU, BLU or BLU+ download because I'm so confused I don't even remember what versions of Duke I own anymore! :huh:

 

[gp32rich]

When all the smoke has cleared I hope someone will write definitive readme files to go with the correct NLU, BLU or BLU+ download because I'm so confused I don't even remember what versions of Duke I own anymore! :huh:

​

It doesn't matter what version you own as it looks like any .grp will work with the .con files posted earlier.

As for BLU(+)... keep your fingers crossed

 

[DaveC]

chatboard support in a later release would be nice...

​

I would just be happy if it worked at all on the BLU.

 

[psyko_chewbacca]

Any chance of an overclocked version that support SFX? My GP can go up to 216Mhz so it could be Really nice!!!

 

[Quiest]

Just a side question:

Wasn`t there always the talk that it would be impossible to run Duke3D on the gp32, or if, it would be unplayably slow, because of something like floating point calculations for the engine?

Just wanna know why it`s indeed possible so all of a sudden?

 

[rygar]

When all the smoke has cleared I hope someone will write definitive readme files to go with the correct NLU, BLU or BLU+ download because I'm so confused I don't even remember what versions of Duke I own anymore!   :huh:

​

It doesn't matter what version you own as it looks like any .grp will work with the .con files posted earlier.

As for BLU(+)... keep your fingers crossed

​

This is gonna sound like a really dumb question from a relative noobie but in the shareware version when I installed it there were no files that ended in .grp? I'm at work so I can't try my other versions until later but am I just looking in the wrong place? :blink:

 

[Vimacs]

there is a duke3d.grp file in the demo, iam 100% sure on that.

 

[Sonic-NKT]

remember, when you download the pack of the 3d realms homepage, you have to install it first with the included exe. After that you have the needed files in the directory where you installed it.

 

[DaveC]

Just a side question:

Wasn`t there always the talk that it would be impossible to run Duke3D on the gp32, or if, it would be unplayably slow, because of something like floating point calculations for the engine?

Just wanna know why it`s indeed possible so all of a sudden?

​

Duke doesn'y use FP. I think RAM and the complex nature of the engine code were the main reasons.

 

[hercule18]

Hi,

use the modiefied cons from http://www.gp32x.de/board/index.php?showt...ndpost&p=274411 to fix the wierd acting enemies

Thanks it worked fine!!

use the modiefied cons from http://www.gp32x.de/board/index.php?showt...ndpost&p=274411 to fix the wierd acting enemies

That's what i done but cause of a misunderstood in the cfg file i had some weird action.

Now a little tips for the key mapping:

you can use the same button for 2 different actions ex: i use select for crouch and open doors.

Bye

Herc. h34r:

 

[woogal]

Just a side question:

Wasn`t there always the talk that it would be impossible to run Duke3D on the gp32, or if, it would be unplayably slow, because of something like floating point calculations for the engine?

Just wanna know why it`s indeed possible so all of a sudden?

​

Duke doesn'y use FP. I think RAM and the complex nature of the engine code were the main reasons.

​

Exactly. I don't think anyone ever said it was impossible (apart from the few people you get popping up on here every now and again who know nothing about coding but like to make crazy statements for no apparent reason). RAM is always an unknown when the original says 8meg needed as you never know how much of the memory is going to be taken up with other stuff on the gp32 compared to the original system. Dos might leave plenty of room for the game to run, but the gp32 might use up just a little bit more and not leave enough for the game data. The only way to find out is to give it a try, and thats the other problem - the code for duke and the build engine is such a mess that several people have started to work on it over the last few years, but given up after a couple of hours and gone on to play with much more sensible code. In fact this is my 3rd attempt at porting duke .

Now a little tips for the key mapping:

you can use the same button for 2 different actions ex: i use select for crouch and open doors.

​

Nice tip .

 

[rst]

Woogal, you not did today another .fxe with some fixes to test in the BLU ?
What about the problem in that model ? Remember the firmware i use is the Slubman one.

Regards ... RST

 

[Lurky]

Amazing.
Thanks woogal.

Runs awsome on my Nlu,
using shareware duke, atomic cons, and the cfg posted in the thread

To people having problems;The cfg posted earlier in this thread saved to my comp as a .txt with .cfg in the name, so people using that cfg might want to check and see if they need to rename it.

ie:
rename duke3d.cfg.txt
duke3d.cfg

 

[WhiteFalcon]

Woogal: As a BLU+ owner I have not been able to see a single picture of the game on my GP32, but it reboots just after the well known BLU+ gfx bug appears (the thick white bar) so it seems the problem lies somewhere in the gfx init routines. I know only the offiial GP SDK, but have you tried compiling the game with the modified BLU+ init procedure in Mirko's SDK? Could you possibly place that another version of the FXE anywhere so we BLU+ owners can test that?

 

[woogal]

So it's getting to the gfx init? Didn't think it got that far in only a few seconds, but that still doesn't explain why it doesn't work on a normal blu. Can't create a blu+ version just yet as it means recompiling chui's SDL lib with the blu+ stuff enabled (it's in there, but you have to enable it then compile a blu+ version) and I can't get it to compile with the version of gcc I'm using. I think chui might have used an older version that isn't as strict with certain bits of code. I've just sent chui an email asking if he can compile a blu+ sdl version for me.