Stppc2x - The Complete Collection - Beta 1


ledow

Member
Joined
Jan 6, 2008
Messages
430
Age
44
Location
UK
Website
www.ledow.org.uk
I'm now releasing my entire progress on porting Simon Tatham's Portable Puzzle Collection to GP2X. This is a a set of 27 addictive logic and puzzle games. Some are old favourites (like sudoku, sliding puzzles and minesweeper) and others you may not have seen before.

STPPC2x.png


This is the first beta release of the entire collection of the games, which I now call "STPPC2x". This beta has 21 fully-working games, the rest are in various states but only two are completely unplayable on the GP2X - mines and pegs.

If you tried the earlier test releases, these games are now in a *much* better state, with vastly improved cursor control. There are also full instructions, buttons mapped for "solve" and number-entry, game-status text, game icons and lots more.

Feedback is appreciated (especially from F-200 and USB mouse users) and full source code is available from:
http://www.ledow.org.uk/gp2x/. I'm also looking for help from any SDL/C coders to fix the rest of the games, create a nice menu, add some more features, etc.

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.

You can download STPPC2x here: http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,25,2532
 
Touchscreen on the F-200 seems to be working now, but it's far from perfect.

"Untangle" can't be played properly using touchscreen, as dragging is very buggy and unresponsive. Fortunately, most of the games require only tapping the screen, which works most of the time. There are instances that the cursor jumps around and incorrectly selects stuff (which can be annoying). Touchscreen is useless on games that require number input.

The D-pad controls is much better now, although still a bit slow. Maybe adding an acceleration to the movement or holding down a button to increase speed would improve this? The number input also seems to be a bit tricky to use.

I noticed that not all the games have the Solve function, but the "Solving..." indicator would still come up.

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.

Thanks for the release, and keep it up. :D
 
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!).

Manjuu:

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.

Arialia:

"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.
 
For touchscreen on GPX 200

you don't have an indicator if touchscreen is pressed or released ?

it is very useful on DS

so we can make a code like that :

CODE
while ( 1)
{
scanKeys();
pressed = keysDown(); // buttons pressed this loop
held = keysHeld(); // buttons currently held



touchXY=touchReadXY();
if (held & KEY_TOUCH) // if touchscreen is pressed during this frame ...
{
pt.x= touchXY.px; // then we can use stylus position;)
pt.y= touchXY.py;
}
....
updateOAM(); //MAj sprites
swiWaitForVBlank();

}
 
Arialia said:
For touchscreen on GPX 200 - you don't have an indicator if touchscreen is pressed or released ?
From what I understand (and I have looked at this issue), the GP2X touchscreen is reported to SDL as either "left-mouse-button pressed at X,Y" or "left-mouse-button released entirely". So there is no way to "drag" without it being always seen as a left drag, unless you do awkward things like entirely ignore the mouse buttons and, say, treat the A button as left-mouse-button etc. That means holding a button on the right of the console while you drag on the touchscreen - a nightmare for any right-handed person.

The only other thing I've noticed is a pressure reading - if that works roughly as it should, I might be able to look further into things and get it to see the difference between "move the mouse cursor over to here" and "click and drag over to here" but I don't think it's that easy, especially without a F-200 tester on 24-hour emergency callout. :) It's very hard to diagnose problems that you cannot see yourself.

Also, from what I've read, the touchscreen only has an accuracy of +/- 5 pixels anyway and that's only due to a lot of heavy interpolating done by the tslib libraries. So, for some games, it will always be a bit of a pain to drag accurately on a GP2X touchscreen. "untangle", for example, draws circles of about 8 pixel diameter. :)
 
Last edited by a moderator:
Back
Top