YouTube’s ‘CryZENx’ has released a brand new fan remake of Super Mario 64 in Unreal Engine 4. This time, CryZENx has recreated Cool Cool Mountain in Unreal Engine 4, and has made this remake available for download. Now I know that some people don’t like CryZENx but let us tell you that this...
It needs Python 3.6+, so I had to update the version in codeblocks (so 3.8.something now, to be release soon-ish).
After that it build quite easily. I changed a bit Makefile and SDL init to start fullscreen and build with regular Pandora flags and it works quite nicely. I used gl4es (but that was optionnal, there is gles2 renderer, but that doesn't change much anyway, it's the exact same shaders taht are used).
It play at roughly 30fps (us version, gpu is the limiting factor here it seems), fullscreen and widescreen enabled...
Of course I cannot publish any PND with that, but once I pused the update codeblocks, I put here the diff so anyone can build a Pandora version for themself to try...
Yes, I think it's limited to 30fps, with from memory certain parts like where you can stretch Mario's face on the start screen running noticeably slower, but it's a pretty steady 30 in game. The only 60fps N64 game I have I think is F-Zero X.
Of course I cannot publish any PND with that, but once I pused the update codeblocks, I put here the diff so anyone can build a Pandora version for themself to try...
You are correct. The OpenGL version is capped at 30 FPS. The DirectX 12 version, however, is uncapped. So you need to use another program to limit it to 30FPS to play it correctly (unless you run the OpenGL version instead)
The only other differences I could see between these two are:
1. At the start up. After the Super Mario 64 screen, the Direct X 12 version goes to the stretchable Mario face (like it does on the real N64). The OpenGL version is missing the face. Instead it displays gameplay demos with PC port text superimposed over the top.
2. The DirectX 12 version goes full screen with Alt + Enter. The OpenGL version doesn't have this option. (You can maximise the window to fill the screen but it is still windowed)
Talking of frame rate, Kaze Emanuar once made a rom hack that would allow Super Mario 64 to run at 60 FPS.
Of course I cannot publish any PND with that, but once I pused the update codeblocks, I put here the diff so anyone can build a Pandora version for themself to try...
I for one am extremely interested to see what the outcomes will be of this leak. But not for the reason that one might expect that I would be.
Sure, I would love to see vast improvements made in emulation of the Gamecube, Wii and - most importantly - the Nintendo64 (Thanks to the Dolphin team, GameCube and Wii emulation have been in a pretty sweet spot for a while now. It's N64 emulation that is in need of help). But I doubt that it will happen. Emulator developers will not look at the leaked material to avoid any legal complications.
What will probably happen eventually is N64 clones.
What Nintendo should do to counter this move is to give up their stubborn stance against creating a Nintendo64 Mini Classic and release an official product first. I assume their reluctance to date has been due to several factors: price/consumer value perception, product quality, licensing issues and Switch promotion.
Price/Consumer Value Perception = Nintendo could easily make a N64 classic but it would not be as cheap to produce as the NES and SNES minis. The N64 controller is more sophisticated than the SNES dogbone mainly due to the analogue stick. Would the replica controllers include the RumblePak? Built-in rumble or removable? If removable - What about the MemoryPak? TransferPak? Would the replica controllers be made backwards compatible with the original hardware addons so consumers can use their original MemoryPaks? To include two full-sized replica controllers would increase the box size which I believe is a consideration for retail stores in their return on shelf space. At an uneducated guess, I would hazard that the N64 mini could be done but with a RRP double the SNES mini. At this point, it would be more expensive than the original Nintendo64 was at time of release! While Nintendo has a strong fanbase, you would expect to see criticism that it is a lot of money to pay for a remake of a console that is almost 25 years old!
Product Quality = The NES mini and SNES mini sold well. Nintendo under-estimated the demand upon their releases creating widespread shortages and scalping. However while casual gamers complained about the length of the controller cords, hardcore gamers noted emulation issues. The N64 is notoriously hard to emulate. The alternative would be to create a system on a chip but that would be significantly more expensive than the emulation route.
Licensing issues = The biggest draw of Nintendo consoles is their game library filled with exclusives. The N64 was home to several of the greatest games of all time: Super Mario 64, The Legend of Zelda: Ocarina of Time, Goldeneye 007. Except this one cant be included. The fact it was developed by Rare who are now owned by Microsoft is unimportant. That could be worked out - look at the SNES mini including Donkey Kong Country. The problem is the 007 license. If it were possible to resolve this, we would have had received an official remake before now instead of the lacklustre 2010 "reimagining" which had next to nothing in common with the original game. Sure there were many other games on the N64 which would be obvious choices for inclusion - Super Mario Kart, most of Rare's games (I say most because I figure that Nintendo would aim to keep an official release PG. So that would be a No for Killer Instinct Gold & Perfect Dark in addition to Goldeneye) and so on. But the N64 mini wouldn't be the same without Goldeneye.
Promote the Switch = Nintendo would prefer that gamers purchase the Switch and then pay for emulated N64 games from Switch Online (coming soon) Instead of getting one-off sales of a mini console, they would prefer that gamers driven by nostalgia will repurchase their N64 library again which would net them much bigger sales overall. (And potentially cause more gamers to purchase a Switch leading to more potential purchases ongoing)
TL;DR - I hope the upshot is that Nintendo releases an official N64 mini classic. It would be an insta-buy for me. Realistically, Nintendo will probably fail to grasp this opportunity. If so, I will be holding out for a hardware clone!
I have had an idea to get this released sooner.You already have a working port on your Pandora, yes? I accept you can not upload this PND as-is. However. Are you familiar with the concept of translation patches for roms? Translators cant upload a fully translated rom without risking copyright infringement. So they bypass any issue by uploading a patch instead. The patch doesn't contain any copyrighted material, only the changes between the input and output file. Gamers can download the patch and use a program to apply the patch to their dumped game to end up with an exact copy of the translated version.
What do you think about this idea? You could use a program to easily create a patch between the input (an untouched Super Mario 64 rom) and the output (Super Mario 64 Pandora PND) and upload the patch to these boards. If you like my idea, I would be happy to help you with the various patch formats and programs available.
Greetings ptitSeb, how is the Super Mario 64 Pandora port progressing?
I'm not sure if you saw my previous post suggestion re creating a patch. Uploading a delta patch would mean that Pandora owners can try the port immediately. What do you think?
Yeah, I saw your previous post, but in fact, this is already how the source port works: it contains no copyrigthed material but need the rom to build. I will not try to create a patch from the binary, I will simply gives the source patch and you will be abble to build it yourself, with your own rom version.
I wanted to push pandora patch upstream, but then I found the process to submit a patch too heavy for me and I just switched to something else.
I have attached my current diff.
Using latest codeblocks, clone the original sm64pc git repo, apply the patch ("path -p1 -N -i pandora.diff") and follow instructions of the repo, using "TARGET_PANDORA=1" to build the pandora version.
Happy compiling.
Well yes I do know that's how the source port works. The reason I asked about a patch is because this method would allow rapid deployment for you and fast + simple apply on the user end.
I will not try to create a patch from the binary, I will simply gives the source patch and you will be abble to build it yourself, with your own rom version.
Thanks for uploading that. At least others will be able to try this out on their Pandoras.
(I wont be able to because I cant compile! I'm not a real programmer. I mean I know SQL and a few scripting languages but that's all. I'm cursed when it comes to compiling. I've never managed to compile anything! I've tried compiling different projects using different compilers and different computers and I've never got anything to work ever. I even tried out the Super Mario 64 PC port GUI builder today which in effect automates the entire compilation for newbs. And that didn't work for me either!)
(Whereas rom patches are simple. I'm heavily into emulation and love using fan translations to play games never released outside of Japan. There are several tools out there where you use a GUI to point to the rom and then to the patch file and press the button. Too easy.)
Off topic - Super Mario 64 PC port now has some interesting mods built for it (with more on the way)
Check out this youtube video of Super Mario 64 PC port being played in HD. Uses a high poly model for Mario and HD retextures (My guess would be they are the 16x AI upscaled retextures)
I've compiled it on my Pandora with the latest head from sm64ex and ptitSeb's patch (manually applied). It's working but it's getting a lot of slowdowns. As soon as I enter the first level (bob-omb battlefield) the game slows down to crawl.
I expected better performances from a native port, I might have missed some optimisation settings in the build...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
arstechnica.com
www.dsogaming.com
www.videogameschronicle.com
github.com
