Grades of accuracy

[tepples]

As I see it, a game console emulator can fall into any of four categories for accuracy:

1. Emulators developed during the early stages of emulation, while the developer still knows very little about the target platform. Some commercial games run.
2. Emulators designed to reproduce the hardware bug-for-bug. Just about everything runs.
3. Emulators designed to make programs look or feel better than on the original hardware.
4. Emulators designed for hardware limited by cost or power consumption, which must compromise accuracy for speed.

Nesticle is a and possibly d. Nintendulator and Nestopia are b, and MAME strives to be b. Some PlayStation emulators aim for c, and so do NES and Super NES emulators that support 2xSaI, Super Eagle, Scale2x, or hq3x. Arguably, debugging emulators are c, as they allow the user to peer into the program's execution. PocketNES is d, but it handles the compromise rawther well.

Have I missed any categories?

[kyuusaku]

What about emulators (to come) that reproduce the hardware clock-edge-for-clock-edge? This would be something like a "hardware preservation" category.

[Zepper]

I see the "b" option as "too heavy", since there are "designed emulators for matching the hardware procedure for (maximum?) accuracy, in priority for running on modern machines".

[hap]

Hmm, try to categorize:

1) novelty emulator made in mIRC script, outputs graphics on a channel with multiple users to prevent flooding, still very slow
2) emulator that uses several hardware components for some chips (like HardSID support in VICE)
3) emulator designed to reproduce hardware bug-for-bug, with options to make it look or feel better
4) accurate emulator made for school project, deliberately emulating only one mapper and no sound output, very clean source code and documentation
5) closed source emulator that uses hacks to make the user believe it's very accurate (if checksum=blargg test-rom then blahblah), refusing to run programs with unknown checksum

etc ;p

[tepples]

kyuusaku: That's b.

Fx3: As I understand it, "maximum accuracy" and "bug-for-bug compatibility" are the same thing.

Hmm, try to categorize:

1) novelty emulator made in mIRC script, outputs graphics on a channel with multiple users to prevent flooding, still very slow

d.

2) emulator that uses several hardware components for some chips (like HardSID support in VICE)

c using d as implementation technique.

3) emulator designed to reproduce hardware bug-for-bug, with options to make it look or feel better

b and c in one binary. Nestopia closely matches this profile.

4) accurate emulator made for school project, deliberately emulating only one mapper and no sound output, very clean source code and documentation

On a continuum between a and b, depending on how accurate.

5) closed source emulator that uses hacks to make the user believe it's very accurate (if checksum=blargg test-rom then blahblah), refusing to run programs with unknown checksum

a, possibly d.

[Zepper]

As I understand it, "maximum accuracy" and "bug-for-bug compatibility" are the same thing.

- "Maximum accuracy" is/was an expression used by Nintendulator, claiming to be the only emulator closest to the hardware operation.

[Bregalad]

[*]Emulators designed to make programs look or feel better than on the original hardware.

Virtua NES could possibly fall in this category, fixing problem that some game have with MMC3 interrupts, by "fixing them" such as the textboxes of Crystalis or the menu in Mega Man 3.

I like the idea of having "grades of accuracy", there should be test ROMs for each grade and if they pass the emulator wins the grade.

[blargg]

I like the idea of having "grades of accuracy", there should be test ROMs for each grade and if they pass the emulator wins the grade.

Someone will need to make an "emulator" which simply checks the CRC and displays the appropriate pass screen from a bank of static images in it.

[Near]

Four rankings seems to be over complicating things to me.

Really, adding things like debuggers and optional graphics filters have little to do with core emulation itself -- so long as the internal emulation has no way of knowing that they are being used.

It's really just a matter of whether someone caters toward getting games to run (even if it means doing something now that you know hardware does not), or toward matching what the real hardware does (even if you know that will break currently working games). And there are a million compromises and shades of gray between those two extremes. A percentage level would work well. UltraHLE would be a pure 0%, whereas the Pong emulator that needs a ~30GHz PC to run at full speed would be a pure 100%.

All that other stuff is just extra features added for the benefit of users.

Someone will need to make an "emulator" which simply checks the CRC and displays the appropriate pass screen from a bank of static images in it.

Simple, just use the Cowering Method. That is, each time the game is downloaded, have the server generate random data into the image, shuffle code around to help foil heuristics, etc. A simple PHP script will do. Make it so complex that fully detecting it would start causing false positives with commercial games :)

[tepples]

Really, adding things like debuggers and optional graphics filters have little to do with core emulation itself

True, some category c features don't need support from the core, but others do. Let's use the example of an upscaler. Some scalers, such as the common implementations of scale2x, hq3x, etc. work on the finished pixel array after the PPU has rendered it. But other scalers work on the textures before they go into the finished pixel array. Do you know about the PlayStation and N64 emulators that use high-resolution texture packs? Imagine an NES emulator that replaces each 8x8x2 tile with a separately drawn 32x28x8 tile suitable for a 1024x768 pixel display. On a game with CHR ROM, the emulator's PPU might just read the smaller tile, discard it, and read the appropriate segment of the larger tile. On a game with CHR RAM, the PPU would use a hash table to map 128 bits of CHR data to a tile index.

just use the Cowering Method

That sounds like either morphic virus techniques or the copy-protection of Earthworm Jim.

[mozz]

Simple, just use the Cowering Method. That is, each time the game is downloaded, have the server generate random data into the image, shuffle code around to help foil heuristics, etc. A simple PHP script will do. Make it so complex that fully detecting it would start causing false positives with commercial games

Rofl, the Cowering Method =)

[tepples]

I just now realized that roughly two years after this thread had died, I ended up implementing the Cowering method in the process of developing a buffer overflow detector.

Related wiki pages: Accuracy and Enhancement