GP2X Hw Accelerated Sdl


Wild[Kyo said:
,Mar 29 2006, 06:38 PM]Again, sorry for my poor english and the explanation of before... :(

That I wish to say is the last thing you say. Support smaller screen sizes. That is, if I put a screen of 200x200 that the HW Accelerated SDL will don't resize automatically to 320 x 240.
No problem, I just wanted to check you need a smaller display. I should be able to get the display to do it fairly easily. Initially it might be fixed to the top-left of the display, but with a bit of luck I'll be able to let you choose where on the display to put it.
I'll start on it in the morning - I've not had my daily fix of Oblivion today (damn you, Bethesda - you stole so much of my time with Morrowind and now you're doing it again :) )
Edit:
I think that I've got it how you want. No source yet, that'll be up in a day or two as I need to sort out the cursor to work with this, but pre-compiled is here
I've added functions to handle window regions (as they were needed to do this) - I'll document them later.
The new function you need is SDL_GP2X_MiniDisplay() - it aligns the screen, sets up window region 1 to blank the borders and puts the scaler back to 1:1. This is mutually exclusive with SDL_GP2X_Display() as that is designed to up/down-scale to fullscreen. You can switch between them if you want, but MiniDisplay() doesn't support hardware scrolling / scaling. If anybody wants that let me know.
To use the smaller screen size, after you've created your screen with SetVideoMode() call SDL_GP2X_MiniDisplay(x,y); where x,y is where you want the top-left corner to be on the LCD.
e.g. for your 200x200 screen, if you want it shown in the centre of the display, call SDL_GP2X_MiniDisplay(60,20).
There's not much error detection, so make sure you pass sensible values.
 
Last edited by a moderator:
Sorry to bother you, but when do you expect the feature you described to specify an area of memory usable to SDL will be implemented? If I understood you correctly, up to the lower 16 MB of the upper 32 MB of RAM would be usable for hardware surfaces the blitter could utilize. Is this correct? ..

Thanks for your excellent work!

P.S. I had a peculiar question but something you may want to look into. In reading through the MMSP2 datasheet I noted there is allegedly hardware support for 'digital zoom' for cameras that use the MMSP2. Could this be utilized to scale an SDL surface in realtime and not have to use SDL_GFX and its slow, float-heavy operations to do the same thing? Or are there specific requirements for its utilization e.g. image resolution?

Is it also safe to assume NONE of the video postprocessor functionality can be utilized from within SDL? I noted it has support for alpha blending, scaling and chroma key operations in hardware. However, from what I hear MES has not even released sufficient documentation about the video processing capabilities of the hardware.
 
Epicenter posted on May 14 2006 at 01:05 AM said:
Sorry to bother you, but when do you expect the feature you described to specify an area of memory usable to SDL will be implemented? If I understood you correctly, up to the lower 16 MB of the upper 32 MB of RAM would be usable for hardware surfaces the blitter could utilize. Is this correct? ..
Right after (or at the same time as) I get joystick support in. I've had a slight hiccough in that my dev setup refused to let me log in properly and I couldn't figure out how to get it back. I ended up upgrading to FC5, which I've only just got working. Hopefully I'll be able to get started bck on it tomorrow.
Thanks for your excellent work!
blush
P.S. I had a peculiar question but something you may want to look into. In reading through the MMSP2 datasheet I noted there is allegedly hardware support for 'digital zoom' for cameras that use the MMSP2. Could this be utilized to scale an SDL surface in realtime and not have to use SDL_GFX and its slow, float-heavy operations to do the same thing? Or are there specific requirements for its utilization e.g. image resolution?
Unfortunately the digital-zoom support is just that the scaler can zoom in on the video-in layer. I've thought about trying to use it to do a better full-screen scale as it can read video-in from memory but I've not had time to play with it.
Is it also safe to assume NONE of the video postprocessor functionality can be utilized from within SDL? I noted it has support for alpha blending, scaling and chroma key operations in hardware. However, from what I hear MES has not even released sufficient documentation about the video processing capabilities of the hardware.
Quite a bit is already in there :-
Alpha blending - this is only available between layers (RGB, cursor, YUV, OSD, etc), not in the blitter.
Currently only the cursor can be alpha-blended because I've not yet implemented the YUV and OSD overlays.
Scaling - again, this only applies to layers.
The RGB layer scaling has been in my SDL for ages, I use it mainly to expand/shrink the display surface to fit the LCD.
Chroma-keying - This is in the blitter, and is used automatically since my first release.
The information we're missing is how to control the video decoder. I've no idea what registers it has, or where they are located.
 
Last edited by a moderator:
this latest version hardlocks my gp2x.

Code:
SDL_GP2X: CreateDevice
SDL_GP2X: VideoInit
SDL_GP2X: Physical screen = 16192x61424 (ilace = 0)
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x125c28 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_SYS_JoystickInit
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=0
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: InitHWSurfaces 0x40025800, 5085184
SDL_GP2X: Screen bucket 0x1251cc
SDL_GP2X: First free bucket 0x125c98 (size = 5085184)
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x125cb0 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5084928 bytes @ 0x125cc8
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x40025800
 
Redeeman posted on May 20 2006 at 06:23 AM said:
this latest version hardlocks my gp2x.
Code:
SDL_GP2X: CreateDevice
SDL_GP2X: VideoInit
SDL_GP2X: Physical screen = 16192x61424 (ilace = 0)
SDL_GP2X: Creating cursor 16x16
Whoa, the physical screen size looks way out! It's got it correct on every firmware I've had (all official, and open2x,) what are you running on? Also, are you in TV-out mode (thought the ilace=0 says not)?
I'll look into what could be causing huge values as SDL is trying to stretch the screen to fit the physical and it's probably locking the display trying to do it.
My linux partition refused to boot last night so I've got to get that fixed first.
 
Last edited by a moderator:
Hey paeryn,

I had done my first build of LGPT using your SDL binaries but it seems SDL_SetVideoMode crashes on some machines. It's a little of a bummer because on other level, the lib runs really fine. Is there any way I could get a FULL_LOG version to see what goes wrong ? Unfortunately, it does not happen on my unit so I have to do a build, send it to virusx for log, etc.. which makes the operation quite painful.

So far, his version shows the following:

Code:
Booting...  
Installing GUI Factory...  
Installing FileSystem...  
Installing Sound...  
Installing Midi...  
Initializing video...  
SDL: GP2X_CreateDevice  
SDL: GP2X_VideoInit  
fastioclk = 0, grpclk = 0  
real screen = 320x240 (ilace = 0)  
SDL_SYS_JoystickInit  
Initializing SDL...  
Reading config...  
Reading battery level...  
Battery Level: 100Boot finished  
Init persistency services..  
Creating application instance  
Creating application window  
SDL: GP2X_ListModes  
SDL: Setting video mode 320x240 16 bpp, flags=1  
SDL: GP2X_FreeHWSurfaces  
SDL: GP2X_InitHWSurfaces 0x40026800, 5089280  
Screen bucket 0x150490  
First free bucket 0x153430 (size = 5089280)

Then it bails out without any notice to the command prompt. It does not seem to matter wheter I use for HW or SW surface.

How can I help to debug this ?

Thanks for the great work !


Marc
 
thebooboo posted on May 23 2006 at 02:44 PM said:
Have these libraries been updated to fix the vsyncing problem with 2.0 firmware yet?
The ultra-up-to-date version has it fixed, well it should work under both now - I've got 2.0, not tested on older firmwares.
There's also support for a USB mouse (multiple mice coming soon), and hopefully USB joysticks should work - I'm just waiting for someone to test it out as I don't have the hardware :)

Lib is here and a simple joystick test is here
Have to rush off,
 
Last edited by a moderator:
M-.-n posted on May 23 2006 at 07:13 PM said:
paeryn posted on May 23 2006 at 07:54 PM said:
Lib is here and a simple joystick test is here
Have to rush off,

Too much rush I guess... the link is broken :)
Oops, sorry... Apart from putting http twice I put .tar.bz2 instead of just .bz2 on the lib (which I realized about 15 minutes after I'd left :rolleyes: )
The links both in this reply and the original now point where they should.
 
Last edited by a moderator:
paeryn posted on May 23 2006 at 06:54 PM said:
thebooboo posted on May 23 2006 at 02:44 PM said:
Have these libraries been updated to fix the vsyncing problem with 2.0 firmware yet?
The ultra-up-to-date version has it fixed, well it should work under both now - I've got 2.0, not tested on older firmwares.
There's also support for a USB mouse (multiple mice coming soon), and hopefully USB joysticks should work - I'm just waiting for someone to test it out as I don't have the hardware :)

Lib is here and a simple joystick test is here
Have to rush off,


when you say the ultra up to date version, you did mean the lib you provided right? and I presume I was supposed to rename it to libSDL.a ?

because when I try and link against it when its called libSDL.a the entire thing blows up in hundreads of errors, all undefined refrances - and some refrancing paths and cpp files i've never even heard of let alone have :x
 
Last edited by a moderator:
Sephnroth posted on May 24 2006 at 12:28 AM said:
when you say the ultra up to date version, you did mean the lib you provided right? and I presume I was supposed to rename it to libSDL.a ?

because when I try and link against it when its called libSDL.a the entire thing blows up in hundreads of errors, all undefined refrances - and some refrancing paths and cpp files i've never even heard of let alone have :x

That doesn't sound healthy. Yes it should be renamed llibSDL.a It's ultra-up-to-date in that I only compiled it the other day. I had a few problems getting it to compile after I had to re-install FC5, I'll reboot into Linux in a few minutes and see if I can sort it out.
Does the joystick program work? That's compiled with the same library and works fine for me.
 
Last edited by a moderator:
i'll try the joystick program now, and just incase its any use, a selection of errors for you:

Code:
ark2X.cpp:(.text+0x570): undefined reference to `SDL_FreeSurface'
Debug\Dark2X.o: In function `dbxSync()':
Dark2X.cpp:(.text+0x5bc): undefined reference to `SDL_Flip'
Dark2X.cpp:(.text+0x608): undefined reference to `SDL_MapRGB'
Dark2X.cpp:(.text+0x618): undefined reference to `SDL_FillRect'
Debug\Dark2X.o: In function `dbxTimer()':
Dark2X.cpp:(.text+0x634): undefined reference to `SDL_GetTicks'
Debug\Dark2X.o: In function `dbxSetDisplayMode(int, int, int)':
Dark2X.cpp:(.text+0x658): undefined reference to `SDL_SetVideoMode'
Debug\Dark2X.o: In function `dbxSetGamma(float, float, float)':
Dark2X.cpp:(.text+0x69c): undefined reference to `SDL_SetGamma'
Debug\Dark2X.o: In function `dbxSetWindowTitle(char const*)':
Dark2X.cpp:(.text+0x6c4): undefined reference to `SDL_WM_SetCaption'
Debug\Dark2X.o: In function `dbxCreateImage(int, int, int)':
Dark2X.cpp:(.text+0x890): undefined reference to `SDL_CreateRGBSurface'

SDL_rotozoom.c:(.text+0x3a44): undefined reference to `SDL_CreateRGBSurface'
SDL_rotozoom.c:(.text+0x3a60): undefined reference to `SDL_UpperBlit'
SDL_rotozoom.c:(.text+0x3d44): undefined reference to `SDL_CreateRGBSurface'
SDL_rotozoom.c:(.text+0x3d8c): undefined reference to `SDL_CreateRGBSurface'

/usr/local/gp2x/libs-gp2x/SDL_image/IMG_bmp.c(215): undefined reference to `SDL_ReadLE32'
/usr/local/gp2x/libs-gp2x/SDL_image/IMG_bmp.c(216): undefined reference to `SDL_ReadLE32'
/usr/local/gp2x/libs-gp2x/SDL_image/IMG_bmp.c(217): undefined reference to `SDL_ReadLE16'

/home/Administrator/newtoolchain/SDL_mixer-1.2.6/mixer.c(828): undefined reference to `SDL_LockAudio'
/home/Administrator/newtoolchain/SDL_mixer-1.2.6/mixer.c(837): undefined reference to `SDL_UnlockAudio'

and so on and so on, pretty much everything that should be in libSDL.a

im not being stupid right, that IS an arm library file for the gp2x, not one compiled for use with x86 linux? I really need this vsync stuff fixed so hope I can fix this xD All the errors go away if i copy my old libSDL.a over that one

EDIT:

yes the joystick program appears to work fine :) it runs at least

Code:
[root@gp2x joystick]$./joystick
SDL_SYS_JoystickInit
Number of joysticks: 1
Joystick 0 is at 0x100590
  It has 0 axes, 0 hats, 0 trackballs and 19 buttons
[root@gp2x joystick]$

:)
 
Sephnroth posted on May 24 2006 at 12:43 AM said:
im not being stupid right, that IS an arm library file for the gp2x, not one compiled for use with x86 linux? I really need this vsync stuff fixed so hope I can fix this xD All the errors go away if i copy my old libSDL.a over that one
Cheers, yes it is GP2X lib. From what you just posted I've an idea what's gone wrong... I'm re-booting right now to check.
 
Last edited by a moderator:
Sephnroth posted on May 24 2006 at 12:52 AM said:
awesome, hope its an easy fix for you :)
Try them now (the joystick test has been re-compiled and is much smaller now :) )
It was compiled with shared library support which makes the lib very big (and crashes for me - I don't support using this as a shared library). I had realized this when first uploading and for some strange reason I thought stripping it would help - it did, with the side-effect of not having the labels for linking - doh!
 
Last edited by a moderator:
very sorry to say it seems to be giving the exact same error :/ lib was same filesize as the original one giving the error too, did it upload properly?

edit:

just to add, i downloaded it several times and compared it to the original lib still in my recycle bin and its byte for byte the same size as the original one you uploaded - so if the originl was missing something I guess the one currently linked to is still the one missing something, because the extra lables etc would surely add at least one byte?
 
Sephnroth posted on May 24 2006 at 01:21 AM said:
very sorry to say it seems to be giving the exact same error :/ lib was same filesize as the original one giving the error too, did it upload properly?
Yeah, I downloaded it too to make sure -
-rw-rw-r-- 1 darius darius 423150 May 24 01:06 /home/darius/downloads/libSDL-joystick.a.bz2
Did you flush your browser cache?
 
Last edited by a moderator:
woah you replied just as i edited :)

i have never had to flush my cache for this sort of thing before, I will go do that and clear all temp files now just incase though, will edit this post in 5 mins
 
Back
Top