Stppc2x - The Complete Collection - Beta 4


ledow

Member
Joined
Jan 6, 2008
Messages
430
Age
45
Location
UK
Website
www.ledow.org.uk
The next step on my efforts to port Simon Tatham's Portable Puzzle Collection to the 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.

puzzlesyt1.gif


This is the fourth beta release of the entire collection of the games, which I call "STPPC2x". This beta has 26 fully-working games, the only remaining one is completely unplayable on the GP2X - mines, a minesweeper clone.

You can download BETA 4 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 Beta3 to Beta4).

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

- Fixed the crash caused by dragging off the screen in map/pegs/guess (why did nobody tell me about this?!)
- Centered all puzzles.
- Added default configuration saving.
- Added game saving (10 saveslots, use L and R while paused to select slot, Select to save and Vol-/Vol+ to load).
- Fixed timers while paused (only affected mines anyway which still isn't working).
- Revamped all mouse code.
- Saved a bit of memory here and there.
[cut]
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 create a nice standalone menu program, 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.

There is also a "development blog", which will contain articles about developments to come etc. at http://stppc2x.blogspot.com[/cut]
 
cool. i have been following the progress, keep it up man.

whoops...just wrote a long post trying to nicely ask for a frontend...just noticed that it's on your list. awesome.
 
I was going to speak up before but I never did.

The touchscreen support only works in games where you don't have to click and drag, such as fifteen and cube. (Although sometimes the cursor seems to move strangely sometimes, like moving to another area really fast even though the click activated the correct place on the screen) In other games such as untangle and guess, clicking and dragging doesn't work. The best I can explain it is that when you press the screen and then try and drag something, not much happens, for untangle, the circle you are trying to move seems to move around a little after you lift the stylus from the screen. I could attempt to record what happens with my webcam, but I'm not sure how helpful that would be.

I miss having this collection on my N800, ever since I upgraded to OS2008, so thanks for making this!
 
morgushong said:
I was going to speak up before but I never did.

The touchscreen support only works in games where you don't have to click and drag, such as fifteen and cube. (Although sometimes the cursor seems to move strangely sometimes, like moving to another area really fast even though the click activated the correct place on the screen) In other games such as untangle and guess, clicking and dragging doesn't work. The best I can explain it is that when you press the screen and then try and drag something, not much happens, for untangle, the circle you are trying to move seems to move around a little after you lift the stylus from the screen. I could attempt to record what happens with my webcam, but I'm not sure how helpful that would be.

I miss having this collection on my N800, ever since I upgraded to OS2008, so thanks for making this!
I should give you an award or something. The first useful, confirmed bug report for F200 touchscreen for which I *know* there should be problems but all I ever get is no reports at all or "it doesn't work nice" without further details. Either nobody uses F200, nobody uses the touchscreen on the F200 or nobody uses these games. And I know it's not the last one, because of my download stats.

The problem is that the F200 touchscreen is basically "mouse with left-button always down". And this game wants left/middle/right mouse buttons for dragging and "no button" for moving around the screen. Now, we can eliminate the middle button because most games don't even use it at all and its functions are minor. "No button" is usually not a problem because that's just the "I'm moving the cursor around the screen" phase which touchscreen pretty much negates.

The problems are:

1) You can't right-click or right-drag (useful in map/bridges) with the F200 without really faffing about.
2) You can't use the buttons for right-click/left-click because (I imagine) that's an incredibly awkward control system
3) I have no idea how the F200 touchscreen responds and can only go by hearsay, code I've seen, videos on YouTube and the actions of a USB mouse.

It seems that dragging is causing problems that it shouldn't, however, given your report above. Dragging works fine with mice. Maybe the touchscreen is sending out button up+down events all the time, I don't know. I do know that detecting the F200 in code is very easy and I can program some sort of workaround if I can determine what it's doing.

A video of the screen would be fantastic, if you can manage it. It's amazing how much you can glean from a simple demo when you know the code. Or someone could record it with one of those VNC programs and tell me when and where they click/drag. I've been trying to set up a touchscreen "emulation" library that somebody pointed me to but I haven't had time yet - I'm planning on doing it (and fixing this problem) for the next BETA though, if all goes well. I still can't guarantee that it will actually DO anything though, because emulating something isn't necessarily the same as using the touchscreen itself.

I don't know how to fix the "right-drag" problem, though, because the only things I can think of that would work is for F200 users to hold down the B key WHILE clicking/dragging (sounds quite difficult to do) or to have B become a "toggle" switch, so clicking/dragging after you pressed B would be right-clicks/drags, and clicking/dragging before pressing B would be left-clicks/drags. They would, of course, only do that on F200's and not F100's.

Also, if I could supply you with a debug build of one of the games (basically the same game but so that it writes lots of info to the card), do you think you could run it, play a short game that demonstrates the problem and post the resulting logfile back to me? It would help immensely to see where the games *think* they get a mouse press/release/movement, and what the game does with it.

Thanks for the report, though. I don't own an F-200 but if I did, I'd find it immensely frustrating that these particular games didn't work - they lend themselves so well to touchscreen use. I know that because I've used them on Palm.

rokdcasbah said:
whoops...just wrote a long post trying to nicely ask for a frontend...just noticed that it's on your list. awesome.
Frontend - I assume you mean a menu you can select the games from? It looks like I'll end up making one eventually. I couldn't say when. Basically, I've ended up writing every bit of code that I would need to get such a menu working, and I didn't think I would. As you can see from the configuration menu in the games, all the potential elements are there - drawing a list of text, selecting text with a cursor, etc. and from there it's a few dozen lines of code and a bit of messing about to get one HUGE executable that includes all the games and lets you play them all (a bit like MAME has).

It's on the list, but don't hold your breath. :D
 
Last edited by a moderator:
Okay, I put some video clips on youtube. Youtube re-encoded them pretty crappy but hopefully you can still get the gist of what's going on.
untangle: http://www.youtube.com/watch?v=Tg5QMRFt4TM
guess: http://www.youtube.com/watch?v=3Aen6pDh8xE
and fifteen works good: http://www.youtube.com/watch?v=ned17FgkWew

I could play a debug build if you want me to. That should give some clue of what exactly is going on, and what you are getting for input from the screen. Holding a button down for right-dragging would work fine (might want to set it to left and right side buttons though for people who are right or left handed, like both of the top buttons) , I'd get the left-dragging working first though. Whenever the stylus is touching the screen, the click button should be down, and should stay down until the stylus is lifted. (judging from my guess video, this is clearly not what is happening. If I click and drag, then stop touching the screen, and then click a blank circle at the top, it instantly moved the colored circle I was trying to drag into that position. So, I really don't have any ideas besides seeing what the debug run spews out.)
 
Last edited by a moderator:
Thanks for taking the effort to do those videos. I will be looking at them more closely tonight to see if a debug build is necessary.
 
Okay, I just managed to view the videos by bypassing the local proxy/filter here (it's okay, I'm the network manager!). Thanks for posting such comprehensive and illustrative videos. I think I can tell immediately what the problem is without even having the code or an F-200 in front of me.

Because of the way the programs work and the need for the GP2X F-100 to "emulate" a real mouse, there are several variables which keep track of a "virtual" mouse position on the screen and whether you're holding a "virtual mouse button" down (i.e. you're pressing A, Y or B on the GP2X). Pressing the joystick "nudges" these values around by a couple of pixels in the right direction and then moves the cursor to where it should be (and the SDL mouse cursor that you see moves with it automatically). This generates a mousemove event which is what is passed on to the game. Depending on if you are holding a button down (real or virtual), the mousemove event triggers a "move" or "drag" operation. The game itself then handles moving the dragged items (pegs and other game pieces etc.) underneath the cursor (don't ask why, it's the way the games are designed).

When you use a "real" mouse, like a USB one on the GP2X or one on a computer running the same code, the mousemotion event is fired directly by the movement of the mouse. Inside there, we "update" the virtual mouse with the "real" mouse's co-ordinates/button presses, so that you can happily switch between mouse/joystick control without things getting confused. In effect, we combine ALL inputs (USB mouse, touchscreen, GP2X "virtual" mouse controlled by the joystick) into one mouse and treat them all the same (you can get some "interesting" effects if, for example, you click and drag with one and finish it off with the other etc.)

It appears that what is happening is that the synchronisation between the touchscreen events and the "virtual mouse" variables are not doing their job (either because some events are never fired, or because they're mis-programmed, I can't tell without the code in front of me but I'll have a look later). So the games see the initial "click" that picks up an object (but strangely only on stylus-release!), SDL registers motion on the screen (the cursor moves) but the motion events aren't seen by the game because the "virtual mouse" variables aren't being updated properly, and then when you take the stylus off the screen again the "virtual mouse button" is still down when it shouldn't be (the dots in untangle stay red when they should only be red while you're actually picking them up).

If you then "click" somewhere else, the game suddenly sees both a press + release event. The press event does nothing (it thinks you're already pressed) and the release event is seen at a co-ordinate far away from where the click event started. Thus it updates the variables, "jumps" the dragged object immediately to the position you clicked and lets the object go.

I think the most probable cause is the F-200 generating just "mouse motion with button down" events instead of proper "press", "mousemotion with button press", "release" events in that order - It might be that it's generating "mouse motion with button down", followed by "mouse press" followed by more "mouse motion with button down" when you first press-and-drag.. Because of that, it's confusing the hell out of the "virtual mouse" code which is sending all sorts of strange things to the midend (although the midend is acting perfectly on the information it's being given).

So it would only be drag-based games that were affected (hence why fifteen etc. work fine), so I assume that the same symptoms appear in untangle, guess and map. This isn't suprising, dragging is one of the most finicky bits of code. But there's definitely an event not doing it's job. It looks like some events aren't being seen properly at all.

The remedy is likely to be either fixing some silly mistake I've made if the events arrive out of order, or F-200 specific code to make sure that whenever we check for joystick buttons we also check for touchscreen presses too, to keep press/release in proper synchronisation with real life. I've found SDL events to be a little unreliable when you generate a lot of them on a slow/busy machine, it might just be that the F-200 touchscreen is generating a ton of events. The games trigger a lot of SDL events - several timers at 50ms intervals, mouse buttons, joystick presses etc. In older pre-release versions I hit a point where events were so unreliable, I started manually polling for the buttons at regular intervals instead and ignoring some events.

Without the videos, I would have had a hard time explaining or picturing what was going on. With them, I can see the problem and know what's going on before I've even looked at the code again. Good job on doing them, they were just perfect for what I needed.

If you don't mind, I might make you my guinea pig for this problem seeing as you know what you're doing - I'll knock up some code to hopefully remedy this AND make it a debug executable just to make sure that I've fixed the problem and, if I haven't, get the right info straight away to save you having to do lots of tests. It's such a shame to see a lovely touchscreen with a perfect touchscreen game not working properly.
 
Ledow, you know that I love these games and I've just created a graphical menu for them. I can't find a valid email to send the binaries to you. If you're interested, please see your private messages :)
 
juanvvc said:
Ledow, you know that I love these games and I've just created a graphical menu for them. I can't find a valid email to send the binaries to you. If you're interested, please see your private messages :)
I just did. It's great. With your permission, I'll include inside the collection in future and eventually merge it in with the STPPC2x code (I think I can given the current licensing, but I'll have to triple-check).
 
Last edited by a moderator:
morgushong said:
Okay, I put some video clips on youtube. Youtube re-encoded them pretty crappy but hopefully you can still get the gist of what's going on.
untangle: http://www.youtube.com/watch?v=Tg5QMRFt4TM
guess: http://www.youtube.com/watch?v=3Aen6pDh8xE
and fifteen works good: http://www.youtube.com/watch?v=ned17FgkWew



Morgushong - thanks for this. Not only can I see the problem, first hand, I've been able to replicate it within a development environment. The fix is eluding me for a moment because I've got side-tracked doing a couple of other new things (not just including the menu that you were asking for, with the help of juanvvc's new menu!). Replicating a problem is the penultimate hurdle to actually fixing it and is usually MUCH harder than fixing the bug.

It looks like the code is talking absolutely gibberish about when the touchscreen is pressed and when it is not. This is partly due to a problem with my code, partly due to SDL events being a bit unreliable in terms of their firing, their order and the data they contain and partly due to the touchscreen being an awkward thing to use in these particular games because of the way it works.

I'm getting to the point where I'm tempted to just say "it's an F-200, do you want touchscreen or not" in some fashion and writing the code two different ways.

For some reason, I'm getting massive bursts of identical events which don't follow the movement of the stylus at all (only the initial press and final release position) even when I just report basic SDL mouse events and nothing else. And I get very little data at all for "dragged" movements... so I end up with:

Mouse moved to X,Y, Mouse down at X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y, Mouse moved to X,Y

where X and Y are identical, when you first touch the screen and then NOTHING or a handful of events at very irregular intervals until you let it go, no matter how much you drag, and then a similar burst of release events.

It might be that it's easier to interface with the touchscreen directly and ignore what SDL thinks is happening when there's only a touchscreen connected. The really weird bit is that SDL is supposed to carry touchscreen events across as plain mouse events and that's just not happening at all, but I had similar problems earlier in development with joystick events if you fired timer events too often alongside them. A mouse works absolutely fine with this code (I play untangle using my Linux desktop and this code all the time, for instance) which is really annoying because you would then assume that a touchscreen would work too provided your code didn't do anything too silly.

Anyway, I'm still looking into it but I can now reproduce the exact problem that you see (thanks to Lithosphere's "VNC Server for GP2X (F200 TS emulation)"). When I said before that I don't expect F-200 touchscreen to work well with the games, I never expected it to be THIS bad. If I can fix this, I'm sure a lot more people would use the games.
 
Last edited by a moderator:
Back
Top