For those following the development of these games, I've just fixed the following bugs and I'm gearing up for a release of all the games. Unfortunately, a few still have problems but I see no reason to hold back and do single-releases for much longer.

- You can now input numbers using the L and R buttons and X. This allows you to play filling, solo (sudoku) and unequal. Solo plays fine but unequal needs a specific fix because by default it only uses the numbers 1-4 as far as I can make out. As Solo needs 1-9, this is a pain and means I need game-specific code to make it work with the L/R/X control system. I just need to make something show what number you have selected because at the moment you have to put the number in to find out, then change with L/R. It stays on the same number until you press L/R though so numeric-input games are playable if you can remember a single-digit number.

- I've fixed a few bugs here and there related to mouse/keyboard input. Most people probably wouldn't have noticed as they only affected games that haven't been released yet.

- I've fixed the absolutey idiotic mistake of mine that makes the wrapper-scripts point to the wrong path (I'm a prat). The directory structure will change for the "full release" and I forgot to change it back for the individual release.

- Mines is giving me more problems than anything else, now, despite running perfectly within the development environment. For some reason on the GP2X it doesn't play correctly from the very first second, even though there is NO GP2X-specific code run up until the point it errors out with an "assert". I've looked at the code around the assert (which is in mines.c and I've NEVER had to do anything to the game code, only the SDL interface code) and I have no idea what's wrong.

Running mines on plain Linux with the exact same code, screensize, bit-depth, SDL libraries etc. doesn't give you any problems. It's either a very subtle timing bug or a problem with memory (but I would expect memory errors in that case). Mines, unfortunately, may have to be pushed to the back of the queue.

- I've made it so that L+R now quits, because it's easy to hit Vol+ accidentally if your finger slips off the control pad on the F-100 (I was SO close to finishing my game of dominosa!). I might change that to Vol- / Vol+ in future.

For the games not mentioned below, I haven't tested them thoroughly but they seem to play fine. I'll reserve judgement until I can complete a whole game on them just to make sure but I think they are all releaseable.

Bridges - I have a slight problem with "locking" squares but that just seems to be the way the game works. Once a circle is locked, it's a pain to unlock it. It can be finnicky on my Linux PC too, maybe the lower clock speed exacerbates the problem a little?

Cube - In a state that I could release it.

Fifteen - In a state that I could release it. Sometimes a little slow on animation - using hardware SDL surfaces or overclocking might speed that up but I'm not too worried as it just "skips" animation frames rather than slow the game down.

Blackbox - In a state that I could release it.

Tents - In a state that I could release it.

Pattern - font display a bit too small for some puzzles, but otherwise fine.

Dominosa - In a state that I could release it.

Flip - In a state that I could release it. Sometimes a little slow on animation, like Fifteen.

Guess - Drag-drop problems like Map but playable. I'll probably just edit the game code to remove the cursors, because I've tried lots of different things to stop it doing it and none of them have made the slightest difference.

Lightup - In a state that I could release it.

Netslide - In a state that I could release it. Sometimes a little slow on animation.

Rect - In a state that I could release it.

Samegame - In a state that I could release it.

Sixteen - In a state that I could release it. Sometimes a little slow on animation.

Twiddle - In a state that I could release it. Sometimes a little slow on animation.

Map - drag-drop display problems the same as Guess.

Pegs - drag-drop display problems the same as Guess but which also lead to an enormous slowdown when you drag, making it unplayable. This is the only problem with pegs, though.

Solo - In a state that I could release it.

Filling - In a state that I could release it.

Unequal - In a state that I could release it. Sometimes a subtle bug crops up.


Anyway, expect a release of all the games in their current state "soon". First, I have to fix the mouse once and for all, then get rid of the drag-drop problems that stupidly stop two games from working when the drag-drop display is totally unnecessary. Then I may add a few little touches such as showing the current digit for the L-R buttons, maybe a quick menu for all the games.

I'm also intending to do a full source release with the full collection, with full LICENSE files, a nicer directory structure, all of my build and test scripts, even the exact Open2X toolchain and libs that I used to get it all working.

At least one person wants to take that and try to port the collection to PSP using my SDL code.

"Net" released

Second release: NET!

The strange mouse behaviour has improved a little (and an update to untangle with the same changes has been uploaded too). Anyway, enjoy the second of many games from this collection!

http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,25,2529

"Untangle" released

First release: UNTANGLE!

I had to change the schedule a bit after Net starting exhibiting strange mouse behaviour under certain situations, only on the GP2x. And bridges did something that I need to double-check but I think that's just me being a pillock. Anyway, enjoy the first of many games from this collection!

http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,25,2526

Okay, so it looks like the order of release will roughly be the following. I'm hoping to get them into some sort of distributable state over the Easter holidays, which for me is the next three weeks. Don't take that as fact, though.

Most tested and verified working through lots of complete games:

Net (most tested, works very well without any problems)
Bridges (very well tested, works very well without any problems)
Mines (user request, works very well without any problems)
Untangle (works very well without any problems)
Cube (works very well without any problems)
Fifteen (works very well without any problems)
Blackbox (works very well without any problems)
Tents (works very well without any problems)
Pattern (font display a bit too small for some puzzles, but otherwise fine) - I'm not too worried about this one given that the excellent GhostPix is the same type of game and infinitely better.

Only basic testing has taken place (i.e. I played with them for a little while by clicking around and checking things changed, and completed the ones that I was able to complete, without any major problems showing up) for these ones:

Dominosa
Flip
Galaxies
Guess
Inertia
Lightup
Loopy
Netslide
Rect
Samegame
Sixteen
Slant
Twiddle

These ones will have to wait until I have released most of the above due to some problem with them:

Map (drag-drop display problems make playing it very ugly)
Pegs (needs looking at to find a quite annoying slowdown when dragging that wasn't there until a few revisions ago, probably SDL Timer related - it looks like it's trying to draw circles over circles over circles as you drag the "mouse")
Solo (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)
Filling (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)
Unequal (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)

If anyone would like to suggest a mapping for the keyboard, or express a preference for right/left/middle click buttons on the normal games, I'd be open to ideas. At the moment, I'm using shoulder buttons but I think it might be easier long-term if I use the top three buttons (A,B,X?) of the right-hand side for "mouse clicks". L+R shoulder buttons will probably change numbers in those games that need them. Select will probably be "restart this game". Start will probably be "new game", with vol+/vol- being "quit".

I'm hoping that F-200 users will get touchscreen but I can't guarantee it as I don't have one (and, honestly, don't really care that much about it so long as it's playable in some fashion, although I am being careful not to use stick-click and other F-100-only features) - but if it's seen as an SDL mouse or it's easy to code, then it will be so. From the look of it, I can open a device file, read an entry and get X,Y co-ords which is enough for "click" but then I'd worry about how you'd right-click or middle-click (probably holding down the relevant button while pressing the screen but then that's more coding to differentiate between F-100's and F-200's and F-200 users who want to use F-100 style controls, etc.).

Changing sizes/difficulty of the puzzles will have to be done by supplying command-line parameters (so a simple menu system could take that away from the actual program executable quite easily), and saving/loading/playing a particular numbered game I really don't care about and stripped out, so all that code would have to be reintroduced by someone else. I suspect the easiest way would be to supply a command-line argument again.

In the future, users would have a "puzzle menu" (which could be quite a simple C / SDL program but I'm not going to write it) which would allow them to select games, change difficulty, size etc. and then run a game. When the game quit, it'd go back to the "puzzle menu". Without such a menu, these programs would have to be run inside script-wrappers if they are to re-execute the main GP2X menu. I'll include those because I care about that, but I don't want to get involved in making a "puzzle menu".