Homebrew Super Mario 64 Port
- Thread starter MarioKartFan
- Start date
- Views 109,624
- Replies 330
Aw. Thing is, on my old 3DS, it only ever gets slow when the sounds get more complex, so the exact same parts of music, or the same sounds, cause lag. Really hoping a solution gets found for this. Old 3DS should be able to play Mario 64 well.
From what I tested, at least with my port, for example in bob-bomb battlefield, it's never full speed at o3ds speed. Even without sound mixing on.
- Joined
- Sep 12, 2003
- Messages
- 866
- Trophies
- 2
- Location
- Netherlands
- Website
- cursors.pocketheaven.com
- XP
- 868
- Country
What a fantastic project.
I'm trying to compile it on Windows, using WSL 2. It's throwing me this error:
/bin/sh: 1: ./extract_assets.py: Permission denied
Makefile:170: *** Failed to extract assets. Stop.
/ edit: fixed that with sudo chmod -R 777 /sm64_3ds/
but the next error is
make: /bin/arm-none-eabi-cpp: Command not found
Makefile.split:152: build/us_3ds/level_rules.mk: No such file or directory
make: *** [Makefile.split:151: build/us_3ds/level_rules.mk] Error 127
I'm trying to compile it on Windows, using WSL 2. It's throwing me this error:
/bin/sh: 1: ./extract_assets.py: Permission denied
Makefile:170: *** Failed to extract assets. Stop.
/ edit: fixed that with sudo chmod -R 777 /sm64_3ds/
but the next error is
make: /bin/arm-none-eabi-cpp: Command not found
Makefile.split:152: build/us_3ds/level_rules.mk: No such file or directory
make: *** [Makefile.split:151: build/us_3ds/level_rules.mk] Error 127
Last edited by jelbo,
From what I gather the leaks recently are incomplete source code and therefore could not be used to create a working game. Although assets from the leaks have been imported into final games (which has been done in recent Youtube videos of deleted Mario 64 levels and Luigi models) there isn't enough runnable code of any of the games to make a compilable build entirely from the leaks. All Mario 64 ports, such as this one, are based on the decompilation which was the outcome of years of work, not the leaks which are too incomplete.
Even if that wasn't the case, using the leaks would be extremely risky as Nintendo owns full copyright of the code, whereas the code in the Mario 64 decompilation was written entirely by the fanbase which is why Nintendo can't take down the PC port. Decompilation-based projects aren't distributing any copyrighted material such as textures, sound or character models - that comes from the ROM that the person compiling it needs to provide.
Last edited by Graxer,
Most of them are incomplete but some of them aren't. Dr Mario 64 is the full source according to 4chan's /vr/ board.
Last edited by Deleted member 323844,
Yeah I saw mention of the Japanese version of Dr Mario 64 being compiled (was previously not released in Japan and it was kicked over to the Gamecube) so presumably is full or near as does not matter.
What it will take to adapt the source to PC on the other hand I don't know. The Mario 64 to PC stuff seemed pretty tame compared to what it could have been when I did a quick compare but there is a difference between "I hope this works" first games on a system and game released so late it got punted to the next one after they could make the consoles sing.
What it will take to adapt the source to PC on the other hand I don't know. The Mario 64 to PC stuff seemed pretty tame compared to what it could have been when I did a quick compare but there is a difference between "I hope this works" first games on a system and game released so late it got punted to the next one after they could make the consoles sing.
For what it's worth, it's really easy to remove the dark filter on a hacked Wii U's N64 VC titles, as described here: https://gbatemp.net/threads/wiiu-vi...re-dark-filter-and-widescreen-support.517158/ input lag though is not something I'm aware of being fixable for the VC, (though honestly I've never noticed any real input lag on N64 VC titles on the Wii U, that isn't to say it isn't there, I just personally never noticed it).
On my old 3DS (And it's the absolute original 3DS from 2011), I have the port installed via FBI, playing at 400px mode. It runs on full speed (At least, it seems like it) until specific parts of music play, or specific sound effects. Something that makes this easily noticeable is Cool, Cool Mountain's music track. When the music ends up at the 0:51 mark, it ends up lagging.
Once it loops right back again like at 1:28 in the above video, the lag disappears until coming back again when reaching the same point of the looping track at 2:15. It's a really weird problem, but it's definitely something to do with the sounds.
Last edited by Gameoverman,
Is it slower when you use 800px mode and/or antialiasing?
I noticed it mainly in the haunted mansion where you need to do a wall jump to get to the attic. The timing is pretty tight and it cost me so many tries to do on the wii u vc. On the 3ds version it seems to be much easier to pull off.
Decided to test that out right now. On my original old 3DS, neither Anti-Aliasing nor 800px mode seem like they do much of a difference, if any. Exact same sounds and parts of music cause lag. Same part of Cool Cool Mountain's music slows down the game too.
One sound that consistently causes lag is when you slide down the mountain on Cool Cool Mountain, and see the lines of coins and grab them all. Seeing as it lags as the music hits specific parts, without doing anything at all, is a sign the sound is to blame. When it loops, and those specific points of the track play again, it will lag the exact same way. When someone reports that big enemies cause lag, that's most likely because of the boss music that kicks in.
Cool Cool Mountain's music track should have some clues as to what causes this slowdown, since it plays at full speed, then slows down towards the end of it, then plays at full speed when it loops back at the start again. Might want to take note of the Wing Cap music too. Whenever it's worn, and the music starts playing, the game will slow to a crawl until the Wing Cap runs out. I'm confident it has to do with the sound
Last edited by Gameoverman,
Did you also try bob-bomb battlefield? It's permanently not full speed in my tests with o3ds speed.
Edit: Either way I could still try to continue the dsp stuff, but I need to revert some things to how they were handled in the original game. The dsp is basically the rsp for the audio stuff and to prevent operating system overhead I would have to send a whole buffer (or rather a pointer to it) of commands to the dsp at once, just like would happen with the rsp on n64.
Last edited by Gericom,
Yep. Bob-omb Battlefield does play at full speed for the most part. Here's a video I recorded to show you where some of the problems are, and it's all on sound.
Oh, and this is an NTSC-U old 3DS. I have the game installed through FBI.
Last edited by Gameoverman,
Fantastic work on this, Gericom. 800px + 64DS Mario looks crisp, game runs beautifully on N3DSXL, I may restart SM64 all over again on this.
Just out of curiosity, what are the upper and lower limits of hardware use based on the version? We're probably a long way from seeing any form of multiplayer on the SM64 ports, let alone 2-player co-op wirelessly between 3DSes, but it'd be interesting to know if there's any headroom left for a network stack to be implemented, even if it means 400px no AA no HD models, N3DS only or what have you.
Just out of curiosity, what are the upper and lower limits of hardware use based on the version? We're probably a long way from seeing any form of multiplayer on the SM64 ports, let alone 2-player co-op wirelessly between 3DSes, but it'd be interesting to know if there's any headroom left for a network stack to be implemented, even if it means 400px no AA no HD models, N3DS only or what have you.
Developer of the Wii U port here. It is worth mentioning that the port is still WIP. While the audio and controls work perfectly fine, the renderer is still entering its early stages. (Nothing will render at the time of writing this post)
Apparently, there is also a memory leak in the title screen if you wait several minutes (doesn't happen during gameplay, though), which I also need to deal with before labeling this port as playable.
The ELF needs to be stripped (using strip from devKitPPC) and converted to an RPX (using elf2rpl from wut) first to prevent this issue.I have tried the WiiU port and it throws a lack of memory error. The elf file is quite massive compared to the 3DS binary
Similar threads
