5 ms·

An interesting article demonstrating the performance dependency of emulation: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-

by dbaupp 14y ago

An interesting article demonstrating the performance dependency of emulation: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/ http://arstechnica.com/gaming/2011/08/accuracy-takes-power-o...

avolcano 14y ago
Thanks for the link! Especially loved this quote, explaining why a performance-intensive emulator that strived for accuracy is more important than a speed-oriented one: "Video games are a piece of our history, and we need to respect the fact that there is a "true" form they had when released. Imagine if we only had a JPEG of the Mona Lisa, a RealVideo stream of the moon landing, or a MIDI rendition of "Walking in the Air." We have the ability to keep our past alive, and I feel like it's almost a duty to do so."
- Dylan16807 14y ago
  > RealVideo stream of the moon landing http://en.wikipedia.org/wiki/Apollo_11_missing_tapes http://en.wikipedia.org/wiki/Apollo_11_missing_tapes
- ekianjo 14y ago
  "Video games are a piece of our history, and we need to respect the fact that there is a "true" form they had when released. Imagine if we only had a JPEG of the Mona Lisa... etc" I respect the work of the creator of BSNES, but somehow this does not really make sense to spend so much effort to achieve 100% accurate emulation. The essence of games is the playability, not in having the exact right timing from the hardware. I doubt that in the design document of super Mario, the game designers wrote that "a jump has to take 0.47s and no more, if not it will mess up the whole game!" - There are very noticeable differences in speed and reactivity between arcade games and their ports on home consoles (at least 10-15 years ago it was certainly the case) and still gamers did not value their port "less" than the arcade ones. They were slightly different, but the essence of the game remained identical. Humans are certainly able to adapt to get past these kind of details and still enjoy the experience. I'm pretty sure you would not find many players who could tell you, without direct comparison side by side, if a game is faster/slower than what it used to be on the actual hardware. It's not like having a JPEG of the Mona Lisa. For games, you'd need to be very, very acquainted with a certain game to know for sure the emulation is not right.
  - indiecore 14y ago
    These exact emulations are important for speedrunning and other high-performance playthoughs. I know that several games (and I think Super Mario is among them) that don't accept Emulator speedruns as records because emulation errors make glitches that aren't possible on console are on emu and vice versa.
  - rcfox 14y ago
    Did you read the article? "Let's take the case of Speedy Gonzales. This is an SNES platformer with no save functionality, and it's roughly 2-3 hours long. At first glance, it appears to run fine in any emulator. Yet once you reach stage 6-1, you can quickly spot the difference between an accurate emulator and a fast one: there is a switch, required to complete the level, where the game will deadlock if a rare hardware edge case is not emulated. One can imagine the frustration of instantly losing three hours of progress and being met with an unbeatable game. Unless the software does everything in the exact same way the hardware used to, the game remains broken."
    - ekianjo 14y ago
      Yes, I have read it. I agree about this point, this is where good emulation is very relevant. However the BSNES creator also makes the point about the importance of having accurate speed, and this is where I fail to see the critical issue of having +/- 10-1% in speed in a game. Most of the time it does not break the game itself.
faragon 14y ago
IMO, post author is an idiot: Nesticle/Nesticle95 did not required patches to NES games, it was that most time-consuming parts were written in assembly (6202 CPU, PPU, and sound synthesis). Also back in 1996, the Snes96 SNES emulator ran some games at almolst playable speed on 486-DX4 @100MHz (ones not requiring DSP nor "mode 7"), few years later NLKSNES was even faster, being even full frame rate (less accurate, though). IMO, a SNES emulator requiring 3GHz means brain-dead implementation, simple as that (even emulating per-line effects -HSYNC IRQ with palette changes-, custom chips DSP1/FX/FX2 or even a second 65816 found in some cartridges for doing RLE decompression, etc.).
- daeken 14y ago
  > IMO, a SNES emulator requiring 3GHz means brain-dead implementation, simple as that No, it means accurate implementation. That doesn't mean accurate gameplay (which many inaccurate emulators achieve), but proper accurate emulation. You should really, really read up on byuu's work; he's probably the best developer in emulation at this point.
  - faragon 14y ago
    Even for accurate SNES emulation implementation, 3GHz (on 3 way OooE CPU with massive SIMD capabilities -e.g. Core2Duo, Core iX, or modern AMD-), is crazy. BTW, my evaluation was based on his article, not on his reputation.
    - daeken 14y ago
      No, it's not crazy at all. There's a massive amount of synchronization that has to be done between, say, the CPU and PPU. It's not possible to even do per-pixel synchronization right now, which is why line-based sync is in use. Have you read the source? The implementation is brilliant, even if it is "slow".
      - faragon 14y ago
        Per-pixel synchronization makes sense on systems writing pixels directly to the CRT, like the case of Atari 2600, which has no framebuffer at all, and required accurate CPU timing for writing to the DAC (Atari 2600 TIA). In case of the SNES, or any tile-based 8 and 16 bit console, IMO, the only accurate synchronization required is per-line (HSYNC) and per-frame (VSYNC), in most cases. If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written (complex multiprocessors systems with CPUs, coprocessors, DMA, rely on interrupts for synchronization, although some per-cycle heterogeneous memory access thing was used as anti-copy protection, timer handling, etc.).

by dbaupp 14y ago

avolcano 14y ago

Thanks for the link! Especially loved this quote, explaining why a performance-intensive emulator that strived for accuracy is more important than a speed-oriented one: "Video games are a piece of our history, and we need to respect the fact that there is a "true" form they had when released. Imagine if we only had a JPEG of the Mona Lisa, a RealVideo stream of the moon landing, or a MIDI rendition of "Walking in the Air." We have the ability to keep our past alive, and I feel like it's almost a duty to do so."

Dylan16807 14y ago
> RealVideo stream of the moon landing http://en.wikipedia.org/wiki/Apollo_11_missing_tapes http://en.wikipedia.org/wiki/Apollo_11_missing_tapes
ekianjo 14y ago
"Video games are a piece of our history, and we need to respect the fact that there is a "true" form they had when released. Imagine if we only had a JPEG of the Mona Lisa... etc" I respect the work of the creator of BSNES, but somehow this does not really make sense to spend so much effort to achieve 100% accurate emulation. The essence of games is the playability, not in having the exact right timing from the hardware. I doubt that in the design document of super Mario, the game designers wrote that "a jump has to take 0.47s and no more, if not it will mess up the whole game!" - There are very noticeable differences in speed and reactivity between arcade games and their ports on home consoles (at least 10-15 years ago it was certainly the case) and still gamers did not value their port "less" than the arcade ones. They were slightly different, but the essence of the game remained identical. Humans are certainly able to adapt to get past these kind of details and still enjoy the experience. I'm pretty sure you would not find many players who could tell you, without direct comparison side by side, if a game is faster/slower than what it used to be on the actual hardware. It's not like having a JPEG of the Mona Lisa. For games, you'd need to be very, very acquainted with a certain game to know for sure the emulation is not right.
- indiecore 14y ago
  These exact emulations are important for speedrunning and other high-performance playthoughs. I know that several games (and I think Super Mario is among them) that don't accept Emulator speedruns as records because emulation errors make glitches that aren't possible on console are on emu and vice versa.
- rcfox 14y ago
  Did you read the article? "Let's take the case of Speedy Gonzales. This is an SNES platformer with no save functionality, and it's roughly 2-3 hours long. At first glance, it appears to run fine in any emulator. Yet once you reach stage 6-1, you can quickly spot the difference between an accurate emulator and a fast one: there is a switch, required to complete the level, where the game will deadlock if a rare hardware edge case is not emulated. One can imagine the frustration of instantly losing three hours of progress and being met with an unbeatable game. Unless the software does everything in the exact same way the hardware used to, the game remains broken."
  - ekianjo 14y ago
    Yes, I have read it. I agree about this point, this is where good emulation is very relevant. However the BSNES creator also makes the point about the importance of having accurate speed, and this is where I fail to see the critical issue of having +/- 10-1% in speed in a game. Most of the time it does not break the game itself.

faragon 14y ago

IMO, post author is an idiot: Nesticle/Nesticle95 did not required patches to NES games, it was that most time-consuming parts were written in assembly (6202 CPU, PPU, and sound synthesis). Also back in 1996, the Snes96 SNES emulator ran some games at almolst playable speed on 486-DX4 @100MHz (ones not requiring DSP nor "mode 7"), few years later NLKSNES was even faster, being even full frame rate (less accurate, though). IMO, a SNES emulator requiring 3GHz means brain-dead implementation, simple as that (even emulating per-line effects -HSYNC IRQ with palette changes-, custom chips DSP1/FX/FX2 or even a second 65816 found in some cartridges for doing RLE decompression, etc.).

daeken 14y ago
> IMO, a SNES emulator requiring 3GHz means brain-dead implementation, simple as that No, it means accurate implementation. That doesn't mean accurate gameplay (which many inaccurate emulators achieve), but proper accurate emulation. You should really, really read up on byuu's work; he's probably the best developer in emulation at this point.
- faragon 14y ago
  Even for accurate SNES emulation implementation, 3GHz (on 3 way OooE CPU with massive SIMD capabilities -e.g. Core2Duo, Core iX, or modern AMD-), is crazy. BTW, my evaluation was based on his article, not on his reputation.
  - daeken 14y ago
    No, it's not crazy at all. There's a massive amount of synchronization that has to be done between, say, the CPU and PPU. It's not possible to even do per-pixel synchronization right now, which is why line-based sync is in use. Have you read the source? The implementation is brilliant, even if it is "slow".
    - faragon 14y ago
      Per-pixel synchronization makes sense on systems writing pixels directly to the CRT, like the case of Atari 2600, which has no framebuffer at all, and required accurate CPU timing for writing to the DAC (Atari 2600 TIA). In case of the SNES, or any tile-based 8 and 16 bit console, IMO, the only accurate synchronization required is per-line (HSYNC) and per-frame (VSYNC), in most cases. If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written (complex multiprocessors systems with CPUs, coprocessors, DMA, rely on interrupts for synchronization, although some per-cycle heterogeneous memory access thing was used as anti-copy protection, timer handling, etc.).