Thanks for the feedback, everyone. And for the screenshot Mr 2X. I was going to do an animated GIF but found I didn't have the tools to build one (well, I do because I run Linux, I just have no idea what they are or how to use them because I haven't used animated GIF's in years!).
Without an F-200, it's almost impossible to tell how the games are going to work on one. Hopefully, now that the source code is "out there", someone with an F-200 and a basic knowledge of C/SDL can provide a patch for me.
All I know is that the same code works perfectly with a "real" mouse, and therefore will (presumably) work perfectly with a USB mouse on GP2X (which the SDL libraries also support). It's just standard SDL mouse event handling, nothing fancy. When I started compiling against Paeryn's library instead of the standard SDL one, the touchscreen working was basically just an unintended bonus.
The touchscreen problem is certainly a funny one. Mouse control of those games is as smooth as silk using the same SDL code on a Linux machine of comparable speed (you can actually compile the same source code for "ordinary" Linux and run them - it's very useful for debugging). It's probably due to the fact that the touchscreen "holds down" left-click all the time. The only way I can think of to fix that is to ignore the actual "mouse" left-click and just use the A, Y, B system to register clicks. That means having to hold a button while "dragging" with the pen on the touchscreen which sounds horrible to me.
So pressing the screen would only affect the mouse cursor position and not actually click/drag anything unless you were holding A, Y or B. That's all I can think of without having an F-200 in front of me to test. Maybe I'll have to get one for my birthday.
"There are instances that the cursor jumps around and incorrectly selects stuff (which can be annoying)."
That's strange. The cursor control under the programs is just SDL. Paeryn has put part of the touchscreen library inside his library to help F-200 users, so the touchscreen appears as a mouse. I don't know why the cursor should jump - the game framework does lots of weird things (like specifying colours in floating-point numbers from 0.0 to 1.0) but the mouse handling is basically "process a left-click on X,Y" or "process a left-release on X,Y".
It doesn't care that you let go of the button half a mile from the place you started moving, it doesn't care about much at all - in fact the joypad code basically "warps" the actual mouse cursor to whereever it feels it needs to be to make a smooth movement - this generates a standard SDL mouse event that then sends the code through the same codepath as if you had moved the real mouse like that. At the moment the joystick moves in blocks of 2 pixels (which I could increase to increase the mouse "speed", but you start to lose accuracy, or I can increase the rate at which it checks the joypad and adds these pixels on if need be - I'll experiment) but if it's in blocks of 10 pixels, or 50 pixels or 100 pixels the games still don't care and still drag perfectly with the joypad.
"Touchscreen is useless on games that require number input."
I take it you mean that you'd like it to skip the whole L/R/X thing and just cycle through numbers on each click? That's only possible by making code that works outside the platform-independent, game-independent, heavily-specifed framework, which I am trying to avoid. At the moment, it needs to fake pressing the "real" 1,2,...,9 keyboard keys and although you can do that with L/R/X, trying to do it when you click means trying to "look into" the particular game you are playing and work out what to do (do I click, drag, enter a number?) as well as moving some items of the game state (e.g. what number is in that box to begin with?) outside of the game code. At the moment, only a single file is modified to make ALL the games work on GP2X and any SDL platform. I don't want to, for example, edit mines just to fix a bug I only get in mines. That means I have to update mines every time it's updated upstream as well as fix my own bugs in there. And it means that "new" games added to the puzzle collection upstream should "just work", once I've ironed all the bugs out of my SDL frontend.
"I noticed that not all the games have the Solve function, but the "Solving..." indicator would still come up."
Yes. There is actually a function "midend_can_solve()" specified by each game which I could use to determine whether a puzzle could be solved or not. I should really make the solve buttons check that before printing text. Thanks for the suggestion.
"I haven't thoroughly played all the games yet, but so far, those I played worked fine (aside from those you mentioned), although some had minor graphical glitches."
Yes, they do. There are off-by-one errors in some of the polygon and rectangle drawing code due to a difference between the GTK functions that I was using as a reference and the SDL functions I was writing. "map" is the best example of this and the one I'll be using to "target" the bugs. Hopefully I will fix as many of these as I can. The only drawing problem that isn't a bug is that in "guess" the rows of circles overlap each other - that's not a bug but because the screen is very shallow on the GP2X - 240 pixels isn't a lot of room. But the "shadows" that get left behind when you drag in "guess", "map", etc. are definitely a bug - I think in either the clipping or blitting functions that the midend uses.
"Argh it's my favourite homebrew on DS (PuzzleManiak )"
Yes. And they couldn't get mines working either, it seems!
Although I hadn't noticed their port and I did a lot of googling beforehand to try to find one.