11 ms·

What always annoys me in emulation is how it always reacts so bad to slowdown. Was trying to get my Tony Hawk's Pro Skater 3 on, but apparently my poor Core 2 D

What always annoys me in emulation is how it always reacts so bad to slowdown. Was trying to get my Tony Hawk's Pro Skater 3 on, but apparently my poor Core 2 Duo E6600 and GTX 275 couldn't handle it. I was getting 30fps - which would be fine in a regular game, but in an emulator actually means playing the game at half speed (full speed being 60fps). Including the music, which, well, that was interesting. Still, I'm glad to see progress being made in emulation. I think it's extremely important that we will have access to gaming history for a long time to come, even after most of the hardware has died or simply can't be hooked up to modern TV systems. Seems like the next big step will be Xbox 1 emulation, which no one has tackled yet. Anyone know why?

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."
- 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.).
malkia 14y ago
I think the PS2 graphics chip had an immense fill-rate, not rivaled even by current graphics chips (I could be wrong, but this is what I remember).
- arkx 14y ago
  Why rely on memory when the truth is two Wikipedia searches away? PS2 graphics chip comes nowhere close to any modern GPU. GPUs have progressed a great deal in the last 12 years. Also, rating GPUs based on their pixel fill rate stopped making sense around a decade ago.
  - malkia 14y ago
    I think it was the eDRAM that made difference, allowing lots of transparent redraw to be handled: "Embedded DRAM gives 48 GByte/sec memory bandwidth to eliminate pixel fill bottleneck." - http://research.scee.net/files/presentations/agdc2000/ThePowerOfPS2.pdf http://research.scee.net/files/presentations/agdc2000/ThePow... Granted that was years ago, so I might be mistaken. But it's still a lot of speed for a device that was made more than 13 years ago...
  - malkia 14y ago
    And you are right that they come nowhere, but if the game relies on one specific feature and over-used it, and that feature is a bit slow on modern cards - then it's an issue emulating it. No wonder the first PS3 came with the Synthesizer chip built-in, rather than emulate it.
- pheon 14y ago
  its not the fill rate/memory bandwidth but the incredibly low latency of the entire GS pipeline (which you cant get without edram) that makes it difficult to emulate.
ZoFreX 14y ago
Some emulators (like EPSXE) let you set a frameskip, so you can render at one speed but still play the game at full speed. There might be a similar option in PCSX2?
- dreampeppers99 14y ago
  yes, there is!
- avolcano 14y ago
  I'll give that a shot. I think I tried an option like that, but it just made things super-choppy (and still somewhat slomo). My system's somewhat underpowered anyways, so I'm not too surprised or upset by the issues emulating.
sliverstorm 14y ago
Seems like the next big step will be Xbox 1 emulation, which no one has tackled yet. Anyone know why? I'd take a wild guess and say, "because the Xbox 360 was backwards compatible for so long". Possibly also that most popular Xbox 1 games have had even more popular successors on the Xbox 360. It's a different beast, anyway. The CPU was x86, so the emulation work will likely consist of encapsulating the software environment rather than mimicking MIPS or what have you.
X-Cubed 14y ago
Xbox 1 emulation has been tackled, but not finished yet. http://www.caustik.com/cxbx/ http://www.caustik.com/cxbx/

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."
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.).

malkia 14y ago

I think the PS2 graphics chip had an immense fill-rate, not rivaled even by current graphics chips (I could be wrong, but this is what I remember).

arkx 14y ago
Why rely on memory when the truth is two Wikipedia searches away? PS2 graphics chip comes nowhere close to any modern GPU. GPUs have progressed a great deal in the last 12 years. Also, rating GPUs based on their pixel fill rate stopped making sense around a decade ago.
- malkia 14y ago
  I think it was the eDRAM that made difference, allowing lots of transparent redraw to be handled: "Embedded DRAM gives 48 GByte/sec memory bandwidth to eliminate pixel fill bottleneck." - http://research.scee.net/files/presentations/agdc2000/ThePowerOfPS2.pdf http://research.scee.net/files/presentations/agdc2000/ThePow... Granted that was years ago, so I might be mistaken. But it's still a lot of speed for a device that was made more than 13 years ago...
- malkia 14y ago
  And you are right that they come nowhere, but if the game relies on one specific feature and over-used it, and that feature is a bit slow on modern cards - then it's an issue emulating it. No wonder the first PS3 came with the Synthesizer chip built-in, rather than emulate it.
pheon 14y ago
its not the fill rate/memory bandwidth but the incredibly low latency of the entire GS pipeline (which you cant get without edram) that makes it difficult to emulate.

ZoFreX 14y ago

Some emulators (like EPSXE) let you set a frameskip, so you can render at one speed but still play the game at full speed. There might be a similar option in PCSX2?

dreampeppers99 14y ago
yes, there is!
avolcano 14y ago
I'll give that a shot. I think I tried an option like that, but it just made things super-choppy (and still somewhat slomo). My system's somewhat underpowered anyways, so I'm not too surprised or upset by the issues emulating.

sliverstorm 14y ago

Seems like the next big step will be Xbox 1 emulation, which no one has tackled yet. Anyone know why? I'd take a wild guess and say, "because the Xbox 360 was backwards compatible for so long". Possibly also that most popular Xbox 1 games have had even more popular successors on the Xbox 360. It's a different beast, anyway. The CPU was x86, so the emulation work will likely consist of encapsulating the software environment rather than mimicking MIPS or what have you.

X-Cubed 14y ago

Xbox 1 emulation has been tackled, but not finished yet. http://www.caustik.com/cxbx/ http://www.caustik.com/cxbx/