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

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.