Changes

Jump to navigation Jump to search

Emulation accuracy

438 bytes removed, 03:48, 19 July 2014
More polish. Don't care about 'hopes'. 'Some people' is code for personal opinion and if there is no evidence why tell us about it?
'''Accuracy''' is how accurate the emulator is to the original hardware. Accuracy is most often achieved by tighter syncing. More accuracy means less graphics and audio glitches, at the cost of additional CPU power required to run the game at fullspeed. There are hopes that less CPU power will be needed for more accuracy with the use of tighter programming.
==Types:==
===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 ROM hack can only be used in that one specific emulator. Such an issue has occurred with [[ZSNES]].
===Medium accuracy===
===Cycle accuracy===
Cycle accurate emulation is basically trying to perfectly emulate timings right down to per-cycle accesses. So each individual component is emulated at exactly the right time, and in perfect sync etc., which takes a performance hit. The size of the performance hit depends on the way cycle accuracy is implemented and the skill of the coder. The accuracy of these emulators are is very accuratehigh, but at a steep CPU cost. However, some people believe that the notion of 100% cycle-based accuracy being slow is a misconception, one that people believe because most attempts at a cycle emulator aren't as well-optimized as they could be. Whether or not this is the case remains to be seen.
===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 1970'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===
Even within the second side, 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 disagreement between those who believe wanting 'good enough' is the goal and those who want nothing but or perfection no matter the cost.
==Further reading==
330
edits

Navigation menu