GP2X Hw Accelerated Sdl


It turns out the crashing problem was entirely because of improper sound frequencies, yet another thing that slipped my mind :unsure:

The touchscreen works great, but I only managed to get readings from it from the SDL mouse event:

(SDL_GP2X_MouseType() returns 2)

CODE
mouseTap = 0;

switch(event.type) {
case SDL_MOUSEBUTTONDOWN:
switch(event.button.button) {
case SDL_BUTTON_LEFT:
mouseTap = 1;
mouseX = event.button.x;
mouseY = event.button.y;
break;
}
break;
}

if(mouseTap) {
// screen was tapped at (mouseX, mouseY)
}


The way I read input is poll all SDL events at the beginning of each program loop. Does SDL_GP2X_Touchpad() use SDL events? If it does, then perhaps it has nothing left to work with by the time I call it. I got a bit confused though because SDL_gp2x.h says the following about it: "Get (semi-)raw touchpad position (not SDL position)", so I assumed it did not use SDL.

I apologize if I'm talking about the obvious here, this is new (and interesting) to me :) Thank you once again for your fantastic work Paeryn!
 
Alex. said:
It turns out the crashing problem was entirely because of improper sound frequencies, yet another thing that slipped my mind :unsure:

I'd really like to know how gph messed up with the sound frequencies - maybe someone from gp sneaked in and sabotaged it :rolleyes:
QUOTE

The touchscreen works great, but I only managed to get readings from it from the SDL mouse event:

The way I read input is poll all SDL events at the beginning of each program loop. Does SDL_GP2X_Touchpad() use SDL events? If it does, then perhaps it has nothing left to work with by the time I call it. I got a bit confused though because SDL_gp2x.h says the following about it: "Get (semi-)raw touchpad position (not SDL position)", so I assumed it did not use SDL.

I apologize if I'm talking about the obvious here, this is new (and interesting) to me :) Thank you once again for your fantastic work Paeryn!


SDL_GP2X_Touchpad() doesn't actually read the touchscreen itself, the coordinates it returns are the pre-modified ones from the last mouse event. It's just there so that you can read the raw lcd position of the touch rather than the scaled position that the event gives you. Basically when the event system reads the touchpad it stores the physical position into variables that Touchpad() returns.

The values returned by the event system are scaled so as to return the position relative to the visible size of SDL's screen, so that if you zoom in so that the top left of the lcd is showing say (60,40) of the surface then that's the position that the event system will give you when you touch the top left of the lcd. Whereas the values returned by Touchpad() will always be (0,0) for the top left and (319,239) for the bottom right - or there abouts depending on how well calibrated the pad is.

Actually, thinking about it, Touchpad() returns the coordinate of the very last mouse event sent so if there are two (or more) mouse events in SDL's queue then the raw touch positions of the earlier events are lost.

Basically don't use SDL_GP2X_Touchpad() unless you really need the raw position - it was only added so that off-screen touches (when using minidisplay) can be read sensibly.

Hope that helps,
 
Last edited by a moderator:
What's the actual issue with the sound frequencies?
I tried a search and came up with the fact the f200 only supports 8250, 16000 or 16500 (depends where I read) & 32000... is this right?

I'm actually using Allegro and all my samples are at 22050 - will this be a problem on an F200 - if I change sample freq to (say) 16000, will that still work okay on the F100.. <confused :)>

EDIT:
Well no worries <_< - figured it out for myself...
 
I'm experiencing issues with using the touch screen with the latest pre-compiled build of the SDL.

When i touch and hold on the screen it seems to be blocking. The SDL cursor however seems to move fine

I tried changing to call SDL_PumpEvents() and it seems to never return until you release the pointer.

Using the following to process the event queue also has the same problem:
while ( SDL_PollEvent( &event ) )
processEvent( event );

Possibly touch screen events are being added to the queue at a very fast rate so the queue can't be cleared?

This is a real problem as my game requires the cursor to be held down s you can drag etc.

Thanks for any solutions to this problem.
 
Crog said:
I'm experiencing issues with using the touch screen with the latest pre-compiled build of the SDL.

When i touch and hold on the screen it seems to be blocking. The SDL cursor however seems to move fine

I tried changing to call SDL_PumpEvents() and it seems to never return until you release the pointer.

Using the following to process the event queue also has the same problem:
while ( SDL_PollEvent( &event ) )
processEvent( event );

Possibly touch screen events are being added to the queue at a very fast rate so the queue can't be cleared?

This is a real problem as my game requires the cursor to be held down s you can drag etc.

Thanks for any solutions to this problem.
Why not add a clause into your loop that polls events that limits it to x number of events taken each game loop? Experiment with the number to see what works best.
 
Last edited by a moderator:
Senor Quack said:
Why not add a clause into your loop that polls events that limits it to x number of events taken each game loop? Experiment with the number to see what works best.
Good idea, I have tried it and whatever the problem is 'possibly' inside SDL_PollEvent() as calling this once results in a lock up when the touch screen is pressed. I have also added a timer to check that the lockup isn't happening else where in my game and it takes 11 seconds, or however long i hold the pointer down, to return from the function.

In windows the code obviously runs perfectly with no problems using the mouse pointer and I'm starting to pull my hair out!

Just to check does this SDL version seem to work fine for everybody else? If possible has anybody got a test build of a simple program that works?

NOTE: Just to clarify I am using the paeryn version of SDL available from http://paeryn.myby.co.uk/libSDL_21.tar.bz2
 
Last edited by a moderator:
Crog I've just tested it, it needs the event thread starting to prevent the touchscreen blocking, I hadn't noticed since I always use the event thread.

I'll look into limiting the reading of the touchscreen but in the meantime just add SDL_INIT_EVENTTHREAD to SDL_Init() and let linux deal with it.
 
Question about SDL audio...
Does it use /dev/dsp?
If so, has anyone noticed the left-right channels swapping for no apparent reason?

I know this isn't really SDL-specific, but it is related..

I have traced the audio data (I'm using Allegro) out of the audio mixer of Allegro to the data written to /dev/dsp and for some reason the kernel driver is screwing up the data interleave.

I have looked through the 2.1.x drivers, comparing them against 4.0.0 drivers and there are numerous differences in the audio driver area; but quite frankly I don't understand it ;)
 
paeryn said:
Crog I've just tested it, it needs the event thread starting to prevent the touchscreen blocking, I hadn't noticed since I always use the event thread.

I'll look into limiting the reading of the touchscreen but in the meantime just add SDL_INIT_EVENTTHREAD to SDL_Init() and let linux deal with it.
Thanks, I've tried that but with not luck. I've decided to put the touch screen interface to the side for now and focus on other things. If all else fails I might use a previous version of the SDL without the touch screen and read the values myself if I get time.

Cheers for the help and good luck on making SDL implementation even better as it sounds like you've done a great job.
 
Last edited by a moderator:
kevcal said:
Question about SDL audio...
Does it use /dev/dsp?
If so, has anyone noticed the left-right channels swapping for no apparent reason?
Yups,

Although not using SDL for lgpt, i do use /dev/dsp directly and channels swaps. There's two main reason I could notice:

+ at startup
+ when the SDL drawing becomes heavier, it *sometimes* swap channels over.

Marc
 
Last edited by a moderator:
I got another questions related to optimizing my SDL code for the 2X. At the moment, it's kind of good but if I refresh SDL a lot, I run into underruns in my audio thread. The global scheme I'm using is:

+ I create the screen using HW_SURFACE, 16 bits.


+ I pre-create most of my drawing elements using CreateRGBSurface with HW_SURFACE too, if I need to write one, I'll simply use SDL_BlitSurface, with no locking of the screen

+ If I need to write stuff that is not pre-cached, I Lock the surface screen and access the pixel right there and Unlock it.

+ Since I'm using the HW surface with no double buffering (I don't care too much about flicker), I never do Any UpdateRect().

Does that seem alright or would there be any possible speedup possible? I get about 5 msexs for refresh and I'd love to get it down to 1 :)

Also, did any of the "recent" SDL changes really affect speed optimisation or they were mainly tweaks/bug fixes ? Since mine is working quite well I'm not sure I feel like upgrading.

Thanks for any hints and the great work.
Marc.
 
M-.-n said:
I got another questions related to optimizing my SDL code for the 2X. At the moment, it's kind of good but if I refresh SDL a lot, I run into underruns in my audio thread. The global scheme I'm using is:

+ I create the screen using HW_SURFACE, 16 bits.
+ I pre-create most of my drawing elements using CreateRGBSurface with HW_SURFACE too, if I need to write one, I'll simply use SDL_BlitSurface, with no locking of the screen

+ If I need to write stuff that is not pre-cached, I Lock the surface screen and access the pixel right there and Unlock it.

+ Since I'm using the HW surface with no double buffering (I don't care too much about flicker), I never do Any UpdateRect().

Does that seem alright or would there be any possible speedup possible? I get about 5 msexs for refresh and I'd love to get it down to 1 :)

Also, did any of the "recent" SDL changes really affect speed optimisation or they were mainly tweaks/bug fixes ? Since mine is working quite well I'm not sure I feel like upgrading.

Thanks for any hints and the great work.
Marc.


Sorry for the late reply - I never got an email from the board telling me that there was new post.

What you are doing is correct and the proper way of doing things from what you describe. UpdateRect() doesn't do anything in my version (it just returns straight away) since in single buffer mode all writing to the screen actually modifies the physical bitmap that you see (I kept forgetting to implement shadow buffers support.) If you are calling Flip() then you will be hit by the v-sync wait, other that that what little housekeeping code there is shouldn't be noticeable.
 
Last edited by a moderator:
I compilied in the latest version with touchscreen support into dosbox. Good news is that it works, but theres a jumping effect or something like that. I think its from the scaling from a higher resolution down to 320x240

I dont have a F200, but heres some comments from a tester:
QUOTE
sometimes appearing or 'clicking' a good centimetre or two below where the stylus tapped the screen. Finding the right place to click was basically trial and error a lot of the time.


Heres more:
QUOTE
I then tried Secret of the Silver Blades and found that if I pressed the stylus gently and held it in position or moved it around the screen, the mouse cursor followed perfectly, but if i removed the stylus too quicky the pointer would jump a centimeter or so seemingly at random. Handling the stylus a little slower and doing things in an almost delayed way seemed to be best - so, it seems as though while I can just click and move the stylus as fast as I please in other touchscreen supported apps/games/interpreters, this DOSBox handling of the stylus needs a little more care.


Edit: If I read it right I think Scummvm experiences the same behavior?
 
M-.-n said:
kevcal said:
Question about SDL audio... Does it use /dev/dsp?
If so, has anyone noticed the left-right channels swapping for no apparent reason?
Yups,
Although not using SDL for lgpt, i do use /dev/dsp directly and channels swaps.
There's two main reason I could notice:
+ at startup
+ when the SDL drawing becomes heavier, it *sometimes* swap channels over.
MarcAh,.. sorry for the late reply - hadn't noticed an update to the thread for some reason...
So it isn't library dependant - I thought as much but no-one else seems to have hit the same problems as me - which I'm surprised at.

I have now found that I have got rid of the channel swapping - I had to add a smattering of sched_yield() calls anywhere where I looped with no system call (ie linux couldn't interrupt). This especially could occur in the tight loops waiting for the blitter to become available.

Also noticeable when I writing config updates to CF - I think there's 'something' wrong in the fs driver(?) somewhere and so have just avoided writing much to CF now and the problem has all but disappeared.

Will investigate FW 4.0.0 when the source is available as there were comments in the kernel audio drivers that may have meant they'd addressed the channel swapping problem. Anyway my initial hassles with it have gone. B)
 
Last edited by a moderator:
does anyone have a later version of the SDL libs with touch screen compilied? PM me if your willing to send them.

I should add if its later than the version that paeryn already has available.
 
well i tried to compile from the svn and it appears it's broke.
tried both using my own ./configure and even through the open2x shell lib script.

This is the 1.2.11 (Ive also tried the 1.2.9 and had other problems)

Here are some of the errors:

QUOTE

./src/video/directfb/SDL_DirectFB_events.c:32:22: error: directfb.h: No such file or directory
In file included from ./src/video/directfb/SDL_DirectFB_events.c:38:
./src/video/directfb/SDL_DirectFB_video.h:40: error: expected specifier-qualifier-list before 'IDirectFB'
./src/video/directfb/SDL_DirectFB_video.h:60: error: expected declaration specifiers or '...' before 'DFBResult'
./src/video/directfb/SDL_DirectFB_events.c:43: error: expected ')' before '*' token
./src/video/directfb/SDL_DirectFB_events.c:44: error: expected ')' before '*' token
./src/video/directfb/SDL_DirectFB_events.c: In function 'DirectFB_PumpEvents':
./src/video/directfb/SDL_DirectFB_events.c:51: error: 'DFBInputEvent' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:51: error: (Each undeclared identifier is reported only once
./src/video/directfb/SDL_DirectFB_events.c:51: error: for each function it appears in.)
./src/video/directfb/SDL_DirectFB_events.c:51: error: expected ';' before 'evt'
./src/video/directfb/SDL_DirectFB_events.c:53: error: 'struct SDL_PrivateVideoData' has no member named 'eventbuffer'
./src/video/directfb/SDL_DirectFB_events.c:53: error: 'struct SDL_PrivateVideoData' has no member named 'eventbuffer'
./src/video/directfb/SDL_DirectFB_events.c:54: error: 'evt' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:54: error: 'DFB_OK' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:60: error: 'DIET_BUTTONPRESS' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:64: error: 'DIET_BUTTONRELEASE' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:68: error: 'DIET_KEYPRESS' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:69: warning: passing argument 2 of 'SDL_PrivateKeyboard' makes pointer from integer without a cast
./src/video/directfb/SDL_DirectFB_events.c:71: error: 'DIET_KEYRELEASE' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:72: warning: passing argument 2 of 'SDL_PrivateKeyboard' makes pointer from integer without a cast
./src/video/directfb/SDL_DirectFB_events.c:74: error: 'DIET_AXISMOTION' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:75: error: 'DIEF_AXISREL' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:77: error: 'DIAI_X' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:79: error: 'DIAI_Y' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c: In function 'DirectFB_InitOSKeymap':
./src/video/directfb/SDL_DirectFB_events.c:97: error: 'DIKI_A' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:97: error: 'DIKI_UNKNOWN' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:98: error: 'DIKI_B' undeclared (first use in this function)
./src/video/directfb/SDL_DirectFB_events.c:99: error: 'DIKI_C' undeclared (first use in this function)
 
Pickle,

If your getting compile errors like that your not building SDL correctly or something is odd with your environment ;).

Do you want to catch me on IRC (#gp2xdev) sometime and I'll give you a hand to build a set of libs (or build them for you).
 
DJWillis said:
Pickle,

If your getting compile errors like that your not building SDL correctly ;) .

Do you want to catch me on IRC (#gp2xdev) sometime and I'll give you a hand to build a set of libs (or build them for you).
To tell you the truth ive never used IRC. I really like to know what im doing wrong in order to learn from it.
Im using the script from the open2x svn, all i did was remove all the other targets from the make file since I only need SDL for touchscreen support.
I have my toolchain in /opt just like the script expects, im using the open2x gcc 4.1.1 toolchain.
Am i mssing something?
 
Last edited by a moderator:
this looks bad:

QUOTE

checking for GP2X support... checking for X... no
checking for directfb-config... /usr/bin/directfb-config
checking for DirectFB 0.9.15 support... yes



im going to dive into the configure script
 
Back
Top