Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

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."

Comment Gist of the article (Score 1) 599

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

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

Slashdot Top Deals

The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth. -- Niels Bohr