kaioa.com

It's photo-based with alpha, JNG would be a good choice [cc-by]

I always wondered why browsers don't support any lossy 32bit image format. With opaque images you can always pick a suitable image format, which will be reasonably small while looking reasonably good. There are always some trade-offs, but that's alright.

If it's photo-based (or just a plain photo), JPG is a great choice. If there are less than 257 colors a PNG8 will work great. If it's also very tiny (like a 1x13 gradient) a GIF might be even a tad smaller than a PNG8. If there are only a few thousand colors and little noise (i.e. there are large areas filled with a solid color), a PNG24 should work great.

Now, if you throw alpha channels into the mix, things become a bit annoying. PNG8 and GIF support so called "bitmask transparency", which marks one specific color as fully translucent. PNG8 actually supports one transparency value per palette entry. This means it's effectively like an RGBA palette with up to 256 values. This option is somewhat less well-known and the support by most tools is also somewhat lacking.

You can quantize and dither PNG32 images with pngquant and pngnq. PNGOUT will also create this kind of PNG, but only if there are less than 257 colors to begin with.

So, this area is covered pretty well by current browsers. However, once you need a "few" more colors, you'll run out of options. There is only PNG32 and – as we all know – PNG is a poor choice for photo-based images. Well, of course it will look perfect (it's lossless after all), but it will be prohibitively huge.

Lossy RGB is smaller

Lossy RGBA images are something that always has been missing on the web (If you ignore Mozilla's brief support of JNG, that is). Nowadays, browsers typically support JPG, PNG, GIF, ICO, and BMP. There is obviously some feature overlap, but there isn't any good choice for true color images which also happen to use alpha.

Generally your choices boil down to JPG and PNG. If you ignore animated GIFs (which are pretty useless for Canvas usage), PNG can easily replace GIF, ICO, and of course BMP.

Today, I'll demonstrate how you can create RGBA images which use JPG for the RGB channels. Since this can decrease the file size up to 75%, it's a very easy and intriguing way to speed up the loading time of your game or application. (If you are currently using heavy PNG32 images, that is.)

Caching makes it feasible

Generally speaking: off-screen rendering allows you to cache expensive drawing operations in some sort of image, texture, or buffer. With the new Canvas API the vector drawing operations for example can be a bit taxing. Same goes for gradients or patterns (Firefox 3.x). Or well, anything that requires many drawing steps or per-pixel calculations.

If you have used any other 2D drawing API in the past, you'll probably picture this a bit more complicated than it actually needs to be. As it turns out, it's surprisingly easy with Canvas since the drawImage function can also take another Canvas as parameter. So, there is no need to construct an actual image – you already got one, kinda.

Mindless retro action :)

About a week ago a friend of mine released his very first indie game – for the iPhone of all platforms. Sounds like a bit of a pain and probably it actually was. The game is basically a bigger and better version of one of his old games. The old one was written in C++ for Win32 (the source is also available over there). Later on he also ported it over to the GBA.

The new version looks and sounds pretty cool. If you're interested check out the video over at the official site. By the way, all models were done with everyone's favorite box modeler Wings3D. And the final audio cutting was done in Audacity. Both tools are mind-boggling awesome for these tasks. Check them out if you haven't yet.

Well, about a week has passed and he only sold a dozen copies so far. In the meantime it was pirated a few thousand times. Ouch. So, if you got $2.99 to burn (and an iPhone to boot) you can make one poor student very happy.

The hashes match

I just finished a tiny web application. And by tiny I do indeed mean tiny. It's a single file and less than 8kb in size (thanks to GZRepack). You can check it over at riddler.kaioa.com.

It allows you to store the hashes of answers to some question in an URL. If someone clicks on that URL he/she is then asked for the solution. If it matches any of the up to 5 hashes the icon and the border turn green and he/she can then start the next round.

Hrrrrrngh!

Intro

With web games you want hits — lot's of hits. A million per month or more if possible. Of course this means lots of traffic. While broadband became faster and cheaper during the last couple of years, traffic is still somewhat expensive. In order to get a nicer cost/income ratio there are apparently two options: reduce the costs and/or increase the income.

As you might have guessed I'm about to tackle the former with brute processing power. If you reduce the file size by 1% every 100th served file is free. With 5% it's every 20th file and with 10% every 10th file. If the price for that are only a few minutes of processing power it looks like a really good deal, doesn't it?

3 alignments and their origins

What for?

If you're writing a game with ActionScript3 you've basically two options: either use the scene graph or handle it yourself. I.e. extend Sprite, create some Bitmap, attach it to your Sprite, and blit onto its BitmapData via copyPixels.

Skipping the scene graph is certainly more fun. If you wrote some games in other languages, you'll quickly feel at home. Apart from that external main loop it's basically the same deal. Additionally, if your game requires full redraws either way (i.e. dirty rectangles won't help), using copyPixels is the fastest option.

However, if you take a look at BitmapData's documentation you might be in for a big surprise — there is no drawString function. How can you draw some text on top of your entities for quick debugging now?

FPSCounter.as in action

Why did I bother?

The last time I looked for something like this I was only able to find horrible implementations. They somewhat worked for the most part, but boy where they ugly. All of them. Well, to tell the truth I gave up pretty quickly. I decided to use a simple 18 lines long version which utilized trace for the output.

And that was fine. However, as I experimented around with Kostas Michalopoulos's Flash mod player I found out that the Debug Standalone Flash Player can be much slower if the bottleneck is on the code-side. It was over 10 times slower. That was a bit of a surprise, given that this kind of thing is free in Java. Of course I wanted to know now how fast my game can actually run in it's current state.

There aren't many calculations right now and there won't be all that many once it's done. Therefore it only runs about 20% faster with a non-debug plugin. But that's still good to know. Now I do at least know that there isn't much of a speed up to expect.

Boring technical details

The FPS counter listens to ENTER_FRAME events, because that's the only way to know how many frames are actually displayed. If you render in response to timer events, you may enter that function far more often than new frames are displayed. The enter frame event is the most reliable pulse generator, I'm afraid. Be sure to use the deltas though and cap them in order to avoid warp-through effects and the like.

Something is missing

Now and Then

ActionScript was introduced with the release of Flash 4 back in 1999. In my never-ending naïveté I assumed it should be pretty mature by now. Almost a decade should be enough for that, shouldn't it? Obviously that isn't the case - otherwise there wouldn't anything to rant about. ;)

I started with ActionScript3 (Flash9+) a few weeks ago. It's supposed to be so much better than ActionScript2. There wasn't much of a reason to not use the latest version; given that about 90% of the users use the latest version of Flash. The remaining 10% quickly fade away if you consider things like the lifespan of small web games (a couple of years easily) and the time it takes to get things rolling for real. A quick look at AS2 was actually enough to discard it completely; it's ugly.

Speed - we need more of it

Back in the Days

Do you remember those days you started programming? Back then all I had was a Commodore 16, one and a half bad books, and BASIC of all things. The really awkward kind with numbers in front. Incrementing by 10 every line in case you need to insert something later on. Drawing a Sinus curve took bloody ages. You could literally see how it was plotted pixel by pixel.

Later at school I had some C lessons. I liked C a lot. It was fast enough to do draw some odd effects in real time and the code looked so much better than C16 BASIC. Well, big deal. But back then it was truly the holy grail for me. I also got introduced to that odd algorithm stuff. Bubble sort. Gasp.