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.
There aren't much details out there about Quake Live (formerly known as Quake Zero) yet. One of the few things that were made public a few months ago was that it won't be written in Java (nor ActionScript... haha... very funny). Some people were really happy about that. Java is slow after all, right? Even Carmack himself said so.
While it's true that Carmack said "Java is really slow"[1], he didn't mean Java in general but J2ME. And he's of course right - J2ME is slow and it really is a platform of pure horror. There are simply too many differences between all those handsets. Different resolutions, color depths, key layouts, features, extensions, glitches, processing speed, memory, and whatever else might get in your way - it gets in your way with J2ME. I salute to the bravery of everyone who's doing that stuff for a living.
Some of you might have seen FontStruct over at Slashdot. It was at the front page yesterday or the day before. The usual thing happened of course - it got slashdotted to death. Fortunately it's back online. It's time to give it a shot.
In a nutshell: FontStruct is a web-based font creation tool. Apart from a few minor issues the Flash-based interface is perfect. It's surprisingly awesome in fact. Well, it's not intended to be used for professional font creation; it doesn't handle kerning or hinting for example. There aren't even any vector tools (all you get is a set of building bricks). But all those things aren't really necessary for less-serious/pixel fonts.
Without net access there wasn't much to do. However, modeling was one of the few things I actually could do. Fortunately I had some recent version of Wings3D installed. A few futile attempts later I got something that looked alright. Semi-satisfied with my low poly (52 polygons, 104 edges, 54 vertices) spaceship I went ahead texturing it with Inkscape.
Since the intended rendering size is rather small there isn't a need for fine details. I also wanted to try some bold semi-futuristic look with a touch of military blandness. Using vectors seemed like the most natural choice. Hard vector edges also fit the flat shaded rendering a lot better.
Before I could start with the texturing I had to do the UV mapping first. UV mapping is a bit annoying in Wings3D, but it's alright for simple models. If you aren't familiar with the term: it's about which part of the texture goes where on the model.
Just a bit unlucky. Twice in a row. Being without net access for about 2 weeks is somewhat akin to a new experience. I can't really remember how I did things before the internet. Almost everything I do requires a working connection. I need it for documentation, looking up synonyms/words, downloading/updating libraries/frameworks/compilers, bouncing ideas around, etc.
Everything seems to depend on it. Heck, I couldn't even make phone calls. Maybe I should get one of those annoying mobile phones. Meh.
Not everything was bad though. Having a few days without any PC running wasn't all that bad. I also got around playing some games. No More Heroes (Wii) and God of War 2 (PS2) were actually pretty entertaining. So, I'll dive into that for now.

In games or educational programs you often don't want real randomness. Unsurprisingly random it's often a bit too random. You may get some items several times in a row and others too rarely. It's either too easy or too hard. Balancing the weights is hard as well, because each run is too different. And if that wouldn't be already bad enough; it's also difficult to verify the results.
Note: The continuous shuffled sequence algorithm which I'll explain in the second half of the article can be easily ported to other languages. All you need are arrays (and a copy function or resizable arrays) and a random number generator.
Before I'll dive into shuffled sequences I'll outline the other issues of the obvious approaches. Because that's apparently more fun to do.

The current EeePC generation uses the typical UMPC minimum resolution of 800x480 pixels. Accordingly to some rumors future generations will most likely use 1024x600. [Update: The resolution has been confirmed. The EeePC 900 has a 8.9" display with a resolution of 1024x600.]
As you can imagine this will cause some issues with full screen 2D games. One can always bi-linearly scale the sprites (or the whole back buffer/FBO), but the blurring may not be desired. After all it's plain ugly. Additionally, it may cause other side-effects such as color bleeding. That is: color values from one frame of the spritesheet may be mixed with the edges of neighbor frames, which causes visible artifacts such as seams or stray pixels.
Current game copy protection schemes are usually pretty obstructive. Nowadays being lucky means only a key, a DVD check, and monitoring the existence of virtual DVD drive software. Requiring a key is acceptable, DVD checks are annoying and slow down the startup of the game, and the last thing... how is that supposed to help anyways? If you can create a 100% identical image, you could just burn that. I never understood that part. Those few cents aren't really an obstacle.
Or if you take a look at DVD movies: not directly transferable (e.g. if you want to copy something on a portable player to watch it on the train), unskippable FBI warning messages & ads, region codes, and of course some horrible menus.
Loops are commonly used for BGM in video games. There are more interesting solutions such as tracker modules or dynamic stuff, but for most games loops are just fine. They are simple to use and generally work everywhere.
Typical BGM loop usage in games:
Now that you roughly know what loops can be used for, I'll explain how to make your piece of music loop perfectly. I'll use Audacity for this, because it's open source software, cross platform (Windows, Mac OS, and Linux), and perfectly suited for this task.
If you've got an HDTV this won't be all that interesting, since you got better options there than S-Video (aka Y/C). Usually you can connect those via D-Sub, DVI-I or HDMI.
Well, let's say you want to build a nice cab to run some emulators on and all you got is an old PAL TV. With vsync enabled those games will run about 17% slower as intended (Note: a few games use 50 or even 55hz!). Additionally, you may get sound buffer underruns which sounds truly nasty. The two available options are disabling vsync (yuck!) or using 60hz.