STPPC2x v1.0 (Work in Progress Information Only)

It's been a while since I posted any updates here and in that time a lot of important things have happened within the GP2X community.

Most importantly, the GP2X has been discontinued (if you didn't know this by now, it was even on Slashdot's frontpage for a while!). This came as a great shame, but hardly a shock, to myself. However, I will be (and have been) continuing development as normal. I don't have an F-200, I don't have a Pandora (an "unofficial" GP2X successor-in-spirit), I don't have a Wiz (an official succesor). I can't afford any of them anyway. Until that situation changes, I'll be programming for the GP2X F-100 (with F-200 compatibility where I can manage it) and will keep programming. The GP2X rekindled my love of programming and I'll be both playing and coding on it until the day my personal unit dies. In fact, just lately I've been seriously looking at the prospect of buying another cheap F-100 second-hand if one comes up.

If I do suddenly manage to get any of those whizzy new machines, though, then I'll still be programming for the GP2X anyway - I prefer the challenge of programming for the lowest denominator. There is little fun in programming on a machine which just laughs at everything you throw at it (however, *playing* on it is another matter entirely!), and a set of 2D puzzles will never really stretch a powerful machine in practical use. So, I'll probably be leaving any Pandora/Wiz conversion of STPPC2x to someone else (to be honest, people would probably just use the official GTK versions on Pandora anyway, or their new Java ports).

That said, development slowed a little this month and last month but this was for completely unrelated reasons. What with a holiday and some end-of-term work at the school I work at, all programming activities took a back-seat. However, when I did get some programming time, I put aside my GP2X for a moment and attempted to update the Palm port of Simon Tatham's Portable Puzzle Collection, the code for which seems to have stagnated a little. However, this proved frustrating and, in the end, fruitless.

My wife has a Palm TX and we found that although the "official" Palm port of the puzzle collection works fantastically on a Palm Tungsten E2, the TX somehow ran the same executable differently. Most importantly, it often saw right-clicks instead of left-clicks all the time, no matter what options were set. This, obviously, made affected games absolutely unplayable. What was odd was that it only occurred in about 50% of the games and there was no way around it short of actually diving into the code and seeing what happened. Additionally, the Palm port doesn't include several of the games in STPPC2x and it would have been nice to get them working on Palm too, not to mention the various bug-fixes and new options that have been added since.

My attempts to recompile a test version of the Palm port proved much more difficult than I ever imagined. First, finding an appropriate build environment was nothing short of a nightmare - the SDK's are hidden away under obscure names that have changed since the README for the Palm port was written, contained only on websites that require arcane registration. After several hours (and some creative hacking), I was able to get a full suite of headers and compilers working. This is when the second and most damning problem showed up.

For some reason, the Palm has a very, very rigid memory structure and programs are written in segments of code that need to be of a certain size. No problem, the original Palm port took care of that with some ever-so-fancy scripting which tags functions so that they end up in seperate modules. With some creative tagging, all the modules are below the required size and they can all "talk" to each other - with nothing more than adding a function name to a script's datafile. However, because of the problems of getting the exact build environment that the original porter used, a straight compile no longer generates the same size code. Thus, a lot of the programs now need to be split into not just two but three or more segments, which greatly increases the complexity of compiling, linking and the various supporting scripts. In short, it's an absolute nightmare.

What started off as "I'll just compile this and see if I can find out what went wrong for Palm TX" turned out to be hours of frustrated downloading, hacking, patching, compiling of compilers followed by more hours of changing headers and filenames, editing scripts and lots of other fannying about just to get the original source code to compile once more in a useable fashion. After deciding to just speed things along and get the simple things running and work on the complex stuff later, I did get a working executable in the end, but without 40% of the games present in it because of the various code size changes and other problems. In short, it really wasn't worth the effort and was certainly useless for anything but a developer.

The frustration was so intense having fought to get to that point that I'd completely forgotten the original point of doing it all and in the end, never even got to looking at the relevant lines of code or whether a simple updated header could fix the problem. I would have spent 5% of the time fixing my problem and the rest just trying to get the original games back into a working state, let alone what would happen once I started introducing the new updates, games, etc. into the Palm collection. In the end, I left it for another day (month, year) and just kept hold of what I had downloaded/patched to get things working that much.

That meant that I was pretty sick of the Puzzle code for a while, although it was hardly the Puzzles' code that was at fault as much as the design of the Palm and/or the gcc compilers/linkers for Palm. Why all that can't be done automatically is beyond me but I'm sure there's a good reason, even if it's just "nobody got around to doing that". I tried other compilers and I tried searching for help but the answer was always the same "There's nothing we can do, split your code into smaller modules".

So, getting back to the GP2X (once I'd mustered some programming enthusiasm again) was an absolutely joy. Compile for x86. Link. Run on laptop. Compile for ARM. Link. Transfer to GP2X. Run. Rinse and repeat. Programming for the GP2X is a cinch in comparison and, more importantly, is intuitive and standardised. If something goes wrong, it's obvious and never anything to do with the compiler/linker being used. I ballsed up a Makefile once, so that things compiled oddly for ARM but okay for x86, but that's hardly anybody's fault but my own.

Unfortunately, my TODO list for the next (and probably "definitive") version of STPPC2x, with which I'm going to tempt fate and call v1.0, is very long but I am working steadily through it, even if I'm not putting out BETA's every month like I used to. A lot of the new stuff involves major infrastructure changes. The dodgy menu code that was thrown in with the intention of having some way to restart a game, and then changed to an actual menu to have some way to pause the game, and then changed to have some way to display the current options (in some of the most horrible code you'll ever see), and then repeatedly altered, bug-fixed and torn apart to fix some interface issues - well, let's just say that it's not going to be practical to extend it again and add the new options that I want to (such as using difficulty presets, etc.).

I've had a design for a new menu for a while and it'll look and work much better than the current one. We're talking a proper menu on the Pause button. With actual sub-menus. And actual proper changeable options. And an actual list of save-games. And an actual list of presets (including custom ones) that can be selected. And all without having to remember fifty keys or cramming it all into one screen.

It does involve touching some code that even I'm not sure I can remember how it works (I made a point of documenting the configuration-option stuff very heavily at the time, because I knew it would become a problem) so it's a big change to make that'll impact on a lot of things. However, all the "big stuff" is already in the code and it's just a matter of making it work in an intuitive way, in the right order, without bugs.

I need to factor out a lot of things to make the changes to the menu and thus there probably won't be many "preview" versions of the new code until it's finished: e.g. at the moment, you are "in the menu" or not, and the helpfile display "sub-menu" is a massive bodge. I need to change that so that you are "in menu number X" etc. so that the game only plays when you're not in a menu and options on sub-menus inherit from their parents etc. correctly and the key-press changes differ depending on the menu you're in etc.

It's a big job but I'm aiming for the magic 1.0 and I'm hoping to get it all working so that the program has that "professional" air to it, rather than the rather hackish backend hidden behind a nice PNG and some bash scripts that the user gets at the moment.

As a first step, I have integrated the "select a game" menu supplied by juanvvc into the main code. This is now just seen as "another type of menu" by the game, so it works much more closely and was a good way to see what sort of functions I need to have. This meant almost a complete re-write of that code but it now uses all the in-game functions to do its job rather than being a tagged-on executable that runs a script, that runs an executable to actually play the game. You won't notice, except that there are some tiny cosmetic changes such as the menu now showing the version number and being "part of" the main program.

Now one program is distributed and run, and the switch in and out of games is nigh-on instantaneous (However, it was pretty damn impressive before!). The Palm port was always the inspiration for this - it uses a so-called "Combined" executable (as does the MacOS port) that has all the games in it. That's now how the GP2X one works, too (after a massive migration from single-game-per-executable to monolithic-executable-that-can-only-run-one-game-at-a-time to the current "proper" combined monolithic executable). Additionally, it means that the "join" between the menu and the games is seamless - so, for instance, a music track could play across both without needing a jolt in between.

It does add a lot of complexities, though. For instance, it does mean that I have to check carefully for memory bugs because they will now accumulate if a player plays a long session of several games without quitting out of the thing entirely. I've already caught quite a few bugs that wouldn't have bitten people on the old menu but bite the second you change in and out of different the games themselves. There are also games which require a resolution change mid-flight if you run them - no matter how you play with them, some games run better in 320x240 and some in 640x480, so the menu has to know about them and switch between them. Fortunately, that's already done and dusted (although for some reason my PC has problems doing that same thing - I must update my SDL libraries!).

All these changes mean, however, that a lot of extraneous files and code can disappear and also that a lot of in-game facilities can make it back out to the menu. I'm hoping to eventually ship just one executable and the associated PNG's, helpfile TXT's and a single menu datafile. If I can manage it, I'd like to put everything but the executable into a single file (probably a ZIP or something) purely so that I can ship the minimum amount of files necessary.

The other thing that I'm working on as and when my mood changes is to have game "persistence". This was one of the things that working on the Palm port brought home to me - if you quit out of the game, you really should be able to go straight back to where you were just by running the program again. It's a bit like an "auto-save" whenever you leave one game and start another, or quit the game entirely.

It'll only work if you specifically leave a game, though, because otherwise it would involve writing to the SD card all the time which is something I want to avoid. Avoiding writes also means doing things like checking whether you've actually done anything to the game or whether you just hit the wrong game on the menu and then quit out straight away. If you didn't press a button, then there's no need to auto-save, which would save one "write" from hitting the disk. It also means that I have to be careful - what if that auto-save is corrupted, or what if it takes hours to load/redraw because it's a massive game? There has to be a facility for the user to ignore it. That means more menu options... All this adds extra code, simple though it may be, which needs careful positioning, checking and re-writing, so it all adds up. Like any big change, it'll be a option for people to turn off - for instance if they want to play on a write-protected card.

I also have some "bigger" items on the TODO list. One of them is to be able to stop a game halfway through generation. Unfortunately, this is quite a tricky one because the games are inherently designed to be single-threaded and non-interruptible while in generation (all the official ports suffer from this and the Palm port suffers especially badly). However, there are a few tweaks to the code that can be made to make them interruptible (even if it takes a few seconds for the interrupt to be "seen" by the program). It means adding code to each and every game, unfortunately, but I think it's a sensible thing to do because hitting a large Bridges game by accident could leave the user with no option but to kill the whole GP2X (or at very least telnet in and kill the process). That's an ugly way to play a game. And now that we have a nice integrated menu to fall back to, there's no reason it can't be done in a nice way.

I'm also pretty certain that the games just aren't drawing themselves properly, even though it's damn close. Other ports show clean lines on all resolutions but the GP2X has some overlap issues. This has been there since the start but I was always of the "it's playable" mindset before so I left it well alone. Unfortunately, without single-stepping the code or sitting down with some graph paper and manually following along, it's rather difficult to see where the problem lays. I'm guessing that there is an off-by-one error somewhere but there are so many "definitions" of the various graphics routines involved that it's hard to track down - does setting a clip rectangle of 10x10 at 5,8 mean that it extends from 5,8 to 15,18 or from 6,9 to 15,18 or from 5,8 to 14,17 or what? It looks likely that I misread something and made a small error between the translation of the puzzles concept of "clipping", "blitting", or "drawing" and SDL's concept of the same. This would fix such things as Solo's missing lines.

One of the other things I have added is massive amounts of debugging code, turned on by compiler options, which should be able to resolve such discrepancies once and for all. It's just a matter of running a debug-compiled version on the PC, capturing the megabytes of debug logs and then manually replicating them on graph paper to see what goes wrong and where.

Then, I have a few extra bits of "polish". I'm considering a musical background noise. I wouldn't normally bother but it's v1.0 and it's a very simple thing to implement. The games seem to have more than enough spare capacity to play music too (the Palm port is noticeably slower on similar-MHz models) and I've found a couple of relaxing background tunes on a Creative Commons site, so when I get bored of the dreary work, I'll plug in some code for that. I've also considered short sound effects for such things as entering a game, pausing it, pressing a menu, clicking within the game etc. None of these things will affect anything if the player doesn't want them - they will be easily turned on and off and may even be off by default.

There is also supposed to be a way to "write down" the definition of a puzzle, so that you can pass it to friends. This is implemented as "Copy" in the desktop versions of these games but I consider it a bit pointless in the modern age. If the GP2X could do Bluetooth or something easily then I would use it as a basis for a "Beam game" option similar to that present on many Palm games. As it is, I might implement it as a menu option purely because it's so simple to do (call one function, get the "answer" as plain text, display it on the screen) but I don't see anybody using it. With the new menus, it can be put there without getting in the way.

The puzzles also have "print" options, but I'm deciding to leave those out entirely because I very much doubt anybody would bother to print them off, and adding the whole Postscript-creation routines into the puzzles is a bit overkill for a function nobody will use and nobody can use easily anyway. You would have to "print" the puzzle to a PS, or possibly PDF, file on the SD card, take it to a desktop machine (which has its own port of STPPC which understands the same savefile format and can print direct) and then send it to a printer. Because it's achievable in an identical amount of time, with an identical process, just by moving a savefile over to the PC version, I'm leaving it out.

I'm looking at downclocking the GP2X when it's not being taxed (i.e. most of the time it's actually in-game or in the menus, but NOT during puzzle creation when the poor thing struggles along) but I've still to experiment and test this thoroughly (when testing, you want to get into the parts you know are buggy as quickly as possible!). There would be a problem if it decided to throttle itself back on a certain game which would actually benefit from going faster and so just frustrate the user for no reason. I don't know if and how it would affect battery life but I hope that running at a slower clock speed is actually better for power consumption that just idling at a higher clock speed. There is a lot of take account of, though, because the cursor-motion and input is tied to the speed of certain timers and it would be very bad if they started getting lagged or overwhelmed because of the number of events happening while it was running slower.

There are lots of other things that I want to do but they are either trivial, cosmetic, only affect the source code, or they really aren't worth mentioning. I don't know when v1.0 will be finished but it will be finished sometime - every time I find myself in a programming mood, I'm on the GP2X straight away. Every time I play the GP2X, I suddenly find myself hacking on the code.

All in all, STPPC2x has been great fun so far and it's only recently that I've actually figured out how to win all the games in it! I still don't succeed every time, and Tents and Blackbox are often the most surprising ones - you get to the end by applying what you think is perfect logic and then you just cannot fathom the answer. Sometimes you can get it by restarting that same game but sometimes you just have to reach for that Solve option and then you start kicking yourself!

I do want to get out a v1.0, something to say "this is a real port of the games", I want it to be polished, I want it to be complete and I want it to stick around with the GP2X. Probably nobody else will continue the port to other platforms based on this particular code (although a couple of people have borrowed the early SDL code that got the games to a playable state for things like PlayStation Portable ports etc.) because there's such an abundance of power in modern consoles to just run the original versions or simple modifications - there are even Java ports of the collection now. But to have hold of a classic games console, quite rare, quite unique, very open, and to have a copy of a polished port for it that I know I wrote - that's something I want to be able to do. I don't care if nobody ever downloads it or nobody else owns the hardware to run it, but I'd like to be able to show it to people and say "I did that".

In twenty years, I want to find my GP2X in a dusty old box somewhere and spot an SD card with "STPPC2x v1.0". I want to plug it in and show any kids I have: This is what I did. This is how we used to make computers work. This is the code and tools I used to do it. This is what a lot of companies "these days" try to make you think is done in a magic box at Microsoft. Look, despite it being 20 years ago, I can still load this stuff up, I can still know how it works, I can still fix it when it goes wrong. Let's have a quick game of it before I put it back.

STPPC2x Beta 5

The next step on my efforts to port Simon Tatham's Portable Puzzle Collection to the GP2X. This is now a set of 30 addictive logic and puzzle games (3 are new to this release!). Some are old favourites (like sudoku, sliding puzzles and minesweeper) and others you may not have seen before. An awful lot has changed in this release, not just some extra games, so make sure you read this whole thing!



You can download BETA 5 of STPPC2x immediately from the main website: http://www.ledow.org.uk/gp2x/ or from the GP2X archive (which may take a while to change from Beta4 to Beta5).

PLEASE NOTE: This release is a bit of a leap in how the collection operates. It is recommended that you create a new folder for this version - the directory structure has changed significantly. INI's and SAV's from previous versions are, of course, still compatible but may need a little renaming (same_game.ini to samegame.ini or rect0.sav to rectangles0.sav, etc.)

So, what's new? First, we have a fantastic menu drawn and programmed by juanvvc:



Many thanks to juanvvc for the great work on that, I think it really makes the collection look much neater and more professional. In fact, it works so well with the games that it is now the default menu, even on my own GP2X. Eventually, it'll get merged into the program itself so that there's just one piece of code for the whole thing.

The games are now just one program and one menu to run that program. If anybody still wants to be able to run each of the games individually as they did before, give me a shout, because I still test the games individually on my own machine. If there's demand, I can do two different releases - one with a single executable, one with an executable for each game.

There are also three new games: Slide, Sokoban and Maze 3D.

Slide is an "unfinished" game from the original collection that, as far as I can tell, is working perfectly but can be a bit slow to generate new games (if it takes a *long* while to startup or make a new game, don't worry - it hasn't crashed, it's just slow! I had to make a loading screen just so that this game doesn't make people think it's crashed!).

The object of the game is to slide the highlighted piece into the gated area by moving the blocks around. It sounds easy but it's not!



Sokoban is another "unfinished" game. I'm sure you have all seen this before - push each of the brown "crates" onto one of the circled areas. It is working perfectly but the levels it produces are randomly-generated and therefore usually very simple. But it plays well, so why not.



Maze3D is a third-party game from Eddy Macnaghten. You have to find your way through a 3D maze (2D if you change the options) to find the yellow sphere exit. It can be a little confusing at first. I recommend that you play mazes with "height" of 1 (i.e. a 2D maze) to get the hang of it, before trying smaller 3D mazes (e.g. 3 x 2 x 2, the smallest possible size). You can happily play up to 20x20x20 mazes (it's actually surprisingly fast to generate them), but you'll never find your way out of one that big without the help of the "solve" function, which puts a yellow thread on the screen which you have to follow to find your way out!



Maze3D isn't perfectly suited to the GP2X (it really needs a larger screen, and a better control system) but given that the code for it was last written in January 2006 and that I had to change one (trivial) line to get it to work on the GP2X, it's amazing it works at all! I also tweaked the code a bit more to allow me to put it neatly into the collection and to adjust the colours slightly.

I think Maze3D shows the power of these games as not just "a collection" but an entire puzzle game API that can be used to write lots of different games and get them ported to many platforms simultaneously, without having to write a single line of machine-dependent code. If anyone knows any other third-party games that use this puzzle engine, please shout. If anyone writes a new one that uses this engine (there is example code, documentation and I'll even give you a hand), shout louder!

STPPC2x has also been relicenced as GPLv2. This allows me to add in some useful code from various places. This was prompted by juanvvc thinking the collection was GPL and ended up with me deciding to change the license to GPL!

This beta now has 29 fully-working games, the only remaining one is completely unplayable on the GP2X - mines, a minesweeper clone. Don't run minesweeper - it'll crash. And yes, it's annoying the hell out of me as well that it doesn't work yet.

The full changelog from the previous Beta also includes items such as:

- A single monolithic executable for all the games.
This drastically reduces the size of the collection (from 17Mb to about 3Mb - mostly due to the fact that each game carried 0.5Mb of static SDL code with it). And eventually I'll be merging the menu with the games directly (at the moment, the menu spawns the games individually from the monolithic executable).

- A new "loading" screen because the new game Slide can take forever to load initially and people might think it has crashed.

- Several optimisations to try to reduce CPU use including: Faster and threaded events code, more compiler optimisations, making the main loop sleep a bit more, tricks like the loading screen to make people "think" it's faster, etc.

- Changed the background colour (well, I had to keep juanvvc happy after he made the menu for me!).
White lines are now more easy to see in Bridges, Inertia etc. The GP2X is just colour-inaccurate and the colour difference never showed up properly before (if you tilt the GP2X screen up on the older versions, you can see the white lines were always being drawn but showed as nearly the same colour as the background). I also had to change Maze3D's default colours because on a PC they look fine and on the GP2X, they all look white!

- Lots of tiny interface updates

Feedback is appreciated (especially from F-200 and USB mouse users) and full source code is available from:

http://www.ledow.org.uk/gp2x/

Note that this is an unofficial port - so please don't bother Simon Tatham with any problems, although he is aware of the project's existence.

There is also a "development blog", which will contain articles about developments to come etc. at http://stppc2x.blogspot.com

Beta 5 Sneak Preview Screenshots

Sneak previews of Beta5. Enjoy!

Development update

I *am* still working on the collection!

In fact, there's a lot of exciting stuff going on, but I've been holding off on a release until they are ALL ready. I had a slight hindrance of a few hours work being lost but I've managed to recover or reproduce all of it without any problems (and even fixed a problem or two that I knew existed in the lost code, because I was able to start from scratch!).

Some sneaky news to keep people's interest:

New games. (!)
New menu for all the games.
New folder layout.
Better colours (so you can see elements clearer).
Interface cleanup - unsolveable games tell you so, games that can't enter numbers won't let you, made the first load of the in-game menu much quicker etc.

The current release-stopper is F-200 compatibility - I have an accurate way to reproduce all the issues seen with the F-200 touchscreen but it takes a lot of time to test each revision. Also, I'm holding back to see what's going on with the new model F-200's with regards to video/touchscreen co-ordinates being different. I still haven't fixed mines, either, and my patience is wearing out with it.

Anyway, I'm hoping to get a release out soon, even if it doesn't have F-200 touchscreen compatibility. So hang on. I'll get there.

SDL Events and the F-200 touchscreen

It's always the way. Fixing one problem creates several more.

The F-200 touchscreen was stalling because the event queue in SDL (or at least the latest ported version of SDL to the GP2X) is, basically, naff. So instead of getting useful information when the queue was full, I got hundreds of identical MOUSEMOTION events with the same co-ordinates, and it skipped lots and lots of BUTTONPRESS, BUTTONRELEASE and other events that were vital. Surely the wiser thing for the SDL library to do would be to discard all MOUSEMOTION events except the last when the queue is going to overflow, or at least discard *identical* MOUSEMOTION events? You're not going to get "smooth" movement over every pixel you touched anyway, because the queue has overflowed, so why not just trim the queue of useless messages and keep the vital ones?

Anyway, moving to EVENTTHREAD functionality (where a thread is spawned at program start to do nothing but handle checking for events) seems to "fix" the problem and you get touchscreen movement that reports the motion of the stylus properly. Unfortunately, it also significantly increases the latency of all events, including mouse, joystick, timer and touchscreen, when the queue is as busy as it was before. The difference is extremely obvious - without it, the code works fine for everything but touchscreen perfectly well, with it, everything just slows to a crawl but touchscreen works. Dragging a circle in untangle, for instance, literally takes a second or so for game to actual catch up with your motion.

However, I have read of several fixes for that and there's some abstraction of code that can be done to improve the situation, so it's not a big problem - it's just a matter of trimming the code that needs to be executed when events are recieved and sorting out the timing a little. I have a number of fixes that can be implemented:

1) Bob Pendleton's fast events
2) Merging of the mouse timer and game timer into a single event that handles both (should cut the events by about 40-50 per second but they do a lot of work each)
3) Optimising all in-event code (and so hope to get rid of events quicker)
4) Optimising code generally (with the compiler, profiling etc. to get rid of events quicker)

I'm hoping that only the first is necessary. At least now things are reported as they should be and giving expected behaviour. I could never comprehend why touchscreen events bothered to fire if they were MOUSEMOTION to the exact same pixel as the last MOUSEMOTION with no difference in buttons or co-ordinates.

Anyway, the next Beta (dare I move to v1.0 status without mines working?) is shaping up to bring in a lot more users - the menu from juanvvc makes it look a lot better, works much easier and will, I hope, be an integral part of one humungous executable that can run all the games willy-nilly. And hopefully F-200 users will finally be happy (although only one of them - Morgushong - has officially bothered to put in a bug report about this problem).

I'm also setting up an SVN server so that more people can get at the code in an easier fashion. Currently, even my own source control is getting a bit out of hand, with BETA's, public releases, debug builds, testing of various ideas, backups of working code etc. so I need to move it to a more logical format.

User-contibruted menu! Thank juanvvc!

Well, my pleas for a nice menu for STPPC2x weren't falling on deaf ears after all. I was recently contacted by juanvvc who has made a fantastic menu for the games that works really well. With his kind permission, I'm going to be including it with the next BETA because it's just so damn useful that within minutes of trying it, I'd modified my whole build environment to use it and put it on my own GP2X to run the games.

So, thank juanvvc for not only giving you a great piece of work but also doing it in such a way that he's been kind enough to provide source for everything included and permission for it to be tied in with STPPC2x. We're going to iron out a few wrinkles first (nothing technical or "wrong", just a few personal preferences of my own) and then it'll become part of the main code.

This will, however, mean that the next version of STPPC2x will have a slightly different directory structure, so you might want to install it into an empty folder and then copy across your INI/SAV files from the older BETA's if you want to keep them. Trust me, though, it'll be worth the effort. I'll post a screenshot when I can get around to it and I'm in the middle of making some a SWF movie to demonstrate the menu, the games and the configuration so that people can see how the newer BETA versions have improved since the first versions.

Development update

Well, BETA 4 is out and includes saving - games and configurations. It also has a couple of tweaks and a bugfix for a quite serious bug.

The bug was related to dragging objects off the top or left of the screen. For some reason, the game midend functions just die when you do this (even though they have "int" as the type for the variable) and the program would crash. I hadn't noticed it and it's been about for a while. It's been in the program for at least the last two beta's, for instance. It only affects the left/top edges of the screen. I fixed it by making sure that the mouse couldn't be moved "off screen", by setting the drawing clipping region properly (it was happening because SDL was being told to "blit" the cursor to a negative x/y value, but it was the game midend that was telling it to do so, even when the mouse was quite some distance from the edge!). So I added proper clipping and a few extra checks and seem to have caught it. At least, I couldn't trigger it with either mouse (no matter how fast I "threw" the cursor against the top or left ) or the GP2X controls.

Mines is still proving an enigma. SDL versions using identical code work fine on PC and crash on GP2X. I'm trying to set up a QEMU ARM environment and see if the same happens there. If so, I'll be able to send a complete "demo" image to Simon Tatham. The GCC options for signed/unsigned bitfields/chars don't seem to fix the problem but the symptoms point at it inserting negative numbers where they should be positive (so, for example, wherever there would be a "1" on the gamefield, a "flagged mine" appears on the screen, before the user has even done anything - flagged mines are represented by -1 inside the game state). These numbers are not generated or used by the SDL frontend at all, they are internal game variables that store the state of the minefield.

Short of running the whole game through GDB or printf()'ing the thing to buggery, it's hard to track down where/why it's doing this. It always asserts at the same point (line 599 of mines.c) but that is part of a recursive function that gets called lots during the course of a game. However, the crash only triggers when you click a box and the game shows problems right from the very start with the initial draw of the gamefield.

I'm also looking more closely at F200 touchscreen and have an emulation set up so that I can test the way it would work on an F200. A few people have reported problems but I had little or no information to go on to resolve them.