Great find. This is the most in-depth article I've read on this subject. I actually use this as an open-ended interview question at the game company where I work. The PlayStation 2 has a bunch of quirks with floating point numbers because it doesn't follow the IEEE standard - for example, floats don't become infinity when they overflow, they just get clamped to the maximum possible float. Now you can't use your FPU for the tens of thousands of floating point calculations that are happening per frame. Sure, your processor is faster, but it's fighting with one arm tied behind its back.
Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
11–20 of 57 posts
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#12Perhaps we should start using CardBus and PCI-E based FPGA cards and go for hardware simulation rather than software emulation? Performance is far easier to achieve there. The devices aren't exactly expensive either.
if you're going to add hardware you might as well just get a real SNES from eBay and use a memory cart.
The issue is that buying an SNES becomes decreasingly viable as time goes on while using an FGPA becomes increasingly viable. I don't know if we've reached the point where the balance shifts yet, but presumably we will at some point.
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#13Perhaps we should start using CardBus and PCI-E based FPGA cards and go for hardware simulation rather than software emulation? Performance is far easier to achieve there. The devices aren't exactly expensive either.
if you're going to add hardware you might as well just get a real SNES from eBay and use a memory cart.
An FPGA can emulate a lot of different systems, but a SNES is just a SNES.
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#14Earlier quoted context omitted.
if you're going to add hardware you might as well just get a real SNES from eBay and use a memory cart.
The issue is that buying an SNES becomes decreasingly viable as time goes on while using an FGPA becomes increasingly viable. I don't know if we've reached the point where the balance shifts yet, but presumably we will at some point.
Also, the medium on which the software is delivered is not the problem either. It's just information after all. The problem is accurately emulating the software in software which is easier achieved by emulating the harware in hardware :)
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#15Perhaps we should start using CardBus and PCI-E based FPGA cards and go for hardware simulation rather than software emulation? Performance is far easier to achieve there. The devices aren't exactly expensive either.
if you're going to add hardware you might as well just get a real SNES from eBay and use a memory cart.
How about a SNES card for my PC with all the hardware on it? ;)
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#16Or consider Air Strike Patrol, where a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extraordinarily resource intensive to emulate. So what's really going on here is that the emulator must emulate not only the SNES hardware, but also the television . Video game emulators have had to deal with this for a long time, to varying and increasing levels of accuracy. Televisio…
Is anyone else reminded of the "copper" effect people would do back in the day where they would cycle the colors of a screen in sync with the horizontal refresh of the monitor to create bars of color the oscillate up and down in really cool patterns?
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#17Earlier quoted context omitted.
FPGAs not expensive? Please let me know where you shop...
It depends on the size. Big FPGA's are amongst the most expensive chips that you can buy ($10K and up), but small ones are affordable. The amount of logic in an 80's era game computer should be within the gate budget of a small to mid sized FPGA. See http://www.fpgaarcade.com/ for many examples of this.
Back in '01 (the good old days), we had volume prices of $40 for Xilinx parts which were big enough to get a PowerPC CPU in it.
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#18Or consider Air Strike Patrol, where a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extraordinarily resource intensive to emulate. So what's really going on here is that the emulator must emulate not only the SNES hardware, but also the television . Video game emulators have had to deal with this for a long time, to varying and increasing levels of accuracy. Televisio…
That particular problem isn't a case of emulating the television, but rather accurately emulating the console's video hardware and its interactions with the rest of the system. If one were simply interested in emulating the television's behaviour then you could construct a frame buffer based on the visible sprites and postprocess that (possibly in conjunction with several preceding fields). If the console allowed sne…
You're correct, this particular problem can be handled with sufficiently sophisticated frame buffer logic. I was generalizing from that to other concepts where emulating the television or its signal processing would be required.
I'll give you another example. On the Atari 2600 game console, the vertical sync is software controlled. The software is responsible for enabling the vertical sync pulse. This can be done 60 times per second as standard -- or you could play tricks with it. Suppose you strobe it at a different or even irregular rate. On an analog TV, the picture starts rolling vertically. That breaks way outside the sandbox of a framebuffer, with signal being displayed in overscan areas, and during the normally-blank retrace interval resulting in ghosting effects. (No commercial game did that, but it's been done in tech demos, and conceivably a horror game could do it intentionally for mood.) To produce that same behavior on framebuffer-based hardware, you need to emulate or at least approximate the workings of a TV's vertical sync logic, none of which appears in the console itself.
(I know this from experience, I wrote an Atari 2600 game: http://www.dos486.com/atari/ )
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#19Or consider Air Strike Patrol, where a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extraordinarily resource intensive to emulate. So what's really going on here is that the emulator must emulate not only the SNES hardware, but also the television . Video game emulators have had to deal with this for a long time, to varying and increasing levels of accuracy. Televisio…
That particular problem isn't a case of emulating the television, but rather accurately emulating the console's video hardware and its interactions with the rest of the system. If one were simply interested in emulating the television's behaviour then you could construct a frame buffer based on the visible sprites and postprocess that (possibly in conjunction with several preceding fields). If the console allowed sne…
However, it should be pointed out that the behavior seen in Air Strike Patrol is due to the developer not adhering to the letters of Nintendo's development guidelines. They found a sneaky way to utilize the SNES hardware, and one Nintendo hadn't foreseen. It's thus the only game making use of those mid-scanline effects.
Also, for a quick comparison of the benefits of accurate SNES emulation, check this overview on the website of byuu, author of bsnes: http://byuu.org/bsnes/accuracy
Re: Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
#20Or consider Air Strike Patrol, where a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extraordinarily resource intensive to emulate. So what's really going on here is that the emulator must emulate not only the SNES hardware, but also the television . Video game emulators have had to deal with this for a long time, to varying and increasing levels of accuracy. Televisio…
Is anyone else reminded of the "copper" effect people would do back in the day where they would cycle the colors of a screen in sync with the horizontal refresh of the monitor to create bars of color the oscillate up and down in really cool patterns?
Indeed. I did copper too, in DOS x86 assembly. Some programs used it to practical effect: you can exceed 256 colors in an 8-bit framebuffer by swapping palette values mid-screen or mid-scanline.
In fact, every Atari 2600 game is a copper effect. The 2600's graphics chip is one-dimensional, working with only one scanline at a time. To display a picture, the software must run in lockstep as the electron beam traces down the screen, changing sprite bitmaps and colors and positions each scanline as appropriate. In other words, the 2600 literally uses the phosphor on the physical TV screen as the frame buffer. No surprise that this was tricky to emulate, and why 2600 emulators took longer to reach usable compatibility levels than emulators for the later more powerful Nintendo systems.