It is currently Wed Oct 18, 2017 5:11 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: Grades of accuracy
PostPosted: Mon Feb 11, 2008 4:46 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 11, 2008 4:55 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
What about emulators (to come) that reproduce the hardware clock-edge-for-clock-edge? This would be something like a "hardware preservation" category.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 11, 2008 6:22 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
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".

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 12, 2008 6:16 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 12, 2008 6:34 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
kyuusaku: That's b.

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

hap wrote:
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.

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

c using d as implementation technique.

Quote:
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.

Quote:
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.

Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 12, 2008 6:52 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
tepples wrote:
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.

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject: Re: Grades of accuracy
PostPosted: Wed Feb 13, 2008 8:28 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
tepples wrote:
[*]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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 13, 2008 9:31 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 13, 2008 11:57 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
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.

Quote:
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 :)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 13, 2008 1:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
byuu wrote:
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.

byuu wrote:
just use the Cowering Method

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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 13, 2008 2:22 pm 
Offline

Joined: Mon Mar 06, 2006 3:42 pm
Posts: 94
Location: Montreal, canada
byuu wrote:
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 =)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 13, 2011 7:19 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group