ant.simianzombie.com

I have released a few other projects to the tinterwebs recently, but haven’t as yet announced them.

ALite

First up is version 3.0 of ALite, a simple data-access and data validation framework for .NET4:

http://bitbucket.org/ant512/alite

This version simplifies much of the framework. I went off on a wild tangent before moving the repository from SourceForge to BitBucket and started implementing features such as pseudo-transaction support. I even tried real transaction support using the classes from the System.Transactions namespace, but ran into so many nasty problems that it quickly became obvious that it wasn’t going to work.

Instead, ALite now works much more like Igmongonious. It uses a document (key/value store) to store the values of properties, which simplifies and speeds up the undo system. Swathes of code have been refactored to make the framework easier to use.

The “changelog” document seems to be inaccurate so I can’t give a complete breakdown of everything that has changed. Fortunately, no-one but me is crazy enough to use this library.

I moved the repository from SourceForge to BitBucket for a number of reasons. SourceForge has done some neat things with their UI and added a host of exciting new features, but:

• BitBucket is a better fit for small projects like this. SourceForge’s insistence on manually vetting all projects doesn’t seem to have alleviated the amount of junk projects in its database, but it does increase the amount of work necessary to get what should be a minor project up and running.

• Mercurial is magnitudes faster than SubVersion, particularly when SubVersion is lumbered with SourceForge’s horribly slow SVN servers.

• BitBucket projects come equipped with a Creole-based wiki. Though SourceForge has recently added a per-project MediaWiki installation to their suite of features, Creole is notably terser than MediaWiki markup. The wiki is much simpler, which again is perfect for smaller projects. The entire wiki can be pulled down as a Mercurial repo allowing local editing and change tracking.

Chroma-X

Next up is Chroma-X, my ill-fated, unfinished and unfortunately-named shoot-em-up for the GP2X:

http://bitbucket.org/ant512/chroma-x

Nothing new in here, but the sourcecode is browsable and easily accessible. Incidentally, I managed to get the game running on a GP2X Wiz. I was disappointed to discover that it was slower on the Wiz than it was on the GP2X F-200, which put a damper on my Wiz coding plans.

Canvas UI

Lastly, my canvas UI project is also now on BitBucket:

http://bitbucket.org/ant512/canvasui

Since the last version I’ve fixed a few bugs and added plenty of new features, including:

• Window close and depth buttons;
• Scrolling lists;
• Shadows on label text for disabled buttons;
• Separation of GUI definition from library code.

Building on yesterday’s code, here’s the latest version:

• Canvas UI

At this point, the similarities to Woopsi should be apparent. This is a basic but workable window manager for the canvas tag. New things since yesterday include window and button gadgets, a top-level container gadget, event handling (click, release, release outside, focus and blur), focus and blur functionality, and probably some other stuff that I’m forgetting.

In various places I’ve just ported code straight from C++/Woopsi to Javascript, whilst in others I’ve taken advantage of lessons I learned whilst writing Woopsi to come up with better approaches. For example, the list of gadget event handlers is a separate class. I’ll probably update Woopsi to follow the same pattern.

As for why I’m doing this - I haven’t the faintest idea. Seemed like a good idea at the time.

Continuing on from the last post, I’ve made some improvements to the Javascript UI skeleton:

• Canvas UI

Try clicking on and dragging the rectangles around and see what happens. Unless you’re using IE, of course, in which case I suggest you go and download a web browser first.

I read up on the canvas API and it transpired that the canvas element already includes clipping functionality. I ripped out my own clipping routines and used the rectangles calculated by the BSP routine to define the clipping regions for the built-in drawing functions. (As an aside, I’m seriously considering pulling the Graphics class out of Woopsi and using the GraphicsPort everywhere, so that clipping is available when drawing to bitmaps. This would require a few changes to the way the clipping region is specified, but I think it would be a change for the better.)

I’ve also improved the way gadgets recalculate their clipping regions when they are moved. Instead of recalculating the entire BSP tree, the system just recalculates the tree nodes within the space defined by the moved gadget’s parent. Since those nodes are the only nodes that can possibly have changed, there’s no reason to recalculate everything.

Gadgets are limited to the confines of their parents. This makes it impossible for them to overlap their parents’ borders. In Woopsi this border protection was aided by the alternative display partitioning scheme; the BSP system used here does not make it quite so easy.

Finally, gadgets jump to the front of the stack when clicked. However, this has been disabled so that it’s possible to move a gadget behind another and actually prove that there’s a reason not to just opt for the painter algorithm instead of this BSP stuff.

Here’s a little HTML5 canvas tag experiment. It’s a demo of interactive hierarchical rectangular regions with clipping, or in other words, the basics of a windowing system. It is very similar in design to Woopsi, and uses the BSP tree screen dividing routine I discussed a while back.

• Canvas UI

You leave web development for five minutes and suddenly amazing revolutions take place. I was browsing Hacker News, and discovered that IE8 is going to support the table layout properties of CSS2 and 2.1.

Those of you who have been using real web browser for the past decade, please join me in warmly welcoming IE users to the space year 1998.

That would make web UI development so much simpler if there weren’t so many luddites still using IE5…

The Pong demo in Woopsi is a bit crap. It served its purpose, but it doesn’t really do anything. I wanted a more interesting demo, but didn’t want to invest a lot of time in writing a new game, so decided that it would be simple to port my PacMan-for-Javascript to C++ and Woopsi.

Here’s the result:

Pong and PacMan on the same screen, running simultaneously, with no slowdown. It’s pretty much the same code as in the Javascript version, but with C++ features (accessors, etc) added in, and some minor optimisation in the drawing routines. Cursor keys move PacMan around.

Putting this together illustrated a few things:

• It seems that it’s actually *faster* to use a SuperBitmap as a game’s display than it is to use a gadget and its GraphicsPort. Probably due to the large overhead associated with clipping.
• There still appears to be a bug in the SuperBitmap::drawFilledRect() routine (possibly related to clipping to the bitmap’s size).
• Drawing with the GraphicsPort outside of the gadget’s draw(Rect) function is a really bad idea unless you’re redrawing everything in a VBL event, because Woopsi doesn’t fire any events to tell you when a window needs redrawing (due to the way I’ve optimised gadget erasing, there’s no easy way to add this in, either).

There are a few bugs in the demo (PacMan doesn’t get drawn when the window first opens, ghosts can collide with PacMan diagonally, and it’s far too fast), but it suffices for a quick tech demo.

A few fixes. Windows are blocked from being dragged out of the top of the screen - I realised that if a screen is partially dragged down, it was possible to then drag a window out the top. It was then impossible to drag it back down again.

The ScreenTitle and WindowBorderTop make copies of the text passed into them to prevent them from referencing deleted strings - Jeff noticed this one a while ago. The BitmapButton offsets its bitmap blitting co-ordinates by 1 to take into account the border size (if the gadget has a border). The SuperBitmap’s draw(Rect) routine was basically a copy of GraphicsPort::drawBitmap(), so I’ve deleted the code from SuperBitmap and used a call to the GraphicsPort instead. Lastly, the demo skin’s buttons are slightly larger, and are now clickable on a real DS.

Some more new features. I’ve added a filled circle routine to the SuperBitmap and GraphicsPort classes, and the Pong demo now has a round ball. The new woopsiRGB() function performs the same function as PA_RGB (ie. it automatically sets the alpha bit in the value it returns). There are a few other minor changes involving optimisations, etc.

Another one of the games I’ve always wanted to have a go at writing was Pac Man, but I’ve never bothered writing it as the thought of having to write a complex pathfinder routine for the AI put me off. Having finally conquered Space Invaders I thought it was about time that I gave Pac Man a try.

After another few hours of fiddling, interrupted by a trip to the pub and half an hour spent researching ghost behaviour, here is Pac Man in a canvas element:

Canvas Pac Man

As it is another game written at speed, it doesn’t feature power pills, levels (the same level repeats over and over), scoring, power-ups or a life display. It does feature two of the AI routines from Pac Man - purple ghosts move about at random, whilst the red ghost takes the shortest path towards the player.

The AI turned out to be very simple - I was all set to either implement the A* pathfinder routine or bodge together one of my own, when I realised that all the red ghost needs to do is move towards the player at every junction - if the ghost can take more than one path, it needs to take the path that will take it nearer to the player if possible. It still has a few bugs in it, but it does the job. To watch it in action you’d never know that it wasn’t a full-blown pathfinder routine, which is ultimately how videogame AI is supposed to work - make the code simple, but make it look complicated in action.

The game is a little sluggish in Firefox, but it’s quick in Safari.

One of the first games I tried to program in AMOS, about 14 years ago, was Space Invaders. Despite it being one of the simplest games to write it completely eluded me at the time - I think I managed to get a single invader moving its way down the screen, but the player’s ship, the other invaders and, most of all, the bullets, were completely beyond my abilities.

Coding in Javascript for the canvas element is so simple and so enjoyable that I decided to have a go at writing something other than Pong, and as I still hadn’t written a version of Space Invaders it seemed like a good choice.

So, here’s another hastily-written canvas element game, coded in a couple of hours today between playing Scrabble in Facebook and reading the latest Harry Potter:

Canvas Invaders

Use the cursor keys to move left and right and the space bar to fire. You have three lives, but the game doesn’t warn you when you lose them, nor does it tell you how many you have left. There is no scoring system and the invaders don’t get faster as you kill them off or progress through the levels (the game doesn’t really include the concept of levels; it’s just the same wave over and over again). If the invaders reach the same vertical position as your ship it’s game over.

Also, all of the graphics are black squares. That’s what you get in a couple of hours, I’m afraid.

In celebration of HTML 5 becoming an in-progress spec at the W3C, here’s a hastily-written, AI-only version of Pong in an HTML canvas element (IE users should go and download a real web browser in order to view this):

Canvas Pong

Suddenly had the urge to find out if anyone had taken up the “Scissors, Paper, Stone” Facebook challenge yet. A search on Facebook turns up two such applications, both of which appear to have been written since I wrote my first ponderings on the subject.

Coincidence?

Probably.