Slashdot Mirror


Firefox 3D Canvas FPS Engine

axonis writes "Benjamin Joffe has developed Canvascape - "3D Walker", a simple javascript browser based 3D first person game engine that shows off the capabilities of the Canvas tag found in Firefox, Safari and Opera. " Don't expect much except a proof of concept ;)

14 of 280 comments (clear)

  1. overhead by jacquesm · · Score: 4, Interesting

    Think about the overhead, here is a triple-layered game engine ! Wonder what you could really do with these machines if you hard coded them 80's style in assembler...

    1. Re:overhead by bradbeattie · · Score: 2, Interesting
      Wonder what you could really do with these machines if you hard coded them 80's style in assembler...
      Not much more than if you coded it in C. Compiler optimizations pretty much took the place of tricky assembly programming.
    2. Re:overhead by squiggleslash · · Score: 3, Interesting
      While I generally agree that you'd end up with something more practical (faster, less likely to break - or at least, less likely for it to be a problem if the binary breaks, on a CPU upgrade) if you write it in C, it's a bit of an exaggeration to say it'd take months vs half a day doing it in assembler vs doing it in C. As long as you think in a high level, and attempt to program with elegance coming before clock-cycle counting, assembler programming can be tremendously quick, once you're in the mindset.

      The big issue is that assembler code doesn't have a lot going for it, so most people who program it these days do it for the extremes where nothing else will do - the glue to start a C program, that kind of thing. Worse still, a lot of it is device driver code designed by people who really aren't programmers. It's hard to find good assembler code in the 2000s. Those of us who were programming Motorola 68xxx code in the 1980s though know elegant, readable, maintainable, well structured, assembler code, generated no more slowly than stuff in C isn't impossible. As it's not as maintainable as the equivalent in C, nor as portable, nor as fast, it's just not worth doing any more.

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:overhead by Guspaz · · Score: 3, Interesting

      Because actual 3D games require far too much data to be practical as applets...

      I disagree. The shareware release of Doom 1 was only 2.9MB compressed, and look at how much content it has. 2.9MB for all sounds, music, maps, code, etc. The game has a limited low-res textureset that is used creatively, used MIDI for music, and had a small number of sounds.

      It isn't a matter of requireing too much data, it's a matter of not being able to use the same mindset when coding games for such platforms.

      I'm not even a game developer, and I can think of a few tricks. For one thing, stream content as needed. Assume the player has broadband. Stream content as you play. Yes, have a loading screen, and use that initial load to grab the content for the first level. Then, while the user is playing, grab the content for the next level or two. Assuming low-end DSL (half a megabit), and 10MB of compressed content per level (Which can store a TON of content), you've got three minutes of load time per level. The initial load time is going to be the big crunch, because after that you can use gameplay time for downloading the next level.

      You can also reduce initial load times by prioritizing content and streaming it in as-needed. If you have a level that is going to have 10 or 20 minutes of gameplay, then you don't need to load in sounds and textures that are only going to be used 15 minutes into the game. Those can be loaded while the user is playing. They only initially need to load stuff that is going to be present in the first few minutes of gameplay.

      Another trick is procedural texture generation, where textures are mathematically generated rather than stored as bitmaps. And of course there's always the trick of combining multiple low-res textures to create higher res ones, like Halo did for terrain.

      And assuming you have a 10 megabyte budget per level, you can always get more out of that by using textures from previously-loaded levels. This has the side effect of the game getting more graphically diverse as the player progresses, so it may not be something you want.

      Anyhow, I think that considering how much can be done with a mere 2.9MB of data, having that much or more PER LEVEL can lead to some pretty good looking content.

    4. Re:overhead by Suddenly_Dead · · Score: 2, Interesting

      Try pouet.net or other "demoscene" websites. The Demo Scene guys still do a fair amount of stuff in low level languages, especially for the 64k (or smaller) competitions. Some of the stuff they do is quite amazing, for its technical merits as well as the artistic aspect.

    5. Re:overhead by coopaq · · Score: 2, Interesting
      Here's a fake example I wrote using just DIV and IMG tags.

      games

    6. Re:overhead by jcnnghm · · Score: 3, Interesting

      I ran a basic benchmark to test this theory a couple of weeks ago. I wrote a very basic selection sort in asm, then rewrote it in C++. The asm took 25 seconds to sort 100,000 random 32-bit numbers whereas the C++ took 45.

      I would suggest compiling performance sensitive apps to asm, and then optimizing nested loops and some comparison orderings. It is possible to get a lot better performance out of assembly.

      --
      You don't make the poor richer by making the rich poorer. - Winston Churchill
  2. Wiki by BibelBiber · · Score: 5, Interesting

    Now include a Wiki environment and people can dynamically built and develop on the levels. Looks nice, really.

  3. Opera 9 preview 1 by sucker_muts · · Score: 4, Interesting

    In opera 9 preview 1 it works, but incredibly slowly. I get about 1 fps, because it reloads all the scenery and redraws the white walls with every move.

    Perhaps because the /. effect? Or is javascript not dependent on the server? Or is the implementation for javascript in opera not optimal?

    --
    Dependency hell? => /bin/there/done/that
  4. end result VRML without VRML by Danathar · · Score: 5, Interesting

    Its funny to see things popup that have been done before but with standards that never made it....

  5. At least... by winphreak · · Score: 1, Interesting

    ...it's better then being in Flash.

    And it seems the programming schools that claim games can be made in JS weren't lying.

    --
    "I'm a well-wisher, in that I don't wish you any specific harm."
  6. One more reason I 3 Firefox 1.5: 3D Canvas by Bushido+Hacks · · Score: 2, Interesting

    First thing I like about 1.5 is that SVG is now supported. The Second thing I like about 1.5 is the 3D Canvas FPS Engine. What will really win me over is if they offered VRML/X3D support.

    I'm taking a peek at the source codes for this web page and they are very well written. He says it does not have much direction at this time. On the contrary. This project has much potential.

    --
    The Rapture is NOT an exit strategy.
  7. Re:Firefox Compatibility by zootm · · Score: 2, Interesting

    Yeah, the <canvas> tag was introduced by Apple, so they were first-to-market with this one. Looks neat, which is probably why it's being adopted by others.

  8. Re:Not just for games by LnxAddct · · Score: 3, Interesting

    Here is a cellular automata simulator I've written. Right now I'm working on a simulator for Conway's Game of Life, here. Next I'm doing an interactive whiteboard using AJAX and then I was thinking about a ray caster like the one in the article but a bit more optimized and possible doing textures. The possibilities with <canvas> are pretty significant, I think we're on the verge of a web revolution.
    Regards,
    Steve