Changes

Jump to navigation Jump to search

Emulation accuracy

971 bytes added, 13:57, 3 July 2017
As much as we respect the efforts of developers, emulators can also be bogged down because of poor code. I didn't want to include that though.
An emulator is '''Accuracyaccurate''' is how accurate when an instruction given to both the emulator is to program and the original hardwareresults in both outputting the same result. Accuracy is most often achieved by tighter syncing. More accuracy That means accurate emulators produce much less graphics audio and audio video glitches, at the cost of additional CPU more processing power required to run needed. It's often achieved by using tighter synchronization.<!-- [[Higan]] is a major example of an accuracy-centric emulator because the developer, byuu, has previously explained why he writes the game at full speedsoftware. Though he strives for accuracy, he still encounters problems.-->==Types:==
===Low accuracy===
Low accuracy emulators will have An emulator isn't accurate when it has a large amount of visual and audio glitchesand favors performance as much as possible. They will To work around these glitches, emulator developers typically use various include game-specific hacks (and prioritize popular games) to skip over problems, such as speed or compatibility issues with specific that can cause gamesto break. Many times, these emulator authors emulators will only prioritize popular games, and be deemed incompatible with the less popular games will be incompatible. An example of this is As byuu explains in a 2011 Ars Technica article linked below, "Speedy Gonzales: Los Gatos Bandidos with emulators such as " will soft-lock towards the end due to a specific hardware edge case that isn't emulated in [[ZSNES]] and or [[Snes9x]], where the game will soft-lock towards but is properly dealt with in his own emulator [[higan]] due to his documentation of the endsystem. This can also become very problematic when ROM hacks use these hacks to run by abusing the abuse software errors to create otherwise impossible behaviorbehaviors to achieve what they can. This means that the When a ROM hack can only be used in that one specific emulator and is , he explains, it becomes incompatible with real hardware (either through a flash cart or reproductionprinted). Such , and that such an issue has occurred with [[ZSNES]] before and still occurs today continues to occur with new N64 Nintendo 64 ROM hacks.
Many times, newer Newer emulators use tend to favor High Level Emulation (HLE) as opposed to Low Level Emulation (LLE), which results in lower accuracy. There are some exceptions to HLE causing low accuracy, such as the While emulators like [[Dolphin]] emulatorfavor accuracy but still retain HLE for performance and have successfully used it to an advantage, but these types of exceptions are uncommon. More information about this can be found at the and [[High/Low level emulation|it can still hinder accuracy]] page.
===Medium accuracy===
Medium accuracy Most emulators will headed by multiple developers tend to have fewer glitches, but will still have many problems. Most emulators fall into this category.
===High accuracy===
High Emulator developers often strive for high accuracy emulators try to replicate when the system cannot effectively be cycle accurate. Their emulator replicates the components of the original system as closely as possible, and for as byuu explains it's that reason take that more CPU processing power is required to do so. They will have The result is fewer audio and visual glitches, and better handling of edge cases used by creative game programmers. High An emulator with high accuracy emulators may or may not be cycle -accurate. Some high accuracy emulators can and sometimes, they achieve 100% compatibility with commercially released games.
===Cycle accuracy===
Cycle accurate emulation is trying to perfectly emulate Perfectly emulating timings right down to the per-cycle accessesresults in cycle-accurate emulation. So each Each individual component is emulated at exactly the right time, in perfect sync, and so on, which has a high CPU cost. The speed of the emulation depends on the way cycle -accuracy is implemented. Cycle accuracy , and it doesn't necessarily mean 100% accuracy. Only if the emulator is implemented perfectly is it perfect. An example of a cycle accurate emulator not being perfect is Even [[Higan]] still has issues with the ROM Hack "Mario and Luigi: Kola Kingdom Quest," where on real hardware, it doesn't emulate the text glitch of the level 's title text has graphical glitches whereas those glitches do not exist in [[Higan]].
===Chip accuracy===
Chip accurate emulation works by By simulating each logic chip on the board individually. Not , this not only does this take takes a tremendous amount of processing power or specialized hardware to run (as in, even emulating something from the 1970s on a chip accurate level would need DolphinAAA-level system requirements to run at a good speed), but they it also require a requires an incredible amount of effort to make. This accuracy method is , and <u>it's also almost useless</u>. Although it is the only way to achieve ''true 100% '' hardware simulation, cycle accurate emulation can already achieve accuracy which is virtually indistinguishable accuracy from the real hardware, aside from a very limited amount negligible set of edge cases. In addition, cycle-accurate emulators have much lower system requirements and programming difficulty. Currently, the The only chip accurate emulators that are currently usable run on Field Programmable Gate Arrays, or FPGAs, which are essentially custom programmable chips. Machines dedicated to this type of emulation exist, such as the Analogue NT Mini by kevtris or the RetroUSB AVS by bunnyboy. Other examples of chip accurate emulation can be found in flash carts such as the SD2SNES, where various add-on chips are emulated on the included FPGA.
===DICE===
This emulator needs type is unique in that its own section on accuracymethod, because its accuracy method is unique. [http://sourceforge.net/projects/dice/ DICE] , emulates arcade machines from the early 1970s. The architecture of these systems is different from a modern architecture, mostly because they don't have a CPU. DICE emulates the discrete logic components of the machines at a circuit level. Although and, although the results are accurate the , you need a fast 64-bit PC to run these arcade games at full speed.
==Controversy==
There are The accuracy debate has very clearly split into two sides when . The ones that don't favor accuracy argue that emulators do not need to be as accurate as possible if it comes can play all the games they need. And because these games tend to be the issue of accuracymost recognized alongside the console, there shouldn't really be an interest in making more games work since those ones do. One side argues A more compelling point is 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 doesn't 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 's emulating comes second to its overall ability to play games.  The other side argues ones that favor accuracy explain their view for an emulator entirely different reason; archival. Emulator projects should ultimately strive to simulate recreate the hardware as much as possible, as ; that is 's the only way for it to achieve as much compatibility as possiblebe compatible, as well as and that's the only way to preserve the hardware. Thus, speed Speed and scalability to most devices is a lower priority to accuracy to the real console, both for purposes of compatibility and preservation.
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 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 wanting 'good enough' or perfection no matter , 'good for all cases', and 'good for the costfuture'.
==Console revisions==
==Further reading==
*[http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/ [httpAccuracy takes power://tasvideos.org/EmulatorResources/NESAccuracyTests.html NES Accuracy Testsone man’s 3GHz quest to build a perfect SNES emulator- Byuu ([[http://tasvideos.org/EmulatorResources/GBAccuracyTests.html Game Boy Accuracy Testshigan]]developer), 2011
===TASVideos===*[http://tasvideos.org/EmulatorResources/NESAccuracyTests.html NES Accuracy Tests]*[http://tasvideos.org/EmulatorResources/GBAccuracyTests.html Game Boy Accuracy Tests]*[http://tasvideos.org/EmulatorResources/SNESAccuracyTests.html SNES Accuracy Tests]
[[Category:FAQs]]
927
edits

Navigation menu