2008-01-25

Woopsi2x Abandoned

Tinkering with and researching the GP2x’s touch screen reveals some answers to the questions posed last time around.

First off, my GP2x isn’t duff. Other people have discovered the same problem as me - the only readily-available example of using the touch screen on the GP2x jitters like crazy.

I’ve tried swapping batteries, which often cause problems with the console, to no effect.

Testing the read() function reveals that the touchscreen will produce new values every time it is interrogated. There’s no need to wait for a VBL before it will produce new values. This means that my initial jitter-removal routine based on mean averages was actually doing something. I’ve increased the sample count from 5 to 40, which has improved things a lot, but it’s still nowhere near perfect.

I realised that I’ve got no idea what the “open(“dev/touchscreen/wm97xx”)” command does. Does it access the raw hardware, or does it just open a driver? Not having done any Linux kernel hacking I couldn’t say. I’ve looked through the driver sourcecode and it appears to have some jitter correction built-in. It definitely compensates for some of the quirks of the hardware. If the open() command works with the driver, there’s something seriously wrong if I’m still getting wildly different values back each time I poll the screen. If I’m working with the hardware, I’ll have to re-implement the driver for the 2x in order to get any decent values from it.

Some digging around in the code for the 2x’s port of ScummVM suggests that the author built a time delay into its touch screen routines to cater for the jitter. At least that way you’re guaranteed to get steady values for the duration of the delay. Works fine for Scumm, as it doesn’t really require fine control. No good for Woopsi - any jitter is immediately obvious. One clever idea the author had was to use the SDL_WarpMouse() command to move SDL’s cursor to match the GP2x’s stylus position. This triggers an SDL_MOUSEMOVE event, which can then be interpreted in a standard SDL event parser block without any custom code. Neat.

The official SDK has no documentation. Nothing. There doesn’t seem to be any way to get the sourcecode, either (which is rapidly becoming my favourite way to understand a program - don’t tell me how it works, just show me the code).

Coupled with the fact that the GP2x has been abandoned by the majority of coders in favour of the forthcoming “Pandora” system (which looks like a weird cross between a 48K Spectrum, a dual-shock PS1 pad, a DS and an N-Gage), I think creating a GP2x port would be a painful waste of time. Shame, because the new d-pad does actually make it quite a good system.

Here’s the touchscreen class I came up with (credit to the author of the original “touchscreen_sample.zip” file, who neglected to include his details in the zip):

GP2xTouchScreen

I’ve switched it from using Woopsi-style “u8”, “u16”, etc types to using SDL-style “uint8_t” types. I haven’t compiled it since then, but it should be OK. Consider the archive public domain.

EDIT:

Increasing the number of samples to 100 further increases the accuracy, but has a noticeable impact on speed. It doesn’t solve the problem of the touch screen occasionally producing totally incorrect values. Having noticed that the amount of pressure needed to trigger a response isn’t even vaguely uniform across the surface of the touch screen, I’m growing more and more certain that GamePark skimped on the touch screen and used components that fell off the back of a lorry.

Comments

Paul Panther on 2008-01-30 at 22:12 said:

[quote]Coupled with the fact that the GP2x has been abandoned by the majority of coders in favour of the forthcoming “Pandora” system[/quote]

Sorry, but that simply is wrong. There are a lot of projects in the pipline for 2008. Look here: http://www.gp32x.com/board/index.php?showtopic=40252

I’m sorry that you decide to abandon Woopsi2x. It looks very promising.

If you need help or clues about the programming of the GP2x you may use this forum for help:

http://www.gp32x.com/board/index.php?showforum=45

ant on 2008-01-31 at 15:59 said:

It’s undeniable that the GP2x homebrew scene is a lot less vibrant than it was. GP32x.com and GP32 Spain list a new release every couple of weeks on their front pages. Compare that to the DS scene, which sees a couple of releases every day.

It’s also undeniable that the F200 was largely regarded as a let-down; if the F200 had been released in place of the original F100 I’m sure that the GP2x would have taken off more than it did (reasonable d-pad + touchscreen, no matter how wonky, equals a more attractive prospect than what was actually on offer). The more vocal developers on the GP32x boards made it clear that they were expecting more.

The Pandora, on the other hand, has its own section of the forum on GP32x.com. The hardware hasn’t even been released yet, doesn’t have a fixed release date and there’s only one confirmed dev board in existence (Squidge’s), yet there are already 10,000 posts about it.

The thing about developers - homebrewers in particular - is that they love the “new”. Shiny new platforms that no-one’s written anything for yet. The F200’s problem is that it’s far too incremental an improvement over the F100 to make it worth the asking price, particularly when people are saving for yet another Linux-based handheld that will (allegedly) be released some time this year. The F200 just doesn”t offer anything new enough.

I’ve been going through the GP32x forum and the file archives looking for something that will solve the touchscreen problems. The simple fact is that there are no solutions. There are hardly any developers working with the F200 hardware, partly because so few of them own the new console, and partly because the new version stupidly omits the USB debug functionality. F200-specific releases don’t make any sense, because they exclude F100 owners. F100 owners no doubt outnumber their F200-owning cousins by a significant amount.

If I want to solve the touchscreen problems I’ll have to do it myself. It may be that I can come back to the 2x port once the main code is finished and try again; porting it is as easy as replacing a couple of files and recompiling (though there’s a lot of optimisation to do if it was proven to work correctly). Thing is, there are already a few GUI toolkits for the GP2x (SDL itself appears to provide one), so the only real benefit of having Woopsi running on the GP2x is to enable Woopsi applications to be compiled for both platforms without needing to make any modifications to the code.

This sounds overly negative. Despite the problems, the GP2x is a great console. There have been some fantastic releases lately - Frontier, UAE4ALL 0.8 and the new port of Roar are all excellent. It’s really easy to develop for - just download the Code::Blocks-based devkit from GP32x and you’re away.

I actually think it’s a shame that the Pandora was announced in such proximity to the F200. I’m sure that if there was no alternative on the horizon, the F200 would have seen some more releases tailored specifically to its capabilities.

Ultimately, this is just my take on it. It may be that I’m misreading the signs, but I’m sure you can find Amiga fans who will tell you that their platform isn’t dead either.

One last point - I’ve given up on Woopsi2x for the time being, but I haven’t abandoned GP2x development. I’ve got a couple of ideas in mind…

Fueler on 2008-01-31 at 20:09 said:

Please look at tslib, it might have some ways of removing the jittering while keeping the touchscreen responsive.

Paul Panther on 2008-01-31 at 21:15 said:

[quote]One last point - I’ve given up on Woopsi2x for the time being, but I haven’t abandoned GP2x development. I’ve got a couple of ideas in mind…[/quote]

Nice to hear this. :-) Good luck to your projects…

ant on 2008-01-31 at 23:56 said:

@Fueler: Interesting, I haven’t seen that library. I’ll check it out.

Terry Simons on 2008-11-09 at 03:43 said:

Opening a device in "/dev" space in Linux is always interaction with a driver. When people talk about "Directly accessing the hardware" they're talking about direct access to the driver. You can't poke hardware directly in Linux without going through the kernel, which means you're talking to the driver.

It sounds like the driver is badly written, although your theory that the screen itself isn't great is a possibility too, or maybe it's a combination of the two.

It might be interesting to look at the driver's source code and see what's happening there.

Also, just out of curiosity... It seems like having your TouchScreen class use a constructor to auto-initialize itself, and a destructor to auto-deinitialize would actually save a user 2 calls (and possible headaches for cleaning up in the case of a major failure).

One last comment...

You should probably use uintX_t and intX_t (not sintX_t) for the various data types. I suggest this because those types are standard types in various unixes (look at stdint.h). sintX_h is not a standard type, so I had to tweak your class to use int16_h instead.

Since your library could be standalone (i.e. not used with SDL) it makes the code more portable.

Terry Simons on 2008-11-09 at 03:47 said:

Oh, one other thing...

I haven't seen anyone talk about the GP2X Wiz on here.

http://gp2x.co.uk/

The Wiz is sure to entice some developers. I know I'm torn between it and the Pandora... I like the form factor of the Wiz a lot better, but the Pandora has some more interesting uses, potentially.

Anyway, perhaps the Wiz would work better for Woopsi.

  • Terry

ant on 2008-11-09 at 21:51 said:

Thanks for the comments Terry. I pre-ordered a Pandora, so as soon as that turns up and a reasonable dev kit is released I'll try a Pandora port.

I was tempted by a Wiz, but I have three main problems with it:

  • As a newly-impoverished student (for the third time) I can't really justify buying both the Wiz and Pandora
  • Despite last-minute changes to fix a terrible design decision, I have no faith in GPH's ability to make a functioning joypad
  • It represents yet another split in the already fractured, niche GPxx market

I might get one eventually, though.

ant on 2008-11-09 at 21:54 said:

Hmm, the Markdown bullet point style seems a bit crazy. Time for some CSS changes...

ant.simianzombie.com » SDL and Woopsi2x Mark 2 on 2009-11-15 at 21:28 said:

[…] also compiled it for the GP2x F-200. I ported it a while ago but gave up because the GP2x’s touch screen is utterly atrocious. At the time Woopsi was too […]