Homebrew Who wants Duke Nukem 3D (JFDuke?) on the DSi?

[JhulkerCraft]

It would be awesome if you could load mods.

 

[Deleted member 578956]

I have a experemental idea, Lets use the arm 7 CPU to add music and sound effects to the game while the arm 9 handels rendering, gameplay, and AI to speed it up and make it feel better

 

[Nikokaro]

Guys, in my opinion these are the changes needed for this port to become perfect:

-Make the Dpad less sensitive to touch, that is, slower (e.g. as in DualHexen);
-Overcome the graphical flaw in the textures due to that particular light already mentioned;
-Skip any movies, which are not supported.
-Introduce a virtual keyboard for saving and typing cheat codes;
-Allowing to play the numerous addons/mods through argv files;
-Finally, insert the map in the lower screen, as a finishing touch.

Personally, I do not consider music to be indispensable, and I fear it takes away necessary resources for what is needed instead. If anyone wants to add anything, I am curious to read other opinions.

 

[elhobbs]

I have a experemental idea, Lets use the arm 7 CPU to add music and sound effects to the game while the arm 9 handels rendering, gameplay, and AI to speed it up and make it feel better

This was my plan. This is what I have done for other games that I have ported. This does cause some people to complain as it requires low quality (11025 mix rate) but it works for me.

 

[mrparrot2]

So I did a small memory analysis on JFDuke3D latest release regarding memory consumption and found the following:

1. Started the game with valgrind's `massif`, tracking all memory allocations.
2. Booted up "Holywood Hollocaust"
3. played the game a little.

The heap profiler that I got shows that JFDuke3D on 320x200 8-bit software mode consumes 22.76 Mb of Heap space.

Backtrace of allocations:

70.29% (23.5Mb) is spent in loadpics (engine.c:38, called by engine.c:7832)
11.01% (2.67Mb) is spent in setvideomode (sdlayer2.c:1076) called by setgamemode (engine.c:7576)
10% (2.4Mb) is used by some SDL unknown stuff, which probably can be cut
5% (~1.5mb) used for untracked stuff (less than massif treshold)
700k for audio buffers.

The size of static allocated objects is concerning, though. Binary uses 11Mb only for static allocated objects. Size of 10 largest objects in bytes :
Id Address Size Type Visibility Link Name 372: 00000000006fda00 [B]65536[/B] OBJECT LOCAL DEFAULT 25 sdlappicon_pixels 444: 0000000000876000 [B]65536[/B] OBJECT LOCAL DEFAULT 27 olinbuf 1042: 00000000011431a0 [B]73728[/B] OBJECT GLOBAL DEFAULT 27 hicreplc 1781: 000000000103d320 [B]73728[/B] OBJECT GLOBAL DEFAULT 27 waloff 2483: 0000000000d64e00 [B]73728[/B] OBJECT GLOBAL DEFAULT 27 actorscrptr 2802: 000000000115d5c0 [B]110592[/B] OBJECT GLOBAL DEFAULT 27 tile2model 1879: 0000000000d18e40 [B]131136[/B] OBJECT GLOBAL DEFAULT 27 script 2117: 0000000000d3a040 [B]144000[/B] OBJECT GLOBAL DEFAULT 27 MusicPtr 2003: 00000000010540e0 [B]163840[/B] OBJECT GLOBAL DEFAULT 27 sector 2318: 000000000109ae80 [B]163840[/B] OBJECT GLOBAL DEFAULT 27 voxoff 669: 0000000000caa5e0 [B]163840[/B] OBJECT LOCAL DEFAULT 27 vsp 2734: 00000000011054a0 [B]199680[/B] OBJECT GLOBAL DEFAULT 27 spriteext 2758: 0000000000eb2c80 [B]221184[/B] OBJECT GLOBAL DEFAULT 27 cac 140: 0000000000810240 [B]262144[/B] OBJECT LOCAL DEFAULT 27 distrecip 2839: 00000000011785c0 [B]294912[/B] OBJECT GLOBAL DEFAULT 27 hudmem 1248: 0000000000fa11c0 [B]524288[/B] OBJECT GLOBAL DEFAULT 27 wall 1098: 0000000000ef0980 [B]720896[/B] OBJECT GLOBAL DEFAULT 27 sprite 53: 0000000000740f00 [B]737280[/B] OBJECT LOCAL DEFAULT 27 smost 2727: 0000000000d793e0 [B]1179648[/B] OBJECT GLOBAL DEFAULT 27 hittype 555: 000000000088fd20 [B]4194304[/B] OBJECT LOCAL DEFAULT 27 pakmem

This sums up to 8.3 Megabytes, so we definitively have to reduce that. `pakmem`, for instance, seems to be used for multiplayer and thus can be removed. I could not find any references of `hittype` in code so it probably come from some macro expansion. `smost` size seems deeply tied to the maximum number of sprites that can be drawn by the engine, so probably this can be tunned down. For instance, JFDuke3D allocates spaces for 16k sprites, whereas Duke3DS allocates space for 2k sprites. And so on...

So if the JFBuild engine is able to run with smaller sprite numbers and cache buffers I'd say a port of JFDuke3D to Nintendo DSi is definitively possible.

Since we have the Duke3DS sourcecode we could also check if the author did some tuning in those variables.

 

[Nikokaro]

@mrparrot2 thank you for your interest. @elhobbs is working on perfecting the old Duke3d.nds and has already made big improvements, but if you also want to try to port this other version to DSi I will be more than happy to test it.

 

[mrparrot2]

So I took one hour to check that the game is actually rendering in a 320x200 surface and then Blt into a 512x200 surface and then stretched into a 256x192 screen using the 2D engine.

I quickly modified the code to render directly in 256x192 and the game performance improved from slideshow to playable. It is definitively maintaining a steady 20FPS.There is even no need to use an additional background to this, we can render directly into the LCD framebuffer.

 

[mrparrot2]

Here is a ROM with improved performance: https://github.com/giulianobelinassi/duke3d-nds/raw/main/duke3d.nds

I've also sent a PR to elhobbs with my changes.

 

[CrashMidnick]

Here is a ROM with improved performance: https://github.com/giulianobelinassi/duke3d-nds/raw/main/duke3d.nds

I've also sent a PR to elhobbs with my changes.

Impressive !! Huge increase of FPS Well done.

EDIT : I tested it on the regular DS and it is much faster on it as well. I can save/load too. Unfortuantely it is a little unstable (freezes or some enemies disappear or some corrupt textures). I was able to complete the first level though

 

[Nikokaro]

@mrparrot2 did you modify the original version (the 2007 one, with the awful sound), or the latest one released by elhobbs?

 

[mrparrot2]

@mrparrot2 did you modify the original version (the 2007 one, with the awful sound), or the latest one released by elhobbs?

Latest release by elhobbs, of course!

 

[CrashMidnick]

I do not know if this this possible with this port but eduke32 (dingux version for DSTWO) has got the following controls :

D-PAD - movement
A - shoot
B - strafe/open
X+up/down - look up/down
Y - jump
L - crouch/center view
R + UP/DOWN - cycle weapons
R + LEFT/RIGHT - cycle items
START - use item
SELECT - game menu

I played a lot this version and I think this control config is really good.

 

[mrparrot2]

I do not know if this this possible with this port but eduke32 (dingux version for DSTWO) has got the following controls :

D-PAD - movement
A - shoot
B - strafe/open
X+up/down - look up/down
Y - jump
L - crouch/center view
R + UP/DOWN - cycle weapons
R + LEFT/RIGHT - cycle items
START - use item
SELECT - game menu

I played a lot this version and I think this control config is really good.

Wait, so eDuke32 runs on top of Linux on Nintendo DS? or is it 3DS?

 

[elhobbs]

So I took one hour to check that the game is actually rendering in a 320x200 surface and then Blt into a 512x200 surface and then stretched into a 256x192 screen using the 2D engine.

I quickly modified the code to render directly in 256x192 and the game performance improved from slideshow to playable. It is definitively maintaining a steady 20FPS.There is even no need to use an additional background to this, we can render directly into the LCD framebuffer.

I had changed this to 320x200. I did not realize that it could be set directly to native 256x192, so that is good to know.

however, I did switch over to using the current jfduke3d source instead of this old version since it has so many issues. I am currently trying to track down an issue where activating cameras causes the frame rate to drop into the single digits, but aside from that it seems to be pretty stable.

In regards to using a background - it does make things easier. the vram only supports 16bit writes. so you would need to read/write every pixel pair or switch to rgb.

 

[mrparrot2]

I had changed this to 320x200. I did not realize that it could be set directly to native 256x192, so that is good to know.

however, I did switch over to using the current jfduke3d source instead of this old version since it has so many issues. I am currently trying to track down an issue where activating cameras causes the frame rate to drop into the single digits, but aside from that it seems to be pretty stable.

In regards to using a background - it does make things easier. the vram only supports 16bit writes. so you would need to read/write every pixel pair or switch to rgb.

So you got it to run in Nintendo DS already? If yes can you post a link to a repository?

 

[CrashMidnick]

Wait, so eDuke32 runs on top of Linux on Nintendo DS? or is it 3DS?

Yep, it uses the DStwo hardware. Pretty much all apps made for the dingoo A320 (legacy) work including eduke32. Unfortunately the project was not updated and optimized.

 

[elhobbs]

So you got it to run in Nintendo DS already? If yes can you post a link to a repository?

there is still a lot of debugging information showing ... and I am not 100% I forked everything correctly ...
https://github.com/elhobbs/jfduke3d
the nds build:
make -f Makefile.nds

I don't have the generation for version-auto.c linked into the arm9 Makefile correctly - so you have run make twice on a full rebuild as it fails to find version-auto.c the first time

 

[mrparrot2]

there is still a lot of debugging information showing ... and I am not 100% I forked everything correctly ...
https://github.com/elhobbs/jfduke3d
the nds build:
make -f Makefile.nds

I don't have the generation for version-auto.c linked into the arm9 Makefile correctly - so you have run make twice on a full rebuild as it fails to find version-auto.c the first time

Here it fails with

make[1]: *** No rule to make target 'jfaudiolib/src\drivers.o', needed by '/home/giulianob/projects/jfduke3d/arm9/.elf'. Stop.

 

[elhobbs]

Here it fails with

make[1]: *** No rule to make target 'jfaudiolib/src\drivers.o', needed by '/home/giulianob/projects/jfduke3d/arm9/.elf'. Stop.

there are submodules that need to be pulled down after you clone -
git submodule update --init

 

[mrparrot2]

there are submodules that need to be pulled down after you clone -
git submodule update --init

Yes, I did that. It fails even after a clean clone and doing a `git submodule ...` right away.