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.