GP2X Hw Accelerated Sdl

[ivanixgames]

Hello all,

I'm having trouble checking out the latest SDL lib from the repository using svn. the reply i'm getting is as follows:

svn checkout https://svn.sourceforge.net/svnroot/open2x/.../libs/SDL-1.2.9

svn: PROPFIND request failed on '/svnroot/open2x/trunk/libs/SDL-1.2.9'
svn: PROPFIND of '/svnroot/open2x/trunk/libs/SDL-1.2.9': Could not resolve hostname `svn.sourceforge.net': Host not found (https://svn.sourceforge.net)

Anyone else having this problem?

Also have a question about mmuhack. is this now part of the latest SDL lib for gp2x or does it need to be added separately?

 

[paeryn]

Hello all,

I'm having trouble checking out the latest SDL lib from the repository using svn. the reply i'm getting is as follows:

svn checkout https://svn.sourceforge.net/svnroot/open2x/.../libs/SDL-1.2.9

svn: PROPFIND request failed on '/svnroot/open2x/trunk/libs/SDL-1.2.9'
svn: PROPFIND of '/svnroot/open2x/trunk/libs/SDL-1.2.9': Could not resolve hostname `svn.sourceforge.net': Host not found (https://svn.sourceforge.net)

Anyone else having this problem?


There was a change on sourceforge a while ago, instead of svn.sourceforge.net it's now open2x.svn.sourceforge.net the rest of the url is the same. Sorry, I'd forgotten to update the first post with this change.
QUOTE
Also have a question about mmuhack. is this now part of the latest SDL lib for gp2x or does it need to be added separately?


It has to be added separately, and always will have to be.

 

[paeryn]

Just a quick post.
Basic F-200 touchscreen functionality is in, calibration is woeful, but that's what I get from gph's own sdl implemetation too.
If you have an F-200 and no USB mouse then the touchscreen appears as a one button mouse. All mouse movements appear with the mouse button down.
It really could do with some other method for mouse buttons - I was hoping for light presses to ceate movement without registering the button press but there doesn't appear to be any pressure levels other than on/off (well, it does register slight variations but it's either 0 or 45200 +/- 200).

 

[Sphinxter]

A pressure sensitive pad like that would be pricey indeed, think of a page of buttons and somebody poking at them, got to have that initial click, in the app to allow cursing around you would need to take the click and then look for movement, no movement then click, movement found and exceeds shaky finger range then drop the click and curse.

Hey thanks for all your hard work on this, you really make development for this platform a snap.

 

[paeryn]

I've figured out the calibration, a new version is being uploaded that reads the calibration file instead of using fixed values.

 

[DJWillis]

Just a quick post.
Basic F-200 touchscreen functionality is in, calibration is woeful, but that's what I get from gph's own sdl implemetation too.
If you have an F-200 and no USB mouse then the touchscreen appears as a one button mouse. All mouse movements appear with the mouse button down.
It really could do with some other method for mouse buttons - I was hoping for light presses to ceate movement without registering the button press but there doesn't appear to be any pressure levels other than on/off (well, it does register slight variations but it's either 0 or 45200 +/- 200).

Hi Paeryn,

I have a variant of the code in my local 1.2.11 SDL tree that I am using with ScummVM.
Seems to work well thanks .

Whilst I don't have a touch screen users seem to suggest the same sort of issues with the touch screens being a little less then ideal. I have been trying to detect pressure and do soft touches verses clicks.
Your comments have just explained why that is not working out so well .

I was looking at a clean way to get SDL to bubble up the mousedrv in use so that code at the app level can make choices about what to do with its control system? Any ideas?

I've figured out the calibration, a new version is being uploaded that reads the calibration file instead of using fixed values.

Fantastic, I’ll take a look.

 

[DJWillis]

Paeryn,

I have started to tweak things so the touch screen code can cope gracefully with mapping the cursor position on an SDL surface that is not 320*240. It won't be exact but I think it may be good enough considering what you loose detail wise in the hardware downscale anyway.

Any problems with me hacking on this? I don't want to duplicate work if your already doing it .

 

[paeryn]

Only just read this after I've just finished adding mapping the position into 1.2.9 - I was so eager to get touchscreen support in that I forgot about that.

I've not updated the 1.2.11 yet, I didn't want to mess up both if it didn't work too well ;-) If you want to update it with what you've done you can, or if you want me to put my code in I can do.

I added the scale variables needed into gp2xvideo to reduce the number of divides since they are the inverse of what I use for mapping the mouse position to the screen. I got rid of the float variables that I was using for that too, it now uses 16.16 fixed point... Shoots self for using floats in the first place

As for exposing the mouse driver - I was thinking of that too, I thought of maybe adding another support function that the program can call.
I also thought about possibly having the option of how mouse button events are generated, sort of allow the touchscreen to only generate movements and use the buttons in conjunction with pressing the screen to generate mousebuttons if the programmer so desired.

Edit:
I've added a function int SDL_GP2X_MouseType() which returns the type of mouse detected (0 = none, 1 = standard, 2 = touchscreen), unfortunately sourceforge isn't letting me check it in just yet - I'll try again later.

 

[DJWillis]

Only just read this after I've just finished adding mapping the position into 1.2.9 - I was so eager to get touchscreen support in that I forgot about that.

I've not updated the 1.2.11 yet, I didn't want to mess up both if it didn't work too well ;-) If you want to update it with what you've done you can, or if you want me to put my code in I can do.

I updated 1.2.11 up to and including reading the calibration data and that works very well. I also checked it in to SourceForge. I moved ScummVM's touch screen code over to this and it works very nicely . I would have just used 1.2.9 but the reason I patched 1.2.11 in the first place was so I could use it for bits of ScummVM's backend .

I added the scale variables needed into gp2xvideo to reduce the number of divides since they are the inverse of what I use for mapping the mouse position to the screen. I got rid of the float variables that I was using for that too, it now uses 16.16 fixed point... Shoots self for using floats in the first place

, i'll take a look at that. At the moment I am handling all the virtual <> physical touch screen mapping in ScummVM as I was not sure of the 'nice' way do it in SDL, I'll take a peek at the code, happy to move it over to 1.2.11 also.

As for exposing the mouse driver - I was thinking of that too, I thought of maybe adding another support function that the program can call.
I also thought about possibly having the option of how mouse button events are generated, sort of allow the touchscreen to only generate movements and use the buttons in conjunction with pressing the screen to generate mousebuttons if the programmer so desired.

Edit:
I've added a function int SDL_GP2X_MouseType() which returns the type of mouse detected (0 = none, 1 = standard, 2 = touchscreen), unfortunately sourceforge isn't letting me check it in just yet - I'll try again later.

Sounds ideal, SDL_GP2X_MouseType() is just what I had in mind. Esp. as you have made it flexible enough to be used to pickup 'standard' mice also.

 

[Hooka]

Keep up the good work guys!

I noticed that with minimode it isn't giving back the proper location (ie, the screen is shifted down ~20 pixels, and the touchscreen input is 20 pixels lower )

I was also wondering, is it possible to have it return touches off the main display...

example:

I have Initialized SDL with a 320X200 screen, with a 40 pixel virtual keyboard underneath... can I return touchscreen locations lower than the SDL screen?

 

[paeryn]

Oops, it's not supposed to do that :-o I'll check it in a bit.

How are you showing the virtual keyboard? The touchscreen maps the point you touch to a screen coordinate relative to what can be seen, the mouse code then makes sure that the coordinate is within the limits set when you initialised the display. So if you initialised SDL with a 320x200 screen then the lowest y coord you'll recieve is 199.

Edit:
Did I mis-interpret what you asked? I've just checked and the touchscreen is returning the correct position. Did you mean that the touchscreen was registering 20 pixels lower than where you were pressing. There's no real way of returning presses in the blanked area of a minidisplay - I could expose the physical coordinates of the last press through another function if you would find it helpful, that would always return a coord in the range of (0,0)->(319,239) irrespective of SDL's screen dimentions.

 

[paeryn]

I've hacked a static version of tslib into SDL to smooth the mouse movements.
It has a fixed module set but it will read /etc/ts.conf if you create one and use the values given to pthres, variance, dejitter and linear. These modules are always run and in that order irrespective of what ts.conf says, you can only alter the modules' variables. Default config is
CODE
module_raw ucb1x00
module pthres pmin=1
module variance delta=30
module dejitter delta=100
module linear

I've hopefully fixed the false mouse detection when USB is enabled but no mouse exists.

Added a function to return the (semi-)raw touchscreen coordinates:
CODE
int SDL_GP2X_Touchpad(int *x, int *y);

(x,y) will always be: Top-left (0, 0), bottom-right (319,239) or thereabouts, depending on calibration. The value returned is the pressure, but since it doesn't seem to be sensitive to varying pressure treat it as a boolean value (0 or !0)

I've started USB keyboard but it isn't finished yet, the GP2X doesn't seem to attatch it to any tty but it does send raw input events so I'm using them and translating scancodes myself.

 

[gavinb2k]

Hi,

just a stupid questions, with this SDL lib i notice there are versions with differnt video memory amounts, does it automatically use the max. amount depending on the version you get from paeryn's website?


Also as a final question,
do i need to download the files from svn then overwrite with ones from paeryn's site?

ta

 

[paeryn]

just a stupid questions, with this SDL lib i notice there are versions with differnt video memory amounts, does it automatically use the max. amount depending on the version you get from paeryn's website?

Also as a final question,
do i need to download the files from svn then overwrite with ones from paeryn's site?

Your questions aren't stupid.
The older 5 & 16 versions were fixed (I think) but as you can see by the dates on them they're a year plus old.
The recent version is the compiled library using what is in svn. By default this version only uses the 5MB framebuffer memory, but by calling SDL_GP2X_AllowGfxMemory(NULL, 0); you'll get access to 21MB (but be aware that SDL will then assume that none of the gp2x's upper memory will be used by you.) The idea behind that function is to add just selected areas of upper memory, but I keep forgetting to implement it.

The reason I have the pre-compiled version available is so that developers don't have to keep getting the source and compiling it if they don't want to.
As long as you have SDL installed in your gp2x toolchain then you can just copy the lib and include files into your comipler's lib and include/SDL directories respectively. Although you may have to compile it yourself if you don't use the open2x toolchain (as that is what I use to create the lib.)

 

[gavinb2k]

just a stupid questions, with this SDL lib i notice there are versions with differnt video memory amounts, does it automatically use the max. amount depending on the version you get from paeryn's website?

Also as a final question,
do i need to download the files from svn then overwrite with ones from paeryn's site?

Your questions aren't stupid.
The older 5 & 16 versions were fixed (I think) but as you can see by the dates on them they're a year plus old.
The recent version is the compiled library using what is in svn. By default this version only uses the 5MB framebuffer memory, but by calling SDL_GP2X_AllowGfxMemory(NULL, 0); you'll get access to 21MB (but be aware that SDL will then assume that none of the gp2x's upper memory will be used by you.) The idea behind that function is to add just selected areas of upper memory, but I keep forgetting to implement it.

The reason I have the pre-compiled version available is so that developers don't have to keep getting the source and compiling it if they don't want to.
As long as you have SDL installed in your gp2x toolchain then you can just copy the lib and include files into your comipler's lib and include/SDL directories respectively. Although you may have to compile it yourself if you don't use the open2x toolchain (as that is what I use to create the lib.)

Many thanks for your help, have got it all installed and seems to work ok
runs very well on the GP2X once compiled. Thanks for all your hard work!

 

[Alex.]

Hi,

I read in the OpenTyrian thread that 8bit palette mode is only supported for hardware surfaces. Is this true? My game does a lot of writing directly to pixels, and thus software surfaces are slightly faster. I got 8bit to work on SDL_SWSURFACE|SDL_HWPALETTE, but unfortunately a larger-than-normal delay appeared between the time my main function terminates and the time the GP2X launcher is resurrected. However, this delay is normal if the video surface is SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_HWPALETTE. Is something awkward happening when I use 8bit software surfaces?

Thanks a lot for your work on this, Paeryn! Sorry if this was talked about before.

 

[paeryn]

I read in the OpenTyrian thread that 8bit palette mode is only supported for hardware surfaces. Is this true? My game does a lot of writing directly to pixels, and thus software surfaces are slightly faster. I got 8bit to work on SDL_SWSURFACE|SDL_HWPALETTE, but unfortunately a larger-than-normal delay appeared between the time my main function terminates and the time the GP2X launcher is resurrected. However, this delay is normal if the video surface is SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_HWPALETTE. Is something awkward happening when I use 8bit software surfaces?

The way my version works at the moment is that the screen surface is always a HWSURFACE but any surfaces that you create can be either. I really must get around to enabling the shadow buffer for a proper software screen surface.

As to using SWSURFACE for the screen causing a long delay, I can't think why it should. The only thing I can think of is if you're program has used enough memory up to cause the kernel to abandon a lot of it's caches (HWSURFACE bitmaps take up a lot less of linux's memory than SWSURFACE bitmaps.) Roughly how long is it taking?

 

[Alex.]

Well sorry for this, it appears that there is no such delay if I return to the menu via a script rather than through the C program itself. It's peculiar how the delay only happened if I set software surfaces (maybe because they were mixed with the hardware video surface?), but it's all irrelevant now Sorry for the false alarm.

 

[Alex.]

I tried to add touchscreen support to a program, but it crashes shortly after calling SDL_GP2X_MouseType(). I use the prebuilt lib from Paeryn's site dated November 23. Here's the code:

After I init SDL:
CODE
int touch = 0;
touch = SDL_GP2X_MouseType();


During game loop:
CODE
if(touch == 2) {
int x;
int y;
int tap = 0;

tap = SDL_GP2X_Touchpad(&x, &y);

if(tap) {
// screen was tapped at x, y
}
}


The person testing it on his F200 says that the program crashes very soon (after calling SDL_GP2X_MouseType()), before reaching any calls to SDL_GP2X_Touchpad(). It must be that I'm doing something wrong here, perhaps I'm not initializing everything I should?

The same program runs fine on an F100, and SDL_GP2X_MouseType() returns 0 like it should.

PS: I use DevKitGP2X, with the latest Open2x libs for DevKitGP2X from open2x.org

 

[paeryn]

I tried to add touchscreen support to a program, but it crashes shortly after calling SDL_GP2X_MouseType(). I use the prebuilt lib from Paeryn's site dated November 23.

...
QUOTE
The person testing it on his F200 says that the program crashes very soon (after calling SDL_GP2X_MouseType()), before reaching any calls to SDL_GP2X_Touchpad(). It must be that I'm doing something wrong here, perhaps I'm not initializing everything I should?

The same program runs fine on an F100, and SDL_GP2X_MouseType() returns 0 like it should.

PS: I use DevKitGP2X, with the latest Open2x libs for DevKitGP2X from open2x.org

Sounds strange, the SDL_GP2X_MouseType() code literally just returns the value of an internal variable, the only time it should cause problems is if it is called before initialising SDL where current_video would be NULL.
It's a similar case for SDL_GP2X_Touchpad(), the pre-SDL coordinates are just stored internally and all the function does is simply copy them for you.

Does the program work properly when using a mouse instead of the touchscreen?