141–150 of 182 posts
Earlier quoted context omitted.
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)
Bedrock edition is written in C++ and does not use C#.
Earlier quoted context omitted.
You can share the prepared binary because it contains no trace of the rom. The rom is still required to play the game.
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…
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.)
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... ?
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.
Earlier quoted context omitted.
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.
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
Earlier quoted context omitted.
Are they using self-modifying code or anything else that would make this tricky?
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?
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.
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.
Earlier quoted context omitted.
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…
> 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.
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.
Earlier quoted context omitted.
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…
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/onl…
Earlier quoted context omitted.
> 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.
Many games were very playable with UltraHLE back in 1999, on the hardware of the time (~ Pentium 133 IIRC)