[HN Gopher] Nearly all Nintendo 64 games can now be recompiled i...
___________________________________________________________________
Nearly all Nintendo 64 games can now be recompiled into native PC
ports
Author : Malic
Score : 284 points
Date : 2024-05-15 12:48 UTC (10 hours ago)
(HTM) web link (www.tomshardware.com)
(TXT) w3m dump (www.tomshardware.com)
| ranger_danger wrote:
| Jamulator did this for NES way back in 2013 but nobody really
| seemed to care...
|
| https://andrewkelley.me/post/jamulator.html
|
| There is also Winlator for running Windows programs on Android:
|
| https://github.com/brunodev85/winlator
|
| Also is the youtube video linked in the article using an AI
| voice?
| BearOso wrote:
| Jamulator was unsuccessful because so much extra hardware was
| on the cartridges. Recompilation complicates things and doesn't
| provide many benefits in that situation.
|
| The N64 is fixed hardware, so it's a little bit easier. Even
| so, this project still uses emulation for the RDP. I don't know
| how it handles generated RSP microcode, maybe it doesn't. A lot
| of games just used the official libraries.
| claudex wrote:
| >Jamulator did this for NES way back in 2013 but nobody really
| seemed to care...
|
| At least Mr WiseGuy seems to care. From the N64Recom Github
| repo[0]: "This is not the first project that uses static
| recompilation on game console binaries. A well known example is
| jamulator, which targets NES binaries."
|
| [0]: https://github.com/Mr-Wiseguy/N64Recomp
| zamadatix wrote:
| Jamulator didn't take it farther than what NES emulators could
| do beyond the way it ran. If Jamulator had released with
| similar enhancements for Zelda it probably would have been a
| lot more popular. I.e. the interest is more from what is now
| available with it than about how it does it.
|
| That's just Nerrel, a real person, narrating. It's crazy (in an
| interesting way, not necessarily a doom and gloom way) how we
| have AI voices these days so good we start to suspect people
| who don't speak like we expect are AI.
| refracture wrote:
| That's just Nerrel; his narration is so flat that he's always
| sounded like an AI. I enjoy that mix with his humor.
| jonhohle wrote:
| This is really cool. Many of the foundational tools created for
| N64 decomp are finding their way into other system decomp
| packages. I recently came across https://decomp.me/ which allows
| collaborative decompilarion for a bunch of systems with presets
| for their relevant SDKs and hardware. I'd imagine this happening
| several more systems in the coming years.
| protoster wrote:
| Do typical emulators compile ahead of time? Just-in-time? If not,
| why? This approach (ahead of time compilation) appears to have
| huge benefits.
| ranger_danger wrote:
| A fair amount of 32-bit and later emulators do have JIT
| recompilation, but I'm not aware of any ahead-of-time
| translation unless that's how TeknoParrot works (you can run
| linux arcade games that use ELF binaries on windows with it for
| example), but I wouldn't call that emulation either way since
| the architecture is the same.
| entropicdrifter wrote:
| Modern Vintage Gamer over on Youtube has worked with
| Nightdive and Limited Run Games and helped design a C
| recompiler called Carbon Engine for various older consoles
| that are functionally the same as ahead of time compiled
| emulators.
|
| https://youtu.be/eZRzaGFWoz8?si=XQyJol0pe2z2oG6d
| jerf wrote:
| You name the compilation and/or interpreter technique and
| there's at least one emulator that uses it.
| chlorion wrote:
| There are lots of emulation methods but interpretation is
| probably(?) the most common or at least very common.
|
| Interpretation involves writing a VM that represents the state
| of various parts of the machine, and executes instructions that
| change the state of the VM, with varying levels of accuracy.
| izzydata wrote:
| I hope this eventually also works for Linux so that N64 games can
| be reliably played on very low end portable handhelds. N64 is
| notoriously tricky to emulate, but building them for the platform
| natively removes all performance problems.
| vaughnegut wrote:
| I watched the youtube video this article links to the other day
| and it mentioned that it supports Linux, specifically
| mentioning that it should be usable on Steam Deck.
| izzydata wrote:
| The steam deck has way more than enough resources to power
| through any and all N64 emulation so that wouldn't change
| much there. I'm specifically talking about something $50
| retro handhelds and the like.
|
| For example Mario64 and Ocarina of Time are completely
| reverse engineered and have native support for Windows and
| Linux and they run perfectly on those systems as where they
| really struggle when trying to emulate.
| vundercind wrote:
| I still get audio pops and glitches with whatever the
| default n64 emulator EmuDeck installs is, on many games. Be
| nice to eliminate that.
| andrewclunn wrote:
| That will likely require full decompilation. This is akin to
| wrapping the emulator up with the rom, with a few common
| functions (found via decompilation) being updated to support
| more modern rendering approaches. This isn't so much "native"
| as it is a patched container in an executable form.
|
| EDIT - But hey, you can always just add another layer of
| emulation via Proton to run it in Linux.
| GaggiX wrote:
| I don't think that's true, it really does recompile the N64
| games into native executables, you can compile them using any
| C compiler like msvc, gcc and clang.
| jjice wrote:
| > N64 is notoriously tricky to emulate
|
| Huh, I wouldn't have expected that. I don't know much about the
| specifics of N64 emulation, but I've had N64 emulators running
| perfectly since the early 2010s. I played mostly the big
| classics, so I'm unfamiliar with more niche title performance.
| LetsGetTechnicl wrote:
| You'd be surprised, even Nintendo doesn't get it perfect
| themselves. When N64 games were first made available on the
| Nintendo Switch Online platform, there were several problems
| with graphical effects and input lag. Here's an MVG video
| from the time: https://www.youtube.com/watch?v=jSyBMSOfPxg
| jjice wrote:
| Haha I remember this launch and how awful it was an
| thinking about how a bunch of fans have done such a better
| job. Hell, even Nintendo did a better job for the Wii's
| Virtual Console.
| LetsGetTechnicl wrote:
| Yeah it's an interesting pattern. Even the GameCube had
| decent N64 emulation early in its lifecycle. But the Wii
| U Virtual Console also had issues with N64 emulation.
| Specifically it added a dark filter for no reason, which
| could be removed with homebrew thankfully. You'd think
| Nintendo would have the best emulation of their own
| systems on their systems, considering how long people
| stick around you probably have people who developed for
| the N64 still there
| jimbobthrowawy wrote:
| Homebrew emulators will almost always work better than
| first-party ones which need to avoid copyleft code, and
| can be content with a small subset of games being
| "playable", or "good enough".
|
| Console makers will often hire lead developers of open
| source emulators to sew something up for them, like what
| was used for the mario 35 collection (part of galaxy was
| recompiled too) or the "ps2 classics" software emulator
| for the ps3.
| 0cf8612b2e1e wrote:
| I think part of the issue is that some purists believe
| anything less than pixel perfect fidelity is unacceptable. I
| recall reading a report on N64(?) Wii(?) about how the flame
| flicker in one level of one game was off.
| tempoponet wrote:
| Any Dolphin progress report will be full of these one-off
| quirks with an exhaustive deep-dive on how the issue was
| diagnosed and solved.
|
| Setting aside the part about purists finding it
| unacceptable, I appreciate the tenacity of the devs that
| find these problems worth solving.
| jezzamon wrote:
| Depends what you're trying to do, but some glitches used in
| speed runs literally depend on the exact values of pixels
| on the screen
|
| https://youtu.be/0B095eHBrCg?t=24m40s
|
| Not saying that supporting glitches like that is a hard
| requirement for these ports though
| jamesgeck0 wrote:
| Inaccurate emulation can also result in stuff like
| altered physics, invisible objects, stuttering
| animations, etc. resulting in a different experience from
| the original.
| grecy wrote:
| Many games were very playable with UltraHLE back in 1999, on
| the hardware of the time (~ Pentium 133 IIRC)
| throwawayben wrote:
| I remember convincing my dad to get a 3dfx voodoo2 because
| I really wanted to run UltraHLE. That was a seriously
| impressive emulator
| mrguyorama wrote:
| The N64 had a fully unified memory architecture, and weird
| custom silicon that also happened to be a fully programmable
| GPU kinda device. For decades, all N64 emulation was done by
| translating calls to that GPU (called the RDP) to openGL or
| DirectX calls, and that works horribly, but anything else
| would have had awful performance. Several years ago however,
| someone decided "Fuck it" and created a fully emulated
| version of the RDP that you could run, ie feed it real N64
| instructions and it spits out pixel values. It was
| significantly slower than the translation approach, so you
| had to have like a powerful 8 or more core CPU to run it
| well.
|
| Some other madlad then took that approach, and ported it to a
| GPU Shader, because fuck yeah thousands of cores! It actually
| greatly improved the situation, as you didn't need a super
| powerful GPU, just a somewhat modern GPU.
|
| That development means devices like the steam deck actually
| have zero issues running awesome N64 emulation, including
| allowing for upscaling to much higher rendering resolutions
| without artifacts because you are literally telling a virtual
| RDP to do it, and it happily complies.
|
| Before AngryLion and ParaLLEl, we were stuck with basically
| the same graphics plugins, glitches, and tweaks as the late
| 90s.
|
| https://www.libretro.com/index.php/category/parallel-n64/ for
| a more detailed description of how this changed things.
| cpressland wrote:
| I'm pretty sure Linux is natively supported via N64Recomp:
| https://github.com/Mr-Wiseguy/N64Recomp
|
| An example of this can be found here: https://github.com/Mr-
| Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
| Fartmancer wrote:
| I tried this out on my Ubuntu PC and it works great. Played it
| for around an hour without any issues.
| xnx wrote:
| Would this recompilation technique be applicable to other systems
| (3DS, GameCube, Wii, etc.)?
| naikrovek wrote:
| In theory it will work for anything, but there is a LOT of work
| that must be done to annotate the binaries on the source
| platform so that tooling such as this can pull it apart and
| reassemble all the pieces into something that works on the
| target platform.
|
| A straight recompilation is one thing, but what this tool does
| is recompile with the target system's apis for input and output
| in mind. A straight recompilation would offer less than an
| emulator, really.
|
| This tool knows (or is told) where rendering routines are, for
| example, so that they can be replaced with destination platform
| versions. That's how higher resolutions and different aspect
| ratios are supported in a recombination.
| vouaobrasil wrote:
| 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.
| wodenokoto wrote:
| Wouldn't it still expect a weird joystick?
| haiku2077 wrote:
| The native ports have additional features, which are easy to
| implement starting from the native compilation. For example,
| the native port of Zelda has gyro aiming and automatic
| autosave options.
| vouaobrasil wrote:
| Well I was hoping there'd be a way to translate mouse input
| into the joystick input in a straightforward way that isn't
| available on emulators.
| haiku2077 wrote:
| It could be done with native mouse control. No joystick
| intermediate- instead modify the C code to allow direct
| control of the player character with a mouse.
| whateveracct wrote:
| 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 aspect and have the mouse just
| 1) rotate Bond like left/right on the stick does and 2) control
| the cursor only in "aim mode" (hit R)..then I think that could
| be fun.
|
| Tbh, I wish shooters didn't go straight to Quake-style
| WASD+mouse free-aim across the board. The modal aspect makes
| gives Goldeneye a certain physicality I really like.
| AlecSchueler wrote:
| You can turn off auto aim in the game though. Always the
| first thing I do.
| anthk wrote:
| Deus Ex has quake controls but you need to focus a little
| before aiming. Then, later you get upgrades and laser
| reticles allowing you to shoot near instantly.
| X0Refraction wrote:
| 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
| GardenLetter27 wrote:
| Yeah, it's awesome as you can set this up relatively easily
| with EmuDeck and play it with the two sticks on the Steam
| Deck.
| hot_gril wrote:
| That's how I played, and while the N64 joysticks aren't
| very good, it was alright. The much bigger problem was lag.
| terramex wrote:
| There is emulator hack for Goldeneye that add WASD + mouse
| support and I heard that it works great.
|
| https://github.com/Graslu/1964GEPD/releases/tag/latest
| hot_gril wrote:
| Something's wrong with it, maybe related to the framerate. I
| can run and shoot a lot faster than before, but enemies take
| just as long as the old version to aim. I was able to beat
| levels on 00 mode with ease, mostly by sprinting past
| enemies.
| ThrowawayTestr wrote:
| The mouse+wasd hack works really well. Also works with Perfect
| Dark.
| skrrtww wrote:
| 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.
| speps wrote:
| Except this work can be done once, stored somewhere and shared.
| Take a ROM (it means read-only after all) and get native port
| out...
| Hamuko wrote:
| Shared legally?
| blindstitch wrote:
| 100% legal if you delete within 24 hours.
| gurchik wrote:
| Source?
| Retr0id wrote:
| That guy's uncle works for Nintendo
| cauefcr wrote:
| True in Brazil, is it true anywhere else?
| TehCorwiz wrote:
| You can share the prepared binary because it contains no
| trace of the rom. The rom is still required to play the
| game.
| GuB-42 wrote:
| I wouldn't count on it, it is still derivative work and I
| am sure the licences for the games forbid this. Some
| companies may let it slide, but Nintendo is known to be
| aggressive about their intellectual property.
|
| And you will probably have a hard time arguing that it
| doesn't promote piracy. You can't get "ROMs" officially.
| You have to extract them from the cartridge with
| specialized equipment, or maybe in some other way, but it
| is not as simple as reading from a CD. It means that most
| people will simply get them from illegal sources. With an
| emulator, you can say it is for "homebrews", but if you
| recompile a commercial game, you can't use this argument.
| immibis wrote:
| Nintendo hasn't been taking down any projects that can't
| work without a ROM input. They'll change that eventually,
| but for now they are not. You can't share a modified ROM
| but you can share binary patches.
| derefr wrote:
| > You can't get "ROMs" officially. You have to extract
| them from the cartridge with specialized equipment, or
| maybe in some other way, but it is not as simple as
| reading from a CD.
|
| Nintendo has, in fact, sold the public ROMs before (and I
| don't just mean custom emulator executables wrapping ROM
| payloads that get delivered encrypted onto DRMed
| consoles.)
|
| Specifically, I'm talking about the NES Classic and SNES
| Classic. These little boxes use multi-image emulators,
| rather than Nintendo's usual approach of a customized
| single-image emulator for each game. And the ROMs used by
| these systems are just sitting there as files on disk.
| The disk isn't encrypted, either; nor is the bootloader
| or kernel integrity-signed; or really anything like that.
| You don't need to "jailbreak" these things -- they act
| like Android phones, where you can just reboot them into
| restore mode and plug them into a computer with a USB
| cable, and see a virtual disk. The "modding tools" for
| them just drop a new kernel with wi-fi support into their
| /boot partition! (And you don't even need to go that far
| to read the ROMs off the rootfs -- any Linux PC will work
| to mount it.) So any DMCA "they used DRM, which means
| their intent was to license you X, not sell you X"
| arguments don't apply. They did _nothing_ to stop people
| from extracting these ROMs.
|
| By buying these systems, you're effectively buying "a box
| full of ROMs" directly from Nintendo (the IP rights-
| holder for said ROMs), at retail, as a "money for goods"
| transaction. So now, by the first-sale doctrine, they're
| _your_ ROMs, and you can do with them as you please.
|
| This is true as surely as buying a DVD box-set means you
| now own those DVDs, and can do with those as you please.
| (Part up and resell the DVDs individually? Sure, why
| not!)
|
| Or -- for perhaps a more interesting example -- as surely
| as buying a stock images or sound-effects library on CD
| (even second-hand!) implicitly brings with it the IP
| rights to use those assets in derivative works you
| create. The primary-market purchaser didn't have to agree
| to any kind of license terms at point of sale? First-sale
| doctrine applies to that IP from then on! (Amusingly,
| Nintendo redistributed exactly such stock-image CD assets
| embedded into Mario 64 -- so their lawyers are double-
| bound to agree that this particular interpretation of
| first-sale doctrine should pertain.)
| MaxBarraclough wrote:
| > it is still derivative work
|
| I don't think that's right, I think it's essentially
| considered the _same_ work under copyright law.
| Apparently compilation doesn 't fulfil the criteria of
| derivative works.
|
| https://opensource.stackexchange.com/a/6435/
| ars wrote:
| A shrinkwrap license is not a real license. The game is
| copyrighted, and fair use applies.
|
| And if you want to avoid the license just steal it from
| someone. You never agreed to a license, but you are still
| required to follow copyright. (I've obviously being a
| little sarcastic, but license agreements on software are
| meaningless, even if a company claims they have meaning.)
| MaxBarraclough wrote:
| > You can share the prepared binary because it contains
| no trace of the rom.
|
| This is wrong. Please do not confidently present your
| guesswork as fact.
|
| If it were true, copyleft would have no chance of
| working; binaries compiled from copyleft-licensed source-
| code would not be subject to the copyleft licence.
| ars wrote:
| It's legal if the recipient owns the game, it would be
| covered under fair use for compatibility purposes.
| keb_ wrote:
| Very true. There is nothing special about this tool at all.
| Nothing to see here folks.
| doublepg23 wrote:
| I don't think that's true. The video in the post shows a no-
| name n64 game being recompiled and running fine. No annotation
| needed.
| amlib wrote:
| The video also makes it clear that only games using a certain
| microcode works for now. I imagine there are many parts of
| HLE emulation that gets added to the recompiled software as
| wrappers and compatibility code to make it all work, so in a
| sense this may be more akin to an embedded emulator into a
| native binary (recompiled code), which can overtime be worked
| on to add new features, fix shortcomings of the original
| software and make it more "ergonomic"/compatible with it's
| new target platform. But such work can only feasibly be
| achieved by reverse engineering the software and giving it
| human readable symbols. In a sense there is almost as much
| work to do as on the previous decompilation projects, but you
| can get results (run the game) right away (or at least much
| faster than traditionally), assuming of course the game uses
| a compatible microcode and isn't doing anything fancy that
| depends on the intrinsics of the n64 architecture.
| christkv wrote:
| I'm guessing it works for the standard Nintendo provided
| microcodes.
| DaiPlusPlus wrote:
| There's also inevitably going to be timing/performance-
| related bugs - the N64's devkit docs say it runs games
| under a thin OS for multi-threading[1] so that's another
| opportunity for things to go wrong.
|
| Also, after conversion these games are still designed and
| hardcoded for an N64 controller and 4:3 aspect-ratio -
| that's hardly "native" as far as PC gamers are concerned.
|
| [1] https://ultra64.ca/files/documentation/online-
| manuals/man/pr...
| lordgilman wrote:
| That operating system is statically linked into the game
| binary.
| slongfield wrote:
| To be fair, N64 is not the PS2 or Gameboy--there are only 388
| games that were released for it. Going through all of the games
| that were released and shepherding them through this process is
| feasible.
| kwanbix wrote:
| And there are probably fewere games that are worth doing.
| Maybe 100? 200?
| tristor wrote:
| I really liked the N64, but if we're being charitable it's
| probably like 30-40 games. For any given console, even
| those that achieve legendary status, the game quality
| follows a Pareto distribution, 80% is crap, 20% is worth
| playing after the console has left the public mind.
| TheGRS wrote:
| What no one wants to revisit Nagano Winter Olympics or
| Tetrisphere? Its probably closer to 50 if you want to
| include some of the lesser-known but interesting titles
| IMO. One of the most interesting games was Body Harvest
| since its clearly a prototype for a lot of what became
| GTA3
| tacker2000 wrote:
| Haha Nagano! I played countless hours of ski jumping with
| my friends back then
| kilburn wrote:
| In fact, Thabeast is beating every N64 game, and he means ALL
| of them. [1]
|
| He has already completed all games, but the videos are waaay
| behind (he's releasing one video/game a week).
|
| [1] https://www.youtube.com/@Thabeast721/videos
| coolmitch wrote:
| if you're interested in this kind of thing, The Mexican
| Runner beat every NES game (over 700 of them [1]) including
| such gems as Miracle Piano Teaching System, which took 91
| hours to beat and required him to become quite proficient
| at actual piano playing [2]
|
| [1] https://docs.google.com/spreadsheets/d/1KDNGI76HoMNyYLL
| 6RqWu... [2] https://youtu.be/PB_LMW72crY?t=3997
| darby_eight wrote:
| > you still need to disassemble the ROM up front and annotate
| it heavily before it can be recompiled.
|
| Why? Surely it's more straightforward to do binary-to-binary
| translation. No human input needed!
| immibis wrote:
| For example, Zelda (both of them) load segments of code from
| the cartridge at runtime. The recompiler needs to know which
| areas contain code, and the original relocation-applying code
| for MIPS instructions obviously won't work on x64
| instructions either, so it needs to know how the relocations
| work.
| ambyra wrote:
| What is the process, and can any of it be chatgpted?
| kkukshtel wrote:
| 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?
| pjc50 wrote:
| Emulating the hardware usually requires cycle-accurate
| emulation of things running in parallel, so it's not quite so
| simple as just the program in the ROM.
| whizzter wrote:
| Yes and no, with the 8bits and probably 16bits like the C64,
| NES, etc you really want cycle accuracy and emulating
| something like the PS2 really well would probably need a fair
| bit of accuracy.
|
| HOWEVER.. writing an recompiler (not feasible for 8bits due
| to the amount of self-mod code) you could probably insert
| pattern checks to detect writes to DMA-starting locations,etc
| (thinking back to our PS2 games) and transform it to safe
| sequences without accurate timing for most games that really
| only would be happy with some extra cycles.
| OnlyMortal wrote:
| Good point about 8bit self modifying code.
|
| The UK C64 disk for "Skate or Die" had copy protection that
| did exactly that, as an example.
| kkukshtel wrote:
| Watching the video, it seems like the explanation is mostly
| "tag the code and transpile to C" - im assuming the tags are
| acting as the hardware-aware part?
| bluedino wrote:
| Are they using self-modifying code or anything else that would
| make this tricky?
| dividuum wrote:
| Really surprised this topic didn't come up anywhere. I
| couldn't find anything in the linked repositories either. I
| guess there's no self-modifying code due to it being mapped
| into the address space from a cartridge?
| lxgr wrote:
| You definitely do need code execution from RAM for high-
| fidelity emulation. How else are people going to implement
| Flappy Bird in Super Mario World? :)
| https://www.youtube.com/watch?v=hB6eY73sLV0
| unleaded wrote:
| Basically every game is written in C on a modern processor
| (MIPS) so i highly doubt it. Maybe some weird homebrew stuff
| like that flappy bird video uses it but emulators tend to
| deal with problems like that by ignoring them (e.g. IIRC
| there is no emulator that can properly run that N64 linux
| port from a few years ago, and there have been plenty of SM64
| glitches that work differently on emulators vs real hardware)
| slongfield wrote:
| The N64 has a GPU, which is not the same as modern GPUs, and
| you need that GPU to render graphics.
|
| 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/
| kkukshtel wrote:
| Was raytracing support necessary to get the compilation
| working to circumvent "normal" GPU calls?
| DCKing wrote:
| Other emulators want to solve the problem generically, and this
| solution doesn't _quite_.
|
| Static recompilation from one machine language to one other
| language is somewhere between extremely difficult to not being
| generally possible in practice [1]. To make recompiling
| something like this properly, you need some help from the
| binaries that make recompilation easier [2] and on top of that
| you need to patch certain things to make this work [3].
|
| Dynamic recompilation doesn't have this problem. It allows you
| to create software you can dump the original binaries+assets
| ("ROMs") in and it will generally emulate it.
|
| There's a lot of confusion about how generic this solution it.
| It's extremely impressive in how much work it saves making
| recompilations/"ports" much easier, and it will be very
| valuable. But it is not able to replace the need for
| traditional emulators.
|
| [1]: https://cs.stackexchange.com/questions/155511/why-is-
| static-...
|
| [2]: N64 game binaries may happen to avoid a bunch of things
| that make general static recompilation hard that help this
| approach, but I don't actually know.
|
| [3]: The Majora's Mask recompilation repository contains a lot
| of handcrafted patches to make it work: https://github.com/Mr-
| Wiseguy/Zelda64Recomp
| anthk wrote:
| I'd love to see this with THPS2 and 3, some games I love but not
| with the 'modern' graphics (PSP/DC and up).
| nottorp wrote:
| 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... ?
| kotaKat wrote:
| Because a few of them will turn and go take a job offer from
| NERD.
|
| https://www.nerd.nintendo.com/files/Secu%20Job%20Offer%20202...
| babypuncher wrote:
| Nintendo doesn't typically go after emulation projects. Yuzu
| was the exception, and there are reasons for that related to
| how the Yuzu team ran their project and distributed it that
| painted a legal target on their back.
|
| This project isn't distributing any of Nintendo's code, game
| assets, or other intellectual property.
| 0xcde4c3db wrote:
| Nintendo has also gone after a handful of specific tools for
| circumventing the Switch encryption, which has led to
| speculation that this push is really about shoring up "Switch
| 2" against existing hacks and emulators being updated (in the
| event that it's substantially the same software platform with
| updated silicon).
| yamazakiwi wrote:
| Nintendo isn't as hard on tracking people emulating older
| systems, emulating their most modern system is where they start
| to get particularly whiny.
| sillysaurusx wrote:
| This isn't true. The smash community has suffered for over a
| decade because Nintendo refuses to let them use emulation for
| melee in tournaments. Any tournament that tries is
| immediately C&D'ed.
| https://youtu.be/fAmidph6QU4?si=wbJvpN6ZhUSxSR17
|
| How anyone has any sympathy or hope for Nintendo not going
| after their users in 2024 is beyond me. This is GameCube era
| games, and they're still litigious.
| yamazakiwi wrote:
| I appreciate you drawing attention to more nintendo beef
| but historically they have cared more about protecting
| copyright for current consoles.
|
| You say the smash community has suffered for a decade
| (dramatic) but they still made Project M on GameCube and
| delisting Dolphin from steam is not that big of a deal. I
| don't need to get into Smash Tournament drama to tell you
| this with certainty and I have all the knowledge and
| history to back up this claim.
|
| I've played Smash competitively for 2 decades and have been
| emulating since 1998 so I know the history better than
| most; my statement was not opinion. I'm not saying they
| absolutely don't care about older emulation but they care
| much more about their bottom line e.g. Yuzu.
| sillysaurusx wrote:
| > historically they have cared more about protecting
| copyright for current consoles.
|
| This is categorically false, and I even linked to
| evidence of it being false in the present day. I don't
| know how you could say this as a smash player, but you're
| acting like they won't come after these people for doing
| what they're doing. In reality it's entirely up to the
| whims of Nintendo.
| yamazakiwi wrote:
| You did not link evidence to my statement being false,
| you posted a Hungrybox video of him complaining about his
| tournament issues he's having with Nintendo. Current
| Smash Tourney problems with Nintendo does not supplant
| Nintendo's history with emulation.
|
| I simply stated Nintendo doesn't care as much, which is
| true, I didn't say "Nintendo absolutely doesn't care and
| won't do anything ever unless it's Switch related." I'm
| uninterested in replying any further since it's not
| getting across that I'm not diminishing the Smash issues,
| it's clear you're passionate and Nintendo are being real
| arseholes for sure.
| elorant wrote:
| dupe https://news.ycombinator.com/item?id=40337009
| djmips wrote:
| 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!
| wmf wrote:
| JIT emulation can cause stutters while AOT should not. The
| difference may not be noticeable now that computers are so much
| faster than the N64.
| ThrowawayTestr wrote:
| Recompilation is not emulation.
| doublepg23 wrote:
| The video shows multiple bugs disappearing when using this
| method vs. emulation.
| skrrtww wrote:
| The goals of this project and the goals of N64 emulation are
| fairly different.
|
| 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.
| hot_gril wrote:
| Honestly SM64 with new graphics in those demo videos looks
| worse than the original game. But Gamecube games running in
| an emulator look amazing because they use a lot more vector
| graphics, which the emu can scale up and apply antialiasing
| to.
|
| What interests me more about recompilation is it can produce
| very efficient binaries instead of having to emulate
| everything. And also makes it easier to add new features.
| deadbabe wrote:
| Would love to play fully ray traced N64 games.
| DrNosferatu wrote:
| Any efforts for other platforms?
|
| I would love to play a source-port of arcade "GTI Club"! <3
| DrNosferatu wrote:
| Any tutorials/step by step guide on why to use these tools and
| perform this from start to finish?
| pipes wrote:
| As an aside, the perfect dark decompile port is really nice to
| play on the steam deck. Not sure why, but the Linux version tends
| to freeze on the villa level. Switching to the windows version
| and using proton works great.
|
| https://github.com/fgsfdsfgs/perfect_dark
| simple10 wrote:
| Super impressive walkthrough video in the article. It does a
| great job of explaining Majora's Mask. Although, it's probably
| glossing over a lot of the upfront technical challenges of using
| it to port games.
| lcnmrn wrote:
| I wish all game executables would be OS agnostic, something
| similar to WebAssembly: GameAssembly. For example you can no
| longer play 32-bit games on new macOS version, neither 32-bit
| Windows games under Wine. It's almost impossible to find 64-bit
| .exe files so they can run under fine under Wine/Crossover.
| lupusreal wrote:
| The JVM does this pretty well for Minecraft. I doubt Minecraft
| would support Linux, the BSDs, etc without it. Bedrock edition
| (the not-JVM version which supports Windows and
| consoles/phones) doesn't even support MacOS even though it
| obviously could.
| hot_gril wrote:
| If Minecraft were a Microsoft product from the start, they
| probably wouldn't have made the Java version compatible with
| Mac or Linux (even though it uses JVM, there are some natives
| included), or wouldn't have made a Java version to begin
| with.
| pjerem wrote:
| Also it's pretty ironic that Microsoft, who wants to
| convince the entire world that c#/netcore is the next
| multi-os platform isn't capable of delivering anything else
| than Minecraft Java on Linux.
|
| It's a shame that I can't play with my son from my Linux PC
| since he plays on switch (so the c#/bedrock edition)
| neonsunset wrote:
| Bedrock edition is written in C++ and does not use C#.
| pjerem wrote:
| Oh, didn't know that, thanks !
| neonsunset wrote:
| If it were, targeting all platforms would have been
| fairly easy (assuming it would still rely on OpenGL),
| sometimes just specifying RID e.g. `linux-arm64`.
| lupusreal wrote:
| > _It's a shame that I can't play with my son from my
| Linux PC since he plays on switch (so the c# /bedrock
| edition)_
|
| There are some plugins for the java edition server that
| allow bedrock clients to join, that might be an option
| for you.
| pjerem wrote:
| Oh nice ! I'll check that !
| hot_gril wrote:
| It doesn't work in Wine? Or maybe that's too annoying to
| deal with.
| jamesgeck0 wrote:
| The PC version of Bedrock edition is only available from
| the relatively locked down Microsoft Store.
| hot_gril wrote:
| Ah, game over
| pjerem wrote:
| No it doesn't. It's a UWP app with DRMs everywhere.
|
| Although there is an unofficial Linux launcher capable of
| running Bedrock natively using the embedded machine code
| in the Android version but it requires to buy the game
| one more time from the Google play store.
| treyd wrote:
| CIL is kinda like this for games implemented heavily in C#.
| hot_gril wrote:
| I was able to run 32-bit Windows games in Wine on Mac, even on
| Apple Silicon. GTA IV on my M1 mini. There's some kind of "32
| on 64" emulation built into whatever version of the 32-bit Wine
| that PlayOnMac installs. Impossible to Google so idk how it
| really works.
|
| It's funny how the Mac is more compatible with old Windows
| programs than old Mac programs.
| josefx wrote:
| Old windows programs had the luck that intel fucked up
| Itanium, which left us with AMDs idea to just take the
| existing 16 bit compatible 32 bit processor and turn it into
| a 32 bit compatible 64 bit processor (that might also be 16
| bit compatible, not sure on that one). As result new and old
| windows programs use a lot of the same basic instructs and
| emulating the newer programs includes a lot of the work
| needed to also emulate the older ones.
| kbolino wrote:
| Modern x86-64 processors are still capable of running
| 16-bit code but, assuming you want to do it from within a
| modern operating system, it needs to be 16-bit protected-
| mode code, which isn't that useful since I think most
| 16-bit games run in real mode. Hence why DOSbox/Bochs are
| used instead (also, for emulating the original
| sound/graphics hardware).
|
| AFAIK, no 64-bit version of Windows ever shipped with
| native 16-bit support, though. That means 16-bit support on
| x86-64 in practice was only ever usable on a 32-bit
| operating system, which means you still couldn't have
| 64-bit, 32-bit, and 16-bit code running side-by-side, even
| if the hardware could theoretically support it.
|
| Intel _does_ want to get rid of most of the compatibility
| modes, including all 16-bit support, but they haven 't done
| it yet: https://www.intel.com/content/www/us/en/developer/a
| rticles/t...
| lambertsimnel wrote:
| I agree with your sentiment, but I've had satisfactory results
| running 32-bit Windows games on x86_64 Linux
|
| On Debian, I found I had to run dpkg --add-
| architecture i386 && apt-get update
|
| and then install the wine32 package
| neonsunset wrote:
| .NET would probably be as close as you can get given it allows
| you to have portable assemblies with pointers, structs and simd
| code which is very relevant to games.
|
| It models statically-typed compiled languages in a much
| superior way to WASM, there are projects showcasing how well
| e.g. Rust maps to it[0], and C++/CLI existed for a long time
| (although it's not cross-platform, and is considered cursed).
|
| C and C++ could be mapped in a perfect manner to IL and then
| AOT compiled in ways that GraalVM's Truffle can only dream of
| (given that .NET exposes a very wide set of intrinsics allowing
| _a lot_ of code to be ported that way).
|
| [0] https://github.com/FractalFir/rustc_codegen_clr
| angra_mainyu wrote:
| Funnily enough, I think Windows might just be it.
|
| Wine (+ Steam's Proton) works incredibly well these days, a
| huge improvement from the old days when barely anything ran,
| and what did run required heavy tweaking or even custom
| compilation.
|
| On Linux, my Steam library of about 300 games runs almost in
| its entirety without issues (except for Last Epoch).
| codedokode wrote:
| It is not enough to provide portable machine code to make games
| portable, there are lot of different APIs that games need:
| graphics API, windows API, input API, sound API, disk API and
| so on. Sometimes they need kernel modules for anti-cheat and
| anti-piracy features.
|
| What saddens me is that open-source OSes do not want to provide
| a common set of APIs so that the developer only has to write
| and test the code once and it works everywhere. There is
| flatpak, but as I understand, it doesn't provide a set of APIs,
| it simply packs a Linux distribution into a virtual machine
| without any specifications or documentation. So ugly, and no
| compatibility for smaller non-Linux OSes.
| lxgr wrote:
| The code running on the CPU is arguably the smaller problem
| when it comes to games: At least for consoles, they're often
| depending on very low-level GPU implementation details,
| especially for older titles and platform exclusives.
|
| Older consoles had even more dedicated chips doing relevant
| stuff other than "simple" I/O, like e.g. the SNES's sound chip,
| which was a completely independent CPU running its own little
| programs in parallel with the CPU and GPU.
|
| Of course you could "mandate" a high-level VM for all future
| game development, but given the static nature of console
| hardware specs, that wouldn't be competitive for titles wanting
| to make use of cutting-edge graphics.
| tombert wrote:
| This is pretty neat; can someone tell me if this could lead to a
| proper working version of Conker on the MiSTer? E.g. could this
| be used to assist in a decompilation and then someone could make
| a fix?
| theyinwhy wrote:
| Any suggestion for a high quality n64 controller compatible with
| windows or linux? The official one touts "Switch only".
| mikestew wrote:
| I'm wondering if a wireless Xbox controller would work. It's
| what I use with Apple TV without issue. Button layout is close
| enough (runs to living room to compare Xbox controller to
| Switch Pro...), in fact they're basically identical.
|
| OTOH, I haven't tried the Switch Pro controller with anything
| else but a Switch, so maybe it can be made to work? (EDIT: just
| tried it: my Mac connects to the Switch Pro via BT, haven't
| actually tried it, 'cuz damned work is in the way.)
| haiku2077 wrote:
| It would but the N64 controller's layout is unique and it's
| more intuitive to play games on the original controller.
| mikestew wrote:
| Thanks for the correction. Of course as someone without an
| N64, I went with "sure, that Dvorak keyboard will be
| recognized!" without checking if it's actually fit for
| purpose.
| haiku2077 wrote:
| 8BitDo sells a kit to modify an original N64 controller into a
| wireless controller with a modern Hall effect joystick.
| Rychard wrote:
| I use the N64 controller with my PC, it's available for
| purchase by anyone who subscribes to NSO. It connects via
| bluetooth (the USB connection is for charging only).
|
| https://www.nintendo.com/us/store/products/nintendo-64-contr...
| rcarmo wrote:
| Nintendo is probably having kittens about now. Extremely
| impressive.
___________________________________________________________________
(page generated 2024-05-15 23:01 UTC)