Come Get Some :)


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...
 
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...
 
rst posted on Sep 28 2005 at 03:59 PM said:
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.
 
Last edited by a moderator:
rst posted on Sep 28 2005 at 02:39 PM said:
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.

Racemaniac posted on Sep 28 2005 at 02:53 PM said:
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.
 
Last edited by a moderator:
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:
 
rygar posted on Sep 28 2005 at 03:50 PM said:
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 :)
 
Last edited by a moderator:
Sonic-NKT posted on Sep 28 2005 at 02:25 PM said:
chatboard support in a later release would be nice...


I would just be happy if it worked at all on the BLU.
 
Last edited by a moderator:
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?
 
gp32rich posted on Sep 28 2005 at 05:07 PM said:
rygar posted on Sep 28 2005 at 03:50 PM said:
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:
 
Last edited by a moderator:
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.
 
Quiest posted on Sep 28 2005 at 04:25 PM said:
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.
 
Last edited by a moderator:
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. :ph34r:
 
Last edited by a moderator:
DaveC posted on Sep 28 2005 at 06:18 PM said:
Quiest posted on Sep 28 2005 at 04:25 PM said:
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 :).

hercule18 posted on Sep 28 2005 at 07:00 PM said:
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 :).
 
Last edited by a moderator:
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
 
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
 
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?
 
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.
 
Back
Top