Changes

Jump to navigation Jump to search

Emulation accuracy

4 bytes removed, 00:43, 6 July 2014
Minor spelling fix. Small clean up to remove some of the slang/metaphor/simile/whatever. Still needs way more clean up.
===Low accuracy===
Low accuracy emulators will have a large amount of visual and audio glitches. They will typically use various speedhacks to skip over problems, as a result many games simply run due to a variety of patches while others don't work at all. This can become very problematic when ROM hacks use these speedhacks to run by abusing the errors to create otherwise impossible behaviour. This means that the romhack can only be used in that one specific emulator. Such an issue has occured occurred with [[ZSNES]].
===Medium accuracy===
===Chip accuracy===
Chip accurate emulation works by simulating each logic chip on the board individually. Not only does this take a tremendous amount of power to run (as in, even emulating something from the 701970's on a chip accurate level would need Dolphin-level system requirements to run at a good speed.), but they also require a incredible amount of effort and money to make. This accuracy method is pretty much useless. Although it is technically the only way to achieve true 100% hardware simulation, cycle accurate emulation can already achieve accuracy which is virtually indistinguishable from the real hardware. Not only that, but cycle-accurate emulators have much lower system requirements and programming difficulty. There are currently no publicly-released chip accurate video game emulators in existence, and there will most likely never be one.
===DICE===
This emulator needs its own section on accuracy, because its accuracy method is unlike any other. Basically, what [http://sourceforge.net/projects/dice/ DICE] does is emulate arcade machines from the early 701970's. The architecture of these systems is very different from a modern architecture, mostly since they don't have a CPU. So the emulator instead emulates the discrete logic components of the machines at a circuit level. Although the results are highly accurate (as in, very highly accurate) the results are quite system intensive. You need a pretty nice fast 64-bit gaming PC to run these early-701970's arcade games at full speed.
==Controversy==
There are basically two camps sides when it comes to the issue of accuracy. One side argues that as long as an emulator plays the majority of games at full speed on most computers and devices without too many obvious glitches, it does not matter how accurately it actually replicates the original hardware and its many quirks and functions. The faithfulness of the emulator to the console it is emulating comes second to its overall ability to play games. The other side argues that an emulator should ultimately strive to simulate the hardware as much as possible, as that is the only way to achieve as much compatibility as possible, as well as the only way to preserve the hardware. Thus, speed and scalability to most devices takes is a backseat lower priority to accuracy to the real console, both for purposes of compatibility and preservation.
Even within the second campside, however, there is some disagreement as to just how much accuracy is actually needed. On most platforms, after obtaining a certain amount of accuracy, going further still requires an exponential growth in system requirements, the results of which may not be noticeable to the vast majority of users. Cycle accuracy in particular has been hotly debated in regards to its usefulness, due to how such an extreme level of accuracy requires a lot of extra processing power for relatively few gains in compatibility.
Simply put, it's a battle disagreement between those who feel believe 'good enough' is the goal and those who want nothing but the pinnacle of perfection no matter the cost.
==Further reading==
330
edits

Navigation menu