Emulation accuracy discussion (split)

[FireFish]

No, it really is not. Because sometimes you need a better system to emulate the older systems. This is not a 1 to 1 CPU emulation we're talking about here - this is an entire hardware system being emualted BY YOUR CPU. An entire system with its own quirks, nuances, and manufacturer defects that developers took advantage of for years to gain some sort of edge. There's more at work than just presenting some fake CPU that allows the game to run. And increasing the system requirements DOES make sense, because back in the past some things were not possible with that emulator that are now.

You know what's going to happen in 20 years when virtual machines start emulating what we use today? The same thing. Those machines will be expected to fully emulate our GPU's *AND* our CPU's, plus numerous other components. That's going to take a lot of resources that we just simply cannot imagine, today.

Looking at the way things are going i can only conclude that they are pushing it too much and too soon.

Indeed, you can emulate game systems up to the individual transistors and resistors their timings and functionality (the world its most extreme pong emulator does that), and that would need immense amounts of CPU and GPU power.However, one could also devise functions and defines in your source-code that emulate a system correctly with not even half of the CPU needed compared to a full blown emulation of every litle transistor, chip, resistor, or coper plate in a motherboard. i would call one a realistic option to play your old games and the other a realistic option for a digital museum which could handle the cost of running a cluster / cloud / super computer for that purpose.

That is all i would add to this subject in a thread about something else.

[Graf Zahl]

However, one could also devise functions and defines in your source-code that emulate a system correctly with not even half of the CPU needed compared to a full blown emulation of every litle transistor, chip, resistor, or coper plate in a motherboard. i would call one a realistic option to play your old games and the other a realistic option for a digital museum which could handle the cost of running a cluster / cloud / super computer for that purpose.

That is all i would add to this subject in a thread about something else.

That's assuming you have the source to begin with - which for most games you never will.

[Gez]

Indeed, you can emulate game systems up to the individual transistors and resistors their timings and functionality (the world its most extreme pong emulator does that), and that would need immense amounts of CPU and GPU power.However, one could also devise functions and defines in your source-code that emulate a system correctly with not even half of the CPU needed compared to a full blown emulation of every litle transistor, chip, resistor, or coper plate in a motherboard. i would call one a realistic option to play your old games and the other a realistic option for a digital museum which could handle the cost of running a cluster / cloud / super computer for that purpose.

I doubt the performance requirements are caused by emulating the physical properties of individual components, unless doing so is absolutely needed for emulation purposes, as demonstrated by game ROMs that work correctly when using painstaking emulation and don't when using a simplified model. Contrarily to the picture you are painting, programmers don't generally try to make their work a thousand times harder just because it'll allow them to degrade performances...

Emulating a system correctly, however, is a difficult endeavor when said system is proprietary. It's one thing to write an emulator based on open specifications and then check for divergence with actual system (often finding in the process that the specifications don't exactly match the actual system, a common issue for WINE); it's another entirely when there are no open specifications at all and you must do all the work through guesswork and reverse engineering, reverse engineering that can even require very expensive specialized materiel (for example, to scan the circuits of a microchip, which is not something you can do with a smartphone or a canoscan). And emulating old hardware can be harder than just emulating their processors accurately: analog sound filters, deliberate use of CRT effects such as color bleeding, etc. A visual example from Sonic 2:

Left, how it appears if you just emulate the console; left how it appears if you also emulate the CRT's color bleeding. The waterfall translucency looks much better, and that's no coincidence.

Of course some people go overboard with that kind of things and make you gigantic scanlines and exaggerated fisheye because they figure they have to exaggerate the effects, in the same way that people often go overboard with light effects when they transpose Doom into a ~~~modern engine~~~ and you end up with ungodly abominations like this:

But anyway, even though I loathe when people put scanline effects just to be hipsters about it, doesn't mean that the games (especially console games) weren't designed taking into account this kind of things, and it has a real impact on what you see and hear, so emulating properly requires more than just making the game code work.

[FireFish]

That's assuming you have the source to begin with - which for most games you never will.

That is one giant piece of misunderstanding... (i did not mean the source of the emulated games)

Most of the respected emulators like SNES9X (snes), EPSXR (ps1), and many more use clever tricks and special emulation routines on a per game-rom basis. pseudo-emulate certain specialities. Most end users do not even notice (by example) that a certain shadow in a certain game has not been produced by emulating a cpu bug, but is being rendered by an extra function whose job is to produce said graphic without pure emulation mechanics. These types of tricks reduce the CPU load and increase the general usability on every-day hardware (aka: people who dont have 2500$ worth on computer). And that is also how they did it in the days of the Pentium 1 running a Snes emulator.

Nice examples Gez, however i dont remmeber ever seeing that effect on a normal high quality television set. I still have a normal end 90's tv in the house and nothing even close to resembling such extreme fading / bleeding could be seen on any media you attach to it by scart or cable.

[Graf Zahl]

That sounds like a pretty stupid way to do things. It may work for emulators of systems that are relatively simple, but good luck doing that for anything that hasn't been written for an old-style to-the-metal console API.

[edward850]

It's also not correct emulation, and usually why people call them inaccurate (because they blatantly are). Tool-Assisted Speedrunners have recently been pushing for something vastly superior to SNES9X so they can actually re-run their results on real hardware. So it's not even working for relatively "simple" systems all that much already. Meanwhile, apparently people have been playing Super Mario (World?) with music that's faster than what it's supposed to be this whole time.

However that's emulation, and this is a Doom source port, where the rules of emulation don't apply (as you're dealing with native code, not reproducing bytecode from a different architecture). Instead you have a much different problem that's closer to how web browsers need to work; you need to be able to run 20+ years of maps and mapping standards. This requires large sets of compatibility redirection, sometimes in cases where the same alleged standard can have two different results under different conditions.
In fact that basically is web browsers. You can even make that CPU efficient but on memory usage it just ain't cheap.

[InsanityBringer]

My favorite part of Playstation emulation is how you spend a year fiddling around with plugins only to have your favorite game from the more obscure parts of the library not work right despite everything.

Also I don't know if it was because the emulator was actually terrible or something, but pSX ran better on my old laptop than epsxe did, and pSX's thing, as far as I am aware, is to be accurate. (also epsxe not letting you shut down the emulator while running for plugin tweaking was awful). Nowadays I like mednafen for my psx emulation.

[YukiHerz]

Off Topic (PS1 emulation):
From my experience epsxe is literal garbage that works 90% of the time, but like the garbage it is, it will still break your head even when everything's working correctly, pcsxr seems like a good alternative, but it seems it isn't updated anymore, i've yet to try mednafen though.

[Gez]

People often joked about "zandronum" sounding like the name of a medical drug, but "mednafen" really sounds like the name of some ibuprofen brand.

[Nash]

Is this thread in need of another split? XD

[Jaxxoon R]

And, coincidentally, both their names draw from weird naming shenanigans caused by a lack of knowing what to call it. Mednafen is actually an acronym for "My Emulator Doesn't Need A Frickin' Excellent Name."

[ibm5155]

Ok, here comes the "triple post".

-You know it's time to upgrade your computer when a new Celeron + integrated gpu is more powerfull than your system ...

-It's funny, that under that emulation talk, for old consoles/computer you actually need to emulate the hardware really well, because people tend to abuse from glitches (ie commodore 64 using the gpu for making sounds), or 8088mph abusing from cga (and the worse is that every year people tend to find new glitches/bugs under the hardware, and so the emulators need to be constantly updated just to support that new glitches...

-Hmm, I didn't knew the draw sides from SDL, I Always took it was the best software for making multiplatform apps (I guess it's better to use the native code for each system [and it's just 3 main os, not 20 like 30 year ago ])

-get rekt 8088mph

[wildweasel]

Should I split the topic again? =P

[leileilol]

Tool-Assisted Speedrunners have recently been pushing for something vastly superior to SNES9X so they can actually re-run their results on real hardware.

higan/bsnes is a thing......oh wait there's that "wah 1 frame latency" and "to slow on my hand me down emachine's *angry picture of user's favorite pokemon*" problem


also seconding mednafen which is highly underrated because it doesn't have a hype marketing cabal and is very accurate and Rypecha is an emulation goddess and it also has its own bsnes derivative and now an accurate-ish new Saturn emulator

too bad it has a hate club of epsxe users because they can't "get psx in hd" which would work against the strive for accuracy.

[InsanityBringer]

what I find weird is that higan's always run fine on my trash machines just fine. Ok maybe I can't turbo at 120FPS, but even the accuracy core when they had multiple cores would run fine on every machine I've thrown it at. Granted I vaguely remember byuu citing a recommended CPU speed of at least 3GHZ or so, and all of my machines have met that.