JavaScript Wolfenstein 3D Engine(devfiles.myopera.com)
devfiles.myopera.com
JavaScript Wolfenstein 3D Engine
http://devfiles.myopera.com/articles/650/step_4_enemies.htm
7 comments
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?
It really just shows that we're a bunch of web programming nerds.
No, not necessarily. You've been spoiled by GPUs.
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, 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.
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.
For comparison, what Flash can do now:
http://www.badsectoracula.com/peponi/rayfaster2/
For comparison, here's what computers could do outside the browser, two years ago: http://www.youtube.com/watch?v=ACQW8iVCbhY
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.
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).
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...)
http://www.gamespot.com/pages/forums/show_msgs.php?topic_id=... for an actual gamers review w GTX 260.
http://www.gamespot.com/pages/forums/show_msgs.php?topic_id=... for an actual gamers review w GTX 260.
thanks, but most of those gamers are noting low frame rates, less than 50 fps... while still playable, it's not as smooth as the '07 demo.
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.
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...
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...
Good point about min. frame rate.
But is that demo lower than 1600x1200? The Youtube video is; but I don't know about the demo.
But is that demo lower than 1600x1200? The Youtube video is; but I don't know about the demo.
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/).
But that's not really the point, is it?
But that's not really the point, is it?
For comparison http://www.quakelive.com/
I really hope that id release an sdk.
I really hope that id release an sdk.
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.
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.
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.
VERY cool! I've seen this before, but this is the best version yet.
How do they do it?
Is each frame created with HTML/CSS?
The CANVAS tag allows per pixel placement. It's what makes things like this possible.
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 [email protected] 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.
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 [email protected] 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.
>> "It's what makes things like this possible."
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 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.
Check the source. This one is done without canvas, and with div and img elements. The canvas elements used here are for the minimap.
It's png sprites:
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.
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.
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.
Well done.
Well done.
Actually, you could do this with Netscape Navigator, sorry to burst your bubble.
It's just images in a row scaled to different sizes. The effect is amazing, but the idea is simple.
It's just images in a row scaled to different sizes. The effect is amazing, but the idea is simple.
seriously...hard to believe that 12 years ago I thought my MIDI jukebox was as cool as javascript was going to get :)
HTML 5 with the 3D css feature should allow a whole different approach to this sort of thing, yes?
Wow this is a good javascript engine benchmark. Chromium 3 gets twice as many FPS as Firefox 3.5
Sir, I am impressed!