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?
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."
"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.
"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.
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.
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".
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.
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.).
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).
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.
> 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.
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.
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.
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.
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.
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.
So let's say I have my copy of Burnout 3, possibly the best arcade racer on the PS2, sitting on the desk in front of me, and I just downloaded the Mac version of PCX2. What all currently stands between me and some classic Road Rage mode on my Mac?
Basically you just need to install (the "full isntaller" install the main plugin) and put your bios on bios folder and then you make an ISO of you own copy and that's it! Go to menu File Run ISO, done!
For sure, you can experiment changing video .... and so on!
Rules 1 and 2 of emulation have always been, for good reason, "You do not ask about roms". Seriously. Dump them yourself if you own them, or use google-fu to find them elsewhere. Nobody here is going to help you find warez.
As far as emulator information, I've always been a fan of zophar.net or emulation64.com
I discovered Star Ocean and Tales of Phantasia at the same time, in 2001. TOP was finished but SO was not translated (or maybe only item names…) and I remember being so impatient that I printed a walkthrough and played about one third of it in Japanese in the summer of 2002. I wanted to play it so badly that it pushed me to register on many forums at that time.
And now I can't even remember my usernames or even the name of some of the the forums I joined.
Do you remember Silhouette? That's the first SNES emulator I've used, back in 1996 or 1997. A friend gave it to me along with 4 roms, including Chrono Trigger. I wasn't into Video Games before that…