DCEmu.co.uk
31/01/2008, 00:45
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. There’s another guy here who has discovered the same problem I have - the only readily-available example of using the touch screen on the GP2x jitters like crazy.
I’ve tried swapping batteries, which often causes 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 the 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.
http://ant.simianzombie.com/blog/?p=271
Más información... (http://www.dcemu.co.uk/vbulletin/showthread.php?t=88378&goto=newpost)
First off, my GP2x isn’t duff. There’s another guy here who has discovered the same problem I have - the only readily-available example of using the touch screen on the GP2x jitters like crazy.
I’ve tried swapping batteries, which often causes 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 the 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.
http://ant.simianzombie.com/blog/?p=271
Más información... (http://www.dcemu.co.uk/vbulletin/showthread.php?t=88378&goto=newpost)