Hacker News Reader

Comment by avolcano | Hacker News Reader

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?

View on HN

An interesting article demonstrating the performance dependency of emulation: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-o...

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

> RealVideo stream of the moon landing

http://en.wikipedia.org/wiki/Apollo_11_missing_tapes

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

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.

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

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.

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

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

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.

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

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

> If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written

That's the whole point. There are games that did crazy stuff, and don't work well on many emulators. Perfect emulation requires software simulation of these crazy exploitations of the hardware.

Yes, but 3GHz of a modern OooE CPU (with at least 3 instruction per clock, capable of massive SIMD)? Come on. Also, from desktop snapshot, in task manager it showed 4 CPUs, with 3 of them at almost 100% (!). It reminds me the comparison between Git and Monotone made by Linus Torvalds. I find no reason in the Earth for perfect SNES emulation with just one core of a modern OooE CPU and 1-1.5GHz (with GPU assistance for stretch and filtering/postprocess), even written in C, with no SIMD assembly at all (SNES 65816 CPU was running at maximum speed of 3.58 MHz, being its coprocessors even slower).

> Also, from desktop snapshot, in task manager it showed 4 CPUs, with 3 of them at almost 100%

The Ars Technica image guy made that screenshot. It wasn't from running my emulator, which is strictly single-core (for a whole host of reasons I won't get into.)

Your guess is as good as mine why he chose that screenshot, I didn't know about it until after the article was published.

Thank you for the answer, byuu. Don't get me wrong, your emulator is great, and I apreciate very much your commitment with open source. I simply pointed about the Nesticle patches were not necessary for speeding up the emulation, and that 3GHz was overkill, in my opinion. I bet in the future it will be much faster, no mater if is optimized by yourself o by others (I understand that may be optimization is not your goal, my point is just that the 3GHz is not a requirement just because precission, but because of current implementation). Best regards, and please, excuse me for telling you "idiot" in a previous post, change it by "innacurate" (Nesticle thing) and "incomplete" (3GHz required not only because accuracy, but also because current implementation limitations).

> If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written

I agree, and there were several such games released for the SNES. Would you rather those poorly written games never be playable under emulation? Because until now, they weren't playable. And now they are on moderate PC desktops. And personally, I don't think the extra emulator overhead will matter in 20 years when our cell phones have ten times the power needed for it.

My current builds do perform per-pixel synchronization of the CPU and PPU. It cuts the speed in half compared to scanline-based, and even that is only because I run the chips out-of-order until synchronization is absolutely required.

It's needed by Air Strike Patrol to draw the plane's shadow, as seen here: http://byuu.org/bsnes/images/accuracy/air-strike-correct.png

It also affects a lot of "line error" issues, but those are fairly easy to work around with a scanline-based renderer.

The brilliant thing about bsnes (the "crazy" emulator you're referring to) is that the author has worked with researchers to reverse-engineer all of the secondary chips that SNES carts used - even an ARM3 chip.

I just pointed that his implementation is slow, not that accurate implementation was not hard or require much more CPU than non-accurate.

I spoke about the article, not a judgement of author's as a whole, which I respect.

You can call him an idiot if you want, but in the early days of Nesticle many ROMs were patched to actually run on it. I was six or seven at the time and I know this because I had to find ROMs that were pre-patched; IIRC (and I may be conflating things slightly but I'm fairly sure) the [f]ixed tag was created to indicate that this ROM was modified from a standard dump largely because of emulator compatibility.

And you seem to be having a very hard time understanding the difference between accurate emulation (i.e., bsnes) and the good-enough-but-much-faster emulation of stuff like ZSNES. The point of bsnes is to be a software implementation of a Super NES, not to run Super NES games, but that one seems to be handled quite nicely in the sibling thread.

I understand the difference between accurate emulation and good-enough emulation. Simply, for me, is crazy to see 3 core @3GHz at 100% for accurate emulation. IMO, bsnes is slow and inneficient, not only justified by accurate emulation, but also because of its implementation.

In Nesticle days I was around 20 (now 37), and actively interested in the emulation scene. The "fixed" ROMs in most cases came from ROM cartridge simulators (with embedded RAM), often requiring ROMs to be patched because of different ways of simulating bank switching or anti-piracy protections.

Of course, I apreciate his work. It is just my opinion, no matter how many negative points I've got.

Did you review the source or profile the emu, or do you make your judgement out of what you believe the implementation of an accurate SNES emulator should take?

In the former case, cold you enlighten us on the parts that are slower then they should be.

In the latter case, please have a look at the source.

Yes, I did, version 089 (http://bsnes.googlecode.com/files/bsnes_v089.tar.xz). Is clean and well written C++, but in addition to the accuracy, I see a problem in the emulation itself: templates, data structures, L1 data cache usage, synchronization. In my opinion, that emulator could be rewritten in plain C, with better data structures, and without such rare synchronization, using just one quarter of the resources is using today (v089).

I pointed just 2 things: 1) against the byuu affirmation about Nesticle ROM patching for speed (in my opinion the speed of Nesticle was because of great implementation of the Bloodlust folks, via 386 assembly -both for the Watcom C + TASM DOS/DOS4GW case, and the Win32 port-), and 2) the non-sense of a whole 3GHz (with 3 of 4 threads at 100% usage), for running a SNES system, even with 100% accuracy.

> Nesticle/Nesticle95 did not required patches to NES games

NES ROMs were distributed pre-patched to work on Nesticle. I was there for it. This was not done by Bloodlust, but by people wanting to play the games.

Some emulators to this day ship with databases of checksums to detect these images.

> IMO, a SNES emulator requiring 3GHz means brain-dead implementation

I look forward to your SNES emulator with no known bugs and much lower system requirements. And if you aren't making one, why are you so sure of what is required? None of the other SNES emulator authors who have looked at my code feel there is a technical flaw in its implementation.

You need to understand the exponential function to understand bsnes' system requirements. When I first started out, I was able to run ~99% of games almost as quickly as Snes9X (the latter used ASM cores for the CPU, SA1 and SFX.) The more accurate you get, the less it fixes. To get everything running at the same time is the hard part. It means you can't take shortcuts anywhere.

If I chose to remove behaviors that would break at best a dozen games, my emulator could run four times as fast. In fact, I've made a build that does just that. Here it is getting 80fps on an in-order Atom CPU: http://imageshack.us/photo/my-images/405/zelda3v.png/ -- this build pushes 300-400fps on my 3GHz E8400.

In my opinion, is slow. And I bet you -or others- have room for increase performance by 2-4x in next years. Even without SIMD intrinsics (autovectorization-friendly code is OK, though), but with proper data structure usage, better code L1 cache usage, increasing data cache hit ratio, reducing function/pointer indirection, reduce data cache pollution, etc.

I wrote an article on this here: http://byuu.org/articles/optimization

Executive summary: yes, I could probably get it twice as fast with identical accuracy (in the absolute best case -- 50% faster is more realistic); but I would sacrifice the portability, maintainability and readability of the code. This is a big problem because I have very limited time and resources as a single person. It's because the code is so straight-forward that I'm able to rapidly fix bugs when they are found.

First of all, your proyect is OK as is, I respect your criteria, of course.

My point in that regard was about the 3GHz requirement was because of the implementation, mainly, not because accuracy requirement. I bet 2-4x faster is possible, without reducing portability. If for "maintainability and readability" you mean keep it in C++ (L1 code cache impact, indirections, data structure penalty, etc.), I agree, that will be a penalty as fix cost in time and space.

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?

yes, there is!

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.

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.

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

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.

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/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...

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.

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.

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

Reply on news.ycombinator.com