WebGL:
http://blog.wolfire.com/2009/09/preview-...-canvas3d/
http://webkit.org/blog/603/webgl-now-ava...nightlies/
http://hacks.mozilla.org/2009/09/webgl-for-firefox/

Contest: make a game, any game, with WebGL. Start now, finish before the end of the weekend. Go.

[ Be aware that enabling WebGL in general is a security risk at this stage, so you may not wish to wander round the general internet with it turned on ]

Usual mini-contest rules -- no prizes, peer judgment by forum poll after the fact.

We've just discovered that WebGL is nonfunctional in the latest nightly build

It's known to work in 50039 from http://nightly.webkit.org/builds/trunk/mac/2 . If anyone finds a better build that works, please post

here's a direct link to the nightly build that has working WebGL (for the lazy )
Working WebGL Nightly

Unfortunately, a bug in current WebKit WebGL means that images with transparency will unavoidably load with pixel junk in the transparent bits. This requires either loading an uncompressed image with a WebGLArray object to work around, or patching WebKit to fix. The patch is trivial (adding a memset, or CGClearRect, or similar to zero the bitmap context's data before drawing the image in imageToTexture() in WebCore/platform/graphics/mac/GraphicsContext3DMac.cpp); I may attempt to build a patched WebKit if I have time.

The FireFox nightlies seem to have worse problems, multiplying the viewport dimensions by 2 or 3, or something weird like that. They're also throwing syntax errors for my shaders for reasons not obvious to me.

WebKit doesn't want to build for me, so I don't know how to fix this bug...

I found a cheap workaround: use a sufficiently large texture that the memory WebGL happens to use happens to be zeroed already.

Where I'm at, in case my asset loading code is of use to anyone:
http://github.com/OneSadCookie/WebGLGame

OneSadCookie Wrote:I found a cheap workaround: use a sufficiently large texture that the memory WebGL happens to use happens to be zeroed already.

Heh, they are probably using CG stuff to load them. Had the same problem on the iPhone. If you didn't zero the array that you load an image into, it would be composited over garbage pixels. Can't really do that in javascript...

It's awesome that you're using WebGL it would be great if you could file bugs on the various implementations when you find them.

For the webkit implementation (eg. Safari and Chrome) the bug database is
http://bugs.webkit.org

And for mozilla it's
http://bugs.mozilla.org

For those of you who are having difficulty with the current webkit (and presumably shortly mozilla) nightlys, the WebGL spec recently changed to have a single shared "experimental" prefix rather than the typical vendor prefix. The new string to use for getContext() is "experimental-webgl".

The problem is that the CGContext they draw the image to is out of your control. You can load the texture from an Image, or from a Canvas, but either way, it goes through the same CGImage->CGBitmapContext(nonzeroed)->texture path, behind the scenes. I thought maybe using the Canvas would skip that, since presumably there's already a CGContext for the canvas, but it doesn't help.

After getting the new webkit, you'll need to run this:

Sounds like a fun contest. WebGL sounds like a pretty great asset to game makers, especially alongside Webkit's fast JavaScript.

I'm limited to iPhone Internet for the moment, otherwise I'd take part. Good luck to anyone who's entering though.

The game now works online, so if you've got a WebKit nightly with WebGL enabled and working, you should just be able to point your browser at http://onesadcookie.com/~keith/WebGLGame/ and play.

The "make a big enough texture to avoid the garbage" solution to the bug I mentioned above is not perfect. For most people, on a freshly-opened WebKit, there'll be no garbage. On subsequent loads, the garbage will get worse and worse until it's unbearable. For some people, every load will be garbage. YMMV.

I'm using HTML5's <audio> to play sounds, and that's causing lots of crashes in FigCRABSInvalidate on 50039 at least.