GP2X Hw Accelerated Sdl

[woogal]

For some reason part of the screen is cut off. It's on the right side it seems that there like 30 or so pixels that missing.

It's the overscan on your TV. CRT TVs never display all of the 720x576 display and some of it always drops of the screen somewhere (on mine I lose quite a bit on the left). The way round it is to create a 360x288 screen, but blit all your stuff onto a 320x240 surface as normal. Then you copy that 320x240 to the centre of the 360x288 screen and when it scales up to 720x288 you'll end up with no scaling distortion (320 will double up nicely to 640 instead of scaling to 720), a bit of a black border around the screen, and with a bit of luck everything will be in the TVs visible area (if it isn't just tweak where you blit the 320x240 to).

 

[joyrider]

For some reason part of the screen is cut off. It's on the right side it seems that there like 30 or so pixels that missing.

It's the overscan on your TV. CRT TVs never display all of the 720x576 display and some of it always drops of the screen somewhere (on mine I lose quite a bit on the left). The way round it is to create a 360x288 screen, but blit all your stuff onto a 320x240 surface as normal. Then you copy that 320x240 to the centre of the 360x288 screen and when it scales up to 720x288 you'll end up with no scaling distortion (320 will double up nicely to 640 instead of scaling to 720), a bit of a black border around the screen, and with a bit of luck everything will be in the TVs visible area (if it isn't just tweak where you blit the 320x240 to).

so i should probably detect if we are in tv out mode or not when my game starts and then create either a 320x240 screen as usual if we are in lcd mode or create a 360x288 screen if we are in tv out mode and do the the blitting according to the screen right ?

update: tried it out and seems to work thanks but i have another question since overscan is probably specific to each television how can u be certain that it works on all tv's ? i mean just take ure tv and my tv for example, with me the right side is cut off with you the left side, so if i try to possition my screen in the middle according to my tv , it probably won't be in the middle on your tv. How do u deal with it so it most probably will work on all tv's ? (just use the center as u suggested ? cause now on my tv i've got a fairly big black border on the left side and very thin one on the right side but on other tv's this probably is not the same right ?) i don't think there's a way to detect which parts get cut off is there ? i do have another option in mind let the user be able to move the game's 320x240 screen around in the 360x288 surface until it gets centered

 

[woogal]

Allowing the user to move the area is the only way to be certain it will look right as all TVs are different. Even then there's no guarentee that everyone will be able to see a full 640x480 (or 240) screen as the recommended area is even smaller than this, but most TVs these days should be able to handle it. To quote BSkyB -

The “safe area” is an area of approximately 20% around the edge of the PAL TV area. The
dimensions of the “safe area” are 592 x 480 pixels and anything within these dimensions should
appear on any television.

That safe area is positioned in the centre of the 720x576 display.

 

[joyrider]

thanks again.

I made it so that they can position it on screen and now i can see everything on my tele's & pc.
will have to icorporate this in all my games now

 

[Lint]

Hey, I think it's 712x576, at least some common DVDs use this resolution, right?
I'll try to find some missing pixels when playing on TV, so far I think that everybody is there

 

[BradN]

DVD's are usually overscanned, so that there's no black edges visible, and then there must be at least a little of the image offscreen. Interestingly, DVD's are almost always 720x480, rescaled to the aspect ratio desired. Maybe it's different for PAL. For that reason, when I rip DVD's, I try to keep the original 720x480 resolution, and then set the relevant aspect ratio flags to make the player rescale it - this way you don't lose data by reducing the vertical dimension in the case of a widescreen movie.

 

[Normmatt]

has anyone got the latest release/cvs thats compatible with the official windows sdk? i'd like to move over to using the hardware lib...

 

[JyCet]

Hi all,
I've updated my old sdl library from June to the last available on the first page (december precompiled), but now SDL_HWSURFACE without double buffer crash the GP2X (of course i dont use SD_flip(...) in single buffer).
Is it normal ?

Thanks

 

[paeryn]

Hi all,
I've updated my old sdl library from June to the last available on the first page (december precompiled), but now SDL_HWSURFACE without double buffer crash the GP2X (of course i dont use SD_flip(...) in single buffer).
Is it normal ?

Thanks

It definitely is not normal, does it crash when setting the video mode, when blitting, or at any other time?
My guess would be that I forgot to change something in initialization when I made the surface managing more flexible. I'll look into it ASAP.

 

[JyCet]

Ok the program is not crached but the display is totaly false some strange pixel alignement on the screen I cant see the original picture
Here the telnet log:

...
[root@gp2x sd]$./glouton_hw_sb.gpe
GLOUTON
v0.2
by JyCet
SDL_GP2X: CreateDevice
SDL_GP2X: VideoInit
SDL_GP2X: Physical screen = 320x240 (ilace = 0, pol = 0)
SDL_GP2X: InitHWSurfaces
SDL_GP2X: InitHWSurfaces scratch = 0
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x184bd0 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5242624 bytes @ 0x184be8
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x41111000
SDL_GP2X: Looking for a mouse
SDL_GP2X: No mice found
SDL_SYS_JoystickInit
SDL_GP2X: SYS_JoystickName(0)
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=1
SDL_GP2X: Freeing cursor 0x184bd0
SDL_GP2X: SurfaceManager freeing 256 bytes @ 0x41111000 from bucket 0x184340
SDL_GP2X: merging with next bucket (0x184be8) making 5242880 bytes
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: Freeing bucket 0x184328 (size 17825792)
SDL_GP2X: Freeing bucket 0x184340 (size 5242880)
SDL_GP2X: InitHWSurfaces
SDL_GP2X: InitHWSurfaces scratch = 0
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x184bd0 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5242624 bytes @ 0x184be8
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x41111000
SDL_GP2X: SurfaceManager allocating 153600 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5089024 bytes @ 0x184de8
SDL_GP2X: SurfaceManager allocated 153600 bytes at 0x41111100
SDL_GP2X: AllocHWSurface 0x185468
SDL_GP2X: SurfaceManager allocating 153600 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 4935424 bytes @ 0x1854d8
SDL_GP2X: SurfaceManager allocated 153600 bytes at 0x41136900
SDL_GP2X: Allocated
SDL_GP2X: AllocHWSurface 0x185528
SDL_GP2X: SurfaceManager allocating 153600 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 4781824 bytes @ 0x185598
SDL_GP2X: SurfaceManager allocated 153600 bytes at 0x4115c100
SDL_GP2X: Allocated
SDL_GP2X: AllocHWSurface 0x1855e8
SDL_GP2X: SurfaceManager allocating 153600 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 4628224 bytes @ 0x185658
SDL_GP2X: SurfaceManager allocated 153600 bytes at 0x41181900
SDL_GP2X: Allocated
SDL_GP2X: AllocHWSurface 0x1856a8
SDL_GP2X: SurfaceManager allocating 153600 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 4474624 bytes @ 0x185718
SDL_GP2X: SurfaceManager allocated 153600 bytes at 0x411a7100
SDL_GP2X: Allocated
SDL_GP2X: AllocHWSurface 0x185790
SDL_GP2X: SurfaceManager allocating 153600 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 4321024 bytes @ 0x185800
SDL_GP2X: SurfaceManager allocated 153600 bytes at 0x411cc900
SDL_GP2X: Allocated
SDL_GP2X: AllocHWSurface 0x186b58
SDL_GP2X: SurfaceManager allocating 7552 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 4313472 bytes @ 0x186bc8
SDL_GP2X: SurfaceManager allocated 7552 bytes at 0x411f2100
SDL_GP2X: Allocated
usb net 0...

I'll test to take a screenshot ...

EDIT:
The digital screenshot

It's very strange because here I can see a part of my picture but sometimes I cant see it.
The program is not crached.

EDIT²:
After a big gp2x shutdown i think the memory was totaly cleared and now:

It's a new game ... divine the picture

 

[paeryn]

Ok the program is not crached but the display is totaly false some strange pixel alignement on the screen I cant see the original picture

The interference looks fairly consistent - does the pattern alter during the run or is it static?
I've uploaded the pre-compiled version of the latest SVN code, here if you want to try that.
I ran my test program in single buffer mode and apart from the ridiculasly fast screen updates I didn't see any interference like you have.
I'm not sure why libSDL.a has grown from 1.1M to 7.5M. I've updated my Linux box and installed the Open2X toolchain rather than Oopo's which I used to use so it must be something in the settings - anyway my test app didn't have much of an increase in filesize so I'm hoping it's just extra debugging data in the lib.

 

[JyCet]

The interference looks fairly consistent - does the pattern alter during the run or is it static?
I've uploaded the pre-compiled version of the latest SVN code, here if you want to try that.
I ran my test program in single buffer mode and apart from the ridiculasly fast screen updates I didn't see any interference like you have.
I'm not sure why libSDL.a has grown from 1.1M to 7.5M. I've updated my Linux box and installed the Open2X toolchain rather than Oopo's which I used to use so it must be something in the settings - anyway my test app didn't have much of an increase in filesize so I'm hoping it's just extra debugging data in the lib.

Thank you for this testing lib, but unfortunately it's the same pb with no double buffer
The background is static but when i select one option (in the program) the screen normaly change, here nothing. I can "play" with the gpe but the display are totally wrong.
Oh just one thing, when I quit the program the picture appear correctly on the screen, there's only the 8 (approximatly) top lines which appear on the bottom screen.

It's very strange, I'm alone to report that ?!!

 

[paeryn]

Thank you for this testing lib, but unfortunately it's the same pb with no double buffer
The background is static but when i select one option (in the program) the screen normaly change, here nothing. I can "play" with the gpe but the display are totally wrong.
Oh just one thing, when I quit the program the picture appear correctly on the screen, there's only the 8 (approximatly) top lines which appear on the bottom screen.

It's very strange, I'm alone to report that ?!!

Ahh, I hope this fixes it - re download the libSDL_21 and try again.
When SDL was initializing the video I set the address of the display to a variable that used to contain the start of video mem, this was fine when the display was hardcoded to be there but it isn't anymore. One of those variable initializations that I forget to update. My test was calling SDL_GP2X_Display() which updates the display registers with the correct values in single buffering so I didn't notice.
If this doesn't fix it then it was coincidence that I found this bug and I'll search for other possibilities.

As for the screen shifting up when quitting, that's the display registers being put back to what they were before SDL took over - it's quite normal since I don't force the display to be exactly where fbcon expects it.

 

[JyCet]

Very nice now all work
The compiled file is bigger but it worked very well
Thank you for your support !

 

[JyCet]

Hi paeryn, it's always me.
After a big search to find why my frontend for cps2emu move the global screen 6 lines lower, I just have discovered my bug disappear with an old SDL lib :-(

This pb is easy to reproduce with fgrab.gpu exept the global screen move 6 lines upper:

With an old lib fgrad and cps2emu screen is normal:

Sorry for this new problem

 

[zodttd]

May not be what people are here for but in the HW SDL I am not able to use the SDL_audio function's for sound effects while using SDL_mixer. SDL_mixer uses the SDL_audio functions for output after mixing my MIDI music.

I don't think it's a HW SDL specific problem, but posting here to make sure. It may very well be a limitation of SDL, but is there a way around it? I guess it doesn't have support for two callbacks for audio.

 

[Simon]

Hi guys

What could be the problem here?

simon@desktop1:~/svn/open2x/libs/SDL-1.2.9$ make
/bin/sh ./config.status --recheck
running /bin/sh ./configure  --prefix=/home/simon/bin/open2x --build=i686 --host=open2x --enable-shared --enable-static --enable-pthreads --enable-pthreads-sem --enable-threads CC=open2x-gcc CFLAGS=-O3 -ffast-math -fomit-frame-pointer -mcpu=arm920t -I/home/simon/bin/open2x/include -I/home/simon/bin/open2x/include/libxml2 CXX=open2x-g++ LDFLAGS=-L/home/simon/bin/open2x/lib build_alias=i686 host_alias=open2x  --no-create --no-recursion
checking build system type... i686-pc-none
checking host system type... arm-gp2x-linux-gnu
checking target system type... arm-gp2x-linux-gnu
./configure: line 2006: syntax error near unexpected token `SDL,'
./configure: line 2006: `AM_INIT_AUTOMAKE(SDL, $SDL_VERSION)'
make: *** [config.status] Error 2

Thanks

 

[paeryn]

May not be what people are here for but in the HW SDL I am not able to use the SDL_audio function's for sound effects while using SDL_mixer. SDL_mixer uses the SDL_audio functions for output after mixing my MIDI music.

I don't think it's a HW SDL specific problem, but posting here to make sure. It may very well be a limitation of SDL, but is there a way around it? I guess it doesn't have support for two callbacks for audio.

It's not HW specific, if you use SDL_Mixer for music then you have to use SDL_Mixer for sound effects too.
I'm not too up on using SDL_Mixer but there's a page here SDL_Mixer tutorial that shows examples of playing just music, just sound effects and both together.

 

[poddy]

Hi guys

What could be the problem here?

simon@desktop1:~/svn/open2x/libs/SDL-1.2.9$ make
/bin/sh ./config.status --recheck
running /bin/sh ./configure  --prefix=/home/simon/bin/open2x --build=i686 --host=open2x --enable-shared --enable-static --enable-pthreads --enable-pthreads-sem --enable-threads CC=open2x-gcc CFLAGS=-O3 -ffast-math -fomit-frame-pointer -mcpu=arm920t -I/home/simon/bin/open2x/include -I/home/simon/bin/open2x/include/libxml2 CXX=open2x-g++ LDFLAGS=-L/home/simon/bin/open2x/lib build_alias=i686 host_alias=open2x  --no-create --no-recursion
checking build system type... i686-pc-none
checking host system type... arm-gp2x-linux-gnu
checking target system type... arm-gp2x-linux-gnu
./configure: line 2006: syntax error near unexpected token `SDL,'
./configure: line 2006: `AM_INIT_AUTOMAKE(SDL, $SDL_VERSION)'
make: *** [config.status] Error 2

Thanks

hi, are you using edgy eft?
have a search for building open2x with ubuntu thread.
makefiles are broken with dash, which eft uses instead of bash linked to /bin/sh.

last time i looked makfiles were broken for latest sdl anyway....
just gonna give them another whirl now.

 

[Simon]

hi, are you using edgy eft?
have a search for building open2x with ubuntu thread.
makefiles are broken with dash, which eft uses instead of bash linked to /bin/sh.

last time i looked makfiles were broken for latest sdl anyway....
just gonna give them another whirl now.

Yeh, im using Edgy Eft, cept Ive returned to default shell to Bash.

Im completely confused - I was having problems with compiling SDL from open2x, so I checked out revision 182 (from memory) which compiled fine, but produces problems with test programs (the same problems as detailed a few posts back).

Is there anywhere I can get a working version of libSDL (hardware accel) for open2x? Even in binary form?

Thanks!