iDevGames Forums
WebGL Mini-Contest - Printable Version

+- iDevGames Forums (
+-- Forum: Community Zone (/forum-4.html)
+--- Forum: Contests (/forum-19.html)
+--- Thread: WebGL Mini-Contest (/thread-535.html)

Pages: 1 2

WebGL Mini-Contest - OneSadCookie - Dec 5, 2009 09:58 PM

The garbage-in-texImage2D bug is

WebGL Mini-Contest - OneSadCookie - Dec 6, 2009 01:15 AM

Thanks to olliej's tip about the context identifier and a bit of digging through the WebKit source to find a couple API changes, my app now works on the latest WebKit nightly (and I'm still supporting 50039).

WebGL Mini-Contest - ThemsAllTook - Dec 6, 2009 04:11 PM

Working on a 3D platformer here:

Doesn't do a whole lot yet, but I'll be updating that location periodically as I go along.

WebGL Mini-Contest - OneSadCookie - Dec 6, 2009 09:10 PM

ThemsAllTook and I at least have agreed that we're having enough fun here to take another 7 days over this contest. Our new ending date is therefore the end of Sunday 13 December 2009.

Any other entrants (are there any? nobody's posted!) can of course choose to finish at the scheduled time, or join us in this glorious extension! (no, I didn't get much sleep this weekend).

WebGL Mini-Contest - ThemsAllTook - Dec 6, 2009 10:02 PM

The link above now has 4 levels of gameplay. In case anyone's keeping score, this can be considered the "weekend version" of the game. I'll post a new link to the "extension version" once there's more to see.

WebGL Mini-Contest - AndyKorth - Dec 7, 2009 02:41 PM

Very cool alex! I won Wink Keith's is looking good too Grin

WebGL Mini-Contest - OneSadCookie - Dec 7, 2009 05:43 PM

Man, I haven't won Alex's yet :|

Latest WebKit nightly build (51788) fixes the transparent pixel-junk bug. Yay!

I'll probably start ripping out support for older WebKits shortly.

WebGL Mini-Contest - olliej - Dec 7, 2009 06:22 PM

OneSadCookie Wrote:Latest WebKit nightly build (51788) fixes the transparent pixel-junk bug. Yay!

Please file reports on any other bugs you find Grin

WebGL Mini-Contest - olliej - Dec 10, 2009 03:51 PM

Woo! There's now a public draft available at

WebGL Mini-Contest - vladv - Dec 12, 2009 09:04 AM

OneSadCookie Wrote: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 and play.

Looks pretty cool! I'm happy that someone's using danc's tilesets in a WebGL game :-) There are some bugs preventing it from working in Firefox, though... here's what I've found. Once those are worked around, it works pretty well Smile

There's a weird race condition in loadTexture/ResourceManager if the image happens to be the last thing to load. I see the 'load' event firing into prototype, which is handled by the xhrImage success function in loadImage... but that calls in to resman.loaded() before it calls the closure, and it's the closure that sets images['tiles'] to the image.

The ResourceManager success handler will then call loadPlanes, which eventually triggers the error() in drawYSlice, but the object still gets returned with a null 'image' property.. and all subsequent draws fail, because they try to grab command.image.width/.height, with image being null.

Checking for "if (!images['tiles']) return;" in the ResourceManager success handler seems like it could work, but if the tiles image is the last resource to load, then things never get initialized properly (because images['tiles'] will be null when we get into the ResourceManager's success call). My hacky fix was to just call the closure in loadTexture before calling the resource manager's loaded function.

The second issue is the 100% width/height in CSS on the canvas element... this is a WebKit bug that I think they're working on fixing. The CSS style dimensions are independent of the canvas backing store size, which defaults to 300x200 (iirc) if no width/height attributes are given. Setting width/height in CSS to 100% means "take my 300x200 canvas image and scale it up to 100% w/h", which is probably not what you want, quality wise. In this case, canvas.clientWidth/canvas.clientHeight is also used with gl.viewport, but the actual dimensions are 300x200, leading to nothing visible being drawn since you can only see the upper left corner :-)

Instead, you can attach a resize handler to the window and set canvas.width/canvas.height to the appropriate size on resize. Or, the hacky solution is to just set canvas.width/canvas.height from the window's dimensions on launch, as in start() in .

Hope that helps!

WebGL Mini-Contest - ThemsAllTook - Dec 13, 2009 09:58 PM

Well, I didn't get as much more done as I wanted to... New version uploaded with sound effects, another level, and a few tweaks:

Source archive:

WebGL Mini-Contest - OneSadCookie - Dec 14, 2009 11:40 AM

As you've probably guessed, I made no (visible) progress despite the extra week.

vladv: I fixed the load race condition (I hope!) before I saw your message, but thanks for the tip about canvas size. That explains what I was seeing in FireFox.