GP2X Hw Accelerated Sdl

[GP2X_Coder]

I am having problems with tv out and scrolling you can check out the pictures and download the program to see what I mean do you have any Idea what could be causing this?

http://mysite.verizon.net/vze7fhdf/gp2xfuturecoderpage/

 

[GP2X_Coder]

Does anyone else have this problem?

 

[Drag]

What does your source code look like where it draws the screen?

 

[GP2X_Coder]

// Clear the screen so we can draw to a clean surface
SDL_FillRect( screen, NULL, SDL_MapRGB( screen->format, 255, 0, 0 ) );

// Blit the image onto the back surface
SDL_BlitSurface( ImageSurface[ 0 ], NULL, screen, &Destination );

// Flip the surface to the main display screen
SDL_Flip(screen);

Am I doing something wrong?

 

[Drag]

That code looks fine to me, I can't possibly imagine why it'd be making stripes on your tv screen.

Though I'm probably not the best person to ask... I don't use SDL's blit functions enough to know their quirks.

 

[paeryn]

I am having problems with tv out and scrolling you can check out the pictures and download the program to see what I mean do you have any Idea what could be causing this?

http://mysite.verizon.net/vze7fhdf/gp2xfuturecoderpage/

The bottom-right pixels problem seems to be hardware related. The display seems to get those last 8 pixels from about (80,239)-(87,239). I've never managed to figure out why - I do know that as soon as you switch the scaler on they appear as they should, unfortunately the scaler cannot be activated with a 1:1 scale.

As for the TV-out, ever since upgrading to FW2.0 my TV can't get a lock on the signal - I hope it's just a coincidence and it's a faulty cable, but I don't fancy buying a new one only to find it isn't. Roll on the BoB!

 

[GP2X_Coder]

Thanks paeryn for the reply glad to know that its not my code that is causing the pixels on the bottom. I just hope that I can get the TV OUT part working. I think this is the coolest part of the GP2X. Has anyone else had this problem with TV OUT?

Oh paeryn I have been meaning to ask you is it possible to HW Scale SDL Surfaces? If it is all you would have to do is pass a negative value to a surface and it will flip/mirror the surface for you with no extra code?

 

[paeryn]

Oh paeryn I have been meaning to ask you is it possible to HW Scale SDL Surfaces? If it is all you would have to do is pass a negative value to a surface and it will flip/mirror the surface for you with no extra code?

Not really. The scaler is part of the display hardware, the blitter itself doesn't have any scaling abilities. Full-screen scaling of the display surface is supported by use of SDL_GP2X_Display(SDL_Rect *area) where area defines the physical pixel to appear at the top-left of the screen and the width/height defines the virtual size.
There is hardware support for rotating by 90, 180 or 270 degrees and I'll add that as soon as. As for mirroring, horizontally there's no support as the src and dest share the same direction flag. Vertical mirroring should however be possible as src and dest have independent strides which can be set to negative values for blitting upwards, the ydir flag seems to be superfluous - I've not tried it yet, but if it works it'll get added

 

[[hjd_uk]]

Hi, im pretty new to programming for linux. Im using the free Vissy Studio 2005 (8) Express compiler and custom build rules, anyway I first started off using the std SDL which was slow, then I exprimented with rylehs minlib and examining / using that code, now im trying to use your accellerated SDL lib. I downloaded the most recent .a and includes and copied ovr them in my devkitGP2X dirs. But now when i compile I get errors :

------ Rebuild All started: Project: RWar, Configuration: Debug Win32 ------
Deleting intermediate and output files for project 'RWar', configuration 'Debug|Win32'
main.cpp
.\Source\main.cpp: In function 'int main(int, char**)':
.\Source\main.cpp:722: warning: converting to 'short int' from 'float'
.\Source\main.cpp:723: warning: converting to 'short int' from 'float'
Linking RWar.gpe...
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_systhread.o): In function `RunThread':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:83: undefined reference to `pthread_exit'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_systhread.o): In function `SDL_SYS_CreateThread':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:92: undefined reference to `pthread_attr_init'
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:96: undefined reference to `pthread_attr_setdetachstate'
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:99: undefined reference to `pthread_create'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_systhread.o): In function `SDL_SYS_SetupThread':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:117: undefined reference to `pthread_sigmask'
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:123: undefined reference to `pthread_setcanceltype'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_systhread.o): In function `SDL_ThreadID':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:131: undefined reference to `pthread_self'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_systhread.o): In function `SDL_SYS_WaitThread':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:136: undefined reference to `pthread_join'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_systhread.o): In function `SDL_SYS_KillThread':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_systhread.c:142: undefined reference to `pthread_cancel'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_syssem.o): In function `SDL_CreateSemaphore':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_syssem.c:103: undefined reference to `sem_init'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_syssem.o): In function `SDL_DestroySemaphore':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_syssem.c:129: undefined reference to `sem_destroy'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_syssem.o): In function `SDL_SemTryWait':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_syssem.c:144: undefined reference to `sem_trywait'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_syssem.o): In function `SDL_SemWait':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_syssem.c:165: undefined reference to `sem_wait'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_syssem.o): In function `SDL_SemValue':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_syssem.c:209: undefined reference to `sem_getvalue'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_syssem.o): In function `SDL_SemPost':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_syssem.c:230: undefined reference to `sem_post'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_sysmutex.o): In function `SDL_CreateMutex':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_sysmutex.c:72: undefined reference to `pthread_mutexattr_init'
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_sysmutex.c:77: undefined reference to `pthread_mutexattr_setkind_np'
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_sysmutex.c:82: undefined reference to `pthread_mutex_init'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_sysmutex.o): In function `SDL_DestroyMutex':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_sysmutex.c:96: undefined reference to `pthread_mutex_destroy'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_sysmutex.o): In function `SDL_mutexP':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_sysmutex.c:133: undefined reference to `pthread_mutex_lock'
D:\devkitPro\devkitGP2X\lib\libSDL.a(SDL_sysmutex.o): In function `SDL_mutexV':
/home/darius/gp2x/sdl/SDL-1.2.9/src/thread/SDL_sysmutex.c:171: undefined reference to `pthread_mutex_unlock'
Build log was saved at "file://d:\gp2x\Dev\RWar\Debug\BuildLog.htm"
RWar - 0 error(s), 2 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

I assumed i could just mix and match the files - is there a newer version of the comlete SDL libs for GP2X i need to use with your version / do I need to compile your source with the SDL complete source?
Am I just being an idiot?

 

[paeryn]

' date='Jun 10 2006, 09:50 PM' post='405658']
Hi, im pretty new to programming for linux. Im using the free Vissy Studio 2005 (8) Express compiler and custom build rules, anyway I first started off using the std SDL which was slow, then I exprimented with rylehs minlib and examining / using that code, now im trying to use your accellerated SDL lib. I downloaded the most recent .a and includes and copied ovr them in my devkitGP2X dirs. But now when i compile I get errors :
<snipped>
I assumed i could just mix and match the files - is there a newer version of the comlete SDL libs for GP2X i need to use with your version / do I need to compile your source with the SDL complete source?
Am I just being an idiot?

You need to link the pthread library (under linux add -lpthread to the link line) to use my version. Also you may need to add -static as I don't support dynamic linking (it's not worth the hastle.)

Hope that sorts things out for you, good luck with whatever you're up to.

 

[[hjd_uk]]

Thanks, adding -lpthread to the GCC linker opts worked a treat. Ta.

 

[Lint]

just curious about the hardware:
as far as I programmed on x86, you can set initial display values to anywhere that you wish (in video ram, obviously, and there's a 4-byte-alignment) and that allowed to develop pretty fast vertical scrolling (by setting display to one-line-later or one-line-earlier you could scroll the whole screen)
does the hardware of gp2x allow such thing too? (everything points so)
can it also be done for horizontal scrolling?
for example: setting a 640x240 display and panning the screen via hardware as soon as the character reachs near right end? (like super mario games)
I'd sure would like to avoid a 76800 byte array write just to pan screen somewhere else..

let's discard page-flipping talking for simplicity's sake :rolleyes: (as surface recycling and page flipping is surely possible, but have to work in a 2-by-2 frame updating scheme..)

 

[paeryn]

just curious about the hardware:
as far as I programmed on x86, you can set initial display values to anywhere that you wish (in video ram, obviously, and there's a 4-byte-alignment) and that allowed to develop pretty fast vertical scrolling (by setting display to one-line-later or one-line-earlier you could scroll the whole screen)
does the hardware of gp2x allow such thing too? (everything points so)
can it also be done for horizontal scrolling?
for example: setting a 640x240 display and panning the screen via hardware as soon as the character reachs near right end? (like super mario games)
I'd sure would like to avoid a 76800 byte array write just to pan screen somewhere else..

let's discard page-flipping talking for simplicity's sake :rolleyes: (as surface recycling and page flipping is surely possible, but have to work in a 2-by-2 frame updating scheme..)

Yes, the start address can be anywhere in the upper memory. It has the 32bit boundry so you can only scroll by 2 (16bit) or 4 (8bit) pixels. It is possible to use the display delay to fine tune this down to 1 pixel, but at the cost of a column (or 3 in 8bit mode) from the right-hand side.
In your example of 640x240 you'll just need to set the stride to double what it normally is to make the hardware skip the extra screens worth of data.
Unfortunately we don't have anything like the old Copper (happy Amiga days :rolleyes to make really easy full 8-way endless scrolling, but we do have plenty of power to do it the hard way.

 

[timbobsteve]

Hi paeryn, Just wondering where I can get the latest source code from... tracked back a few pages until I found a link, but I think it was for the non-FW2.0 version (with flickering).... anways... want to compile it on my new Slackware DevBox, but can't find the source code. Thanks in advance.

 

[paeryn]

Hi paeryn, Just wondering where I can get the latest source code from... tracked back a few pages until I found a link, but I think it was for the non-FW2.0 version (with flickering).... anways... want to compile it on my new Slackware DevBox, but can't find the source code. Thanks in advance.

Hello, I stopped keeping a seperate tarball of the source when I was given access to the open2x svn, the latest version can alwas be obtained from there by the following command:

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

All the correct links should be on the initial post of this thread (as long as I remember to update it)

 

[Gadget]

Just like to add to this:-

Many thanks for producing these libs, it's LIGHTNING fast compared to the software version!

I did experience a problem with the SDL_Mixer not working anymore with either ogg or mp3. Had to revert to the original lib. I also ran into the problem mentioned several pages back, related to the screen flickering like mad. Added SDL_DOUBLEBUF in the init call and now it's fine, and FAST!

Thanks

 

[Lint]

Yes, the start address can be anywhere in the upper memory. It has the 32bit boundry so you can only scroll by 2 (16bit) or 4 (8bit) pixels. It is possible to use the display delay to fine tune this down to 1 pixel, but at the cost of a column (or 3 in 8bit mode) from the right-hand side.
In your example of 640x240 you'll just need to set the stride to double what it normally is to make the hardware skip the extra screens worth of data.
Unfortunately we don't have anything like the old Copper (happy Amiga days :rolleyes to make really easy full 8-way endless scrolling, but we do have plenty of power to do it the hard way.

So it does have support for skipping 'x' bytes at the end of each horizontal line? (my english is quite poor, I'm not sure if I get it all right) that's nice for x-scrolling, together with setting display initial ram addr we shall be capable of scrolling everywhere hardware-supported B)
sure it could be easier, but at least we won't have to scroll everything by hand

does the sound got any acceleration on hw implementation of sdl?

 

[paeryn]

Yes, the start address can be anywhere in the upper memory. It has the 32bit boundry so you can only scroll by 2 (16bit) or 4 (8bit) pixels. It is possible to use the display delay to fine tune this down to 1 pixel, but at the cost of a column (or 3 in 8bit mode) from the right-hand side.
In your example of 640x240 you'll just need to set the stride to double what it normally is to make the hardware skip the extra screens worth of data.
Unfortunately we don't have anything like the old Copper (happy Amiga days :rolleyes to make really easy full 8-way endless scrolling, but we do have plenty of power to do it the hard way.

So it does have support for skipping 'x' bytes at the end of each horizontal line? (my english is quite poor, I'm not sure if I get it all right) that's nice for x-scrolling, together with setting display initial ram addr we shall be capable of scrolling everywhere hardware-supported B)
sure it could be easier, but at least we won't have to scroll everything by hand

does the sound got any acceleration on hw implementation of sdl?

Yes, you can tell the hardware what the start address of the top-left corner you want, how wide the screen is in pixels (you can use this with the scaler to either up or down scale to the 320 of the LCD or 720 of the TV)or use the region extension for smaller displays without scaling,) how many bytes there really is from the start of one line to the next for horizontal scrolling, how many lines you want (same as with horizontal you can up/down scale.)

I've not tested too much (really must do though ) with altering the scaler mid-display, but I know that the start address is latched at the start of a field (ie changing it mid-display won't affect the current frame) so I'm assuming all the display registers are latched at the start of each field.

The sound HW is basically a DMA buffer, you tell it where to start reading from and how big the buffer is, and it'll tell you when it needs refilling. I think Linux has pretty tight control over the buffer and requires us to access it via /dev/audio (or whatever it uses), I don't think we have access to the interrupt. SDL uses the standard Linux method - I don't manipulate the hardware directly like I do with the graphics. Maybe one day when I've finished everything else I'll look into programming the hardware directly (if nobody else does first), but I've never done much audio programming.

 

[Lint]

Gee man, that's great!

I just asked about the sound because I saw someone complaining about sound on accelerated SDL implementation, so I was wondering if there's any difference between standard sdl... like if 'accelerated sound' would allow hardware playback of mp3 frames or mixing different samples in real-time, etc...

Since you're using linux interface to SDL, wich is already dma-based, I think you've got too little to take advantage by direct access against the flexibility of using the standard API, so keep on doing your work with video indeed..

keep the good work man, as soon as my gp2x get delivered over here I hope I'll be able to help you with any further issue h34r:

 

[paeryn]

Initial large memory support, this version uses the first 16MB of the upper 32MB for the framebuffer and surfaces. If your program uses this space it will not work. I'm going away for a few days but when I get back, if this version works I'll add the 5MB frame buffer back and make the 16MB an option which will need to be enabled so as to not to interfere with anything using it.
I'll add support for using more of the 32MB as long as Linux doesn't mind it being used. I know that the .5M (and possibly upto 1M) after the framebuffer is allocated to the audio DMA buffer and so shouldn't be used. And as long as you don't mind loosing video playback & the 940 I can take over the 1MB reserved for the 940 code. There's also the 3MB reserved for YUV overlays I can take.
Does anybody know if the last 6MB is used by anything? If it isn't I'll add that too!

So to sum up, my original version had 5MB, this one has 16MB, I can definately go up to 24MB, possibly 25MB. All this extra memory will have to be asked for explicitly according to what your needs are so that SDL doesn't tread on any toes.

Anyone wanting to test the 16MB version can get it here I don't expect any problems with it unless I've overlooked any old hard-coded values.
I'll be back Monday or Tuesday to deal with any issues.

Cheers,