#N64 recompiled

[therealbosszombie]

Zelda 64: Recompiled for PC - Majora's Mask

Zelda 64: Recompiled is a project that uses N64: Recompiled to statically recompile Majora's Mask (and soon Ocarina of Time) into a native port with many new features and enhancements. This project uses RT64 as the rendering engine to provide some of these enhancements.

Play Majora's Mask natively on PC! Download here for Windows or Linux:

Note: Project does not include game assets. Original game is required to play.

Features:

Plug and Play

Simply provide your copy of the North American version of the game in the main menu and start playing! This project will automatically load assets from the provided copy, so there is no need to go through a separate extraction step or build the game yourself. Other versions of the game may be supported in the future.

Fully Intact N64 Effects

A lot of care was put into RT64 to make sure all graphical effects were rendered exactly as they did originally on the N64. No workarounds or "hacks" were made to replicate these effects, with the only modifications to them being made for enhancement purposes such as widescreen support. This includes framebuffer effects like the grayscale cutscenes and the Deku bubble projectile, depth effects like the lens of truth, decals such as shadows or impact textures, accurate lighting, shading effects like the fire arrows and bomb explosions, and various textures that are often rendered incorrectly.

Easy-to-Use Menus

Gameplay settings, graphics settings, input mappings, and audio settings can all be configured with the in-game config menu. The menus can all be used with mouse, controller, or keyboard for maximum convenience.

High Framerate Support

Play at any framerate you want thanks to functionality provided by RT64! Game objects and terrain, texture scrolling, screen effects, and most HUD elements are all rendered at high framerates. By default, this project is configured to run at your monitor's refresh rate. You can also play at the original framerate of the game if you prefer. Changing framerate has no effect on gameplay.

Note: External framerate limiters (such as the NVIDIA Control Panel) are known to potentially cause problems, so if you notice any stuttering then turn them off and use the manual framerate slider in the in-game graphics menu instead.

Widescreen and Ultrawide Support

Any aspect ratio is supported, with most effects modded to work correctly in widescreen. The HUD can also be positioned at 16:9 when using ultrawide aspect ratios if preferred.

Note: Some animation quirks can be seen at the edges of the screen in certain cutscenes when using very wide aspect ratios.

Gyro Aim

When playing with a supported controller, first-person items such as the bow can be aimed with your controller's gyro sensor. This includes (but is not limited to) controllers such as the Dualshock 4, Dualsense, Switch Pro, and most third party Switch controllers (such as the 8BitDo Pro 2 in Switch mode).

Note: Gamepad mappers such as BetterJoy or DS4Windows may intercept gyro data and prevent the game from receiving it. Most controllers are natively supported, so turning gamepad mappers off is recommended if you want to use gyro.

Autosaving

Never worry about losing progress if your power goes out thanks to autosaving! The autosave system is designed to respect Majora's Mask's original save system and maintain the intention of owl saves by triggering automatically and replacing the previous autosave or owl save. However, if you'd still rather play with the untouched save system, simply turn off autosaving in the ingame menu.

Low Input Lag

This project has been optimized to have as little input lag as possible, making the game feel more responsive than ever!

Instant Load Times

Saving and loading files, going from place to place, and pausing all happen in the blink of an eye thanks to the game running natively on modern hardware.

Linux and Steam Deck Support

A Linux binary is available for playing on most up-to-date distros, including on the Steam Deck.

To play on Steam Deck, extract the Linux build onto your deck. Then, in desktop mode, right click the Zelda64Recompiled executable file and select "Add to Steam" as shown. From there, you can return to Gaming mode and configure the controls as needed. See the Steam Deck gyro aim FAQ section for more detailed instructions.

System Requirements:

A GPU supporting Direct3D 12.0 (Shader Model 6) or Vulkan 1.2 is required to run this project (GeForce GT 630, Radeon HD 7750, or Intel HD 510 (Skylake) and newer).

A CPU supporting the AVX instruction set is also required (Intel Core 2000 series or AMD Bulldozer and newer).

Planned Features:

Dual analog control scheme (with analog camera)

Configurable deadzone and analog stick sensitivity

Ocarina of Time support

Mod support and Randomizer

Texture Packs

Model Replacements

Ray Tracing (via RT64)

[loonastarlivht]

when a banjo kazooie pc port / recompilation comes out i am playing that immediately, i love banjo kazooie so muchhh

[truthdealsandcoupons]

(via Zelda 64 Recompiled: Relive the Classics in Stunning HD - shop today online)

[clownkiwi]

okay a bit of a spoiler for wednesdays stream. i was gonna try out that n64 recompiler thing and make a native pc port for banjo, but i have no idea how anything works. i think i'll just wait until that banjo decomp is done, which also means no native pc banjo stream </3

[tap-tap-tap-im-in]

As a counterpoint to my other recent thoughts about video games, it's a really interesting time to enjoy games.

Yesterday I spent a few hours playing some emulators of old Zelda games. Specifically Twilight Princess from the GameCube, and Majora's Mask from the N64. Both games I was playing at 60fps for vastly different and incredibly cool reasons.

Let's hit Twilight Princess first. Because I structure essays not unlike food bloggers, that of course means a little introspective anecdote about the game and what it means to me; Twilight Princess came out while I was in High School. I'd been loaned a copy of Wind Waker by a friend in Junior High and it was the first Zelda game I'd ever beaten. I adore WW's soundtrack to this day. When I was moving out of the state, a good friend of mine who'd shared a love of the game, gave me his copy of Wind Waker and Twilight Princess (which had just recently come out), so my recollection of the game is beating it on an old 60s era CRT in my bedroom the summer before my Junior year of highschool started. The game has a lot of themes of balancing an old (often decaying) world against a new literally forcing its way into the old, which seemed hugely appropriate.

But for the sake of this discussion, since I played on a very old CRT (turn nobs rather than buttons mind, had to plug the GameCube into an adapter connected by screws to the antenna input old), late at night, the game has a twofold sort of soft focus filter over it. The normal CRT fuzz, the very tactile sensation of adjusting the adapter to resolve fuzz, and the classic nostalgia filter over it all. It's my opinion that the game is beautiful, hugely limited by the capabilities of the GameCube, but has absolutely fantastic art direction and artistic use of those limitations, so I've always been fascinated by emulating it to increase the resolution and poke at the edges of that artistry to better understand how it comes together (and what elements are dependent on analog artifacts like the use of CRTs).

So I love replaying and poking and prodding this game. But these days it's easier than it's ever been with the Dolphin Vulkan renderer, and then a few weeks ago I learned about a piece of software called Lossless Scaling: https://store.steampowered.com/app/993090/Lossless_Scaling/

This is an application that can replace any scaling within Windows with one of several upscaling techniques, including the AI trained ones from the GPU manufacturers, which is interesting in its own right, but it also allows arbitrary frame generation for any application using the Windows window API (anything not exclusive full screen). Which is hugely interesting. It's not perfect, but absolutely fascinating to be able to suddenly play Twilight Princess at 60 frames per second. It has the limitations of frame generation everywhere, it doesn't increase input response (in fact it slightly increases latency), it works best with already high framerates to give your eyes less time to see artifacts, and with only limited data points it shows more artifacts when items are moving quickly and/or entering and leaving the frame. That said, super interesting.

But arguably far more interesting is Majora's Mask 64. If you hadn't heard yet, an intrepid developer has created a tool to fully recompile N64 code into valid C code. This means native ports of N64 games can be generated just from ROM dumps. The tool requires additional Meta data and tweaks that are hard for the average user to implement, but a native PC port of Majora's Mask has already been created: https://github.com/Zelda64Recomp/Zelda64Recomp. This port enables high frame rates (the game was originally limited to 20 frames per second, and had severe performance issues on the N64), high resolutions, custom control binds, and they are all looking to add features like texture replacement and ray tracing soon (as well as support for OoT). All of this is without the overhead of having to emulate an N64, so it performs amazingly. I beat OoT on the GameCube collectors edition a couple of years after beating Twilight Princess, but never made it past beating the first temple in Majora's Mask, so this experience is fully new to me, and directly addresses the issue I had with the game. OoT was also 20 fps, but it was far more consistent about it so you could get used to it, but the performance issues with Majora's Mask made it painful to play after being introduced to Zelda via the 30fps GameCube era games. It's bringing what's widely considered an absolute classic to a completely new generation, and because it requires a valid ROM file to run, it's completely above board as far as current US copyright laws and therefore unlikely to get shutdown by Nintendo's lawyers.

In fact, if Nintendo follows their own habits, this tooling may very well mean that future releases of N64 games on modern platforms like the Switch have vastly improved feature sets, high resolution, wide-screen support, better framerates, purely because they can utilize the underlying code to enhance those ports and make them much more quickly and with less effort (though Nintendo would have to walk a legal tightrope of their own around the GPL 3 license the code is released under, as derivative works must themselves retain the GPL 3 license, but that's not stopped them in the past).

So, it's a really interesting time to be in the hobby, not because of what any corporation is doing, but because organize groups of fascinated people are doing incredibly cool work.

[derekscorner]

Wake up Zelda and PC gamers, they’ve found a way to make N64 games true ports rather than emulation.

Majora’s Mask is full recompiled already!

[liminalitycarb]

Majora's Mask: Recompiled (5/17/2024)

A new thing in N64 Emulation came out recently. So we're giving it a spin and starting Zelda: Majora's Mask Recompiled!

(Stream starts at 7pm EDT). https://twitch.tv/LiminalityCarb

[gbatemp-net]

Unreleased "Dinosaur Planet" N64 game by Rare gets an initial recompilation port using N64 Recompiled

ICYMI: https://gbatemp.net/threads/unreleased-dinosaur-planet-n64-game-by-rare-gets-an-initial-recompilation-port-using-n64-recompiled.670742/

[cavenewstimestoday]

N64 Recompiled Is Planning Its Best Year Yet In 2025

Unofficial PC ports to get mods & performance boosts by Alana Hagues Mon 31st Mar 2025 Image: Zion Grassl / Nintendo Life By this point, you’re probably well aware of N64 Recompiled which, in basic terms, allows N64 games to be played on PC by natively running the game’s code on your target platform. Most recently, we’ve seen Majora’s Mask get a “PC port” thanks to the project. And it sounds…

[gumi-megpoidd]

despite being a sonic fan myself im horrified of the community because just last year game recompilations/decompilations were limited to like n64 era games and took quite some time

and then like 2 days ago some motherfuckers just drop an entire recompilation-based pc port of a xbox 360 sonic game because this fandom was annoyed from waiting for an official pc port of the game out of literally fucking nowhere

no announcements about working on it or anything just dropped the entire full thing like it wasnt some gigantic fucking leap in game recompilation efforts???? what is wrong with these people i thought it was fake until it dawned on me that no. motherfuckers actually did that. recompiled a full fucking xbox 360 game while everyone else was on the n64 level

wild

[therealbosszombie]

Zelda 64: Recompiled - Majora's Mask

Everyone, look at why my brother made!

[dadgamerhq]

Banjo-Kazooie N64 Decompiled: PC Ports and Shenanigans Ahoy!

THE CODE CAN NOW BE USED TO SPRUCE THINGS UP A BIT!

Hold onto your Jiggies, folks! Banjo-Kazooie for the Nintendo 64 has officially been decompiled, meaning PC ports of the beloved classic could soon be a reality. Thanks to the eagle-eyed efforts of X user @BringBackBanjoK (clearly a person of taste), we now know that the fan-driven decompilation project has hit the 100% mark. That’s right – all the code has been meticulously reverse-engineered, turning it from Nintendo’s ancient sorcery into lovely, legible C code. In layman's terms? We’re one step closer to firing up Banjo and Kazooie on our PCs.

What’s All This Decompilation Malarkey About?

Good question! Decompilation is the process of taking the original code from the N64 game and converting it into something modern developers can tinker with – in this case, C code. Once that's done, you can compile it back into a working game, except now it’s not bound to your dusty old console. It’s ready for all the modding mischief you can dream up on PC. And speaking of modding, the possibilities are endless. We’re talking fancy new features like smoother frame rates, ultra-wide screen support, 4K resolutions, and even ray tracing. Yes, you read that right – Banjo and Kazooie, in glorious 4K with shiny reflections. If that doesn’t make your feathers ruffle, I don’t know what will.

But Wait, There’s a Catch!

Now, before you start dusting off your keyboard in excitement, there’s a little caveat. Should a PC port pop up, you’ll need to supply your own *legally-sourced* N64 ROM of Banjo-Kazooie. The clever software will then pull all the assets (like character models, audio, and textures) from your ROM, mix it with the decompiled code, and voilà – Banjo on your PC. Easy peasy, right? Why the legal hoops? Well, reverse engineering projects like this are generally considered above board because the developers aren’t using any dodgy leaked content or copyrighted assets. It’s a bit of a legal tightrope walk, but so far, it’s been enough to keep the big N’s lawyers at bay. Fingers crossed!

It’s Not All Jiggies and Jinjos

In May, a nifty tool called *N64: Recompiled* made its debut, claiming to automatically convert N64 binaries into C code in record time – much faster than full-blown decompilation projects like Banjo’s. Sounds great, right? Well, there’s a catch. The tool’s creator, Nerrel, warns that while it’s quick, it’s far from perfect. The automated process tends to throw a spanner in the works when dealing with things like the lightning-fast speeds of modern hardware, meaning manual fixes are often needed. So, while it’s a handy shortcut, proper, fan-driven decompilation projects like this one for Banjo-Kazooie tend to be more accurate and reliable. After all, if you’re going to take on Gruntilda, you want everything running like clockwork!

Conclusion

In summary: Banjo-Kazooie has been decompiled, and PC ports are now a tantalising possibility. Expect better graphics, wider screens, and maybe even a touch of ray tracing. But remember, keep it legal, and brace yourself for all-new adventures with Banjo, Kazooie, and the gang. Now, who’s up for some Mumbo Jumbo on the PC?

Read the full article

[maximuswolf]

The Legend of Zelda: Majoras Mask

The Legend of Zelda: Majoras Mask Man idek where to really post this, but if you haven't tried the new majoras mask recompiler then you definitely should. Ive been looking for years for the best way to play n64 zeldas on PC. Ive tried all of the n64 emulators. Ive tried 3ds emulators with the 3ds remakes of the game. And ive tried dolphin with the collectors edition (this one up until now was the best) but holy fuck this new recompiler blows all of them out of the water. If you're looking for a way to relive majoras mask on PC then google "majoras mask recompiler" and click the github link. Its absolutely amazing. High FPS, high resolution, AA, and all the other good shit to truly enjoy one of the best zelda titles in high fps high resolution fantasticness. Thanks for listening to my ted talk. Submitted May 28, 2024 at 02:32PM by sopedound https://ift.tt/76KPtL9 via /r/gaming

[luigiblood]

Nintendo 64 Switch Online - The infodump

Nintendo 64 - Nintendo Switch Online is a DISAPPOINTMENT.

I haven't ran out of things to say, good and bad. Some games look worse than on Wii Virtual Console, the input lag is apparently worse than Mario 64 in 3D All-Stars in some games...

But if you want more information on the quality of emulation, check out Modern Vintage Gamer's video on the topic: https://www.youtube.com/watch?v=jSyBMSOfPxg

I will not talk about the quality of graphics emulation in this post, but rather some of the other technical aspects of it.

Prediction Results

First things first, I actually predicted some of it correctly. Nintendo does offer you ways to play the PAL versions of games for language accessibility, which is a good thing. The American & European apps are also indeed the same one, meaning that Americans can actually play the PAL versions if they desire to.

I just didn't expect that they would be seperate (optional) PAL box arts on the game selection screen, which is going to look very weird once we get 5 Pokémon Snap box arts for every language when that gets out there.

The Nintendo 64 controller also works with other Switch games, but I didn't expect the C Buttons to be actually mapped to the right stick outside of the N64 app, that's honestly a good touch.

But now let's go deeper into the app itself.

Technical Stuff

Now, the emulator inside the Nintendo 64 app is actually very much like the one from 3D All-Stars, functioning in almost every way the same, meaning the base work from iQue is very much like probably 80% of the app and work to make games working, except it is codenamed Hovercraft, which makes me suspect NERD was actually involved in this but very probably in a much less obvious way.

First of all, every game definitely contain a lot of files (archived within two bnz and dtz files), compressed this time. Those files work almost identically to 3D All-Stars, there's a JIT (Just In Time) for code recompilation in real time, but then there's also a NRO file for every game with what looks like AOT (Ahead Of Time) recompilation, which means the emulator doesn't have to actually worry about recompilation most of the time for performance. The JIT might be useful in case there are parts of code that were ignored in the AOT recompilation process.

Exemple from Winback: Covert Operations, see Assembly code from the game and its decompiled AOT equivalent from the NRO file:

There are a few files that I don't necessarily understand at the moment, but Lua scripts are making a comeback for every single game, allowing finetuned more complicated game hacks to help the game code run correctly (which from a standpoint of code only, not graphics, seems to be doing the job just fine).

Some games do use Lua scripts abundantly like Ocarina of Time, where it makes sure to fix heap based glitches (by making malloc fail for actor mapping, for the technical explanation), we originally thought it was for avoiding exploits, but a similar fix was done for Yoshi's Story's malloc code. I am unsure why it is the case.

An exemple of Ocarina of Time Lua scripting:

RPT files are also making a comeback, RPT files are replacement textures for games, and there's oddly more of them than it used to be. Sin & Punishment's english translation rely completely on these textures as the base ROM used is an unmodified Japanese ROM.

Ocarina of Time also has a lot of them, Winback has a few, some others as well.

Games also have lots of game specific rendering hacks in their configuration files, of many kinds.

Various Hidden Stuff

When it comes to hidden features, here's a few of them that got my attention. They're not necessarily brand new for the Switch Online app.

First of all, I did look at the 64DD emulation code, it is identical to 3D All-Stars, which was already pretty much identical to Wii U Virtual Console, meaning the 64DD emulation was left untouched from last time and still unplayable. This is disappointing as this does not give me hopes for F-Zero X Expansion Kit ever appearing. FFS Nintendo.

The configuration files also supports PAL, but also PAL60, meaning PAL games running at 60hz. Mind you this is only useful when the game is adapted for this, but the feature seems to exist at least.

Another feature is Controller Pak support, it is fully functional, which makes it even more baffling how Winback does not support it, as Lua scripts definitely shows that every game have been reverse engineered in some way, which should have allowed automatic ways to swap Controller Pak and Rumble Pak as needed.

N64 Transfer Pak support is seen but in reality, the only code for it is simply to power it on or off, not much to do with I'm afraid.

MondoMega has touched on this on Twitter, but there's indeed potentially 38 N64 games that are already supported by the developers. ID N-3038 is none other than Ocarina of Time and is the highest ID of them. I do not want to give a lot of hopes, because supported games do not necessarily release in the future, as there are lots of gaps for NES, SNES and Genesis that have still yet to be filled.

Lost potential

So what I see inside the emulator is technically promising stuff, there's a bunch of cool features that can actually help emulation and also improve games, I dare say there's enough to do translations for games in ways that don't necessarily need a lot of work of reprogramming and hacking the original ROM for it which is nice.

There should even be enough for Lua scripts to actually automatically swap Controller Pak and Rumble Pak as needed for Winback. Save states are NOT supposed to be THE way to save for games, only an alternative, this fact annoys me a lot as I originally thought Nintendo strived for authenticity, but not here.

Mario Tennis still doesn't have Transfer Pak features unlocked either (and they're no small feature), this is sad.

Since I don't see completed 64DD emulation code either, no F-Zero X Expansion Kit coming, which like, for fuck's sake, we deserve it now.

To me, this attempt feels like the bare minimum. It was fine for NES and SNES in my personal experience, but as always Nintendo does not show any ounce of real interest in preserving their games the best they can, and always making sure that people like us to be annoyed by their lack of effort at times.

I don't even ask them to improve their games (I personally think almost all N64 games in HD look like shit), but at least to respect them; the Dark Link room in Ocarina of Time is honestly bad and unacceptable.

I heard of framerate/audio performance issues at times, which is super odd, I was told a theory that maybe Nintendo 64 emulation was for a more powerful Switch but I just don't buy it, it mostly worked fine on Wii and Wii U, how come the Switch, being more powerful than the Wii U, fail?

They even use Vulkan for extra performance, make sure to use AOT NRO files, precompiled shaders and other pipeline things.

My guess is this... maybe the team didn't have enough time, but this is still odd that this passed their QA. It's functional, but still, they deserve better.

So complain about it to Nintendo, please make sure they understand, and don't put your money on the Expansion Pack, for me it feels like a ripoff even more because this is a premium service at this point, we deserve better, their online is still not super great (though I heard something is on the pipeline for next year...), but like, holy fuck Nintendo.

[pokefan531]

Legacy AMD APU Llano Laptop for Emulation tests - Part 3

A6-3420m CPU Emulation performance

I wanted to test my laptop's APU for performance test on emulation. To recap, it is AMD's first gen APU that the CPU is based on Phenom K10 CPUs, except having boost. It is unlocked so you can overclock it with a software. By default, the A6-3420m is a quad core 1.5Ghz cpu with boost to 2.4Ghz on one core. Boost was new so it helps a little. Overclocking brings some programs significant jump. From being a weak CPU to a decent one for emulation is an interesting story. The first gen Llano APUs are all unlocked, and are the few exceptions to overclock your laptop without being an actual risk. It came out in 2011, and seeing the first gen APUs in action should be surprising. They're weak from the start, but offers decent GPU performance, and I'm offering both stock and overclocked benchmarks here for each emulator.

Benchmarks:         A6-3420m 1.5Ghz-2.4Ghz and OC A6-3420m 2.3Ghz-2.8Ghz All tests are using the lowest non stutter FPS on the exact scene for a while to see how it performs and to see how to avoid sound stuttering to have smooth experience. Retroarch is on some of the benchmark and is using DX11 as main on windows, and OpenGL for Linux and for hardware rendering. Standalone hardware rendering based emulator is preferred (ex. Standalone Flycast vs Libretro's Flycast, Standalone Mupen64Plus vs Libretro Mupen64Plus). Testing a 3D emulator is best with DirectX on Windows most of the time, and OpenGL for the rest or on Linux. Mesa drivers are the fastest and offers better compatibility. GPU bottleneck is not an issue by using native resolution without any shaders or anti-aliasing applied. The lowest FPS of a heavy game is a way to see which Emulator you could generally use. Note, if a specific system hardware or emulator to emulate one most demanding game doesn’t go fullspeed, doesn’t mean you can’t use the emulator for general good performance. BSNES’s demanding games for the CPU are three rare ST018 games. You may not play one game that is only demanding, but to see how many other popular titles perform. Some emulators may not play a demanding game due to compatibility or development issue. It’s a good way to see how good of a performance you would get to use it generally. Having over 60fps is a great way to have smooth experience and to throw any or most games without any problem.

NES: Mesen-Stock:       Megaman 2 Intro                        82.0 (100.0) Mesen-Very-High-OC:Megaman 2 Intro                        48.0 (59.5) Nestopia UE works very well and very light. Mesen by default performs fine at stock. For virtual overclocking, only the CPU overclock can barely perform. However, it's best to use Nestopia UE for those features, as well as using Runahead feature for lower input latency.

SMS/GG/Genesis/CD/32x: Genesis-GX-Nuked:  Virtua Racing Demos (MAME OPN2 / Nuked OPN2)                        118.0 (154.0) / 75.0 (93.0) The Genesis GX Plus core is too efficient to find any issue, and it is the most accurate currently and it was made for GC and Wii. Virtua Racing is the only demanding title since it uses SVP chip for 3D rendering. While it performs good, the Nuked OPN2 audio was added for more accurate sound. It seems to perform great, I suggest using MAME for fast forwarding, especially Runahead feature. 32x Virtua Racing runs around four times the fullspeed on Picodrive. I haven't tested it on Fusion yet, but assuming it will run at fullspeed.

SNES: SNES9x:            Super Mario RPG                        116.0 (163.0) Bsnes-v110 fast:   Super Mario RPG                        50.0 (63.0)                   ST018 Game                        36.0 (47.0) Higan:             ST018 Game                        21.0 (29.0) Bsnes-HD-Mode7:    Super Mario Kart 1x (2x) Testing the new Bsnes or BSNES-HD core performs really fine. Non-chip games works fullspeed out of the box. Games with Super FX2 chip or SA-1 chip are a bit demanding, and they are below fullspeed with CPU in stock. With overclocking, they are barely above 60fps. Super Mario RPG uses SA-1 chip. It would stay smooth and may not encounter small slowdowns. The most demanding games are the ones that uses ST010 DSP4 chip. Only three Japanese games use it, so they aren't common. However, they won't play at fullspeed, regardless. Higan an be used on Bsnes Standalone if you turn off all special fast features. Generally, it's best to use Bsnes since Higan's performance isn't there at all for the CPU. I also suggest the newest Bsnes standalone or HD core over any Bsnes forks you find from Retroarch. I haven’t tested the Super FX overclocking feature. I recommend the main SNES9X if you want to fast forward and use Retroarch’s Runahead for less latency, especially paired with overclocking for SA1 games. HD side on Bsnes is also tested. Using Super Mario Kart and playing the demos, and the game has DSP1 chip. On any game with Mode7, it is not fullspeed at 2x at stock CPU. For overclocking, it generally performs smooth on most Mode7 games. With Super Mario Kart, since it has an external chip, it is slightly demanding, that it goes down to almost below fullspeed. For a long test, I do get 59fps at the lowest I got, but it generally plays at fullspeed. 2x with overclocked APU should be good, as long as you don't use 2x on other games that has more demanding chip games than any DSP games.

Virtual Boy: Simple, perfect performance, regardless of hard sync.

Sega Saturn: Yaba Sanshiro is the best emulator you can use on the APU. You can enable frameskip to get the best performance as much as possible. Some parts of any games may go a bit below fullspeed, but the audio is async, so it may not be as noticable, as long as the CPU is overclocked.

PlayStation: Beetle-PSX Core:   Crash Team Racing (Interpreter / Max Perfprmance 1024 DMA)                        36.0 (45.0) / 47.0 (54.0) Mednafen:          Crash Team Racing                        41.0 (57.0) PCSX-Rearmed:      Crash Team Racing (Interpeter / Dyanmic) 57.0 (71.0) / 61.0 (81.0) PCSX-R PGXP:       Crash Team Racing (Vanilla / PGXP MEMORY + CPU 1.5x) ~85.0 (~115.0) / ~60.0 (~85.0) These are four emulators tested for the laptop and each has its own story. Beetle PSX Core from Retroarch is based on Mednafen. I am testing with the new dynamic recompiler on performance mode and most games should work with it. While the performance is noticably faster than standard interpreter, it is only more playable with overclocked CPU to barely have any lag, at least in software. Hardware rendering is quite slower on this laptop. I don't know exactly why it's slower than software, even using Linux with Mesa Drivers, but it still hits really similar speed when comparing interpreter and dynamic. If you want to do hardware with higher resolution and PGXP, use PCSX-R fork. With Crash Team Racing intro and test the ice bear scene, that's the part where I found the slowest point. Even with that, dynamic at max performance with software and host CPU overclock gives best results. Although, the interpreter on beetle is kinda slower than Mednafen and beetle is a fork of it. Mednafen is a multicore emulator, and I used its PSX emulator that is the most accurate. Without frameskip for full mesaurements, Mednafen is faster than Beetle core. Somehow, overclocking your CPU brings the performance up dramatically. It is pretty close to 60fps on few spots on CTR demos, but fullspeed on a lot of areas. It's unbelievable for standalone Mednafen to be faster then Retroarch core that you may use this for faithful emulation. Although, you can turn on frameskip for full emulation performance, I recommend not having frameskip for good response. Somehow, Mednafen doesn't use CPU boost clock for me, but still shows it's faster than Beetle core. Another Retroarch core is PCSX-Rearmed. In the last few years, we do have it for x86 and x64 PCs. It uses less accurate interpreter and Pete's Software for performance. On stock CPU, the performance reaches fullsleed most of the time, but you can encounter minor slowdown, but it's not that below. With Overclock, it reaches fullspeed on all areas of testing. Like Mednafen, it renders at 1x. Recently, we got dynamic recompiler for x86, x64, and Arm64. It made PCSX-Rearmed run at fullspeed without overclocking the CPU. For a 1x resolution, this emulator is preferred over the other two for performance. PCSX-R PGXP is a really good emulator and performs excellent. You can use Pete's OpenGL for Linux and OpenGL2 2.9 Tweak version for Windows. Pete's OpenGL 1.78 on Linux is more reliable than Windows version and just as fast as OpenGL2 2.9 tweak when using full framebuffer settings. Only difference are that OpenGL 2.9 allows shaders and xBR upscaling on textures. Both Pete's OpenGL 1.78 and OpenGL2 2.9 Tweak offers PGXP capabilities, so you should see very great polygon rendering. Only PGXP Memory for the CPU are usable with fullspeed. Combining PGXP memory and internal CPU overclock at 1.5x gets you slightly above fullspeed. Overclocking your CPU should bring more relief for fullspeed on any games. The Linux drivers, despite performing better than official drivers from AMD for OpenGL, it performs the same. Only one downside with r600g drivers at the moment on any video plugin is the lighting on Spyro on some areas, but they are minor, not severe. Regardless, you should have great experience on PCSX-R PGXP. Although, neither of the builds use .CHD iso files. I did test Windows PCSX-R PGXP on Wine, and while I was able to use OGL2 Tweak and get the same performance as Windows, I do have problems with the audio plugins and Xaudio2 driver. I do recommend finding PGXP Linux Build for easier setup. It's available as a PPA and AUR build.

N64: Angrylion Plus with Project64 using internal LLE mode plays at half the speed or lower mostly. This is gonna be a long explanation about this laptop hardware and drivers. In short, you can play many N64 games with pretty great accuracy without the use of Angrylion. However, it is a mess on Windows side. I've tested many video plugins. Windows 10 updates seems to make things a bit slower. Rice plugins are all over the place, and many of them have problems. GLN64 is not as good. Jabo's D3D8 1.6.1 is the fastest you would get. Glide64 and GlideN64 are bottlenecked by AMD OpenGL drivers, meaning that it's slower. Glide64's performance is mediocre. I tried using nGlide, and it helps a bit, it's still doesn't solve the lag on some games, mainly Quake 2 demos that's used as a test to see if the lag is present. Jabo's is the fastest, and only has minor lag because of Windows 10 updates. GlideN64 is really slow, even turning off framebuffer at 240p. It's a driver issue, and overclocking the CPU didn't help much. Quake 2 demo lag was few frames per second. I would've test Windows 7 since the laptop was made for it, but I no longer have it since 2016. Mupen64plus is slightly slower, since all plugins use OpenGL. Let's jump into Linux. This is unbelievable! I use Mesa Drivers and downloaded Mupen64Plus and got GlideN64 4.0. I tested Quake 2 demos, and by default, it's much faster than almost every plugin I tried on Windows. I overclocked the CPU, and turn off Depth Buffer to RDRAM with non-noticable regression, and it goes from minor lag to none! I bumped up the resolution and no lag is present at all. I do however set Framebuffer mode to VI origin to use less GPU usage on high resolutions. GlideN64 is really fast on Linux on this laptop. Even 3-point filtering finally works on my laptop. I recommend using standalone Mupen64Plus for Linux since it's faster. On Retroarch on Mupen64Plus-Next, I still have minor lag with the same settings. To get the easiest way to have mupen64plus with GlideN64 bundled, search M64p.

Dreamcast: Redream is the fastest emulator you can use for the CPU. It works fine at CPU stock. Reicast's fork, Flycast, is more compatible with games, but is more demanding. Even with CPU overclocking and turn off few accurate settings, it is a bit below fullspeed. On my drivers, I do have sprite glitch on Marvel Vs Capcom on Redream. It was tested on Linux, but on Windows, the performance may worsen due to dated drivers and poor OpenGL drivers.

GBA: mGBA:              Mermaid Melody PPPP Menu 141.0 VBA-Next:          Mermaid Melody PPPP Menu 126.0 VBA-M:             Mermaid Melody PPPP Menu 127.0 Plays very fine. mGBA is newer and more accurate than VBA emulators. VBA-M is the slowest generally. VBA-Next is sometimes close to mGBA's speed and sometimes by VBA-M's speed. Even when using bios and disable remove idle as shown, mGBA offers better performance.

NDS: Desmume 0.9.11+:   Pokemon Black2/White2 Title Screen (No Frameskip / Frameskip 9)                        33.0 (40.0) / 60.0+ (80.0+) MelonDS 0.83:      Pokemon Black2/White2 Title Screen (OpenGL 1x / Jit Recompiler)                        20.0 (29.0) / 00.0 (42.0) I’m testing two emulators for measurements. I'm using a jit command on Desmume Linux build for full performance. On Windows, it has OpenGL renderer, but Software is the fastest, so that's why I'm using software rendering on Desmume. I'm testing a demanding area on Pokemon B2W2. Without frameskip, you would get almost down to half fullspeed. With overclocking, you would get a bit more performance. With frameskip at max, I get fullspeed. Although, I suggest using lower frameskip, like one or two. On a lot of games, it may not need that much frameskip, generally. It performs fine on other games that have less demanding scenes. It's probably better for overclocked CPU since you can lower frameskip by one. On MelonDS, since it has an OpenGL renderer, I decide to test it myself. As a result, I get below half the speed at stock clocks. On Overclock, I get about half the speed, so it's the interpreter CPU that is the bottleneck. With beta ready Jit recompiler with default settings for pre-0.9 release, I do see some increase. It slightly passes Desmume without frameskip. However, some games will run near fullspeed and others at fullspeed. Not much has been tested for high internal resolution or other games. Your last choice to get better performance to games that are in the first 2/3 of the DS life cycle, No$GBA is your choice. It is fast and you can use Nocash or OpenGL renderer. Although, Wine has problems with OpenGL that it crashes wine. The nocash is faster and No$GBA is the fastest option while being really least accurate, like you can hear the audio have noisy sounds on couple of games, and it has problems playing Pokemon Gen 5 games. (Note!) I heard Drasic DS is gonna go Open Source after it has AARCH64 ARMv8 dynamic recompiler implemented. It is faster than Desmume that you can run it on an android emulator at fullspeed. It may not be that easy to set up since it's payware and using an emulator, but it does perform well. Although it does have a slight input lag, it still considerable for emulated Drastic DS. I haven't test it yet. Dev is working on x86-64 and x86 builds and will be out once the emulator goes free.

GameCube/Wii: Dolphin x64:       Soul Caliber 2                        36.0 (45.0) Soul Caliber 2 runs fine. At some parts, you can encounter a little slowdown. With big effects that happens during fighting, I see 3/4 of performance with overclock. Some games may play fine though, at least with overclocking. Make sure you run at 1x with async shaders, not using ubershaders. You won't play any heavier titles though. You can play with the virtual overclock options and you may set it to half the speed or quarter for some games.

PS2: While it runs at least, even with overclocking, a lot of games runs slower that it's not a recommended system to use PS2 emulators. At best, you stick with DX11 on Windows or OpenGL on Linux for PCSX2. Pushing speed to very aggressive may be appropriate for certain games that can run decently or almost fullspeed, but those are lighter titles.

PSP: PPSSPP:            God of War 37.0 (48.6) It runs games completely fine. Only demanding game is God of War. You can encounter slowdown on certain parts of the game. You can solve it by only setting the CPU clock to 222mhz on the option specifically for GOW. The game isn't constantly slow or majority of the time, it's just it has slowdowns sometimes, and goes fullspeed on other times. If God of War only has slowdowns on many enemies with the performance given above, you won't at least encounter slowdowns on the rest of PSP titles.

3DS: On overclocking too, I couldn't generally get Pokemon games to play at fullspeed on needed amount of times. It goes lower than fullspeed on battles, somewhat lower on overworld, and a bit lower than half the speed on double battle or battle royale. A lot of 3DS games runs generally slow. They barely reach fullspeed, even overclocking the CPU. Citra won't run fast enough for this system.

Dosbox: From any Dosbox builds I use as explained from previous page, it runs the dynamic recompiler fine. It reaches commonly around above near late 486 performance, around 24000. With overclock, it goes up around 36000, equivalent to 486DX4-100Mhz. Although, some 486-pentium era games are able to use more cycles without slowing down the emulator. On Interpreter, it runs around 12000, equivalent to 486DX-33Mhz. With overclock, you go to around 18000, equivalent to 486DX2-50Mhz. I do recommend Dosbox ECE, or finding Dosbox builds that has patches, and is 32bit build since 32bit dynamic recompiler is robust.

PCEM: It can run any 386 processors. 486, it can run on any SX ones pretty fine. However for DX, let's get into it. 486DX-25mhz can run fine at stock as an interpreter. Interpreter seems more constant on speed than dynamic recompiler. With Overclock, it can use DX-33mhz pretty good as an interpreter. Dynamic Recompiler is a way to get good performance for emulated CPUs and go higher, but on places like Windows 95, sometimes windows being on idle or loading things on Windows can bring the performance down a bit than expected. It can go above the targeted interpreters, but dynamic is better used on DOS mode on this laptop. On stock, it can go up to 486DX-40, and with overclock, it can go up to 486DX2-50. I use DBOPL on sound blaster setting to get a little more performance for the CPUs. The laptop can't go any higher to use Pentium CPUs, and using 3DFX Voodoo hasn't been tested, but I recommend using threads of 2 since the host CPU has four cores.

Recommended Emulators: NES: Nestopia UE SMS/GG/Genesis: Genesis GX Plus SNES: Snes9x PSX: PCSX-R PGXP, PCSX-Rearmed N64: Mupen64Plus (Gliden64, Linux), Project64 (Jabo's, Windows) Saturn: Yaba Sanshiro Dreamcast: ReDream GC/Wii: Dolphin GB/GBC: Sameboy GBA: mGBA NDS: Desmume 0.9.11+ PSP: PPSSPP PCEM: 486DX 25Mhz/40Mhz DOS: Dosbox ECE

Recommended emulators are listed as usable. If a system or emulator is not listed, it either that it won’t be playable due to speed, not past playable yet, or too fast enough to play (Stella, Atari 2600). The emulators on the list are recommended for general use. This is using stock settings on most emulators listed. Also, lighter games will perform faster, and you can toggle more settings for those games, like Runahead.

If any of you know what are the most demanding games for GBA, Saturn, Dreamcast, or DOS, let me know and comment.

Using AMD cards on OpenGL Emulators: On Windows, you can only use official AMD drivers. It runs pretty fine for DirectX stuff, but for OpenGL, a lot of OpenGL programs runs slower and sometimes broken. OpenGL drivers are not really optimized, and since Terascale GPUs aren't supported for at least four years as of this writing, you may not get to use newer OpenGL emulators or updates, even though you feel it should be more capable than how it performs. Even worse, first few generations of AMD APUs have short lifespan for graphic drivers from AMD, and Windows 10 can make things a bit slower than using the first version or using Windows 7. Again, Terascale GPUs will not have Vulkan support on any drivers.

Using Linux with Mesa Drivers, r600g: I tested OpenGL emulators on few distros with Mesa drivers. It does perform almost as good as Nvidia’s OpenGL drivers. On GlideN64, all the slowdowns on Quake 2 are gone. I don’t have that problem on Linux. The Mesa drivers are much more reliable, even if there very few errors I explained above, it's still very much stable and efficient. Trust me, it's far better than Windows.

Since we covered the CPU performance for emulators, we'll test out GPU performance of Radeon HD 6520g on the next page.

Next Page on GPU emulation performance.

Previous Page on software and emulators use.

[eggman-is-fat-mkay]

alright listen, okay, compilers are hard

back in ye olden times, circa 80s and early 90s, CPUs were pretty slow, but they were deterministic. out of order execution, superscalar, hyperthreading, none of that had been invented yet. they also didn't have operating systems that could run multiple programs at the same time. heck some of em didn't have operating systems at all. your code was the only thing running on the hardware.

turns out it's a LOT easier to optimize when you know exactly how the CPU will behave under any given set of circumstances. when you know for a fact that there's no other code running that could interrupt you. when you know for a fact what the end user's hardware configuration will be, and exactly, down to the nanosecond, how long the CPU takes to execute one instruction. when a single person can easily understand every single detail of how the computer works and what all of the different instructions hardware registers do. since you know for a fact that no code other than yours is talking to the hardware at any given moment, you can do cool tricks like sending a command to the graphics chip at the exact right moment in the middle of a frame to change the sprite table and double the number of sprites you could show on screen at once.

none of that is possible anymore. the MOS 6502 CPU has 56 unique instructions and the complete spec doc is under 40 pages that you can read in an hour or two. the instruction set document alone for a modern intel CPU -- just the list of all the different operations the CPU can perform and what they do, nothing about the hardware -- is over 2,500 pages. making matters worse, different instructions take different amounts of time to execute, depending on the make and model of the CPU, its current temperature, operating system, what other programs are running, and the phase of the moon. one approach will be 20% faster than another on an Intel CPU and twice as slow on an AMD. worse still, graphics chips are completely proprietary now. NVidia and AMD refuse to publish documents detailing how their chips work internally for fear their competitors will copy them, making it impossible for anyone but them to write a driver for it. games have to talk to the hardware through this driver which sometimes lies about what features the underlying hardware supports to maintain backwards compatibility. and when the exact same game engine (Unity) has to run on everything from a top of the line gaming PC to a smartwatch with minimal or no changes to the game itself beyond being recompiled for different targets (basically just a button the developer pushes when they're already done), it becomes acceptable to sacrifice some performance for cross-platform compatibility. and since modern graphics APIs like Vulkan are almost impossible for developers who don't want to do full-time development on a game engine to directly use, using a pre-made engine like Unity or UnrealEngine is basically a necessity if you want to do any sort of 3D anything.

as for programmers breaking the laws of physics to get games to run where they shouldn't, they absolutely still do -- check out this demake of Portal to the N64, for example. they just do it where it's possible to do it.

2D indie games are so easy to make (from a computational perspective, at least) that most of them don't use hardware acceleration at all. they do ALL of the rendering on the CPU and then send the completed frame to the graphics card to be displayed, because CPUs are that fast now. That would absolutely not have flown in the 16 bit era. Indie devs aren't magically better at optimizing than AAA studios -- they're just doing orders of magnitude less, and the performance of their game scales accordingly. Solo indie developer Bethany Esda absolutely could not make an open world game in her basement without borrowing a premade game engine (either by making a Unity game or by making a total conversion mod for a game like Skyrim), not before her death. it is absolutely true that if crunch culture didn't exist, and project managers didn't get scope creep and gave developers time to finish, we'd see a LOT less of these day one, completely game breaking bugs -- but let's not pretend like that's because AAA developers are bad at their jobs, mkay?

we should globally ban the introduction of more powerful computer hardware for 10-20 years, not as an AI safety thing (though we could frame it as that), but to force programmers to optimize their shit better