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.