Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Nintendo Games

A Quest For the Perfect SNES Emulator 227

An anonymous reader sends this excerpt from the Opposable Thumbs blog: "It doesn't take much raw power to play Nintendo or SNES games on a modern PC; emulators could do it in the 1990s with a mere 25MHz of processing power. But emulating those old consoles accurately — well, that's another challenge entirely; accurate emulators may need up to 3GHz of power to faithfully recreate aging tech. ... As an example, compare the spinning triforce animation from the opening to Legend of Zelda on the ZSNES and bsnes emulators. On the former, the triforces will complete their rotations far too soon as a result of the CPU running well over 40 percent faster than a real SNES. These are little details, but if you have an eye for accuracy, they can be maddening. ... The primary demands of an emulator are the amount of times per second one processor must synchronize with another. An emulator is an inherently serial process. Attempting to rely on today's multi-core processors leads to all kinds of timing problems. Take the analogy of an assembly line: one person unloads the boxes, another person scans them, another opens them, another starts putting the item together, etc. Synchronization is the equivalent of stalling out and clearing the entire assembly line, then starting over on a new product. It's an incredible hit to throughput. It completely negates the benefits of pipelining and out-of-order execution. The more you have to synchronize, the faster your assembly line has to move to keep up."
This discussion has been archived. No new comments can be posted.

A Quest For the Perfect SNES Emulator

Comments Filter:
  • I don't care how many times the triforce spins. Seriously.

    • by FhnuZoag ( 875558 ) on Wednesday August 10, 2011 @05:52AM (#37042100)
      Haha, yes. I can't wait for the new wave of emulators that make you blow on your hard drives before your roms will work.
    • no, but he does cite a more practical example. Speedy Gonzales doesn't work right on most emulators it seems.

    • Well, there is a difference. Here's a ZSNES emulation of the LTTP intro [youtube.com], which you can compare with the Speed Demos Archive run [speeddemosarchive.com]. SDA don't actually accept emulator runs, so the video there is from an actual SNES.

      Now, the TAS videos run [youtube.com] doesn't display the same problem, but that was probably run from Snes9x, not ZSNES(technically from a custom Snes9x build supporting re-recording). So the issue is not the processing power required but simply the fact that the Snes9x and ZSNES developers focused on different features.

      Overall, it can be seen from all three videos that in general, a good emulator can emulate the underlying hardware with extremely high fidelity for the vast majority of games and gameplay.

      Fidelity isn't a burning issue in modern 8 or 16 bit emulation. Emulators are now literally concerned with advanced features like recording, "rewinding", and video and audio filters that actually improve the games graphics and sound beyond what the hardware was capable of. The only outstanding feature I personally feel is missing from most emulators is cross platform support.

      • by Hatta ( 162192 )

        Fidelity isn't a burning issue in modern 8 or 16 bit emulation.

        Fidelity is the only thing that matters. Compare any emulator besides Nestopia or bsnes to the real thing. It's not there yet.

        Emulators are now literally concerned with advanced features like recording, "rewinding", and video and audio filters that actually improve the games graphics and sound beyond what the hardware was capable of.

        They really shouldn't be. Recording can be done by external apps. Rewinding, meh, that's just cheating. And v

        • And video and audio filters never look or sound as good as the real thing.

          I still have an SNES, and used to play a ton of ZSNES. I also used to play a lot on a GBA emulator. After using some of the graphics filters, I completely disagree. Try blowing a GBA game up to 800x600 without a filter, and then try it with a filter, and tell me theres not a world of difference.

          • by Hatta ( 162192 )

            I like nice crisp pixels more than I do a blurry mess. I don't even like the filter that comes with the GBA player.

            I never do anything but nearest neighbor scaling, unless it's actually rendering the source at higher resolution, e.g. ePSXe in high res. That works well because the 3d models are vector in nature. For sprites, I don't care whether it's bilinear filtering or if it's HQ3x, I'll pick the nice crisp blocky pixels every time.

            • by Guspaz ( 556486 )

              I'd love to know how you got crisp blocky pixels from your NES in the 1980s, because I certainly didn't. I got a wonderfully softened image from the 1980s TV tubes, and "crisp blocky pixels" are the opposite of fidelity.

              True fidelity would also simulate the display presentation. The simple TV filters provided with most emulators do an OK job, although they normally just do horizontal linear interpolation and then simulate a scanline effect for the vertical. But some people out there go farther than that and

              • by Hatta ( 162192 )

                You have a point there. Pixel perfect display is not fidelity, but that's one case where I think it's actually an improvement. In fact, I go as far as to upgrade my actual console's video-out to get the best display I can. RGB out on a CRT is really a thing of beauty.

      • Comment removed based on user account deletion
        • Funny that you should mention emulating a xbox, as that's what I use for my emulating needs. I spent about four months without the use of a PC for gaming and so bought a premodified xbox. The shop was nice enough to load it up with a wide selection of emulators and roms. I still use it everyonce in awhile to play games with visiting nephews.
        • by Guspaz ( 556486 )

          There are a few xbox emulators. The most famous of which is Cxbx, which is still semi-actively maintained (in a fork after the original author abandoned it):

          http://shogun3d-cxbx.blogspot.com/ [blogspot.com]

          It's not the only one. There was another one that came out early on that emulated Halo (and only Halo). Like Cxbx, it was also a high-level emulator. I don't remember the name of that one. Another is DxBx, which has a handful of playable games. There might be some others.

          Overall, the reason why XBox emulation is so prim

  • Chipsets (Score:4, Interesting)

    by WorBlux ( 1751716 ) on Wednesday August 10, 2011 @05:45AM (#37042056)
    Isn't the chipsets used just about out of patent, and thus allowing perfect emulation by including a copy of the chips used on a USB device?
    • That's not emulation, that's having the actual hardware. You may as well just build a whole snes...

    • Re:Chipsets (Score:5, Informative)

      by AmiMoJo ( 196126 ) on Wednesday August 10, 2011 @06:34AM (#37042290) Homepage Journal

      Latency on USB is terrible. It just isn't designed for that sort of thing.

      The problem that the summary alludes to is context switching, changing from one task to another. Every time you do it you have to save data from one task to memory and reload data for the next one. Most operating systems do that and it isn't a problem when you are only switching 1,000,000 times per second even for a fairly low end console.

      Amiga emulation was thought to be nearly impossible because of this, but some clever chap realised that you can do a fairly close approximation and get a reasonably good result while running at the speed of the original machine. TFA doesn't make it clear but I think what it is trying to demonstrate is how the CPU can end up running too fast because in an actual SNES the other hardware causes wait states for memory access and the like which effectively slows it down. Say the CPU wants to access video memory but the graphics chip also needs to use it. Since the graphics hardware can't wait (it would cause corruption on the display) it gets priority and the CPU has to wait instead. The delay is handled internally by the CPU so there is no hint in the game's code that this is happening and a traditional emulator would not take account of it.

      • What everyone looks for in an emulator is a "cycle accurate" simulation of the hardware. Its pretty tough to do with any system loaded with custom chips, even more so when its clocked at an oddball speed (relative to PC clocks) like typical NTSC/PAL timings. Both the SNES and Amiga meet both criteria.
        • The emulators I have experiance with work by running in bursts. The "emulation clock" runs much faster than real time for the duration of the burst then stop until the next burst is due so there is no real problem with the emulation clock being a weird speed relative to PC clocks.

          Afaict the main problem is determining all the performance interdependencies of the real hardware and then coding those interdependencies without adding unacceptable performance pentalties to the main emulation loop.

          • by Hatta ( 162192 )

            The emulators I have experiance with work by running in bursts. The "emulation clock" runs much faster than real time for the duration of the burst then stop until the next burst is due so there is no real problem with the emulation clock being a weird speed relative to PC clocks.

            Seems like that would cause problems with input latency.

            • Depends how long the bursts are. Afaict the norm is one burst per frame but there is no real reason the bursts couldn't be shorter than that if desired.

      • If the device itself was running all of the processing, the latency shouldn't be an issue. USB gamepads do not have noticeable latency, so theoretically a program could be written to pass a ROM to the USB device, handle the sound and video output (SNES were rather low-resolution, bandwidth on USB shouldn't be an issue), handle battery-backed RAM (for saves and such), and send control input from the keyboard or gamepad(s).

        The real question I would ask is if this is even emulation at this stage, so much as a

    • Yes, and you can buy reproduction SNES consoles (and even NES/Mega Drive/SNES combo consoles) online for about $30-50.
      • by Hatta ( 162192 )

        You can, but the reproduction quality is universally poor. You're better off emulating than you are using any clone console.

      • But are these running hardware chips or are they running general purpose CPU's with emulators?

  • I love bsnes. Performance mode only takes about a Pentium 4. It performs perfectly. No crashing or heavy visual glitches. The sound works great. The qt UI was nice, much better than the hacked together UI of zsnes, but I haven't tried the newer phoenix UI. If you have the processing power, there is no reason to put up with zsnes's glitches, crashes, sound problems, or any other quirks any more.
    • But how much time do you seriously spend in the GUI of the emulator? As long as it plays the game, I would be happy running it from the command line.
      • Actually, a command-line interface would be *better*, because then it would be easy to write your own GUI launcher, or call it from XBMC or whatever.

        Think in terms of a little shell script that just meant you could run a ROM as if it was a normal app.

        • That's the way I run mine on MythTV. I wrote my own menus, and when the emulators are launced from the menus, the Exit button on my universal remote is mapped to the keys to exit the emulator.

        • by tepples ( 727027 )

          Actually, a command-line interface would be *better*, because then it would be easy to write your own GUI launcher

          But with a command-line interface, how would one reconfigure game controls after having already started the game?

        • That isn't the problem. Most emulators do have extensive command-line configuration. The problem is that most users don't go near these settings and they aren't well documented. If all you want to do is enjoy a couple of classic games now and then it's hardly worth trying to get your head around the obscurity.
          If you're willing to invest a couple of hours you might be able to configure your perfect emulator, but with a nice GUI you could have everything you want in minutes.

  • by Windwraith ( 932426 ) on Wednesday August 10, 2011 @05:53AM (#37042102)

    I played a lot of SNES games when I was a kid. Then I played those games when I was older in an emulator (it's easier than dusting off the console).

    Any difference is pretty much minor detail. Your memory won't really tell you stuff you see in a modern emulator is wrong, because most people doesn't memorize the amount of time a triforce takes to spin around, and probably doesn't care as long as it shows OK.

    I think you only need emulation that faithful when you are actually writing software for the SNES using an emulator. (Hey, it happened for the NES, why not?)

    • You evidently didn't RTFA, where the author enumerates a few cases where the glitches in emulation make for either unwinnable games (like Speedy Gonzales) or for materially worse gameplay (like Air Strike Patrol).
      • Yeah you got me. I saw the news in the RSS feed and posted without having my morning coffee. Now I did, read the article, and wondered why Slashdot doesn't have a delete comment option.

        Either way, seems I am pretty lucky, because I never got such misbehavior when playing emulators. Much less a crash, even under PSP or other homebrew+lowend emulators.
        At most I notice some sound effects sounding different than in TV, and I recently saw someone playing Doom in an emulator and it had rounding errors in the rend

        • by Luckyo ( 1726890 )

          That's not luck. As author notes in the article, popular speed-focused emulator have game-specific hacks for about 50-100 most popular titles, that enable them to work "good enough".

          • I honestly doubt I am playing "50-100 most popular titles", precisely one of the beauties of SNES is the incredibly good software that never left Japan or was too obscure to hit cult status, or software never released in Europe.

            Out of the games I play often, I think the only ones having speedhacks are Terranigma and Illusion of Time/Gaia, I guess Earthbound. I can assert without any doubt that stuff like Great Battle V, Nightmare Busters, Wild Guns, Ninja Warriors Again, Thunder Spirits (sort of like the SN

            • by Luckyo ( 1726890 )

              Not "50-100 most popular titles in retail", but "50-100 most popular among those who emulate".

              In most cases it's a pretty good guess that whatever you're playing is also played by many others. There are obviously exceptions to this, and it's quite possible that you are among the small minority that really does need games that no one else plays.

              There's also an issue of people hacking roms themselves to get them to work with zsnes. Many of the huge torrented libraries you find on the net in fact include such

    • by iYk6 ( 1425255 ) on Wednesday August 10, 2011 @06:14AM (#37042190)

      You seem to be missing the point. The triforce spinning was probably a bad example, since it's not that important. The problems with inaccurate emulators range from annoying visual glitches, to crashes, to actually making a game unbeatable. Star Ocean, for example, will sometimes crash in zsnes, but I haven't experienced that in bsnes. The battles run at double speed, much like the triforce in LTTP. Playing Yoshi's Island in zsnes, any level with those giant fuzzballs will tick every time you move. It's nauseating to get through. In zsnes, Super Mario RPG battles will sometimes de-sync to the point that the music and animations will continue, but your input will no longer work and you have to reset the game.

      In Speedy Gonzales - Los Gatos Bandidos, if you're playing with zsnes, you can't even beat the game, because it doesn't emulate everything necessary to do so. In Sink or Swim, the room fills with water, and you need to swim above it. But because of timing and speed issues, the room fills up much too fast and you will drown instantly.

      You can read about some of these issues, and many more, here: http://byuu.org/bsnes/accuracy [byuu.org]

      • I admit I didn't RTFA, although I never experimented such issues...for whatever reason.
        Although you happen to mention games I only played on real hardware...never really tried emulating them. But I will take your word for it.

      • Touch Fuzzy, Get Dizzy

  • 3GHz for a SNES? Makes you wonder just how accurate MAME actually is.

    Then again, when you go as for as photographing a rom chip under a microscope [blogspot.com], I guess there's no doubting the level of dedication.

    • by Luckyo ( 1726890 )

      Nothing new, same was done for speciality chips in SNES cartridges.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      MAME isn't accurate, it's just badly coded. Accuracy is an excuse the current developers use because they're not actually very good programmers, and many of the performance issues just boil down to poorly implemented core features.

      To get a like-for-like comparison, MESS is a side-project of MAME using the MAME code to emulate consoles. It has to rank as one of the worst in terms of both performance AND compatibility. It's actually slower than BSNES and has a compatibility rate worse than ZSNES of 10 year

  • by neokushan ( 932374 ) on Wednesday August 10, 2011 @05:59AM (#37042130)

    I must have been using ZSNES for over a decade now, possibly even longer. Snes9x was pretty good, too. I never had much of an issue with either emulator, as far as I was concerned, it played the games and it played them just fine. The odd glitch, maybe, but nothing that put me off completing a whole bunch of games I played as a kid, or missed out on.

    However, I do agree with the author of bsnes that "just fine" isn't really acceptable when you want to preserve the computer you're emulating, not just play some games. I believe MAME takes a similar approach, aiming for accuracy rather than speed (Which is why it runs mostly in software and not hardware, hence 3D games like Tekken run very slowly) as MAME is primarily about preserving the games and not just playing them.

    Computing power isn't really an issue, computers will only get faster and faster over time. The computers in use 10 years ago would be eclipsed by even a mid-ranged smartphone today. In 10 years from now, when there's even fewer working SNESes out there, it's good to know that the code will be portable to whatever machines we have at the time and that it'll run games as they're intended. It's not unthinkable that someone might unearth a previously unknown SNES game cartridge only to not be able to find a SNES to play it on. bsnes may well be the only emulator capable of playing it, for one reason or another.

    • by jez9999 ( 618189 )

      Every now and then, when entering/exiting a room/cave in Secret of Evermore, in ZSNES the game just hangs at a black screen. For this reason (and various other important accuracy issues mentioned in byuu's page), I started using bsnes as my SNES emulator and never looked back.

      I would like to see bsnes have recording functionality but you can't have everything. ;-)

  • Hz != Power (Score:3, Insightful)

    by Anonymous Coward on Wednesday August 10, 2011 @06:02AM (#37042142)

    3GHz is a measure of frequency, not power. Words mean things, use them correctly.

    • by tepples ( 727027 )
      Power is work per unit time. Frequency is cycles per unit time. Assuming work per cycle is constant, power is proportional to frequency. So what was your objection?
      • His objection is almost certainly that work per cycle is not constant. Why assume something that is clearly false?

        • But it is constant, once you get the time per cycle to be granular enough.

          Think of it as approximating a curve. The more "samples" per second, the closer and closer to the actual curve you get. Except in this case, the curve really is stepped once you get close enough, which means it's not an "approaching infinity" problem any more.

        • by tepples ( 727027 )

          His objection is almost certainly that work per cycle is not constant.

          To me, the wording of AC's comment sounded like a pedantic "Quantity X and quantity Y are not commensurable [wikipedia.org] and thus can never be compared" retort. So I offered a unit conversion by which they could be made commensurable. A proper response, like Osgeld's below [slashdot.org], would begin to explain why this conversion factor is not constant.

    • hmm... ya caught that but didn't cathch this?

      as a result of the CPU running well over 40 percent faster than a real SNES. These are little details, but if you have an eye for accuracy, they can be maddening.

      SNES CPU frequency is 3.58MHz,
      40% faster than that is 5.01MHz

      There's the problem! He's using CPU's from the late 1970's to emulate a console from the early 1990's!

      • by Sancho ( 17056 ) *

        I assumed he was referring to the emulated CPU.

      • The Super NES CPU could run at two different speeds: 2.7 MHz and 3.6 MHz. The slower speed was for accessing RAM, as well as for accessing ROM while in slow mode. Flipping a bit would put the CPU into "fast ROM mode" where it could access ROM at the full 3.6 MHz speed. (A couple registers related to the controllers take even longer to access.) In addition, some emulators don't properly count the cycles that an instruction takes in all contexts. This would cause an emulated CPU to finish a method in fewer cy
  • If you take an old game that ran on a TV screen and emulate it in fullscreen on a modern PC, you will see every pixel clearly.
    You never saw those on the TV. The pixellated Super Mario character was designed with the signal to noise ratio of an old TV in mind. When a modern emulator does not blend these pixels together like old blurry TVs did, the graphics look more blocky than they ever did originally. I can still see this in emulated computer games as recent as monkey island 2, which I originally played wi

    • Do you mean something like this [byuu.org]?
    • I know some games' graphics appear to have been designed with TV output in mind. Old consoles take shortcuts in generating a composite video signal. These shortcuts produce visible artifacts, and a few games take advantage of these artifacts by placing pixels in odd places to produce richer textures with more apparent colors than the system can produce at once. NES emulators at least have been emulating TVs [slack.net] for years. I almost can't tell the difference between a game running on an NES displayed on my Vizio
  • Just check the Atari ST emulators which are capable of doing overscan. This is so timing dependent that the CPU has to be emulated cycle precise.
    Most do it scanline by scanline, only one, AFAIK does the real job: SainT (windows only)

  • by Truekaiser ( 724672 ) on Wednesday August 10, 2011 @10:30AM (#37044586)

    over zsnes. the sound dev for zsnes if i remember correctly is also the head dev for bsnes. both now require oss4.0 on linux for sound, he infact refuses to code zsnes to the specs and documentation on zsnes on purpose to push people to oss4(as in he calls the devices directly rather then through alsa-lib so library can do sound mixing on non hardware sound mixing cards for example). This is a no go for me due to what the company behind oss and oss4 did. years ago oss was the only sound system for linux, what people in the foss movement and people running linux in particular did not know was the company behind oss was just using them for free code debugging and feature improvement. Once the code matured to something that they could sell they closed off any more code improvements to the foss crowed and started selling their work. this royally pissed off a lot of people, enough that alsa was made so linux would always have a sound system that can't be yanked out from under them like that.
    years later the same company comes out with oss4, promising they won't do what they did before. the past experience plus the fact that some of the code in oss4 uses stuff that the kernel devs have now decided does not belong in the kernel as it could allow a single program to hard lock the machine. prevents it from being allowed in and not get the tainted kernel status which means your bug reports will be ignored. because of this the oss4 people like the one who makes bsnes and codes the sound system for zsnes cry 'i'm being prosecuted for using a Superior system!' alsa isn't perfect but it's better then the alternative that can and will get yanked out from under people once they deem it so after pulling the same trick again.

    so in short if oss4 is required for 'accuracy' i will take inaccurate but functional any day.

  • http://www.fpgaarcade.com/ [fpgaarcade.com]

    More focused on older arcade systems at the moment, but since it's powerful enough to "be" an Amiga computer I figured it's probably powerful enough to be a NES, SNES, TurboGrafx-16, Neo-Geo, etc

    • It's mentioned in TFA. Really. Go read it. If you're so lazy you can't be bothered, here's a summary: the author reckons FPGAArcade is great, but accessible to relatively few people.

  • TFA makes it sound like syching between threads is an open problem.

    It's not.

    And pipelining / OOO execution has next to nothing to do with synching between two cores, which operate on a much, much coarser level of granularity.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Working...