kaioa.com

bzzzzzzt

In a nutshell: A static initializer is executed whenever you do anything with that class. It's executed before whatever you wanted to do (e.g. calling the constructor or accessing a field). It's also only executed once.

Many moons ago I released some code which utilized a static initializer. That code worked fine back then, but recent versions of the Flex SDK compiler don't really like it. Well, to tell the truth I also didn't like it, because the construct I used was sorta ugly and, well, pretty wrong.

The art of shuffling

What it says on the tin, really

Here you'll get Flash (AS3), haXe, JavaScript, PHP, Perl, and Python ports of my continuous shuffled sequence algorithm. (Update: There are C# and C++ versions in the comments.) As usual the code is available under a Zero-clause BSD-style license, which means you can use it in any way you like.

All implementations utilize an un-seeded default source of randomness. If determinism is required, you'll only need to hand over a PRNG and use that one instead. Or hand the seed over and initialize the PRNG with that one as the original Java version did it.

If you port it to other languages or if you modify it a bit (e.g. as outlined above), you'll have to verify that it works correctly. Fortunately testing it isn't that hard. E.g. if you add "X" and "O" and call next four times you should receive one of the following sequences:

• XXOO
• OOXX
• XOOX
• OXXO
• XOXO
• OXOX

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.

I can't hear you

Motivation

A few weeks ago someone complained about screencasts being (ab)used as replacement for documentation. I think I saw it somewhere over at reddit or dzone. Well, that rant wasn't all that interesting, really. However, it did point out two real issues: they are useless to the deaf and you lose the advantages of text (searchable, quick scanning etc.). I can't agree more with those bits - it's something that bothered me for ages.

The former can be addressed with subtitles. The latter, however, is more complicated than that. Solving that problem would also solve the issue that screencasts don't really reveal much of their content to search engines. If you put countless hours of work into your screencasts it would be pretty sad if your audience is unable to find them.

Interestingly subtitles are also the solution to this problem. Once they are written (or copy/pasted from the script) you have a complete transcript together with the timing information. With those two pieces (text and time) you can create a transcript where each line can be clicked to seek over to that position.

As I mentioned earlier this new version of the flash player supports MPEG-4 AVC (H.264) and High Efficieny AAC (HE-AAC). Check the press release for some details. Well, there isn't much of a surprise there.

What's surprising tho is that it was released for Windows, Mac OS X, Linux, and Solaris simultaneously. Way to go Adobe! :)

Grab it while it's hot!

Update: There seems to be some issue with Adobe's mirrors. Right now it claims it would be 9,0,115,0 (the version I spoke of), but the version I'm actually getting is 9,0,47,0. I guess I have to wait a bit.

Update2: OK. Seems to work now. Unfortunately the "lossless" H.264 mode from ffdshow tryouts still doesn't work. It's a shame really, since that one would have been perfect for screencasts.

Wow that's some awesome news. Just a few hours ago I thought how nice it would be if Flash would support H.264. And there it is! :)

The compression ratio of the lossless codec (Screen Video/Screenshare) is sorta bad, Sorenson Spark (a H.263 bastard) looks really bad and VP6 is a major pain to get working (and it isn't really all that great). H.264 (2pass), however, works really well for screencasts. You get very good compression and almost perfect looks. It's currently the best choice for the last mile.