GP2X Hw Accelerated Sdl


Ok did a quick test with PrBoom.
Sound doesn't work (using Woogal's precompiled SDL_mixer) and colors are wrong.
Here are the SDL related log:
Code:
SDL: GP2X_CreateDevice
SDL: GP2X_VideoInit
SDL: GP2X_ListModes
SDL: Setting video mode 320x240 8 bpp, flags=A0000000
SDL: GP2X_FreeHWSurfaces
SDL: GP2X_InitHWSurfaces 0x407f4c00, 5166080
I_UpdateVideoMode: 0xa0000000, SDL buffer, direct access
SDL_SYS_JoystickInit
SDL: VideoQuit
SDL: GP2X_FreeHWSurfaces
SDL: GP2X_FreeHWSurface 0x23c488
SDL: GP2X_DeleteDevice
 
You've not requested double-buffering when setting the video mode (SDL_DOUBLEBUF), without that you're drawing directly to the visible screen and are not synchronised with the refresh rate. When using double-buffering you have to use SDL_Flip(screen) to swap the screen you are drawing on to the screen the user sees (SDL_UpdateRects is an empty call)

Thanks for letting me know about sound - I must have been too eager when I switched the defaults to no.

Uploaded new version with sound enabled (hopefully).
Also the GP2X specific header file is now copied when doing "make install". It isn't needed for normal SDL operation - it's just to expose non-standard things like the scaler


Thanks, using double buffering solved the flickering :)
 
Last edited by a moderator:
Ok did a quick test with PrBoom.
Sound doesn't work (using Woogal precompilec SDL_mixer) and colors are wrong.
Hmm, looking into the colours now. It's setting the initial palette but SDL seems to be not calling my SetColours after that one time...
I've not touched the sound side of things, I'll look into it later though.

Hopefully fixed the colours. I wasn't telling SDL that 8-bit screens had hardware palettes, so it didn't call the function to change them. It snook past me because SDL calls my internal setcolors when initializing the screen. When I tested it I saw it was calling it that first time and assumed it worked.
I'm uploading now so grab the new version and let me know how it looks.

I'll look at the sound issue tomorrow. Is it thinking sound is working & not making a noise, or complaining that it can't initialize?
 
Last edited by a moderator:
Ok, I recompiled PrBoom. Colors are Ok but audio doesn't work using SDL_mixer.
Code:
I_InitSound: Mix_OpenAudio(22050, 32784, 2, 128)
couldn't open audio with desired format No available audio device

I did a quick benchmark, here is the result:
./prboom -iwad doom.wad -nosound -nomusic -fastdemo e1m5-nm.lmp
non-optimized: Timed 10204 gametics in 3042 realtics = 117.4 frames per
optimized: Timed 10204 gametics in 1924 realtics = 185.6 frames per second
 
Not bad... What times were you getting before?

I haven't had time to look into the sound or timer problems yet, though I've got TV support now - just having a few problems with getting the scaler to resize to the TV properly.
I've got to be up early so no late-night coding for me or I'll never get up :(
 
is prboom useing sdl for anything else but blitting? if not, nice (to me) unexpected improvement!

I wonder if this would also give a small improvement for other sdl ports, like nk's emulators.

And a big thank you to evryone who is working on this, it makes gp2x such a better platform :)
 
GPH's version of SDL doesn't properly support 8-bit. It uses /dev/fb which only supports 16-bit, so when you've finished drawing to your 8-bit screen and call UpdateRects, SDL has to convert it all pixel-by-pixel into 16bit.
My version has native 8-bit support. Down side is that writing to a hardware surface is a little bit slower, but there's no conversion at the end.
Plus you get hardware blits and super-fast FillRects at no extra cost.
I thought of trying to squeeze 24bit support, but I doubt it'd be much use, and memory bandwidth could be limiting.
 
I don't know if PrBoom uses SDL for anything else but blitting.
A tried to play PrBoom this morning, and I have two issues. The first is with controls, buttons X and Y are inversed. The second is unstability, PrBoom randomly crashes. In menu or in game. I had such crash when not using paeryn's SDL, but it looks like they append more frenquently with it.
 
I don't know if PrBoom uses SDL for anything else but blitting.
A tried to play PrBoom this morning, and I have two issues. The first is with controls, buttons X and Y are inversed. The second is unstability, PrBoom randomly crashes. In menu or in game. I had such crash when not using paeryn's SDL, but it looks like they append more frenquently with it.

Hey, it works faster, so it also crashes faster :D :D

Great work paeryn, keep it up ^^
 
Last edited by a moderator:
I tried this with Quake2 just to see what the improvement would be like, but it failed to set colours (I'm using 8 bit) and also the scaler didn't seem to work when I was trying to use a 240x180 screen (but that might be the way Quake2 is handling the screen I suppose, I haven't really been through the code in that much detail yet). It sounds like you fixed the colour problem before I downloaded, but I'm wondering if I maybe got a cached version or something. I'll download again and give it another try soon.

I'll also give it a try on an older version of Quake1 (my latest code is using minilib for graphics now). That should show if the scaler is working correctly (it works fine with minilib), and it will also show if there's much difference now between minilib and sdl surfaces.
 
The ScummVM alpha (quick hacky one here) uses my own hacks merged with paeryn's code so it's not the best of tests of the true SDL but...

When bullied correctly the scalar is working well for downscaling (far better then I ever got it on my own) :).

Sound, blitting and most other bits and bobs seem to be working well enough in there software and hardware flavours.

I have only been hacking about with the 16bit modes but 8bits modes do seem to work (after quick tests).
 
Last edited by a moderator:
I tried this with Quake2 just to see what the improvement would be like, but it failed to set colours (I'm using 8 bit) and also the scaler didn't seem to work when I was trying to use a 240x180 screen (but that might be the way Quake2 is handling the screen I suppose, I haven't really been through the code in that much detail yet). It sounds like you fixed the colour problem before I downloaded, but I'm wondering if I maybe got a cached version or something. I'll download again and give it another try soon.

I'll also give it a try on an older version of Quake1 (my latest code is using minilib for graphics now). That should show if the scaler is working correctly (it works fine with minilib), and it will also show if there's much difference now between minilib and sdl surfaces.
I'll check too, one of the archives might have the old code by mistake. Are you using the pre-compiled or source?
Just tested 240x180 and it looks okay, though the scaler code is slightly different now it has to cope with TV resolution as well.
Got a new gfx card to install on my PC, I wonder if I can get the GP2X to interface with the 9800pro I'm taking out :)
 
Last edited by a moderator:
I'll check too, one of the archives might have the old code by mistake. Are you using the pre-compiled or source?
Just tested 240x180 and it looks okay, though the scaler code is slightly different now it has to cope with TV resolution as well.
Got a new gfx card to install on my PC, I wonder if I can get the GP2X to interface with the 9800pro I'm taking out :)
What's the best place to download your libs? I had the odd experience of trying them out one day on a simple (and very slow) particle demo and seeing a nice improvement, albeit with some flickering. I came here to ask about it and someone had already asked and you'd answered (SDL_DOUBLEBUF was required), so I wanted to try it again. I couldn't find where I'd stashed the download, so I went and downloaded again and this time it wouldn't work at all. I'm not sure if I did something brainless or if I went to a different archive or what.

BTW, thanks very much for the work you're doing on this - it really is appreciated.
 
Last edited by a moderator:
Source
Pre-compiled
One of these days I'll make a proper web-page :)
The above two links will always get you the latest version.
When it gets to a stable level I'll see about getting it on gp2x.de or something, it's very much w.i.p. at the mo. Any problems with it let me know either on here or email (sdl@sephs.no-ip.info) and I'll do my best to fix it.
 
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.
 
tried lastest build and works perfect!

good work paeryn

PD:It's normal that if I draw a trasparent box with SDL_gfx the FPS decreases too much? (4 FPS in my lastest test, without SDL_gfx 45 FPS).
 
hey hey, just compiled ttx with this thing and it became playable again :)

quick note - the action button in my game is X, but after compiling with the hardware libs i suddenly need to press Y x_X im using the standard joystick defines from the wiki, im guessing x and y have somehow switched - i'll simply alter the defines for now :)
 
hey hey, just compiled ttx with this thing and it became playable again :)

quick note - the action button in my game is X, but after compiling with the hardware libs i suddenly need to press Y x_X im using the standard joystick defines from the wiki, im guessing x and y have somehow switched - i'll simply alter the defines for now :)
The wiki is wrong and/or the version of SDL it was written about is wrong. If you read /dev/gpio (which sdl does) then X is 1<<15 and Y is 1<<14. The wiki lists X as 14 and Y as 15.
 
Last edited by a moderator:
Last edited by a moderator:
Back
Top