I would shave my head for a New 3DS version of this (not the emulated version)
ROM Hack Does Mario 64 being decompiled mean a 3DS port is possible?
- Thread starter GreenAndACat
- Start date
- Views 30,058
- Replies 136
- Likes 4
I'm surprised no one's thought of a Dreamcast port, that console has a lot of potential. I know there was an N64 emulator for the Dreamcast but it ran at like 5fps without sound. Maybe they can use Windows CE to port it over...
D
Deleted User
Guest
https://dreamcast-talk.com/forum/viewtopic.php?f=5&t=12753&sid=c089a48e2fc195017159adfb1e9440f1
A Dreamcast port is possible according to this thread.
Of course it's possible. Dreamcast is like twice as powerful as the N64. But the real question is, would it be easy? The thread says it's easier to port the PC version, and that makes sense since the DC runs a modified version of Windows. A change they would have to make is the camera controls. Since Dreamcast has only one analog stick they would need to use the D-pad for camera. They could also make a little picture for the VMU which would be nice. I think the Dreamcast is the oldest console on which a port would be possible. Almost the same generation too.
Thank you i will dig in his youtube channel because i have two ps2 and one ps3 consoles
It is cool to imagine what ports might be possible, but... this is a thread about a 3DS port, right?
It can run Windows CE, however most games don't because it was terrible. I'm not convinced it would help so much either as DirectX is just a brand name and every version is different.
Being decompiled, you could run Mario 64 on anything that can handle it. You could port it to a Samsung fridge if you wanted to, as long as it can run a nearly 25 year old game. Mario 64 can become pretty much the new Doom.
I wanna see someone try the ultimate taboo, and port it to the Playstation 1. Yes, I know it'd run like ass, but it'd be funny.
Last edited by Viri,
Would it even run at all? I doubt PS1 has the specs required to pull off such a feat.
This talk of other consoles has me curious.
Has anybody poked around the code to see what sort of things it leans into that the would be porter might want to lean back out of?
In a lot of other projects over the years we have seen people have to downplay the amount of times a given game leans into floating point (or more precision in floating point).
This in addition to whatever console specific stuff might want to be changed in favour of generic inputs and outputs for audio and video.
Has anybody poked around the code to see what sort of things it leans into that the would be porter might want to lean back out of?
In a lot of other projects over the years we have seen people have to downplay the amount of times a given game leans into floating point (or more precision in floating point).
This in addition to whatever console specific stuff might want to be changed in favour of generic inputs and outputs for audio and video.
D
Deleted User
Guest
Unfortunately its a case of if you need to ask that question it is not something you'll be able to do. At least not without spending a long time and a lot of effort learning to code.
Yes. It uses the 3DS 3D effect. Why is this so hard to understand. You could literally download it and check it out yourself.
OK start with learning C programming (the N64 effort is in written in it, and the 3ds responds well to such things, though there are large differences in C today/for the 3ds and what was done decades ago for the N64 and in general C of the time as well).
http://programming-motherfucker.com/become.html
I quite like this video course myself as well.
I would also throw in some game coding skills as well as most of the above will be the (still essential for this) data handling and program flow.
https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true
http://hciweb.usask.ca/uploads/332-aim-assist-cameraReady-v8-final.pdf
Being but two links. GDC talks, existing open source game code, https://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php (though probably no networks involved in this so there is that) , bit of game theory maybe, I really like this book (characteristics of games), learning to hack games and make cheats is not a bad plan and will teach you a lot... this sort of reading never ends either really as there is always more to understand.
You will also want to learn the N64 hardware at least moderately well, hardware that is generally considered some of the most complex and annoying hardware ever devised for a popular console (the Sega Saturn probably being the only thing that is worse). This is as the original game, despite being a launch title, was coded to play to its strengths and that is the code you have here.
If you can follow along with what these two are saying and maybe speak a bit on any of the points brought up you are probably there.
Bonus link
https://www.copetti.org/projects/consoles/nintendo-64/ and also be familiar with the idea of microcode, though you are spared the really fun stuff from later N64 games here ( https://github.com/gonetz/GLideN64/...ine-and-Star-Wars-Episode-I:-Battle-for-Naboo ).
3ds hardware next. You will want to be intimately familiar with this as that is what you will be limited by, the limits will hit you hard as well (if the Switch, which is considerably more powerful, is having issues and slowdowns then yeah), though the DS (which is less than the 3ds) did see Quake 2 (released after Mario 64) and an official port of Mario 64 itself so there is that. Or shorter version is you are going to want to be able to make the 3ds hardware sing.
http://problemkaputt.de/gbatek.htm is mostly known for the GBA and DS but has DSi and 3ds these days as well. https://www.3dbrew.org/wiki/Main_Page is also good stuff.
I am not sure what problems you will face both going from N64 to 3ds and with the code in question as well.
Generally we tend to find the handhelds are pretty weak and won't have much in the way of support for things like floating point (which the N64 and mario do make extensive use of*), at least to the point where you can't just basically go all floats all the time and will want to be a bit sparing with them.
Looking around it seems graphical output is kind of there but you will probably have to optimise that one, and controls being redirected was done for the PC (and then Switch) so there is that.
You may also be faced with decisions about converting things to be in formats more akin to what the 3ds
*see the various qpu, speedrun explanations and a press run type videos for more on that one
3ds C compilers are mostly https://devkitpro.org/wiki/Getting_Started (the devkitarm component of it) so you will also get to learn how it works, or learn to write your own libraries to handle things (a possibility if you don't want to convert things to be more close to it).
Any one of those you could probably spend a lifetime mastering, and people do. Combining all three has some overlaps but not as many as you might thing.
Even if you somehow gained this overnight or over a few weekends... which you most likely won't -- this sort of thing is usually what otherwise very smart and motivated people spend a long time in school to just about scratch the surface of, and said schools won't tend to teach old school embedded hardware like the devices in question, the sorts of coding used in games and mario above, and maybe if you are lucky as modern phones are usually also arm devices you might get a tiny bit of insight there compared to some things some years ago. I have seen people make serious inroads into this sort of thing in about a year (schools do have an awful habit of padding stuff out and ultimately don't mean all that much), though they usually come from a background amenable to it (high end maths, electrical engineering, high end physics, sometimes other engineering type backgrounds, maybe some existing background in computing or game hacking...).
But anyway even if you did it would take an accomplished coder with all the skills already on lock (a rare combination) probably some considerable time (few months full time maybe, weekends and evenings longer still) to get it all dialled in here. At which point you now have a portable version of an old game you could have played a dozen other ways far better on a very long in the tooth console with a middling homebrew scene, not able to really release or collaborate on the source code (it is anything but open source or clean room reverse engineered after all) and not able to release the binaries as anything more than a nudge, nudge, wink, wink type scenario.[/url]
Fixed point calculations would ruin graphics accuracy, and graphics would look really bad. That's why floating point calclations is used on graphics.
In the sense of "speed calculations", yes its faster, but as said before, it doesn't mean faster is better (not on this case), if that was, then fixed point calculations would be used instead of floating point calculations on computer graphics.
That's the main reason why graphics cards are way faster that processors calculating polygons and their geometrical transformations, they are specialized hardware, just like the math coprocessor was on the early days.
Similar threads
- Poll
- Question
