GP2X Allegro Patches For Gp2x

[gfoot]

I've uploaded some preliminary patches against Allegro 4.2.0, to make it build for the GP2X. It's not yet complete - see the end of the post for a list of what's working and what isn't. You can download the patches at http://gfoot.homeip.net/~gfoot/gp2x/gp2xallegro-0.1.diff.gz

Initially I was using the SDK from gp32spain, but it doesn't seem to work properly either for my joystick reading in Allegro or for rlyeh's minimal library examples. Open2x works fine though, and I'd highly recommend upgrading to it.

• Unpack Allegro: tar -xzf allegro-4.2.0.tar.gz
• cd allegro-4.2.0
• Apply patches: gunzip -c gp2xallegro-0.1.diff.gz | patch -p1
• Configure - see below.
• Build: make && make install
• To link into your own programs, use `/opt/gp2xallegro/bin/allegro-config --static ...` with --cflags and/or --libs as appropriate. I might rename allegro-config to gp2x-allegro-config, so you could path the directory and not conflict with a native Allegro installation.

The following configure options work well for me. Ask if you want any of them explained. --enable-lgp2x already turns off some other features, I might make it change other defaults too... not sure at the moment.

LDFLAGS=-static ./configure --host arm-open2x-linux --without-x --enable-lgp2x --enable-static --disable-shared --disable-modules --prefix=/opt/gp2xallegro --enable-dbglib --enable-dbgprog

What works:

• GFX_FBCON graphics driver at 320x240 16bpp
• Joystick support via custom GP2X joystick driver
• Sound seems to work, I haven't tested it much though, it's just standard Linux stuff
• Non-hardware stuff, obviously - datafiles, fixed point math routines, etc

What doesn't work:

• Timers - I'm not convinced they're working properly
• FLI player - probably due to the timer issues
• MIDI player - again probably due to timer issues
• Keyboard - I might hook up the buttons to generate key events, for best compatibility, but that might also get in the way, and in any case the buttons don't generate interrupts so you'd need to poll the keyboard, which most games don't bother doing. For now, recode to use joystick only.
• Page flipping / triple buffering / video bitmaps - I wonder how necessary these are. Maybe you can just write GPIO registers to map the framebuffer from your own address space or something.
• The demo game - it currently crashes just as the game is about to start, needs more debugging.

 

[DJWillis]

gfoot,

Very tasty . The more libs like this the better, it's all about choice after all.

I wonder if much of the work on hardware acceleration and scaling being done for SDL could be ported over to Allegro with a bit of work?

 

[gfoot]

Yeah, it's always possible Allegro's video driver system supports supplying accelerated versions of pretty much anything you like, so it could be possible. The stretching routines might not be part of that, I'm not sure. They usually work by on-the-fly compilation of code to stretch a single line, on x86 platforms, so that system could be extended to support arm anyway. I don't find stretching to be that useful an operation though, so it's probably not worth much effort!

I really need to find time between changing nappies to figure out why the timer system isn't working now.

 

[Mentor]

changing nappies :blink: Gawd, these programmers get younger every year

Mentor

 

[paeryn]

Page flipping / triple buffering / video bitmaps - I wonder how necessary these are. Maybe you can just write GPIO registers to map the framebuffer from your own address space or something.

​

The way I've got SDL double-buffering is to mmap 5MB from the base address given by fb0 (0x3101000), fb1 starts straight after if fb0 was 1280x1024x16 (2.5MB) so I'm assuming all that space is reserved for the frame buffers. Page flipping & panning around a larger surface can be done by setting the MSC_STL registers, scaling a larger surface to fit the screen should be fairly easy to add too.
Only problem so far is that the left-most pixel has to be even (address of top-left pixel has to be 32-bit aligned).

All the free memory after your frame buffers can be used for HW surfaces with HW blitting. You can't use malloc'd memory for HW accellerated stuff as you need the physical address, not virtual.