JavaScript Wolfenstein 3D Engine
devfiles.myopera.com
devfiles.myopera.com
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.
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.
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'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.
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.
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).
http://www.gamespot.com/pages/forums/show_msgs.php?topic_id=... for an actual gamers review w GTX 260.
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.
PS: I wish most reviewers would note the worst frame rate instead of letting 100FPS in some areas cover for sub 30FPS in others. EX: http://www.guru3d.com/article/palit-geforce-gtx-260-sp216-so...
But is that demo lower than 1600x1200? The Youtube video is; but I don't know about the demo.
I really hope that id release an sdk.
But that's not really the point, is it?
From the Source-
This file is part of the article series by Jacob Seidelin about creating a ray casting engine with JavaScript, DOM and Canvas.
If you have questions or comments, please contact the author at either jseidelin@nihilogic.dk or http://blog.nihilogic.dk/
The code samples here are freely available under the MIT license. See: [http://www.nihilogic.dk/licenses/mit-license.txt]
The graphics for sprites and walls are property of id Software.
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.
http://devfiles.myopera.com/articles/650/walls.png http://devfiles.myopera.com/articles/650/lamp.png http://devfiles.myopera.com/articles/650/tablechairs.png http://devfiles.myopera.com/articles/650/guard.png
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.
Well done.
It's just images in a row scaled to different sizes. The effect is amazing, but the idea is simple.