Editing Emulation accuracy
Jump to navigation
Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | ;It's important to know that emulation accuracy | + | ;It's important to know that emulation accuracy shouldn't be confused with compatibility; while how closely an emulator mimics the original hardware is important, don't mistake that for compatibility. Whether games run properly is a separate concern, accuracy can sometimes influence it. See [[#Perfection.3F|"perfection"]] and [[#Controversy|"controversy"]] sections. |
− | + | An emulator is '''accurate''' when an instruction given to both the program and the hardware results in both outputting the same result. That means accurate emulators produce much fewer audio and video glitches, usually at the cost of more processing power needed. It's often achieved by using tighter synchronization. | |
− | + | The more accurate an emulator is, the lesser deviations there is from real hardware behavior but the more demanding it is. Ironically, that aspect might at times be at odds with how authentic the experience is, when it introduces [[Input lag]]. A similar debate surrounds CRT shaders as well. Not to mention the hardware intensive nature of very accurate emulators for later consoles may be at odds with the emulator's usability, especially with the recent collapse of Moore's Law (in layman's terms, you can't just "buy a better PC" if semiconductor technology does not catch up fast enough with what it takes for accurate emulation that makes zero compromises for optimizing speed) | |
− | + | As a result, accuracy and emulator authenticity continue to be controversial subjects and highly a matter of opinion depending on what aspect of the experience the user values more. | |
==Types== | ==Types== | ||
Line 11: | Line 11: | ||
===Low accuracy=== | ===Low accuracy=== | ||
− | An emulator isn't accurate when it has a large amount of visual and audio glitches and favors performance as much as possible. To work around these glitches, emulator developers typically include game-specific hacks (and prioritize popular games) to skip over problems, such as compatibility issues that can cause games to break. Many times, these emulators will be deemed incompatible with the less popular (obscure) games. As Near (then known as byuu) explains in a 2011 Ars Technica article linked below, ''Speedy Gonzales: Los Gatos Bandidos'' will soft lock towards the end due to a specific hardware edge case that isn't emulated in [[ZSNES]] or [ | + | An emulator isn't accurate when it has a large amount of visual and audio glitches and favors performance as much as possible. To work around these glitches, emulator developers typically include game-specific hacks (and prioritize popular games) to skip over problems, such as compatibility issues that can cause games to break. Many times, these emulators will be deemed incompatible with the less popular (obscure) games. As Near (then known as byuu) explains in a 2011 Ars Technica article linked below, ''Speedy Gonzales: Los Gatos Bandidos'' will soft lock towards the end due to a specific hardware edge case that isn't emulated in [[ZSNES]] or [[Snes9x]], but is properly dealt with in his own emulator [[higan]] due to his documentation of the system. This can also become very problematic when ROM hacks abuse software errors (aka. emulator oversights) to create otherwise impossible behaviors to achieve what they can. When a ROM hack can only be used in that one specific emulator, he explains, it becomes incompatible with real hardware (either through a flash cart or printed), and that such an issue has occurred with [[ZSNES]] before and continues to occur with Nintendo 64 ROM hacks. |
===Medium accuracy=== | ===Medium accuracy=== | ||
Line 19: | Line 19: | ||
===High accuracy=== | ===High accuracy=== | ||
− | High accuracy is a level of precision that emulator developers strive for when achieving [[#Cycle_accuracy|cycle accuracy]] or even [[#Partial cycle-accuracy|partial-cycle accuracy]] is not practical or necessary. | + | High accuracy is a level of precision that emulator developers strive for when achieving [[#Cycle_accuracy|cycle accuracy]] or even [[#Partial cycle-accuracy|partial-cycle accuracy]] is not practical or necessary. In this approach, the emulator replicates the components of the original system as closely as possible, aiming for a faithful reproduction of the system's behavior. The pursuit of high accuracy often results in the need for more processing power, leading to fewer audio and visual glitches and improved handling of edge cases used by creative game programmers. Emulators with high accuracy may or may not be cycle-accurate, but they generally exhibit a notable level of fidelity to the original hardware. Achieving 100% compatibility with commercially released games is a common goal for emulators with high accuracy. |
+ | |||
+ | Some of these emulators even represent an even more meticulous level of precision in replicating the original system compared to other highly accurate emulators, aiming to achieve an even closer match to the behavior of the original hardware. This heightened level of accuracy often involves more sophisticated techniques, demanding increased computational resources. The distinction between high and very high accuracy lies in the finer details and nuances that very high accuracy seeks to capture, resulting in an emulation experience that minimizes any discrepancies or artifacts compared to the original system. Emulators with very high accuracy may be especially appealing to users seeking an unparalleled level of authenticity and completeness in their emulation experience. | ||
===Cycle accuracy=== | ===Cycle accuracy=== | ||
Line 26: | Line 28: | ||
So, in summary, we can talk about three types of cycle emulation: "partial cycle-accuracy", "cycle-based accuracy" and "full cycle-accuracy". These can be considered as subsets of "cycle accuracy." Due to technical challenges and performance considerations, emulators often employ either "partial cycle-accuracy" or "cycle-based accuracy" depending on the specific requirements. | So, in summary, we can talk about three types of cycle emulation: "partial cycle-accuracy", "cycle-based accuracy" and "full cycle-accuracy". These can be considered as subsets of "cycle accuracy." Due to technical challenges and performance considerations, emulators often employ either "partial cycle-accuracy" or "cycle-based accuracy" depending on the specific requirements. | ||
− | Mesen, BlastEm, NanoBoyAdvance, Azayaka, MartyPC and Stella are recognized for their cycle-accurate emulation, though for knowing the specific degree of cycle-by-cycle precision for each needs further research. | + | Mesen, CEN64, BlastEm, NanoBoyAdvance, Azayaka, MartyPC and Stella are recognized for their cycle-accurate emulation, though for knowing the specific degree of cycle-by-cycle precision for each needs further research. |
====Partial cycle-accuracy==== | ====Partial cycle-accuracy==== | ||
− | This focuses on replicating the timing of instructions and key internal operations, while simplifying or skipping some less critical details. This can lower the performance requirements | + | This focuses on replicating the timing of instructions and key internal operations, while simplifying or skipping some less critical details. This can lower the performance requirements while still maintaining good compatibility and accuracy. |
− | : | + | :Example of partial cycle-accurate emulator is [https://old.reddit.com/r/emulation/comments/vy8cg7/ares_v129_has_been_released_crossplatform/ig4da06/ bsnes]. |
− | |||
====Cycle-based accuracy==== | ====Cycle-based accuracy==== | ||
This type of emulation accuracy aims to reproduce the system's functional behavior within a specified number of cycles without necessarily adhering to the exact | This type of emulation accuracy aims to reproduce the system's functional behavior within a specified number of cycles without necessarily adhering to the exact | ||
− | timing of each individual | + | timing of each individual instruction. Since this method doesn't go out of its way to mimic the precise timing and execution of each instruction, it may not be able to handle all hardware edge cases. |
:An example of a cycle-based emulator is jgnes with its cycle-based emulation of the Ricoh 2A03 and PPU. | :An example of a cycle-based emulator is jgnes with its cycle-based emulation of the Ricoh 2A03 and PPU. | ||
====Full cycle-accuracy==== | ====Full cycle-accuracy==== | ||
− | This aims to mimic every aspect of the CPU's timing and behavior, including internal operations and interactions with other components like memory and I/O devices. This demands the highest processing power for emulation | + | This aims to mimic every aspect of the CPU's timing and behavior, including internal operations and interactions with other components like memory and I/O devices. This demands the highest processing power for accurate emulation. |
− | :[https://old.reddit.com/r/emulation/comments/vy8cg7/ares_v129_has_been_released_crossplatform/ig4da06/ | + | :[https://old.reddit.com/r/emulation/comments/vy8cg7/ares_v129_has_been_released_crossplatform/ig4da06/ Example of fully cycle-accurate emulators: higan and ares]. |
===Subcycle accuracy=== | ===Subcycle accuracy=== | ||
Line 68: | Line 69: | ||
==Perfection?== | ==Perfection?== | ||
− | While it may be theoretically possible to have a 100% perfect emulator, that feat is very rare (if not nearly impossible), even for some highly regarded emulators such as [[higan]] or kevtris's work on the various FPGA-based consoles by Analogue. Just because an emulator claims to be "cycle accurate" or "100% compatible" does not mean that said emulator is flawless. This even includes situations in which all emulator accuracy tests ( | + | While it may be theoretically possible to have a 100% perfect emulator, that feat is very rare (if not nearly impossible), even for some highly regarded emulators such as [[higan]] or kevtris's work on the various FPGA-based consoles by Analogue. Just because an emulator claims to be "cycle accurate" or "100% compatible" does not mean that said emulator is flawless. This even includes situations in which all emulator accuracy tests (ie. [[PS1 Tests]]) are passed, as these tests cannot cover every single edge case, and some of these tests may even fail on real hardware, leading to even more confusion. Some things are nearly impossible to perfectly emulate, such as some of the illegal opcodes of the [[wikipedia:MOS_Technology_6502|6502]], where the results are completely unpredictable on hardware, and different hardware revisions have different results and different illegal opcodes. The closest one could get to writing a perfect emulator would be if someone were to exactly copy an original ASIC map or a decap onto an FPGA, and even then, that isn't always a magic bullet. |
While any given emulator may not be perfect, that does not mean that the emulator is bad by any means. Writing an accurate emulator is extremely hard work, and while perfection may be nearly impossible at the moment, that doesn't mean that games can't be enjoyed. Work on archival via emulation has come a very long way since the emulators of the 1990s, and things are only getting better from here, with excellent emulators such as the previously mentioned [[higan]] and kevtris's [[FPGA]] cores being available to use right now. In other words, "good enough" goes a long way. | While any given emulator may not be perfect, that does not mean that the emulator is bad by any means. Writing an accurate emulator is extremely hard work, and while perfection may be nearly impossible at the moment, that doesn't mean that games can't be enjoyed. Work on archival via emulation has come a very long way since the emulators of the 1990s, and things are only getting better from here, with excellent emulators such as the previously mentioned [[higan]] and kevtris's [[FPGA]] cores being available to use right now. In other words, "good enough" goes a long way. | ||
Line 75: | Line 76: | ||
The accuracy debate has very clearly split into two sides. | The accuracy debate has very clearly split into two sides. | ||
− | The ones that don't favor accuracy argue that emulators do not need to be as accurate as possible if it can play all the games they need. And because these games tend to be the most recognized alongside the console, there shouldn't really be an interest in making more games work since those do. 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 doesn't matter how accurately it replicates the original hardware and its many quirks and functions. The faithfulness of the emulator to the console it's emulating comes second to its overall ability to play games. | + | The ones that don't favor accuracy argue that emulators do not need to be as accurate as possible if it can play all the games they need. And because these games tend to be the most recognized alongside the console, there shouldn't really be an interest in making more games work since those ones do. 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 doesn't matter how accurately it replicates the original hardware and its many quirks and functions. The faithfulness of the emulator to the console it's emulating comes second to its overall ability to play games. |
The ones that favor accuracy explain their view in that when playing a game with inaccurate emulation the experience may sometimes be quite different to the real thing, particularly with games focused on split-second reactions. There is also an entirely different reason: archival. Emulator projects should ultimately strive to recreate the hardware as much as possible; that's the only way for it to be compatible, and that's the only way to preserve the hardware. Speed and scalability to most devices is a lower priority to accuracy to the real console, both for purposes of compatibility and preservation. | The ones that favor accuracy explain their view in that when playing a game with inaccurate emulation the experience may sometimes be quite different to the real thing, particularly with games focused on split-second reactions. There is also an entirely different reason: archival. Emulator projects should ultimately strive to recreate the hardware as much as possible; that's the only way for it to be compatible, and that's the only way to preserve the hardware. Speed and scalability to most devices is a lower priority to accuracy to the real console, both for purposes of compatibility and preservation. |