Changes

Jump to navigation Jump to search

Emulation accuracy

30 bytes added, 23:54, 12 October 2013
Types:
'''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 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 very non-sneslike behaviour. This means that the romhack can only be used in that one specific emulator. Such an issue has occured with [[zsnes]].
==='''Medium accuracy'''===
Medium accuracy emulators will have fewer glitches, but will still have many problems. Most emulators fall into this category.
==='''High accuracy'''===
High accuracy emulators try to replicate the original system as closely as possible, and for that reason take more CPU power to do so. They will have fewer audio and visual glitches. High accuracy emulators may or may not be cycle accurate.
==='''Cycle accurate'''===
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. How much performance is taken depends on the way cycle accuracy is implemented and the skill of the coder.
The accuracy of these emulators are close to perfection, but at a steep CPU cost.
==='''Circuit accurate'''===
*[http://sourceforge.net/projects/dice/ DICE]
Anonymous user

Navigation menu