Super Mario 64 has been decompiled
- Thread starter Ecchi95
- Start date
- Views 205,872
- Replies 252
- Likes 32
If the rom hacks have PIC code (relocatable, shared library), yes. Otherwise you'll get a nice crash.
I think early N64 games were compiled with very little optimization because that way these'd have been easier to debug. It is easier to debug barely optimized code (as it is simpler), than it is optimized. Maybe the SDK was made out of Mario N64? Not to mention optimized code always end up breaking code not supposed to be optimized at all (such as older system's IO port read/writes, which required drain write buffer + invalidate cache + read/write primitive opcodes (ie, single, the most basic opcodes) and not subsequential read/write opcodes (sequential), such as ldr/str vs ldm/stm, because these would cause unexpected behaviour.
D
Deleted User
Guest
More info from the modern vintage gamer:
Also an interessting reply from famous Super Mario 64 romhacker Kaze Emanuar:
"This is not entirely true. The CPU is almost never fully utilized. The mistake with the DDD lag is making the collision triangles dynamic rather than permanent. O2 compilation only mitigates this issue. It could be entirely solved by making the collision from the sub permanent (and I did that in SM64 Multiplayer, for example) Most of the lag in SM64 comes from GPU which this doesn't change so O2 compilation doesn't change anything for most of the game."
Also an interessting reply from famous Super Mario 64 romhacker Kaze Emanuar:
"This is not entirely true. The CPU is almost never fully utilized. The mistake with the DDD lag is making the collision triangles dynamic rather than permanent. O2 compilation only mitigates this issue. It could be entirely solved by making the collision from the sub permanent (and I did that in SM64 Multiplayer, for example) Most of the lag in SM64 comes from GPU which this doesn't change so O2 compilation doesn't change anything for most of the game."
D
Deleted User
Guest
A patch for Super Mario 64 called Super Mario 64: Arguably Better Edition has been released on Mario Fan Game Galaxy (MFGG).
Made by MFGG member Mors using the SM64 Decompilation project.
https://www.mfgg.net/?sess=6974d051c1924154716229e6525e45d9&act=resdb¶m=02&c=7&id=36500
Made by MFGG member Mors using the SM64 Decompilation project.
https://www.mfgg.net/?sess=6974d051c1924154716229e6525e45d9&act=resdb¶m=02&c=7&id=36500
Nice to see things starting, I am still mostly hoping for a PC port or better but improvements (even if some of them are emulator only) is still good to see. I will have to play it to see what the changes do as far as balance (wall kick was already pretty powerful and allows you to cheese some stuff, more so would be more so. Also wall sliding I guess is fun but might change things again, still always up for more hacks.)
You might as well quote the readme at least
You might as well quote the readme at least
The readme for the Super Mario 64: Arguably Better Edition - R3 download said:
I want to see someone make an engine out of it.
So those awesomely intelligent people create new games based on it, not only derivative more Mario games.
Kind of like iD did with Quake.
So those awesomely intelligent people create new games based on it, not only derivative more Mario games.
Kind of like iD did with Quake.
Surely there are better engines already out there, likely with far less legal headaches for releasing the end result too. Mario 64's engine does not do all that much special these days, and has a massive list of quirks and limitations to deal with that are a complete non factor in more modern stuff.
D
Deleted User
Guest
https://github.com/DavidSM64/SM64-Fast3D-AA-Reducer
This simple tool will overwrite the Fast3D 2.0D microcode within a SM64 ROM, and replace it with a slightly modified version that disables full anti-aliasing. It does this by blocking any attempt to write the IM_RD render mode flag into the RDP's othermode variable. This should improve performance on real N64 hardware by 3-4 fps (~10%).
How to use:
Just simply open up a Super Mario 64 ROM file, and then you can click the "Reduce the AA!" button if the ROM is compatible.
What Super Mario 64 Rom are compatible?:
Any SM64 ROM that uses the Fast3D 2.0D microcode is compatible. This includes the Japanese and North American versions of SM64 and any ROM hacks made with those versions.
Benchmark:
The beginning area of Jolly Roger Bay does lag a significant amount. Going down to a 22 fps minimum in my testing. Injecting the modified microcode makes a significant difference in the feel of the game, with the minimum increased to 25 fps.
My jolly roger bay benchmark starts at the beginning of the level and has Mario swim into the underwater cave. The framerate is bad in the beginning, but gets a lot better when you are deep underwater.
This simple tool will overwrite the Fast3D 2.0D microcode within a SM64 ROM, and replace it with a slightly modified version that disables full anti-aliasing. It does this by blocking any attempt to write the IM_RD render mode flag into the RDP's othermode variable. This should improve performance on real N64 hardware by 3-4 fps (~10%).
How to use:
Just simply open up a Super Mario 64 ROM file, and then you can click the "Reduce the AA!" button if the ROM is compatible.
What Super Mario 64 Rom are compatible?:
Any SM64 ROM that uses the Fast3D 2.0D microcode is compatible. This includes the Japanese and North American versions of SM64 and any ROM hacks made with those versions.
Benchmark:
The beginning area of Jolly Roger Bay does lag a significant amount. Going down to a 22 fps minimum in my testing. Injecting the modified microcode makes a significant difference in the feel of the game, with the minimum increased to 25 fps.
My jolly roger bay benchmark starts at the beginning of the level and has Mario swim into the underwater cave. The framerate is bad in the beginning, but gets a lot better when you are deep underwater.
trying to compile SDL ver on Manjaro (archlinux based) on raspberry pi 4 (aarch64) and get
Anyone have any ideas?
Code:
as -I include -I build/us_pc --defsym VERSION_US=1 -MD build/us_pc/sound/sequences/00_sound_player.d -o build/us_pc/sound/sequences/00_sound_player.o sound/sequences/00_sound_player.s
sound/sequences/00_sound_player.s: Assembler messages:
sound/sequences/00_sound_player.s:87: Error: too many positional arguments
sound/sequences/00_sound_player.s:88: Error: too many positional arguments
sound/sequences/00_sound_player.s:89: Error: too many positional arguments
sound/sequences/00_sound_player.s:92: Error: too many positional arguments
sound/sequences/00_sound_player.s:93: Error: too many positional arguments
sound/sequences/00_sound_player.s:194: Error: too many positional arguments
sound/sequences/00_sound_player.s:195: Error: too many positional arguments
sound/sequences/00_sound_player.s:197: Error: too many positional arguments
sound/sequences/00_sound_player.s:200: Error: too many positional arguments
sound/sequences/00_sound_player.s:202: Error: too many positional arguments
sound/sequences/00_sound_player.s:225: Error: too many positional arguments
sound/sequences/00_sound_player.s:225: Error: unknown mnemonic `restore' -- `restore the value'
sound/sequences/00_sound_player.s:227: Error: too many positional arguments
sound/sequences/00_sound_player.s:228: Error: too many positional arguments
make: *** [Makefile:677: build/us_pc/sound/sequences/00_sound_player.o] Error 1Anyone have any ideas?
Something old, something new:
RT works amazingly well in this game, well on this stage at least because the rest of them would have reflective carpets and glow in the dark walls.
RT works amazingly well in this game, well on this stage at least because the rest of them would have reflective carpets and glow in the dark walls.
- Joined
- Jan 7, 2014
- Messages
- 14,600
- Trophies
- 4
- Location
- Another World
- Website
- www.gbatemp.net
- XP
- 25,207
- Country
That looks seriously incredible.
Combining this to SM64 EX and Render96 models and this will become a really serious remaster project.
There have been quite a few high effort remasters:
But generally the overly reflective ray tracing and effects don't match the rest of the game as well as they do in the originally linked video:
Shiny reflective grass for the lulz!
The n3DS version of this is the ultimate remaster. Playing it in real 3D makes it feel brand new and the 800px mode when the effect is turned off on the small screen makes it look really crisp and authentic in a way the remasters don't.
But generally the overly reflective ray tracing and effects don't match the rest of the game as well as they do in the originally linked video:
Shiny reflective grass for the lulz!
The n3DS version of this is the ultimate remaster. Playing it in real 3D makes it feel brand new and the 800px mode when the effect is turned off on the small screen makes it look really crisp and authentic in a way the remasters don't.
Fans do what Nintendont:
Looks really good and was what I was expecting them to do with a full remake, even if they kept the engine the same underneath with a new skin on top.
Looks really good and was what I was expecting them to do with a full remake, even if they kept the engine the same underneath with a new skin on top.
-
Xdqwerty
what are you looking at? -
K3Nv2
-
The Real Jdbye
*is birb*
-
-
-
-
-
-
-
-
-
@
K3Nv2:
I can think of the design teams process another joystick and no audio or a joystick and mono audio
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
