They were thinking "this code will only ever run on a N64 so it has no other configurations possible to program for"
Hopefully the port devs address it soon, I'd love the see the game running at a high framerate
-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
A PC port of Mario 64 has appeared out of nowhere
- Thread starter RoboitoAM
- Start date
They were thinking "this code will only ever run on a N64 so it has no other configurations possible to program for"
Hopefully the port devs address it soon, I'd love the see the game running at a high framerate
you really wondering why Yasunari Nishida, in 1995 or whatever, wasn't sitting at his dev station thinking "yes, this needs to be like Quake"
going through all the game logic and making it scale to arbitrary frametimes is a tough process when the game wasn't built for it in the first place
The port dev only put the N64 graphics calls through an SDL wrapper.
The game logic programming is near identical to the N64. It's literally from a decompilation project. It's not on them.
I don't know if I had that exact problem, but I eventually got it working after adding that flag to the end of every make step (all 3 of them). Not sure if that's what helped, but it finally worked.
well, just did the first make command, hahaha. ill see if what i think is the issue is. if not, ill try yours.
EDIT: did it. it's working perfectly now, even saving the settings and not resetting them. this is so cool
Last edited:
The analog camera mod annoys the hell out of me with this. The default camera controls inverted the goddamn stick and I hate inverted sticks! And then setting it to normal in the options causes the camera to go haywire.
Avoid the analog camera mod people.
Avoid the analog camera mod people.
Maybe try the latest source code from github instead of whatever ancient leaked version you're using because that bug has since long been fixed and it locks to 30 FPS properly on whatever refresh rate.
GitHub - sm64pc/sm64ex: Fork of https://github.com/sm64-port/sm64-port with additional features.
Fork of https://github.com/sm64-port/sm64-port with additional features. - sm64pc/sm64ex
github.com
And if your question is why the 1996 Super Mario 64 game is not variable framerate ready then I won't bother to answer lol
Last edited:
I have absolutely no idea what you're talking about. The camera settings work fine with the latest master source code. And if don't like it, guess what, the game builds with it disabled by default. You have to specifically build the game with BETTERCAMERA=1 to get the analog mod. And it's WIP, unfinished. And the goal is to be able to turn it on and off ingame.
See how they hit right and the camera pans in the opposite direction? I hate that.
Changing it in the options causes the camera to go haywire until you switch it back.
this has been fixed for 2 days on the repo already. build it again.
Yes. It's called inverted camera controls.
And I'm telling you that's not the case in the latest version because I also hate inverted camera controls and I changed it in the settings and it works fine.
Sweet.
It's almost like my original post said that the stick was inverted, I know what it's called.
The port team are ultimating details on multi language support.
When it's ready, it will include a Spanish-Spain translation made by yours truly :D It's very unapologetic about being Castilian Spanish, so LATAM people: expect to hate the translation. It doesn't matter, as the target audience are Spaniards, and I told the dev team to account for the possibility of having multiple variations of the same language so you can make a LATAM translation too if you want and they can both coexist ;)
The translation is made completely from scratch and is not based on Nintendo's official translation of the DS version for obvious reasons. I refused to look at it. It also takes many liberties and I've snuck a few jokes in there. I hope people like it.
Also, in theory, multilang support will mean that you wil be able to extract the official German and French translations from the EU ROM, while still using the US ROM as a base. This means that if you want to play the game in German or French, you need to dump both and US and an EU ROM, at least for now.
When it's ready, it will include a Spanish-Spain translation made by yours truly :D It's very unapologetic about being Castilian Spanish, so LATAM people: expect to hate the translation. It doesn't matter, as the target audience are Spaniards, and I told the dev team to account for the possibility of having multiple variations of the same language so you can make a LATAM translation too if you want and they can both coexist ;)
The translation is made completely from scratch and is not based on Nintendo's official translation of the DS version for obvious reasons. I refused to look at it. It also takes many liberties and I've snuck a few jokes in there. I hope people like it.
Also, in theory, multilang support will mean that you wil be able to extract the official German and French translations from the EU ROM, while still using the US ROM as a base. This means that if you want to play the game in German or French, you need to dump both and US and an EU ROM, at least for now.
Chill. But it was pretty frustrating seeing you dismiss the hard work in progress of so many people because of an old issue that isn't even a thing anymore.
I wasn't dismissing work and I was never irritated or irate; I said the analog mod was annoying under the assumption that the build I made days ago was still relevant to possibly let people know that they should avoid it. Dismissing work would've entailed me saying that everything sucks.
Either way, it's been redone, camera is mapped.
yep I just built a binary (first time I've ever done that, it was tricky!) and now it works great!Maybe try the latest source code from github instead of whatever ancient leaked version you're using because that bug has since long been fixed and it locks to 30 FPS properly on whatever refresh rate.
GitHub - sm64pc/sm64ex: Fork of https://github.com/sm64-port/sm64-port with additional features.
Fork of https://github.com/sm64-port/sm64-port with additional features. - sm64pc/sm64ex
And if your question is why the 1996 Super Mario 64 game is not variable framerate ready then I won't bother to answer lol
Question: how do I do a build with the BETTERCAMERA=1 thing? I am entering the following command to do my build currently:
PATH=/mingw32/bin:/mingw64/bin:$PATH make
Do I literally just change that to
PATH=/mingw32/bin:/mingw64/bin:$PATH make BETTERCAMERA=1
Last edited:
Yes but run "make clean" first because sometimes if you build on top of the regular version it will ignore the BETTERCAMERA thing
No, it doesn't. Unless someone puts in the huge amount of effort to decompile each one.
Decompilation projects are not like emulators. Work on one game doesn't magically apply to other games. It's all done on a game by game basis.
However, OOT is a possibility at some point. There's a decomp project for that which has been going for a while: https://github.com/zeldaret/oot
That same people is doing the same for Majora's Mask btw:
GitHub - zeldaret/mm: Decompilation of The Legend of Zelda: Majora's Mask
Decompilation of The Legend of Zelda: Majora's Mask - zeldaret/mm
github.com
really curious why they opted for master quest first. but cool stuff nonetheless
MQ had debug symbols left in, which helps them reverse engineer what's going on.
Not completely accurate. They're using the debug ROM of Master Quest, which does have debug symbols. The regular Master Quest ROM doesn't.
fireworksordie
Ah, my mistake. Looking at the page again, you are right.
Last edited:
That same people is doing the same for Majora's Mask btw:
GitHub - zeldaret/mm: Decompilation of The Legend of Zelda: Majora's Mask
Decompilation of The Legend of Zelda: Majora's Mask - zeldaret/mm
I would LOVE to see a PC version of Majoras Mask! The only thing putting me off compiling this is all the steps on Windows to compile the binary. It looks like a lot of hassle. Surely someone can make a easytool to do this?
neither the oot nor mm repositories appear to be anywhere close to the state that the sm64 source is, so it will probably be a while before we see what we're seeing for sm64 right now.
These decomp projects don't build Windows binaries. They are pure decomp projects, with the goal of reproducing the original ROM. Much like the original SM64 decomp.
Only once that is done should people start looking at adding an DirectXL/OpenGL wrapper, and all the other things needed to get it built on PC.
Are you talking about MM there? You can't compile OoT or MM yet lol.
Yes I know, my post was badly worded sorry. I meant I would like to be able to compile the Super Mario 64 binary but not go through the hassle of installing libraries and dependencies. Just a tool where you can point it to the N64 rom and click make me :)
It literally takes 10 minutes tops. And that's the first time you build the game. After that, updating the source code and re-building it takes like one minute.
I'm wondering if it would be possible to include very basic placeholder assets in the repo so that a rudimentary build is possible without the ROM. Being able to boot directly into the first world would be amazing for development purposes too.
In theory, this should be easily fixable by also adding in checks during sound effect playback that Mario is within the original draw distance. I'd try it myself, but there's no Mac build yet and I really don't feel like setting up a Windows dev environment. Compile flags are fine for the time being, but I think the top priority right now should be refactoring the code so it that making a "proper" PC port is possible.Someone made a PR that allows you to optionallly build the game with unlimited draw distance for entities! I'm trying it out, it's cool
Kind of annoying to hear Chain Chomp attacking the whole time you're in the stage tho lol
I'm not going to test it right now, but I got curious:
In src/game/behaviors/chain_chomp.inc.c
Seems like this is the code which governs how chain chomp moves. Seems like there is a oDistanceToMario variable that can be accessed there. Adding an if statement so the cur_obj_play_sound_2 method calls only run when oDistanceToMario is less than the old draw distance would probably fix it.
Code:
if (abs_angle_diff(o->oAngleToMario, o->oMoveAngleYaw) < 0x800) {
if (o->oTimer > 30) {
if (cur_obj_check_anim_frame(0)) {
cur_obj_reverse_animation();
if (o->oTimer > 40) {
// Increase the maximum distance from the pivot and enter
// the lunging sub-action.
cur_obj_play_sound_2(SOUND_GENERAL_CHAIN_CHOMP2);
o->oSubAction = CHAIN_CHOMP_SUB_ACT_LUNGE;
o->oChainChompMaxDistFromPivotPerChainPart = 900.0f / 5;
o->oForwardVel = 140.0f;
o->oVelY = 20.0f;
o->oGravity = 0.0f;
o->oChainChompTargetPitch = obj_get_pitch_from_vel();
}
} else {
o->oTimer -= 1;
}
} else {
o->oForwardVel = 0.0f;
}
} else {
cur_obj_play_sound_2(SOUND_GENERAL_CHAIN_CHOMP1);
o->oForwardVel = 10.0f;
o->oVelY = 20.0f;
}In src/game/behaviors/chain_chomp.inc.c
Seems like this is the code which governs how chain chomp moves. Seems like there is a oDistanceToMario variable that can be accessed there. Adding an if statement so the cur_obj_play_sound_2 method calls only run when oDistanceToMario is less than the old draw distance would probably fix it.
Now this is what I've been waiting for. Interesting to see how much game logic fixes this will require before it causes no issues.Someone made a PR that allows you to optionallly build the game with unlimited draw distance for entities! I'm trying it out, it's cool
Kind of annoying to hear Chain Chomp attacking the whole time you're in the stage tho lol
Okay, can i ask for a favor over here?
If i provide someone my own, legal Super Mario 64 rom from the Wii U Virtual Console, can he/she compile the DX12 version for me? I can also provide any info necessary to prove that it is, in fact, a legit purchased digital copy of the game.
I'm tired of trying to compile it but always having some kind of error fucking up the proccess. I just want to do some testing :/
If i provide someone my own, legal Super Mario 64 rom from the Wii U Virtual Console, can he/she compile the DX12 version for me? I can also provide any info necessary to prove that it is, in fact, a legit purchased digital copy of the game.
I'm tired of trying to compile it but always having some kind of error fucking up the proccess. I just want to do some testing :/
First of all, why are you using the ancient leaked DX12 source code? Use the current OpenGL code:
GitHub - sm64pc/sm64ex: Fork of https://github.com/sm64-port/sm64-port with additional features.
Fork of https://github.com/sm64-port/sm64-port with additional features. - sm64pc/sm64ex
github.com
What you're saying is not legal because you'd be sharing the ROM over the internet, but even if it was, it's better if you learn how to build it yourself so that you can update the game whenever you want. Try to use the tutorial in the github I just linked, with that sourve code, and let me know if you have any issues.
there are builds of both out there. if you're trying to do some testing it would probably be better to instead get assistance from someone regarding your build errors.
Understood, sorry for bringing it up.
I'll get on it again this weekend.
Someone made a PR that allows you to optionallly build the game with unlimited draw distance for entities! I'm trying it out, it's cool
Kind of annoying to hear Chain Chomp attacking the whole time you're in the stage tho lol
Are there currently any other known issues with the increased draw distance besides chain chomp in BOB? Has anyone done some good testing with it yet?