Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


A Quest For the Perfect SNES Emulator 227

Posted by Soulskill
from the do-a-barrel-roll dept.
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."

Comment: Gist of the article (Score 1) 599

by Nerzhul (#36598752) Attached to: The Enterprise Is Wrong, Not Mozilla

Browser version numbers are completely irrelevant. It's new features or changing behavior which is causing problems for Enterprises because they require a complete regression test of all internal web tools (in theory at least).

So even if FF5 would have been called FF4.0.1.1 the new features (CSS animations, more HTML5 support, various internal changes) would mandate a thorough regression test. You can't blindly roll out a new browser version just because the version number was incremented by 0.0.1 instead of 1.

Btw the FF3.6 branch received more than security fixes, e.g. changes to the way plugins are executed. The new version numbering simply highlights the faulty Enterprise processes.

Now, if Enterprises would simply code against standards there'd be much less problems in migrating...

Comment: FF5 release notes (Score 5, Informative) 282

by Nerzhul (#36518550) Attached to: Mozilla Ships Firefox 5, Meets Rapid-Release Plan

In case you're wondering what's actually new:

- Added support for CSS animations
- The Do-Not-Track header preference has been moved to increase discoverability
- Tuned HTTP idle connection logic for increased performance
- Improved canvas, JavaScript, memory, and networking performance
- Improved standards support for HTML5, XHR, MathML, SMIL, and canvas
- Improved spell checking for some locales
- Improved desktop environment integration for Linux users
- WebGL content can no longer load cross-domain textures
- Background tabs have setTimeout and setInterval clamped to 1000ms to improve performance
- Fixed several stability issues
- Fixed several security issues

Is your job running? You'd better go catch it!