Sam and Max

OK, so this post doesn’t have any useful information whatsoever. Big Deal? Well yes, because it’s got something so utterly useless that it stands out: A dog in a suit and a naked white rabbit.

More precisely, a guy in a dog suit wearing a suit carrying a rabbit.

In case you haven’t noticed, over at Telltale games, they’re developing a new video game series and well, these guys are simply nuts. Here’s their official report from Comic-Con. Watch it, enjoy it, vote for Max!

Spore – It’s not that scary!

I just finished reading an article over at Bona Fide Reviews and I simply can’t keep but smiling. You should read the actual article for yourself and then consider my reply. Enjoy:

OK, let’s start one by one. First of all we should clarify if we’re talking directly about programming or rather some greater logic that is the basic for the whole program. In this case this is almost certainly the logic behind the programming, not the actual language itself. In fact, it’s not even the logic behind the whole program: It’s the logic behind one subsystem, namely the model generation.

The point is that Spore simply adds a whole new level of abstraction for generating and maintaining models. Notice that the system itself is nothing new… it has been around since the first days of game programming. But maybe it’s easier to explain it using a well known example.

Consider the model generation in Half Life
You see a guy lifting his arm… what data is actually stored and which one is generated on-the-fly by Half Life, DirectX or your graphics card?

What you see is a two dimensional raster image, so does Half Life come with a image of that guy from every imaginable angle?
No, it doesn’t. This would either require a huge amount of memory or limit the number of angles. However, this was done by older games like Doom to save processing power… as a result no matter from which angle you would look at a monster, it was always one of four images (Left,Right,Front,Back).

So, we’ve established that the guy isn’t stored as a 2D raster image, so what is he made of? What data is processed into the image we see? Well, it is a vector image… an image where points and the areas between them, together with a number of parameters like the color of a area make up a description that can be used to generate a bitmap. But this doesn’t really solve our problem, there are still way too many angles.

We really have to abstract some more. What data can be used that when combined with a particular angle results in a 2D vector image? You’ve got it: a 3D vector image! We just spread the points along an additional third axes and suddenly we can generate a 2D vector image from every imaginable point. Hurray!

But wait, the guy is lifting his arm! Uh… do we have to store a 3D vector image for every single point in time while he’s lifting his arm? Well… this was done by the game on which Half Life is based (Quake) and it wasn’t a very good system… In order to keep the size of all these models down, they had to remove precission resulting in a very strange effect where parts of the model would appear to change shape. Luckily, there’s an alternative! We can use yet another form of abstraction! We simply divide the data up again, in this case in the static 3D vector image and a skeleton that defines which parts of the 3D vector image belong to which bone. So now we just have to store the 3D model of the skeleton and in order to for example lift his arm, we simply move the arm bone, and all points in the 3D vector image that belong to the arm bone will move the same way.

But this isn’t enough! There may be hundreds of guy in the game and most of them lift their arm in a similar way. Since we separated the skeletal animation data from the 3D vector image, we can use it for all guys, not just this one!

But we still have to define all individual states, so let’s abstract some more! We can simply define a number of points along which the bone should move, and voila, we only have to save two or three states and interpolate between them.


This is where it ends for Half Life. But wait! There’s more!

Unreal was one of the first games to dynamically generate images to be used as textures for the areas in a 3D vector image: They would for example specify a image and then generate a whole series of images where water was flowing across it.

Quake3 brought parametric skeletal animation to the masses. There would only be one animation for walking which was modified to make it appear as if different characters walked differently. Some would spread their legs more, others less and so on.

Others, like the famous N64 game Waveracer, would generate models for a whole see using a set of rules that formed a simplistic physics model.

And finally we see games like World of Warcraft creating a near infinite number of models by combining parts of different models.


But there’s one gap. We always end up with a static model that’s being deformed in various ways. And this is where Sporn offers (or appears to offer) something new. We can create arbitary models from a simple model (in this case a ball). In fact it’s not new at all. We’re simply adding better deforming algorithms and give them more freedom in that we not only allow them to not only move existing points, but also add new ones. We add routines that we’ve developed to simulate physics to make it appear a if we were actually sculpting. Then we apply all the techniques mentioned before.

It’s a great example of evolution, but it’s not a revolution.

xmlTree – minimalistic XML processor for PHP

xmlTree is a tiny, little XML processor for PHP that doesn’t even offer 10% of what the XML spec has to offer, but still manages to do almost everything a normal developer needs (and besides, it’s easy to extend). It’s meant for all those people that

  • Hate to use code that they cannot possibly understand
  • Prefer small libraries
  • Don’t expect the XML Library to validate their data
  • Don’t need the XML library to handle data that’s not trustworthy
  • Don’t need automatic character conversion, like ” to \” or <>

So, it’s really quite minimalistic. It was initially written to store configuration data for another program, but ended but managing quite a bit of the HTML code too.

Essentially, it provides the following features:

  • An XMLElement class that provides parentNode, childNodes, tagName and attributes. It also provides a value for text nodes
  • A Javascript like DOM manipulation system, featuring such gems as appendChild, setAttribute, getAttribute, removeChild, getElementsByTagName, getElementsByName,getElementById, toXML and toFile, all of which (with the exception of the last two methods) behave almost exactly like their Javascript counterparts.
  • An XMLDocument class with html, head, title and body (nothing special, but it makes life easier)
  • An XMLParser class that turns an XML string into a XMLElement tree.

You can find the source, along with some more notes here. Oh, and it’s GPL too.

Canvas 3D Renderer updated

I’ve updates the Canvas 3D Renderer with new sample data, a few performance tweaks, background image support, support for colored polygons and a few tweaks here and there.

Note however that the car you see is not a sprite, it’s simply an image put in front of the canvas for my amusement. So don’t get confused if it doesn’t behave the way you expect it to do.

Right now the sample data has around 200 faces and while the code is almost ready for shared vertices (which means that one vertex belongs to many faces, resulting in a much lower number of vertices in memory and therefore a lot less calculations) right now a face still consists of 3 vertices, meaning that it does about 500-600 rotations, projections,clipping and collision tests per frame update, with very few optimizations so far and for that the speed is (at least in my opinion) amazing.

What’s interesting to me are the test results… I didn’t time them, so I can’t give you any numbers, but
Opera 9.1 is definitely the slowest one, but with a very steady framerate, which probably means that drawing and garbage collection are very fast (as these tend to take up a variable amount of time), but arithmetic is slow.

Firefox 2 is pretty steady as well, and a lot faster than Opera.

Firefox 3 Alpha is certainly the fastest browser, but with a very unsteady framerate. I guess the new garbage collector is causing this while drawing speed is increasing thanks to Cairo.

You can still find it at (Note that the background gets drawn during the first screen update after the image has loaded, so it will probably take a second or two to appear the first time you load the page. Screen updates happen whenever you move around).

P.S. I’d appreciate it if you could send me mail if you want me to answer your comments. hansschmucker at gmail dot com

Real 3D Rendering right inside the browser

So far, you’ve always needed a plugin to even display dynamic 2D graphics, never mind 3D. So here‘s a 3D engine that works right inside your browser, no plugin required.

OK, first for all of you impatient guys, the controls:

  • Arrow Keys: Turn/Walk
  • PageUp/PageDown: Fly

Flying only works when you’re outside the map, on the map you’ll get put onto the nearest surface automatically.

Now a bit of background info:
This is a demo program for the Canvas element, which is right now being formulated as a standard over at
The Canvas element is a 2D Bitmap surface to which you can draw to directly from JavaScript. So far, you couldn’t
do graphics in Javascript, aside from dynamically loading different bitmaps from the server. The Canvas element closes
that gap. Now you can actually draw arbitrary shapes, without loading anything from the Server.
For that purpose, the Canvas element provides an API that allows you to draw vector shapes and bitmaps.

The target for Canvas is to not only provide a 2D API, but also one for 3D based on OpenGLes. Sadly, this API
hasn’t yet arrived, and it looks like it will take some time until browsers support it, but the 2D API is here and it’s
working just fine in anything but InternetExplorer, and even for that Google provides wrapper code free of charge
(note however that this wrapper code isn’t being used here, so you’ll need either Firefox 2+ or Opera 9+, Safari hasn’t
been tested). So I decided to write a little 3D Renderer myself. It’s not complex, it’s not finished, but what the hell:
it works. While this isn’t the first attempt to do this
(Canvascape comes to mind),
it is as far as I know the first one to try real 3D instead of Doom-style pseudo 3D. In fact, this demo loads a standard
Alias Wavefront OBJ file, and builds the model from the triangles it finds in there.

So what does this demo do? Well, basically this:

  • Load a model
  • Set up controls to modify a view object
  • Find the nearest triangle below the player
  • Move the player down to that triangle
  • Rotate the model
  • Clip it against Z=0 so you only render what’s in front of you
  • Split partially visible triangles against Z=0
  • Project all vertices, so that they get smaller the farther away they are
  • Draw them, with the distance dictating the color

It’s a bit more complex, but these are the important parts.

So what do I want to do with this? Well, eventually it should becomes a little racing game. Remember ReVolt?
Something like that and from the performance I get so far, it seems possible.
Which brings me to the needed optimizations:
I’ve got absolutely no idea why, but it seems like all Canvas implementations do pixel based clipping against
the drawing window, instead of shape-based clipping… essentially that means that drawing a 1000×1000 pixel
shape, it takes 100 times as long as drawing a 100×100 pixel shape, even when the Canvas is only 20×20 pixels
in size.
Then the game needs a BSP tree because JavaScript is too slow to calculate visibility for every triangle in
realtime… so there has to be a structure that dictates that from position 1,1,1 faces 2,5,8,10 are visible, while
from position 5,6,12 faces 3,15,33,110 are visible.
Then we need a real colission detection for a meaningfull game and support for sprites.
There will probably be a 1000 other things to do, but that’s what I have in mind now.
Oh, and forget about textures… it’s just not possible at descent speed.

Notes. The code is copyrighted Hans Schmucker and licensed und the GPL v2.5

Sudoku! (Update: Now with 1000 puzzles)

OK, so yesterday evening I started working on a new Javascript minigame: Sudoku.

I know what you’re going to say: there already are way too many Sudoku games around. And you’re absolutely right.

Problem is, there are very few good games around, and even less that run in your browser and almost none that require no plugins.

There’s already a first Alpha version available here (but with just a single puzzle):

The feature list is already longer than for most other Sudoku games:

  1. Use the buttons at the bottom to add notes to the selected field.
  2. Use the buttons at the right to confirm a number.
  3. Use the “?” to get all notes automatically.
  4. You can’t confirm numbers that collie with other numbers in the field, however you can enter numbers that are simply wrong.

So what’s still missing (aside from a new UI):

  • Automatic Solver
  • Generator
  • Tabs for different versions of the same puzzle
  • True handwritten notes
  • Menu to enable/disable solvers.

Did I forget anything? Tell me!


Now there are 1000 new puzzles available. While there is still no generator in this, I have instead opted to instead create a converter for the files generated by QQwing, A free Sudoku generator published as OpenSource. Now, on launch the game will select a random number between 0 and 1000 and load the level with that number. However there are no difficulty levels yet: While QQwing supports this, it is not being used yet. All levels are difficulty “Expert”.

Tutorial for native ARM PalmOS applications using PRC-Tools

Writing applications for PalmOS using native ARM code, especially using only free tools is something that seems impossible to most people. Well, with this tutorial I aim to prove them wrong: the aim is create a simple breakout tool using only free tools. It’s primarily aimed at people who have some experience with the programming language C, but have never developed for PalmOS. However if you have some understanding of how a computer works, you should be able to complete it without too many difficulties as well.

Basically, this document is divided into the following parts:

  1. Tools Setup

    1. Cygwin

    2. PRC-Tools

    3. PalmOS SDK

    4. PEAL

    5. PARM Lib

    6. pilrc

The breakout game will be posted lateron 🙂


Naturally, the first thing you want to do is set up all the tools you’ll need to compile your code into a PalmOS application, While this is a bit of a task, most of it is pretty straightforward, the most difficult part is actually knowing what you are going to need:

Cygwin (and PRC-Tools)

All the tools you are going to use are actually Linux tools, so the first thing you’re going to need is a Linux-like environment. Of course you could install Linux, but of course that’s not for everybody.

Cygwin is basically an environment that translates Linux commands into their Windows counterparts, so that Linux apps can run under Windows. Think of it as a Linux emulator (Before the more experienced users start crying: I know that’s not the way it works, but for our purposes this comparison is sufficient).

Installation is very simple, just download the installer from (“Install or update now! (using setup.exe)”) and run it. Chose the following options:

“Next” ->

“Install from the Internet”, “Next” ->

“Root Directory” (Enter the path where you want to install Cygwin), “Install for All Users”, “Default Text File Type Unix / binary”, “Next” ->

“Local Package Directory” (Enter path where downloaded files should be saved, so you can reuse them when reinstalling Cygwin), “Next” ->

“Direct Connection” or whatever you need to get a connection to the internet, “Next” ->

Enter “” into the “User URL:” field, press “Add”, Locate “” in the list, click to select, locate a different mirror, for example “” is pretty reliable, hold down “CTRL” while selecting it, check if both “” and “” are selected, “Next” ->

Click on the “+” in front of “Devel” and find the packages “GCC”, “Make”, “PRC-Tools” and “PRC-Tools-ARM”. Click on the word “Skip” next to them until it says “install”or the latest version number (Don’t install “pilrc”), “Next” ->

“Installation Complete”

Now the compiler is installed and ready.


Unfortunately, you need a little more than just a compiler to create a working program. You also need some libraries that allow you access to the PalmOS system internals. These libraries are contained in the PalmOS SDK. To get it, you have to register at After you have registered, sign in and go to “Palm OS Developer Tools“. Chose “Core Palm OS SDK” and finally download “Palm OS Garnet SDK (68K) R3 PRC tools Generic UNIX”. Don’t worry about it saying “UNIX”, that includes Cygwin as well. Create a new directory inside your Cygwin installation and name it “PalmDev”. Save the file to that directory. (While you’re there, it’s probably a good idea to also get the PalmOS reference, companions and simulator)

Open the Cygwin Bash Shell from your Start Menu and perform the following actions:

cd /PalmDev/

tar -xzf palmos-sdk-5.0r3-1.tar.gz


(Of course, if the archive has a different file name, use that instead of “palmos-sdk-5.0r3-1.tar.gz”)

After running palmdev-prep you should get something like this:

Checking SDKs in /PalmDev

sdk-5r3 headers in ‘include’, libraries in ‘lib’

When GCC is given no -palmos options, SDK ‘5r3’ will be used by default

Writing SDK details to configuration files…


OK, so now the SDK is installed and configured as the default option for the PalmOS compiler. Now you could already start writing code for the 68k plattform. But we want to do a little more than that.


Problem is that the arm-palmos-gcc compiler, aside from not working well with the SDK, is that it is pretty limited in what C features it supports. Especially global variables are a problem and this is where PEAL comes in. PEAL is a little parser that relocates data so that global variables work. To install it, just download the tar.gz archive from and place it in PalmDev as well. Extract it with

tar -xzf peal-2005_4_14.tar.gz

(Or whatever you named that file).

This will extract peal and create a directory named something like “peal-2005_4_14” to rename it to just “peal” enter

mv peal-2005_4_14 peal

Now, change to that directory with

cd peal

And go to the postlink directory

cd postlink

Now all you’ve got to do is compiling PEAL. Just type in


You’ll get a few warnings, but after a few seconds you’ll get back to the shell.



and you get the help message for PEAL.


Now we have to overcome the final (and most difficult) shortcoming of arm-palmos-gcc: It’s inability to communicate with PalmOS. PARM does some magic to do this… it’s rather complicated and you actually don’t need to understand it, so there’s no point trying to explain it. Installation is very simple, just download and extract it to your PalmDev directory. It will create a PARM directory containing the necessary files and an example. Change to the example directory with

cd /PalmDev/PARM/example/

The sample code is contained in main.c, contains the information to build the application so that the PalmOS simulator can run it, while compiles the real ARM application. Try it. Run


and a main68k.prc file should appear in the directory. Drag it onto the simulator and run “MyBreakout”. It will display an empty screen and when you click somewhere it will draw “Hello World” at that point.

Now try to build the native application. Run


and it will first output a warning message

In file included from ../../pnotest.c:27:

../../pace_gen.c: In function `StrPrintF’:

../../pace_gen.c:133: warning: dereferencing type-punned pointer will break stri

ct-aliasing rules

Just ignore it, that’s normal. You’ll get it every time you compile something, there’s nothing wrong with that. A mainpno.prc file should appear that’s identical to main68k.prc, but contains fast, native ARM code. Hotsync it and see if it works. If throws any more errors than it probably can’t find some file, because you placed it somewhere other than the default location. In that case you need to edit the make* scripts. You really only need a simple text-editor for that, but it has to support UNIX-style linebreaks… that’s something pretty much any editor besides notepad can do, but my favourite editor is SciTE ( ), because it requires no installation and has pretty good source highlighting for about any programming language I know. Open in the editor of your choice and you’ll see the script’s source. The most common problem is that you installed PEAL somewhere else than /PalmDev/peal . Just look through it and most likely, you’ll spot the culprit within seconds.


Pilrc is a resource editor for PalmOS. You’ll need it to add icons, forms, bitmaps and so on to your PRC file. Just download from and extract it to your \windows\system32\ directory. That’s it 🙂 I’m not going to give you a sample now, but we’re going to need it when we do the breakout game next time.

See you then 🙂


T8Launcher 0.4 with new layout engine and button input

This release features en entirely new layout engine, which will soon allow T8launcher to work on any ARM PalmOS device, even on Cliés with their hybrid Sony Hires/Garnet Hires API. However for now it still only works on the Zodiac as I have yet to modify the screen setup to handle different screens correctly. Also, the portrait skin is still incomplete and the square aspect ratio skin doesn’t even exist.

The most notable improvement in this release is the ability to enter text with the buttons and joystick:

To enter text with the joystick, just press it, move it to the desired position (let’s say top-left for “abc” or center for “mn”) and release it again. While you’re pressing the joystick, the letters that you would enter if you released the joystick will light up.

Another way are the 4 colored buttons on the Zodiac. Just press the button(s) that point in the correct direction. For example Blue and Red (at the same time) for “abc”, Red for “def” and so on. To enter “no” you have to press (at least) two opposite buttons, for example blue and green. Pressing three or four buttons at once has the same affect.

The other functions are also available: Press “Home” for Backspace, “Func” to cycle the list and one of the triggers to launch the selected application.

While the joystick feels more natural for inputting text, the buttons are actually a lot more precise, so I’d recommend using this method for text input.

  • New layout engine with skining
  • Added wrappers for various HiRes APIs (not used yet)
  • Added partially complete 320×480 skin
  • Added button input

You can download it here:


T8Launcher updated to 0.2

OK, it seems like the main problem was that the interface wasn’t informative enough, so the changelog is pretty UI-centric:

  • Made text transparent, instead of white background
  • Added label “Launch” to launch button
  • Added label “Next App” to cycle apps button
  • Added label “Backspace” to delete button
  • Added count of remaining matches to cycle apps button (including label “Remaining Matches in List:”)
  • Added input string position to delete button (including label “Number of entered Chars:”)
  • When there’s no match for the current query string, display message and delete last character.
  • Fixed rotation after exiting from Portrait app
  • Don’t display hidden apps anymore

You can download it here: