I've just fixed another round of bugs/new features:

- I now have working "status bar" display, so you can see how many moves you've taken, whether you've completed the game or not etc. The same code will be used to display which number is currently selected for input in filling, solo and unequal.

- I've just found an incredibly stupid bug of mine that was loading a font every time it was used without closing it properly (a code path problem that I hadn't noticed). This meant that "fifteen" was getting to about 50 moves and then running out of memory (50 x 20fps x [number of characters in game] x [size of font characters in RAM] x [probability that it would take the bad code path] > [RAM in GP2X]!). How it survived for so long, how it didn't show in other games, how it doesn't make the machine run out of memory quicker, I have no idea. But quitting the game made it clear up after itself and you could run it again or load any other game without problem!

That's now completely fixed and I've gone through the whole code again looking for missing/skipped free's and close's to make sure it doesn't happen with anything else. SDL does a damn good job of clearing up after itself anyway, so memory leakage isn't a problem if you quit a game and then run any other, but I don't like stray pointers. The games don't write *anything* to "disk", i.e the SD card or NAND, but that's no excuse for not checking that everything frees itself properly. I thought I'd been particular careful but apparently my wife makes a very good bug-finder despite never having coded in her life.

- I've linked against Paeryn's SDL libs instead of the default Open2x and it appears to work absolutely fine. However, this opens up the possibility of using hardware accelerated surfaces to do fancy zooming tricks and work the F-200 touchscreen without having to change any code. Again, people with actual F-200's would need to test to make sure. This also allows "panning" of the game area, although I haven't implemented that yet. So, in theory, you could have a 640x480 playboard and move around it by touching the edges of the screen. This would make "pattern", in particular, much easier to play.

- The mouse is now much smoother and faster but still seems to have problems with the way it moves on F-100 at least. You should now be able to switch between left/left-up/up without problems but on the F-100 it sometimes stops for no reason and you have to press the direction again. I've tried several of the "joystick biases" from the Wiki but I can't stop it happening. Anyway, it's much more comfortable to play now.

The following are not implemented (deliberately) on any game but usually run to no more than a handful of lines of code each, plus a GUI to do them in:

- Saving/loading functions (I don't like writing to other people's disks from C... However, the games automatically save/load themselves to an ASCII string using built-in functions and it's just a matter of putting that string somewhere and then letting the user get that string back... that will almost certainly involve GUI work which I'm not interested in doing, or passing command-line parameters from a menu with a GUI that I'm not going to make either)

- Clipboard functions (GP2X hasn't got one!)

- Changing game parameters, like size, difficulty, etc. (a simple matter of querying the midend for parameters available, collecting the parameters from the user and passing to a function... this is all code that isn't affected by my SDL code but someone would have to design an SDL menu that adjusts to each game or another way of presenting the user with a list of options and passing them to a function. I have tested it briefly and the games will automatically adjust to the size and difficulty specified as that is all done within the game code, not the display code)

Icons inside the executables (I can't be bothered to figure out how to do it, but there are .png icons already supplied with the game and I'm really not that interested, especially because I run the games through wrapper scripts which can't have icons! And people using things like GMenu2x or similar can just use the game's icons, I assume).

I'll be submitting a "beta" version of the entire collection once I've had a few more attempts at fixing the outstanding problems (mostly with mines, because that's the only one that's completely unplayable). That will most probably be synched to the latest SVN version as well but the only things that have changed since the revision I'm using are some MacOSX fixes, a tiny "fix" for code cleanliness and allowing you to "drag" and set multiple squares at a time in "filling", so it may not be worth it if it breaks anything at all.

The full collection is 27 games (Eek! I never realised it was that many). 22 are fully-working with just minor display issues that don't affect gameplay. 2 have drag-drop display issues (map, guess) that don't affect actual gameplay. 1 is incredibly slow but works (pegs) and I believe is down to the same drag-drop display issues but exacerbated by the dragged bitmap being larger. 1 sometimes has problems if you use a particular feature (bridges, locking an island with right-click) but it otherwise playable. 1 has fonts too small due to the nature of the size of the game (pattern) but if you squint you can read it. And 1 is unplayable (mines, quits safely on startup with an assert error inside the game code, not the interface code). I don't consider that a bad track record, personally, given that I've built a whole new frontend.