61–70 of 182 posts
One thing this could be cool for is games like Goldeneye, which is hard to play on PC because it expects that weird joystick input. It would be awesome to have a native Goldeneye port with normal mouse behaviour like other FPSes.
What's the advantage over an emulator? This is after all, a form of an emulator - one where you translate ahead. This sort of thing has been done in the past with things like Bleem so it can be more performant but on a modern PC any good emulator is going to perform well. https://en.wikipedia.org/wiki/Bleem !
The goal of N64 emulators (generally) is to accurately recreate the behavior of the original console.
Conversely, there is a large crowd of people who just want to play SM64, OOT and MM with a bevy of "graphical enhancements" like 60fps, widescreen, texture packs, randomizers, etc.
For these people, the fact that these games originally ran on the N64 is practically irrelevant. In fact, it's a hindrance; The N64's graphical pipeline is cumbersome to emulate and actively stands in the way of modern 'enhancements.'
This project is more aimed at giving the games themselves modern treatments, removing the N64-centric aspects of the games from the equation entirely.
Earlier quoted context omitted.
WASD with mouse aim control doesn't really work with the game though. The modal aspect of aiming combined with the travel time/return-to-center of the cursor is a really fun part of the game. If you could just free-aim while running a la PC FPS it would kind of ruin the campaign since everything is designed around this. Picking your spots and keeping cool while aiming are the appeal. That said, if you keep the modal…
Weirdly Goldeneye did have a control layout where you could move with one joystick and aim with the other using 2 controllers: https://www.youtube.com/watch?v=dZaEpugk3hY
To operate this tool, you still need to disassemble the ROM up front and annotate it heavily before it can be recompiled. This tool is very nice, to be sure, but the hyperbole about anything close to one-click generation of standalone executables for an arbitrary ROM is getting out of hand.
I saw this when it came out, and as someone that doesn't follow the ROM hacking scene, I'm wondering - why did this approach take so long to come up with? Translating the assembly instructions to C and then recompiling them seems like an obvious method to try early on, but I'm wondering if there was some other breakthrough that made this possible in a way it wasn't before?
Skimming the Github repo, looks like this uses rt64 under the hood for the raytracing support ( https://github.com/rt64/rt64 ), and that uses the ubershader technique to emulate the GPU. This excellent article talks about the what, why, and insanity that are ubershaders: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
To operate this tool, you still need to disassemble the ROM up front and annotate it heavily before it can be recompiled. This tool is very nice, to be sure, but the hyperbole about anything close to one-click generation of standalone executables for an arbitrary ROM is getting out of hand.
Why? Surely it's more straightforward to do binary-to-binary translation. No human input needed!
Isn't Nintendo hunting every one of their fans^H^H^H^H IP abusers with their black helicopters? Why do people even bother when they know they'll get lawyers at their door in 3... 2... 1... ?
This project isn't distributing any of Nintendo's code, game assets, or other intellectual property.
Isn't Nintendo hunting every one of their fans^H^H^H^H IP abusers with their black helicopters? Why do people even bother when they know they'll get lawyers at their door in 3... 2... 1... ?
I would love to play a source-port of arcade “GTI Club”! <3