PCSX2 1.0 released
pcsx2.net
The best ps2 (PCSX2) emulator is out with new major version
pcsx2.net
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?
"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."
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."
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.
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.).
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.
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.).
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.
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.
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.
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.
I spoke about the article, not a judgement of author's as a whole, which I respect.
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.
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.
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.
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.
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.
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.
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.
Also, rating GPUs based on their pixel fill rate stopped making sense around a decade ago.
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...
No wonder the first PS3 came with the Synthesizer chip built-in, rather than emulate it.
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.
For sure, you can experiment changing video .... and so on!
I wonder how long it will take before we see PS2 emulated on android devices.
As far as emulator information, I've always been a fan of zophar.net or emulation64.com
BTW, I designed the icons for the firt Mac port of PCSX(1) back in the days.
Those were good times.
For me, the game to beat was Star Ocean on the SNES, came out 1/1/2003.. the last translation that DeJap ever did.
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…