I don't get it, sure it's impressive, kind of like a Rube Goldberg machine is impressive. But let's step back a second - isn't it a sign of a monumental failure of computer programming that we're gawking at a machine which can perform ~6 billion calculations/second (not counting the GPU) displaying a 310 by 190 "3d" maze at ~25 frames a second?
Try filling any modern screen buffer (>1024x768) pixel-by-pixel, just as software rasterizers do, even with just a solid color. You'll find it takes a long and quite frankly unacceptable time (for real-time apps at least), even with modern processors.
Even at 1024x768 (@ 25 frames/sec), you are given just ~300 cycles/pixel, which is gone quickly after slow memory accesses and multi-cycle instructions.
Try filling any modern screen buffer (>1024x768) pixel-by-pixel
Sure, if you completely throw away SIMD, things might be slow.
you are given just ~300 cycles/pixel, which is gone quickly after slow memory accesses
Memory accesses are pipelined and are generally not slow; an L1 cache access is 3 cycles and prefetching on modern CPUs is generally flawless for such situations.
multi-cycle instructions.
Since when do you need multiplies to fill a screen with a solid color? Even if you had to do YUV -> RGB conversion, that is done much faster with a multi-dimensional LUT than with multiplies (see swscale). Of course it's even faster in SIMD.
It's quite possible to do very fast rasterization on modern hardware without a GPU. It's just that people generally don't do it, because everyone has GPUs to do it for them.
Why do our expectations drop so drastically just because something is downloaded from the web and run in a browser? Not that there's anything wrong with that, but accessing something via web and running things naively aren't necessarily mutually exclusive.
Anyone know what specs are needed to run Crysis at the performance as in the video? My impression is that you still can't do it with mainstream hardware.
I was thinking pedantically that there are more powerful "computers" available than a high-end PC and they would be able to do even better than this example, but then it occurred me that it's also possible that game engines are the most sophisticated physics/graphics engines... worldwide, they probably have more attention and money focussed on them than even the US military could afford (guessing).
You can play Crysis just fine on a at 1600 x 1200 on a 700$ gaming system today. 90% of what you see is done by the graphics card, and for $180 you can get a GTX 260 which plays crisis just fine. Leaving 500$ for the rest of the system which is still ok. (http://www.newegg.com/Product/Product.aspx?Item=N82E16814150...)
That demo is also at a lower resolution than 1600 x 1200.
However, the average frame rate is almost useless, it's the minimum that's important and an absolute minimum of 24FPS on the most demanding demo is perfectly playable. Mostly when you play the game it's far higher than that, but in the middle of a huge firefight when vegetation is being chopped to bit's it's still playable.
If you're going into plugin route, then Java applets can already do OpenGL without any hacks, and will blow away anything that Flash can do. Quake 2 has already been ported, for example (http://download.java.net/javadesktop/plugin2/jake2/).
Incredible stuff. Do you know if this is using anything intrinsically Flash-only, other than a fast VM? It looks like a software rasterizer - is there anything preventing a port to some kind of Javascript/HTML setup?
It is software rasterizing, written in haXe. I know the author from his posts on the haXe compiler ML, so I have a few details about the engine. haXe itself compiles to JS/C++/PHP/etc., however the only way that engine could possibly be fast enough is to make use of haXe's Flash-specific "Memory" API, which uses opcodes from Adobe Alchemy to manipulate a flat memory space at the byte-level.
While it could definitely be ported, you'd have to change the part of the implementation that makes it fast to do so. If JS got a similar ability to do byte-level manipulations, it wouldn't be out of reach, but right now it looks like JS implementations are avoiding these kinds of proprietary extensions.
I think this version doesn't use the "Memory" API. I have two versions, one that uses it and one that doesn't and the difference is very minimal - not worth to drop the Flash 9 support at least.
I'm not sure if RF2 can be done in regular JavaScript though. Maybe in Chrome 3, which about twice as fast in my 3D canvas benchmark test (this one: http://gimme.badsectoracula.com/canvas3dbenchtest.html ). But Flash works 'equally' in almost all browsers while JS+Canvas is very browser specific when it comes to performance.
You could, and I've seen, versions that use loads of <div> elements which get resized, or you could use a ton of <img> elements. So it's certainly possible without canvas, but I'm not sure how the frame rate would compare.
You use the piece you want then scale it. For distance, make it smaller, for viewing something that is on the side you shrink it in width while leaving the height alone, this gives the illusion that it is slanted.
It would not be possible to do true 3d with this because you would need to scale something into a trapezoid which HTML can not do.
The guard png implies that you can shoot (and get shot), but I could not get that to work. By the name of the URL looks like there should be a step 6.
This rocks. So many Javascript demos that we see here are just rehashes of things we all did as demos back in the days of Netscape Navigator. This actually does something you couldn't have pulled off a few years back.
