GP2X Hw Accelerated Sdl

[paeryn]

I default to 16bpp, the only other depth you can ask for is 8. Well, actually if you don't specifically ask for 8 it gives you 16. I know it should really let you ask for 24 & 32 too, but since memory is limited and it'd mean having to down-convert every frame I didn't think it was worth it.

 

[luteijn]

long shot, but perhaps boeseronkel is not linking with -static?

 

[boeseronkel2k]

here's a bit of my makefile

LIBS = -L/usr/open2x/lib -Wl,-rpath,/usr/open2x/lib -lSDL -lpthread -lm -ldl -static

i have linked it staticly
...
but now i am building a new toolchain and hope it will work

edit:

i have a new toolchain, i build it with the perl script

but i have the same problem, no graphic, no error, no whatever
a black display, nothing else

 

[yaustar]

Doesn't -static have to be declared at the beginning of the cmdline for it to work?

LIBS = -L/usr/open2x/lib -Wl,-rpath,/usr/open2x/lib -static -lSDL -lpthread -lm -ldl

 

[paeryn]

Nope, I usually tack -static on right at the end. I'm wondering if this is a problem with the pre-compiled lib, is anyone having problems with it when building from source?

 

[nickspoon]

I'm using the precompiled lib, and I have no problems at all.

 

[BlackMac]

Looks like it really IS a problem with the prcompiled version. It worked fine with an older one, but now that I upgraded to the most recent version my game does not start anymore. It runs until it reaches this:

screen=SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_DEPTH, SDL_HWSURFACE | SDL_DOUBLEBUF);

The last thing I see on the console ist

First free bucket 0x1c7d40 (size=4935680)

then my game hangs ...


EDIT:
Compiled your SDL-Lib myself and got the same problem too bad. I hope I will be able to finish it before the coding competition deadline now...

 

[gfoot]

I don't know if it's related, but some people found that an early version of Allegro I uploaded, based on paeryn's code, just hung. It was dependent on their specific gp2x, rather than anything to do with the build environment - the same binary would work on other people's gp2xes.

Until now I assumed that I had missed something out somewhere. The actual hang occured while waiting for the blitter to be idle, before my code had actually written any data to it. It didn't seem to be related to firmware versions, nor which programs had been run - it was very consistently failing on specific gp2x units.

If you want to see whether you suffer from this hang with my code, you can try the binary of my parallaxing demo here:

http://www.glost.eclipse.co.uk/gfoot/gp2x/parallax.zip

It would be interesting to hear if this fails for the same people.

 

[paeryn]

Hmm, only reason I can think that would cause the blitter to lock is if it's expecting data to be put into the fifo. I'll see if I can put some checks in when initializing.
I'm in the middle of putting the hardware cursor in at the moment and it's doing my head in - maybe I should go and get some sleep, it's been a long day...

I notice fbcon is getting better in FW 1.4. We can ask it if it's in TV mode now! And set the LCD timing... It still doesn't seem to support anything other than 320x240x16 though
And /dev/GPIO has functions for setting the clock speed...

 

[Voyageur]

All right, here come my gp2x newbie's 2 cents:
I have set up a gp2x toolchain on my gentoo box with the help of ooPo's latest newtoolchain script (20060215). I tried the SDL "hello world" pixel display from the wiki and got a shiny static arm binary using HW SDL
However running it on my gp2x hangs at the SDL_SetVideoMode... A freshly recompiled smsplus2x and gfoot's parallax demo hang too (no logs are produced at all by the latest, btw)

After that I grabbed the libSDL.tar.bz2 from the first page and linked against it... my test program worked! I wonder why the freshly compiled SDL won't work though... Now to get gdb on the beast to make the best use of the usbserial link

 

[paeryn]

That's strange, the pre-compiled version is compiled from the very same source.
To get the source to compile with the debugging statements, uncomment the #define at the end of src/video/gp2x/SDL_gp2xvideo.h Most of them just let you know when the functions are called, a few print extra info where I needed it.
I'll be releasing an updated version in the next few days (or even tonight), I'll do a clean install first instead of just tar-ing up my working version to see if the config is at fault.

 

[Voyageur]

Hum, this time the SDL test program worked... once !(this was just after gp2x bootup, I did not wander in the menus before launching the usb serial and then the test program). I rebooted after (still cannot send Control-C on the serial link) and it did not work anymore...

Apres declars
SDL: GP2X_CreateDevice
SDL: GP2X_VideoInit
fastioclk = 0, grpclk = 0
real screen = 320x240 (ilace = 0)
Apres SDL_Init
SDL: GP2X_ListModes
SDL: Setting video mode 320x240 8 bpp, flags=0
SDL: GP2X_FreeHWSurfaces
SDL: GP2X_InitHWSurfaces 0x40013c00, 5166080
Screen bucket 0xfb218
First free bucket 0xfc070 (size = 5166080)

So I moved on to the ballfield test program..

bash-2.05a# ./ballfield
SDL: GP2X_CreateDevice
SDL: GP2X_VideoInit
fastioclk = 0, grpclk = 0
real screen = 320x240 (ilace = 0)
SDL: GP2X_ListModes
SDL: Setting video mode 320x240 16 bpp, flags=40000001
SDL: GP2X_FreeHWSurfaces
SDL: GP2X_InitHWSurfaces 0x4004b000, 4935680
Screen bucket 0x17b6a8
First free bucket 0x17c0e8 (size = 4935680)

So it looks like the same as BlackMac, but I wonder why the sdl test program ran this time? Maybe there IS something set in the gp2x menus?

 

[paeryn]

I'm starting to suspect GPH's doing something somewhere. I've upgraded to the latest firmware and now I'm getting a blank screen. Not crashing, just not showing anything. An old executable of ballfield freezes after the first frame, but an old test I had for 8-bit works flawlessly.
This could take a bit of time for me to work through - so annoying as I've just got the hardware cursor working and was planning on releasing the new version...

 

[ooPo]

I just upgraded to 1.4 to see what was causing these failures. Here's what I've found:

- Apps compiled against paeryn's SDL from about a week ago work fine.
- SDL_mixer makes sound, but it seems to be playing way too fast.

I'll whip up a testing app sometime soon, but in the meantime it looks fine to me, with the exception of fast audio. I don't have anything newer built here at the moment but will when I get home later tonight.

More testing required!

 

[ooPo]

http://www.oopo.net/consoledev/files/tester.tgz - Source and precompiled tester.gpe file.

Compiled with the latest of everything, the SDL parts work fine but the music plays way too fast. Perhaps this can help you track it down.

 

[bjimba]

Just to add to the mix here -- I'm getting similar reports (app freezing consistently on some GP2Xes, working fine on others) with the DosBox port. I built the release with ooPo's 20060215 toolchain.pl as well.

 

[paeryn]

I'm not sure about the locking-up yet, but I've tracked down the problem I was having with just a blank screen. Somewhere along the line region 1 of the RGB layer was getting switched off. I've forced it on for now, but proper support for the regions will be in the next release.
The cursor should now be working. I've only tested it with the default cursor that SDL sets. I'm not 100% sure about how SDL is handling it as it has some tie-ins with mouse handling, but you can at least switch it on & off, and use SDL_MoveCursor() to set its position.
The main difference is that the hardware does not scale the pointer, and it currently sticks to 320x240 resolution regardless of what resolution the screen is in.
SDL only seems to support black and white (& transparent), I'll add a function later to let you choose the foreground and background colours. Maximum size is 64x64 pixels.

There's been a couple of internal alterations to the surface allocator so for now I'm not overwriting the main links, I'd appreciate any feedback on if this version is stable enough.
Source with cursor support
Pre-compiled with cursor support <- don't forget to change filename back to libSDL.a after bunzipping

Opps, forgot to say - I've swapped the X & Y buttons in the new version to how they should be
Thanks to you all for your support,

 

[Flavor]

I was about to test this new version and then I remembered that I left my card reader at work.

Paeryn, have you found any problems in the code that could have been causing the graphic corruption that I showed you? I'd love to fix that problem.

The hardware cursor is a very nice addition, too. I hope to test this tomorrow.

Thanks!

 

[Voyageur]

I only had time to test my 3 test programs (sdl basic, ballfield and ooPo's test program) before leaving for work, and all worked with the 0222 version! I'll test on some bigger programs tonight (after switching the / partition to cramfs to reboot faster)

 

[paeryn]

Flavor: I'm not sure about the gfx corruption. I've seperated the memory manager from the surface allocater as the cursor (and other things in the future) need to be allocated from the same pool. I also changed slightly how it frees memory, I think that's where the problem was, but let me know if it hans't fixed it.

Voyageur: I use a (slightly) modified version of ballfield as my main test app, I started porting mirrormagic as a bigger test app but haven't had time to do much. Any tests are welcome - don't go out of your way (unless you want to)

I realized after I logged off last night that a couple of debug fprintf's are still in the Flip and DummyBlit routines - since these are called a fair bit, there may be a slight slowdown.

If anyone runs tests using sterm on the GP2X then stderr needs redirecting to a file otherwise sterm starts overwriting the screen (as I found out when testing TV-out)