Emulation central - recommendations in 1st post

[Puukko]

I feel like at this point you could do a doctoral dissertation on these shaders, or at least a 4 hour video essay. An absurd number of settings, many of which I have no idea what they even do.

I've mostly been trying to get the curvature right, and the reflections subdued enough. I wonder if this counts as raytracing.

As a side note, I recently got my first set of dedicated speakers in a very long time (cheap Edifiers) and man, the FF6 soundtrack is bliss. I can just sit at the inn or overworld, chilling. Who even needs to make progress?

 

[Ezekiel]

Is there a way to not make Ryujinx take insanely long to unpack/pack and update the 12,000 shaders every time I open Tears of the Kingdom?

 

[soutaiseiriron]

no
welcome to PSO shaders, it sucks, i love it

 

[AndyS]

Interesting development in N64 emulation: static recompilation of roms, starting with Majora's Mask. I can't claim to understand it how it works, something about instantly converting the rom to an .exe, but I did download it and play it for a short while and it was really impressive in terms of the game running so smoothly with higher widescreen resolution. It would be nice to see this extended across the whole library. One of my pet peeves is that the Aki wrestling games are among my favorite N64 games but even the best emulators still have serious timing issues with those.

https://github.com/Mr-Wiseguy/Zelda64Recomp

 

[pakoito]

It's a bytecode-to-C transpiler, with some extra code for input and window management. Seems obvious in retrospect that it could be the best approach to playing old games, rather than emulation. It's closer to how modern emus like Yuzu worked, once the games started shipping using mainstream CPU/GPU architectures.

 

[Odoryuk]

Seems obvious in retrospect

I'm not entirely sure if it's so simple and it's just a coincedence that nobody thought of that before

 

[Rincewind]

It's a bytecode-to-C transpiler, with some extra code for input and window management. Seems obvious in retrospect that it could be the best approach to playing old games, rather than emulation. It's closer to how modern emus like Yuzu worked, once the games started shipping using mainstream CPU/GPU architectures.

Huh, but what's the point? Why not just do it at runtime with a JIT? Many emulators have been doing that for ages.

What's the selling point here? Getting rid of the JIT overhead? Or doing extra optimisations at compile time that couldn't be done with a JIT in real-time?

I would think barring the JIT overhead, the JIT approach is superior as there is more room for "context dependent" optimisations at run-time. Some times of optimisation opportunities are just impossible by doing static analysis. Plus if the JIT runs threaded, any supposed performance overheads are moot? (Given the CPU emulation code most likely needs to run on a single thread anyway.)

But then, I'm not exactly an expert in this area.

I kinda got interested in this, and found this old topic in the PCSX2 forum:
https://forums.pcsx2.net/Thread-Static-Recompilation?page=4

Basically, they're saying what I'd instinctively think, namely that nope, this is hogwash and a runtime JIT is king.

 

[Nutmeg]

What's the selling point here?

He is explaining things poorly perhaps because he doesn't quite understand but basically what he is enamored with is using the combination of decompilation and API wrappers or polyfilling as the basis for native-PC ports (e.g. the Majora's Mask project he cites is exactly that).

 

[Rincewind]

What's the selling point here?

He is explaining things poorly perhaps because he doesn't quite understand but basically what he is enamored with is using the combination of decompilation and API wrappers or polyfilling as the basis for native-PC ports (e.g. the Majora's Mask project he cites is exactly that).

Ok, cool.

I still don't get it what the fuss is about. From https://github.com/Mr-Wiseguy/N64Recomp:

N64: Recompiled is a tool to statically recompile N64 binaries into C code that can be compiled for any platform. This can be used for ports or tools as well as for simulating behaviors significantly faster than interpreters or dynamic recompilation can. More widely, it can be used in any context where you want to run some part of an N64 binary in a standalone environment.

Significantly faster how? Numbers, stats, or it didn't happen.

I'm very skeptical about the approach, and I have a feeling he's not doing honest apples to apples comparisons when he claims these huge JIT vs static recompilation differences.

I also find the prospect of distributing recompiled stuff instead of the actual bit perfect game dumps that you can run in a proper emulator also a bit depressing (I'm viewing this from a preservation angle).

 

[Nutmeg]

I also find the prospect of distributing recompiled stuff instead of the actual bit perfect game dumps that you can run in a proper emulator is also a bit depressing.

Think of these as akin to source ports for PC games (e.g. eduke32 or DarkPlaces), which is essentially what these projects are. Both source ports and actual emulation and things in between have their place.

 

[Hirato]

Seems obvious in retrospect

I'm not entirely sure if it's so simple and it's just a coincedence that nobody thought of that before

People have.

There are many issues however, one being "Self-modifying code" which is fairly typical of SNES/N64 era games.
This is a writeup from an attempt someone made back in 2013.
https://andrewkelley.me/post/jamulator.html


EDIT As an aside, RPCS3's primary means of functioning is by recompiling the code into native x86_64 code, albeit by still executing everything within a virtual environment it controls and dictates.

 

[Rincewind]

EDIT As an aside, RPCS3's primary means of functioning is by recompiling the code into native x86_64 code, albeit by still executing everything within a virtual environment it controls and dictates.

Yeah, and again, certain kinds of optimisations that are possible in dynamic recompilers (JITs) are impossible or extremely hard in static compilers/recompilers. Hence my skepticism for the approach.

Plus yeah, all sorts of weird low level tricks throw a spanner in the works. Plus the practicality angle, this is not a very good approach with home computer emulators, but can work with consoles where you just have a fixed static set of ROM files.

WinUAE, Basilisk II, DOSBox, etc. have had dynamic recompilers for ages.

We have separate x86_64, ARM, and PPC dynamic recompilers in DOSBox Staging, for instance

 

[Nifft Batuff]

The important thing is to make Nintendo butthurt.

 

[Odoryuk]

The important thing is to make Nintendo butthurt.

Do they even have the means to stop people emulating their old games they don't make money from when people emulate their newest games earlier than people play them on actual Switch console?

 

[Hirato]

EDIT As an aside, RPCS3's primary means of functioning is by recompiling the code into native x86_64 code, albeit by still executing everything within a virtual environment it controls and dictates.

Yeah, and again, certain kinds of optimisations that are possible in dynamic recompilers (JITs) are impossible or extremely hard in static compilers/recompilers. Hence my skepticism for the approach.

I was more just using it as an example where the static compilation method has been used to good success (likely due to a lack of nasty low level tricks being common).
Dynamic recompilation is by far the more compatible method, and that was the conclusion of that writeup from 2013.

 

[Rincewind]

Ok, I got it now what it is. It's not well-suited for general purpose emulators, but basically for making ports. Yeah, kinda cool, it's a narrow specialiastion of a general purpose emulator.

But yeah, once the program starts using self-modfying code or loads code dynamically, you'll need to introduce an interpreter anyway and/or some form of JIT (or get rid of the self-modifying code).

 

[Baron Dupek]

Looks like PS1+PSP and even PS2 emulation power is coming to PS4 and PS5.
Gentlemen - PS5 haz games. Soon... a mere fraction of PS2 library would be massive boost for the dessert that you can see behind the Mike

is this the cure for Sony fanboys seething recently more than usual? Does it remove biterness and bring joy to live again?

music time!

 

[flyingjohn]

Meh, Sony Emulation efforts are doghsit and copyright bullshit will make sure nothing of value gets added. Unlike Nintendo who owns their own IP's, Sony has to beg third parties for permission to put stuff on digital stores.