More pardonings of continued dust, if you please...

I'm going to be doing some more server shuffling over the next day or so, so I apologize if things are a bit up and down again. I'm working on it!


EDIT: Sorry for the downtime. I'm having some annoying issues getting my DNS entries sorted. In the meantime I've got tojicode.com redirecting to my blogspot address so everyone should at least be able to continue seeing the blog while I try and get a more elegant solution going.


EDITING THE EDIT: Alright, so it looks like the current configuration is stable so I'm sticking to it. blog.tojicode.com is going to be the official address, and for the time being tojicode.com will redirect to it. 

Obsolete texImage2D... Wha?

I've seen a couple of people around the web mention that with newer versions of WebKit they have begun getting the following warning in their console when running WebGL apps:

Calling obsolete texImage2D(GLenum target, GLint level, HTMLImageElement image)

Calling obsolete texImage2D(GLenum target, GLint level, HTMLImageElement image, GLboolean flipY, GLboolean premultiplyAlpha)



Things still work this way but obviously having the browser barf out a bunch of warnings is less than desirable. Fortunately a bright guy at http://darkhorse2.0spec.com/ (site is in Japanese) did some digging through Webkit's code and found the "right" definitions, which he lists. For me, I was able to get the errors to go away by changing my code from:


gl.texImage2D(gl.TEXTURE_2D, 0, image, true);

to:

gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image);


And yes, that works with Minefield too. (Well, technically Firefox 4 beta 1) Of course, this probably only works for me because I happen to know that all the images I'm loading are 32bit PNG's. I imagine that telling it the image is RGBA if you were using a JPEG may not work so well (I'll have to try that sometime soon), so your mileage may vary.

Why is there bacon in the soap!?

Just need to vent for 2 seconds: Can someone out there explain to me the logic behind not allowing Float32Arrays (or any other Typed Arrays for that matter) in Web Workers? Seriously?!? (And no, I'm not trying to fill GL buffers in a worker, I'm using them for binary file parsing.) Please at least tell me that this is in the works!

WebGL's greatest challenge as a gaming platform

[UPDATE: I noticed this post still gets a decent amount of traffic, so I figured it's worth pointing out that it's hopelessly out of date at this point. Microsoft supports WebGL now (mostly), JS is faster all the time and we have asm.js now to boot, and browser have largely embraced fullscreen, pointer lock, gamepad, and camera APIs. So, yeah... don't reference this post for anything. Ever.

Post is preserved here simply for the sake of mocking my (lack of) predictive powers.] 

This may come as a surprise to some of you, but I'm rather fond of WebGL. :) And if you've been following some of my demos you'll probably notice that they tend to have a somewhat game-oriented tilt to them. This is fairly natural for me, since I'm both a gamer and a programmer. It's two passions in one sweet package, kinda like a Reeses Peanut Butter cup.

Anyway, I'm a firm believer that as it matures WebGL will play a big part in game development, just as the web has already altered the game industry. I doubt that we'll ever reach a point that browser based games take over entirely, but they're going to keep getting bigger and better and the lines between desktop and browser games are going to blur. Some people will embrace this, some will fight it, and if nothing else it will be an interesting ride for everyone involved.

There are some key limitations, however, that need to be overcome before WebGL (and the browser as a whole) can really truly be considered a full fledged, general purpose gaming platform. And those issues are going to be hard to solve. Incredibly hard, for both technical and theological reasons. So hard, in fact, I'm not sure that the minds behind the web today are able to fix them, or even that they want to. In fact, I'm not convinced that they should.

glMatrix 0.9.4 (1.0 RC1) Released

I've just finished posting a new version of glMatrix (you know, that really fast javascript matrix library?) to Google code. The release number is 0.9.4 but I would like to treat it as a Release Candidate for 1.0.

I get the impression that some people may be disappointed by this release since for me it was more about house cleaning and documentation than any big new features or optimizations. A good deal of the issues I'm getting back for the library now are stylistic preferences, though, that involve restructuring or renaming the functions of the library to work or read a certain way. Some of these items I think are valid and some I feel are more a matter of personal preference, but in all cases I've decided that I would rather:

A) Get the library to a stable state
B) Get unit tests (a personal requirement before I can call the lib version 1.0) and better documentation in place
C) Get the library out to a wider range of developers and gather more feedback

before I make any big structural changes. Please don't consider this to be a rejection of any specific ideas that have been posted, I simply feel that the library structure is "good enough" for the time being and would like to let it mature a bit before shaking things up in a version 2.0.

That said I'd love to get any and all feedback on the library in it's current state so I can officially move it to a 1.0!

Finally, a Big Huge Thank You to everyone who has pitched in so far! Specifically:

jeroom832, Daniel Heres, Julian Walker, Denis Rangel, Aaku Kokko, and Drew Whitehouse

(And I'm terribly sorry if I missed anyone or misspelled any names!)