Seeing this port makes me think a ps1 port might actually be possible
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 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.
Maybe try having DSP handle the audio?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.
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.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.
That's something I might actually look into. I don't know anything about the DSP though, so it's kind of intimidatingMaybe 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.
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 easierI 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
The rom detection on the ievo? Other dsi homebrew works pretty well, and properly dumped games work fine too.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.
src/nds/nds_controller.c, if you don't mind touching a bit of source code. There isn't any built-in control remapping yetYo this is amazing! btw what do I have to edit to change the controls?
Yes, by porting this to the PS1 Classic!Seeing this port makes me think a ps1 port might actually be possible
Thank you!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
Seeing this port makes me think a ps1 port might actually be possible
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 :/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.
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.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.
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.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).
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.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)
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!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.
I heard that you can double the polygon count by using the DS screen capture feature.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.