Homebrew Super Mario 64 (1996) Port for DSi

[firke_the_one]

Seeing this port makes me think a ps1 port might actually be possible

 

[Hydr8gon]

I can't imagine there's any reasonable way to use SM64DS's audio without entirely rewriting SM64's audio logic for it. At that point we'd probably need a decompilation of SM64DS as well, and a bunch of hacks to stitch its audio logic into SM64.

Regardless, I'm running into bigger issues. I managed to separate the bulk of the audio processing and run it on the ARM7, but even this is too intensive and the ARM7 can no longer keep up with the game. On top of that, the audio logic that remains on the ARM9 (and is far too entangled with the game to be separated) is causing slowdown on its own, so even if audio playback wasn't an issue, we'd still be getting noticeable performance drops. Not to mention the ARM7 now mysteriously dies on hardware when it reaches the file select, so that's super fun! At this point I'm not sure if audio is feasible without drastically modifying the game to make it less intensive for the DS. That's something I'd really like to avoid, since not only would it be a lot of work, it would also no longer be a "true" port of the original game. Bleh. I'll keep messing around with things, but I'm not sure what else I can do.

 

[Deleted member 397813]

HOW DOES A N64 GAME RUN SO WELL ON A DSI

 

[RocketRobz]

I can't imagine there's any reasonable way to use SM64DS's audio without entirely rewriting SM64's audio logic for it. At that point we'd probably need a decompilation of SM64DS as well, and a bunch of hacks to stitch its audio logic into SM64.

You could just use the code from my fork of SSEQPlayer. It can play music straight from a DS ROM without any need for decompilation, it seems.

Regardless, I'm running into bigger issues. I managed to separate the bulk of the audio processing and run it on the ARM7, but even this is too intensive and the ARM7 can no longer keep up with the game. On top of that, the audio logic that remains on the ARM9 (and is far too entangled with the game to be separated) is causing slowdown on its own, so even if audio playback wasn't an issue, we'd still be getting noticeable performance drops. Not to mention the ARM7 now mysteriously dies on hardware when it reaches the file select, so that's super fun! At this point I'm not sure if audio is feasible without drastically modifying the game to make it less intensive for the DS. That's something I'd really like to avoid, since not only would it be a lot of work, it would also no longer be a "true" port of the original game. Bleh. I'll keep messing around with things, but I'm not sure what else I can do.

Maybe try having DSP handle the audio?
GBARunner2 is the only homebrew that can use DSP (for audio emulation), so maybe check it's source code for DSP usage.

 

[Hydr8gon]

You could just use the code from my fork of SSEQPlayer. It can play music straight from a DS ROM without any need for decompilation, it seems.

I'd still have to translate SM64's audio events in some way so they can be used to select and play the right sounds out of SM64DS, or something. Plus it would add SM64DS as another dependency, which would suck.

Maybe try having DSP handle the audio?
GBARunner2 is the only homebrew that can use DSP (for audio emulation), so maybe check it's source code for DSP usage.

That's something I might actually look into. I don't know anything about the DSP though, so it's kind of intimidating

 

[Hydr8gon]

I played a 16 star run earlier this morning which worked surprisingly well, it softlocked once at BiTS but worked fine on the second try!
But is there any chance to make the c-buttons work, with a button combination or something like that? I'm surprised I could even play through it without actually adjusting my camera left and right

I just pushed a change to map the left and right C buttons to the touch screen (left half of the touch screen for left C button, right half for right C button). This should hopefully make things easier

 

[squeakycleanswine]

The problem is that the DSi ROM detection is bugged, so there's no way to run it yet.
Maybe when the ROM is made to load it's data from NitroFS, it'll be fixed, so you could then use TWiLight Menu++ to run it from your flashcard.

The rom detection on the ievo? Other dsi homebrew works pretty well, and properly dumped games work fine too.

 

[Deleted User]

Wow, that's impressive.

 

[Sammy6]

Yo this is amazing! btw what do I have to edit to change the controls?

 

[Hydr8gon]

Yo this is amazing! btw what do I have to edit to change the controls?

src/nds/nds_controller.c, if you don't mind touching a bit of source code. There isn't any built-in control remapping yet

 

[Viri]

Seeing this port makes me think a ps1 port might actually be possible

Yes, by porting this to the PS1 Classic!

 

[Sammy6]

src/nds/nds_controller.c, if you don't mind touching a bit of source code. There isn't any built-in control remapping yet

Thank you!

 

[Apache Thunder]

Seeing this port makes me think a ps1 port might actually be possible

That thought came to mind for me sometime ago when I first heard about it getting ported to a bunch of other systems (like MS-DOS lol).

But I then read that the PS1 lacks a z-buffer so I would be curious as to how one gets it running on a PS1. It would be super cool if someone managed it though but the graphics system would probably have to be completely redone.

Would be nice to see it running on my iMac G3 though. MacOS 8.0/9.0 port? It's running on MS-DOS now we just need it on vintage Macintoshes.

As for the DSi port, I hope it eventually gets audio and that the eventual NitroFS support is optional. The thing about homebrew and NitroFS is that it's not mounted the same way as retail apps and as far I can tell homebrew with NitroFS don't work when installed to System Menu instead of started from hbmenu. This would prevent me from installing the game directly to System Menu. Sure could use a forwarder but that seems like a lazy trick.

Also I don't recall if DSi enhanced homebrew even supports NitroFS currently (when launched from SD card and not slot-1). Only stuff I've seen use it are DS homebrew and DLDI is required which means it has to be booted off slot-1 and not on DSi SD. Been quite a bit since I've worked on DSi stuff. maybe that's been worked out. This was mainly a limitation with libnds/devkitarm stuff that homebrew are built on so it would require an update to libnds/devkitarm for that to support DSi SD.

 

[firke_the_one]

But I then read that the PS1 lacks a z-buffer so I would be curious as to how one gets it running on a PS1.

There were some PS1 tech demos that had manually written z-buffer logic through code and it did a decent job, just don't know how intensive it would be on the hardware :/

 

[Hydr8gon]

Alright, I pushed a change that adds experimental audio support! It's not finished yet, though; there are still issues, and it causes a bit of slowdown, so it can be toggled at any time with the select button.

Getting this working has been interesting. Running the PC port's mixer with the game's synthesis code was too intensive for the DSi, but @StapleButter hacked apart the game's code and was able to get things playing directly through the DS hardware, so there was hope. Decoding the samples was still too much though, so we discussed the idea of converting them to a native DS format at compile time. I thought this would be hard, but I somehow managed to get it working without much trouble, and the overhead of decoding was gone! That's the short version of it, but I'll probably talk about it more in my eventual blog post about the entire porting process.

Anyway, there's still work to do on this, but I wanted to commit what I have now because it's starting to work pretty well, and I figure some people might want to try it

 

[Deleted member 323844]

Thank you Hydr8gon. It works surprisingly well, considering the big impact in performance the mixer gave to other projects, like Dreamcast, Playstation Portable, Vita or 3DS.



PSA: Compilation now requires Sound eXchange (sudo apt get sox). It's already in the readme.

 

[Hydr8gon]

Thanks to @nadiaholmquist we now have better sample conversion, and things are sounding even better! There are still somewhat jarring issues with notes that have higher frequencies than the DS can handle, but other than that this is sounding really nice

 

[Apache Thunder]

I was able to test things out with a compiled SRL. Looks like arm7 load address/entry point is too high in ram for DSi System Menu to accept it. Probably because arm9 binary being quite large.

I suppose I can't boot this from there until NitroFS support comes. It appears Robz8 got NitroFS to work with HiyaCFW SDNAND so if you get NitroFS up and running consult with him to include that fix. He may have also done fixes to make it work with DSI SD in general but I'm not sure if his fixes just add SDNAND support or SD support in general.

As for how the game pefroms, it's pretty close to perfect. Only thing it's missing at this point is NitroFS, a UI of somekind for bottom screen and having top/down section of touchscreen for the Up/Down C button mapping. I'd like to see one of the freed up X/Y buttons used to have a walk function so you can have Mario walk instead of run. Similar to how Mario 64 DS has a run button. (but I think run should be the default action instead unlike Mario 64 DS).

There are still some slowdown in places and UI/Text will definitely need some fixes to work with the lower screen res of the DS. What's the polygon count of a typical Mario 64 scene? I do recall a 2048 or so polygon hard limit that you shouldn't exceed with the DS/DSi. The Mario 64 DS port was built specifically with this in mind. Though perhaps Mario 64 doesn't run into that limit either since it doesn't have any of the fancy additions that Mario 64 DS had.

Anyways some of the slow down I see in Bombomb Battlefield might be due to the game hitting the polygon limit perhaps? Might have to adjust draw distances on some objects or something to resolve this if that's the issue. (though maybe it's just the new sound system responsible for the slowdown. I don't know yet)

One of the end goals is possible support for 3DS analog stick via RTCOM but also having a emulated stick on touch screen similar to Mario 64 DS for DS/DSi users. Though unlike Mario 64 DS, try to make it a stationary one. The one thing I hated about the way Mario 64 DS handled it is that the virtual stick moves around the screen on me sometimes because it doesn't have a fixed position and recenters around any new area I press on the touchscreen first.

This made it quite unusable for me. This was one of the reasons I've yet to ever complete a Mario 64 DS run. The controls just get in the way too much for me.

 

[Hydr8gon]

I was able to test things out with a compiled SRL. Looks like arm7 load address/entry point is too high in ram for DSi System Menu to accept it. Probably because arm9 binary being quite large.

I suppose I can't boot this from there until NitroFS support comes. It appears Robz8 got NitroFS to work with HiyaCFW SDNAND so if you get NitroFS up and running consult with him to include that fix. He may have also done fixes to make it work with DSI SD in general but I'm not sure if his fixes just add SDNAND support or SD support in general.

You're right about that, but NitroFS support isn't as simple as just adding it to the build; the way the game handles assets will have to be reworked, since it was designed for the N64 which has its ROM mapped directly to memory and therefore doesn't need to load anything in dynamically.

As for how the game pefroms, it's pretty close to perfect. Only thing it's missing at this point is NitroFS, a UI of somekind for bottom screen and having top/down section of touchscreen for the Up/Down C button mapping. I'd like to see one of the freed up X/Y buttons used to have a walk function so you can have Mario walk instead of run. Similar to how Mario 64 DS has a run button. (but I think run should be the default action instead unlike Mario 64 DS).

This is actually exactly what I had in mind for a better control scheme! I hesitate to change the hardcoded controls at this point though, because it might confuse people who have already been using the port. I'm thinking of setting up some sort of control configuration, so people can configure it the way they want instead of relying on a preset scheme.

There are still some slowdown in places and UI/Text will definitely need some fixes to work with the lower screen res of the DS. What's the polygon count of a typical Mario 64 scene? I do recall a 2048 or so polygon hard limit that you shouldn't exceed with the DS/DSi. The Mario 64 DS port was built specifically with this in mind. Though perhaps Mario 64 doesn't run into that limit either since it doesn't have any of the fancy additions that Mario 64 DS had.

Anyways some of the slow down I see in Bombomb Battlefield might be due to the game hitting the polygon limit perhaps? Might have to adjust draw distances on some objects or something to resolve this if that's the issue. (though maybe it's just the new sound system responsible for the slowdown. I don't know yet)

The 2048 polygon limit is enforced by the amount of RAM the DS has to store polygons; if you exceed the limit, any additional polygons you try to send simply won't be drawn. The slowdown is indeed mostly caused by the audio; you can toggle it with the select button to see how performance is with it disabled. I'm hoping that the audio work still being done on the ARM9 can be moved to the ARM7 to eliminate the extra slowdown, but I need to look into it more.

One of the end goals is possible support for 3DS analog stick via RTCOM but also having a emulated stick on touch screen similar to Mario 64 DS for DS/DSi users. Though unlike Mario 64 DS, try to make it a stationary one. The one thing I hated about the way Mario 64 DS handled it is that the virtual stick moves around the screen on me sometimes because it doesn't have a fixed position and recenters around any new area I press on the touchscreen first.

This made it quite unusable for me. This was one of the reasons I've yet to ever complete a Mario 64 DS run. The controls just get in the way too much for me.

An analog stick on the touch screen would be a good option for the control configuraton I'm planning; I'll keep it in mind!

 

[RocketRobz]

The 2048 polygon limit is enforced by the amount of RAM the DS has to store polygons; if you exceed the limit, any additional polygons you try to send simply won't be drawn.

I heard that you can double the polygon count by using the DS screen capture feature.
This could work, as the game runs at 30FPS, and if there's indeed more than 2048 polygons shown in the original game, though I'm not sure if it'll cause more slowdown.