Monday, August 9, 2010

Rendering Quake 3 maps with WebGL: Demo

So, after a good long delay it's finally WebGL demo time again! This one is pretty elaborate, but I feel like it was worth the effort:

WebGL Quake 3 - Q3TOURNEY2

A quick note: I've heard reports that Chrome 5 has trouble with the demo because I'm using the newer texImage2d signature. Your mileage may vary, but if you're having trouble give it a try with the Chrome dev channel.

Now, there are SOOO many things to talk about in regards to this demo: Optimizations, remaining issues, changes made to resources for web use, etc. Unfortunately I don't have the time to elaborate on them right now but I wanted to get the demo out there ASAP to get some feedback on it. Expect another post (or maybe an addendum to this one) within the next couple of days about my thoughts on Quake 3 bsp maps under WebGL.

(UPDATE: My ramblings about the demo are online now)

Have fun!

EDIT: Quick update. I've tweaked the code a little bit to reflect gero3's suggestion of combining the multiple event loops into one. It worked pretty well, and the movement in particular feels better for it (well, not the mouselook. Not much I can do there though). Not to mention the code now reflects a "traditional" game loop much more.

16 comments:

  1. Amazing work once again. Runs great for me with surprisingly high framerates; hovering around 60 (MacBook Pro, Chrome 6).

    Does highlight WebGL's need for fullscreen and better mouse input controls.

    ReplyDelete
  2. great demo but you I think it would get even better if those 2 setintervals were handled inside drawframe.
    Just use the timestamp to determine when you should handle them.

    ReplyDelete
  3. That's a good idea, thanks! I'll give it a try (probably tonight sometime).

    And yes, this kind of demo really does scream for things like fullscreen and high-resolution mouse input. But I've griped about that before, and for the time being it's probably best to just avoid FPS style games/demos. (I'm very bad at following my own advice, BTW ;)

    ReplyDelete
  4. Well look at that! Sounds like a fullscreen API is in the works!

    https://wiki.mozilla.org/Gecko:FullScreenAPI

    ReplyDelete
  5. Very cool demo, but is sad that Minefield gives me only 20 FPS on Core i5 - GT240

    ReplyDelete
  6. Limit the FPS by default. I'm getting more than 30.000fps and it just screwed my system.

    ReplyDelete
  7. Sorry, I think I missed something. You're getting more than 30 thousand fps? (Us silly Americans use commas as a numeric place delimiter) That's not while the demo is actually running is it? Because if so I want your hardware! :)

    In any case, I'll throw a upper limit on it. Maybe something like 200fps would be reasonable?

    ReplyDelete
  8. Okay, I've put in some safeties that prevent the render loop from firing until there's actually something to render. Hopefully that prevents any strange behavior caused by an overactive event pump.

    ReplyDelete
  9. Oh, sure. lol 30,000fps. I don't think it was the actual frame rate. :P

    ReplyDelete
  10. Actually, I've seen framerates like that on my machine while the map was still loading. It's not really a "framerate" at that point, since nothing is rendering. It's just a count of how many times the message pump is looping every second. Still, that kind of rapid pumping apparently has an adverse effect on the system. My mouse would start to become unresponsive if I left it in that mode for too long.

    That problem is solved, in any case. If you feel that getting framerates above 30 FPS is causing you trouble I'd need to know more about what kind of effects you are seeing.

    ReplyDelete
  11. This issue happened on Google Chrome. Since I get it installed on Windows 7 x64, WebGL apps that freely draws images repeatedly are crashing my system.

    I cannot test your app right now for my Google Chrome isn't updated. But I surely will test as soon as I can. :)

    ReplyDelete
  12. Another update: the newest versions of Chrome have dropped support for WebGL___Array types, which I was still using in my demo. I've updated the demo now to use the correct formats (Float32Array, Uint16Array, etc) which should keep all the browsers happy.

    ReplyDelete
  13. It's working with Chrome now. But as I said before: If "Cap FPS" is not set, it will get something around 500 fps and get slow.

    ReplyDelete
  14. This is most awesome! It seems to run much better than the GWT Quake II demo, and is really smooth on Firefox 4 as well. Well done!

    So there is no HTML5 API for mouse grabbing at all? That seems quite unfortunate.

    ReplyDelete
  15. Happy happy joy joy with my Rift and WebVR! 280FPS in 2D (i7 GTX770); no FPS counter in VR, but it's silky smooth. I do get stuck sometimes when I get too close to a wall, and AWSD doesn't work anymore, but a great demo of plug-and-play VR. Most excellent!

    ReplyDelete