GP2X Hw Accelerated Sdl

[telengard]

I am attempting to use this version of SDL and am very close to getting it working w/ gp2xmess. The one issue I have left is getting the displayed image scaled. I am definitely doing something wrong and if someone could give me some idea where I'm going wrong that would be great.

I call SDL_SetVideoMode w/ 320x240x16 + HW + DOUBLEBUF
I then create an offscreen surface (HW) that is larger than 320x240 (in this case 560x192)
I call SDL_GP2X_Display w/ {0,0,560,192}
I then call SDL_BlitSurface with the offscreen surface as the src and the video surface returned from SDL_SetVideoMode as the destination. I use the full size of each for rects
I then call SDL_Flip

What I get is a "viewport" into the upper left of the screen. Sorta like when using a virtual workspace on a UNIX window manager. So I only see a portion of the 560x192 and it's zoomed. I have also tried all kinds of different combinations of sizes to SDL_GP2X_Display etc and all of them give me the same results.

Any ideas?

~telengard

 

[luteijn]

you might want to read this if you haven't already; some background on the why of the 560 horizontal resolution
(or 280 or 140?) looks like mess doubled the resolution again to be able to get the colours right and/or not have to worry about subpixels, but this would probably mess with aspect ratio, and scaling it would probably ruin your picture.
http://grc.com/ctwho.htm

 

[paeryn]

I am attempting to use this version of SDL and am very close to getting it working w/ gp2xmess. The one issue I have left is getting the displayed image scaled. I am definitely doing something wrong and if someone could give me some idea where I'm going wrong that would be great.

I call SDL_SetVideoMode w/ 320x240x16 + HW + DOUBLEBUF
I then create an offscreen surface (HW) that is larger than 320x240 (in this case 560x192)
I call SDL_GP2X_Display w/ {0,0,560,192}
I then call SDL_BlitSurface with the offscreen surface as the src and the video surface returned from SDL_SetVideoMode as the destination. I use the full size of each for rects
I then call SDL_Flip

What I get is a "viewport" into the upper left of the screen. Sorta like when using a virtual workspace on a UNIX window manager. So I only see a portion of the 560x192 and it's zoomed. I have also tried all kinds of different combinations of sizes to SDL_GP2X_Display etc and all of them give me the same results.

Any ideas?

~telengard

​

It's the display surface (the one created by SetVideoMode) that gets scaled, you have to call SetVideoMode with 560,192 - the scaler will then shrink the surface automagically to fit the screen and as far as SDL and your app are concerned you've got a 560x192 surface.
The blitter doesn't do any scaling and will only copy the area of the smallest surface.

 

[telengard]

I am attempting to use this version of SDL and am very close to getting it working w/ gp2xmess. The one issue I have left is getting the displayed image scaled. I am definitely doing something wrong and if someone could give me some idea where I'm going wrong that would be great.

I call SDL_SetVideoMode w/ 320x240x16 + HW + DOUBLEBUF
I then create an offscreen surface (HW) that is larger than 320x240 (in this case 560x192)
I call SDL_GP2X_Display w/ {0,0,560,192}
I then call SDL_BlitSurface with the offscreen surface as the src and the video surface returned from SDL_SetVideoMode as the destination. I use the full size of each for rects
I then call SDL_Flip

What I get is a "viewport" into the upper left of the screen. Sorta like when using a virtual workspace on a UNIX window manager. So I only see a portion of the 560x192 and it's zoomed. I have also tried all kinds of different combinations of sizes to SDL_GP2X_Display etc and all of them give me the same results.

Any ideas?

~telengard

​

It's the display surface (the one created by SetVideoMode) that gets scaled, you have to call SetVideoMode with 560,192 - the scaler will then shrink the surface automagically to fit the screen and as far as SDL and your app are concerned you've got a 560x192 surface.
The blitter doesn't do any scaling and will only copy the area of the smallest surface.

​

Ahh, excellent. I will try that out, thanks. I would have never thought to try that because I thought that (SDL_SetVideoMode) had some magical property in that it was actually doing something w/ HW/registers/whatever. Having the primary surface be that size will make my code a lot cleaner too.

thanks!

~telengard

 

[paeryn]

Ahh, excellent. I will try that out, thanks. I would have never thought to try that because I thought that (SDL_SetVideoMode) had some magical property in that it was actually doing something w/ HW/registers/whatever. Having the primary surface be that size will make my code a lot cleaner too.

​

SetVideoMode sets the scaler to fit the surface to the LCD. The surface isn't actually scaled itself, just how the HW reads it.

UPDATE: new version uploaded, preliminary TV-Out support.
Note: TV resolution is 720x576 (or 720x480), there's no way (at the mo) for SDL to know if it's in TV or LCD mode, but the scaler takes care of it.
Note 2: There is a double-free problem when quitting, I'll sort this out later. Screen isn't returned to how it was properly, but going back to the menu resets it.

 

[ooPo]

I've been unable to compile with --enable-threads, is this a known issue?

 

[paeryn]

I've just gotten around to looking into the thread and sound problems.
It seems on my dev system the linker is throwing a wobbly if you try linking pthread as shared. Unfortunately the SDL configure ends up thinking that pthread isn't available.
After modifying configure to force -static I'm getting sound working fine.
If you've got a similar problem then try:
Edit configure at line 26916 (or thereabouts) add the -static as below

        # Add the pthread compiler flags and libraries
        CFLAGS="$CFLAGS $pthread_cflags"; LIBS="$LIBS -static $pthread_lib"

I'm uploading my bodged versions now..

 

[ooPo]

I've copied over src/thread/linux/clone.S from the stock SDL-1.2.9 to your source and I'm able to compile with '--enable-shared --enable-static --enable-threads' now. This has stopped the errors with SDL_mixer but now it segfaults when I try to play audio.

I'm using the sample program found here:

http://www.gp32x.de/board/index.php?showt...ndpost&p=309843

Using my toolchain script found here:

http://www.oopo.net/consoledev/files/newto...in-20060131.tgz

Here's a fancy patch:

http://www.oopo.net/SDL-1.2.9-GP2X-paeryn.patch

It adds the clone.S file and adds a gp2x target to config.sub.

 

[ooPo]

You're right, it isn't detecting pthread at all.

/usr/local/gp2xdev/gp2x/lib/: file not recognized: Is a directory
collect2: ld returned 1 exit status

That's a very strange error to get when trying to link in a shared library.

Its working fine when compiled and linked as static, however. That's a definate improvement.

 

[ooPo]

Change your libpthread.so file from:

/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /usr/local/gp2xdev/gp2x/lib/libpthread.so.0 /usr/local/gp2xdev/gp2x/lib/ )

To:

/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /usr/local/gp2xdev/gp2x/lib/libpthread.so.0 /usr/local/gp2xdev/gp2x/lib/libpthread_nonshared.a )

And linking works fine.

 

[lemon]

well, right now I have been able to enable sound again while using your SDL version.

But I have some strange screen corruption. I use a 8-bit screen depth. Al processing is done by pure software to a ram buffer which is simply copied via one memcpy per line to the screen surface. Now the strange thing is that the screen appears "wrapped" one pixel to the left, the rightmost column shows what should be the leftmost.
Anyway, I tried to solve it meantime with a dirty hack, by copying from 1 byte before the current image (so each line finishes one pixel after, but then it works ok, it wrapps one pixel to the right (and in the leftmost column appears what should be in the rightmost).

Any idea about this? it does the same if I init as an SDL_SWSURFACE or as an SDL_HWSURFACE | SDL_DOUBLEBUF

With the old SDL libs I was using before everything shows perfect...

 

[paeryn]

Cheers for that ooPo, I didn't have time to look into what was causing the pthread problem hence my bodge I'll try and remember to edit my setup in the morning. I was very confused by the error, and since none of my test programs use either sound or threads I never noticed SDL wasn't including it.

As for your problem lemon, it sounds strange. I think SetVideoMode will ignore SWSURFACE, at least if it gets as far as my routine I ignore it and always return a HWSURFACE. I'll look in the morning, only thing I can think off the top of my head is if there's a problem with alignment - The HW requires the screen to start on a 32-bit address. I might've got a typo in the 8-bit code, my test wouldn't show that error up.
Maybe I should get to writing some proper borderline tests - I feel rather mean getting you all to test it for me

 

[lemon]

I think SetVideoMode will ignore SWSURFACE, at least if it gets as far as my routine I ignore it and always return a HWSURFACE.

I get exactly the same behaviour using SWSURFACE and HWSURFACE, and any way, I get a smoother movement as with the non-accelerated sdl (I suppose that's decause the SDL_Flip is sync to a vrefresh, as it should be when using a hw surface).

I'll look in the morning, only thing I can think off the top of my head is if there's a problem with alignment - The HW requires the screen to start on a 32-bit address. I might've got a typo in the 8-bit code, my test wouldn't show that error up.

That's what I thought too, as at first you didn't support 8 bit and I have seen no comments on people using 8 bit yet... I will wait for you to look at it (don't have right now much time for checking them myself...)

Ah, and thanks a lot for your libraries!

Edited: if you want to check the behaviour, you can download my new BoR version using your libs at http://gp32spain.com/foros/showthread.php?t=25648

 

[paeryn]

Downloading now, but I really must get to bed
The very first release was just after I got the blitter working and found that GPH's fbcon is very poor (it doesn't support half the things it should - like 8-bit!) I've not used SDL for years, I only started this as an example of how to use the blitter, I never expected to go this far - but I'm having fun. I really appreciate all the feedback, it's nice to know I can do something for the community.

I think your problem is the last thing I need to fix (other than trying to get rid of the scanline issues) bar any other bugs turning up I'll next be adding support functions for :-
Switching LCD &| backlight on/off.
Regions: upto 4 user-definable rectangles over the screen. Areas not within these regions won't be visible.
HW cursor: 2 colour, 32x32 or 64x64
OSD: overlay surface, could be useful for displaying stats/score without destroying main surface.
Video surfaces: upto 2 of these.
Any other HW acceleratable features...

If we ever get better docs on the MMSP2 I'd like to use the HW mpeg decoding too - I don't fancy disassembling the 940's code to find out which registers do what (and even where the registers are.)

 

[Uncanny]

A question paeryn, is missing the README.GP2X with your own changelog and extra info such as in a previous release? I ask this because I don't know if you include another file with the doc or info about your new functions (p.e: the function that allow dynamic scaling or the function to set the colour for colour expansion of 1bpp blits).

Thanks for your libraries!

 

[telengard]

just tried the latest build and it worked ok with my program after i removed SDL_INIT_TIMER from SDL_Init. i think it was mentioned a few pages ago that the timer does not work when initialised, it locks up my gp2x. if you can get that working that would be great! update - audio (only tried OGG) isnt working yet.

​

Boy, I need to pay more attention and read all posts carefully. I just spent a lot of time tonight finding out that. Locked up my gp2x also. Let this be a lesson to me!

I should probably grab the latest also...

~telengard

 

[paeryn]

A question paeryn, is missing the README.GP2X with your own changelog and extra info such as in a previous release? I ask this because I don't know if you include another file with the doc or info about your new functions (p.e: the function that allow dynamic scaling or the function to set the colour for colour expansion of 1bpp blits).

Thanks for your libraries!

​

Oops, looks like I overwrote my updated README.GP2X with the original...
I'll re-write it and upload it later, ta for spotting that.

Telengard: There was a problem with pthread not being compiled in, try the latest version. I know sound relies on pthread and that now works, if timer does too then it should work now. I'll check in a bit when I reboot into my dev system.

 

[ooPo]

http://www.oopo.net/consoledev/files/newto...in-20060131.tgz <--- a very easy way to build and install an up-to-date toolchain with paeryn's SDL working with sound support

 

[darokin]

Link on http://paeryn.myby.co.uk/SDL_gp2x.tar.bz2 is broken...

 

[chris_r]

http://www.oopo.net/consoledev/files/newto...in-20060131.tgz <--- a very easy way to build and install an up-to-date toolchain with paeryn's SDL working with sound support

​

Thanks, I'd formatted my pc and this got my toolchain set up again without any hassle at all