Starting with Sprites and Animation
You might've guessed from the names in the example I gave the other day, getting Ant to process XSLT2 with Saxon, that I'm doing some sprite animation stuff. I am. And so far my output is in DHTML. The whole development isn't perfect yet, but I've got a simple DHTML sprite that seems to work. If you're not familiar with the term, a sprite is an animated block. Every time I hear the word it reminds me of myCommodore 128. Sprites on that machine could be set up by poking colour values into the right spots in memory, basically drawing out a bitmap. Sprites are basically just little raster images that are animated by replacing frames quickly. After the little CSS mouseover example I threw in last week, I started thinking about how simple it would be to use the same technique to animate the background-offset value to create the illusion of animation. I know this technique has been done before - I don't claim to be the first - but it wasn't hard to build my own from where I was at already. The thing that really sucks is that SVG should make this sort of animation easier. Well, this sort and a lot of others. The SVG recommendation from the W3C includes extensive descriptions of support for SMIL, SMIL should be available to handle many kinds of animation. Unfortunately the only way to get SMIL in a browsers is with Adobe SVG ViewerSMIL support is not yet ubiquitous (it's available in Adobe SVG Viewer and Opera today). The fact that it's not available in all the native browser implementations of SVG means that you can't rely on it as a developer. If you're really into declarative animation or want to bank on native SMIL spreading in the future, you can get SmilScript, a clever innovation of Doug Schepers and Vectoreal. SmilScript will use Javascript to make part of SMIL available to your SVG.
I just wanted to put something simple together that will work, though. For today the quickest route to that for me is DHTML in the browser. Tomorrow, I can't say. So the approach I've started to develop is all about moving to an XML document that describes what I'm building and a method to transform that XML into the format that's most digestible for the browser. Call it a thin client again. Of course the 'thin' here is relative. The document that I serve right now uses HTML, CSS and Javascript. By moving my core logic out of the document delivered to the browser, I gain a couple advantages:
  • Changing the document format to suit the browser means changing one output component, not the entire design.
  • I can include a lot more bloat in upstream documents since they don't have to be processed by the client.
There are some big disadvantages as well:
  • I have a build phase (and the accompanying issues with archival and deployment).
  • It's way the hell more complicated. Just like writing Javascript code mingled with PHP, but a little uglier.
The only decent demo I have for today is the resulting animation (mouseover to start it up).   It doesn't look like much, but there's a lot of potential there. Since the graphic here was drawn in SVG then transformed by Batik into PNGs, I can use all the SVG that Batik supports. That includes filters for lighting and shadows (which I'll use once I get them to behave). With lighting it'll look more like this This post has turned out to be more of a brain-dump, so I apologize if it doesn't all make sense, but I'll have more details coming on what I think is going to be a pretty decent toolchain for developing web-based games.
Your rating: None

Opera 8.5+ has SMIL support too.

The demo is cool - but every time you mouse over it speeds up and looks worse and worse. You need to ensure in your JavaScript that init() is only run once (just make a global variable that latches true upon running once).

It's "Schepers"

Jim - Fixed, thanks. This is mentioned at the bottom of Doug's SmilScript page as well, I notice.
Jeff - Simple fix, but I've no FTP access at the moment.
stelt - Fixed, thanks.

I was running late for a very important date last night, being Valentine's and all I put the love life ahead of the blog life.

[...] I got a little furthur with the websprites demo I started earlier this month. I’ve decided to hold off on the XSLT source document for now since I find the development toolchain just gets too long for me at this stage. Maybe when I have more documents to generalize from I’ll go back to using XSLT for the source. After all, isn’t that what XSLT is for? Transforming many documents with the same semantics in a similar fashion? I found that I didn’t have a thread to extend from. What I’ve done on this little sprite demo is just one document that I really don’t have a concrete plan for right now. [...]