GP2X Gp2x Allegro V0.3


I just tried commenting out the redundant wait-for-idle calls, and it still runs fine for me but still crashed for Anata on IRC. http://www.glost.eclipse.co.uk/gfoot/gp2x/test.zip

It's starting to feel like mine is the only GP2X that doesn't crash here, but I can't see why - I haven't modded anything on the nand, it was delivered last month with firmware 1.0.1, which I later upgraded to 1.1.0 with Rob's upgrader. I've tried running from batteries and running from a PSU, putting the files in the root vs in a subdirectory, and I'm now using a card reader whereas previously I was using the USB mass storage driver. I've also tried running it immediately after booting (having left the device off for a while), running it after the movie player, and after the MP3 player - it just seems to work every time.

If it was working for everybody *except* me, I'd be a lot happier really. :) In any case, the whole point of hardware like this is that they should all behave the same way...
 
In any case, the whole point of hardware like this is that they should all behave the same way...
It sounds like you have one from the same batch as mine... even upgraded the same way I did. Although I did mess a little with what's in the nand: installed the sdl libs to it. Not sure if the upgrade to 1.1.0 would have reversed that, assuming it didn't...
Current conjecture: the gph menu-application, using the stock sdl-libs, pre initializes the blitter for you.
Hmm another thing that works for some is sdl_mixer.
Does stuff using sdl_mixer work for you, or do you get 'Couldn't create mixer lock.'?
For me mixer works, but maybe it can't create the semaphore if the gp2x has the original sdl-libs, pre-loaded by the launcher?
 
I don't have any programs using sdl_mixer, or at least, not that I know of... I too installed the SDL libraries as required for some games, before applying the 1.1.0 patch. I can understand that gp2xmenu might use the blitter, but I would have thought it would still behave the same on all gp2xs, or would be erratic. It's a bit spooky having it either work or not work, consistently!
 
Hello,

I'm a total newbie in GP2X world,
I will try to post my experience, Allegro is working here!.

Host platform: SUSE linux 9.3
Firmware version: 1.2.1
I have not installed SDL in the GP2X (I don't know if they're included).
I have installed the devkit with the instructions found here:
http://wiki.gp2x.org/wiki/Setting_up_a_dev...nstaller_script
After 4 or 5 hours compiling, I got the devkit.

arm-linux-gcc -v

Using built-in specs.
Target: arm-linux
Configured with: ../../gcc-4.0.2/configure --prefix=/usr/local/devkitPro/devkitGP2X --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=arm-linux --enable-languages=c,c++ --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-sysroot=/usr/local/devkitPro/devkitGP2X/sysroot --with-build-sysroot=/usr/local/devkitPro/devkitGP2X/sysroot --enable-shared --disable-win32-registry --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --disable-nls --with-float=soft --with-cpu=arm920t --enable-cxx-flags=-mcpu=arm920t --enable-symvers=gnu --enable-c99 --enable-long-long --disable-multilib --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.0.2

I made some links to the files and place them in /usr/local/bin

I have downloaded Allegro and patched it with the 0.3 version of the patches cleanly.

I have configured it with LDFLAGS=-static ./configure --host arm-linux-gcc --without-x --enable-static --disable-shared --disable-asm --enable-lgp2x --disable-modules --prefix=/usr/local/devkitPro/devkitGP2X --enable-dbglib

Note: First of all I tried without --disable-asm and it didn't work.

make worked without problems.

Then I have downloaded the example made by George Foot (parallax), his binary ran at
about 55-59 FPS. I have compiled the same program myself, it worked but with a minor
perfomance (35-40 FPS aprox). I am testing small programs now to see how Allegro works,
at the moment, the most important things seem to be ok.
 
Since G2PX allegro port maintainer seems to be unreachable via e-mail and it is the most relevant allegro thread, posting it here:
I'm also trying to make Allegro work on Nokia 770:
http://www.allegro.cc/forums/thread/561300
http://www.allegro.cc/forums/thread/571721

One of the problems with allegro C code is poor performance with blitting. There is memmove patch integrated into latest allegro SVN that should improve performance (and it really does), but looks like the performance can be improved even more. Could you please test the following code on GP2X and report results:

http://maemo.org/pipermail/maemo-developer...rch/003269.html

If this code works fine on GP2X as well, I'm going to prepare and submit patch for Allegro, so everyone should benefit from that.
 
Since G2PX allegro port maintainer seems to be unreachable via e-mail and it is the most relevant allegro thread, posting it here:
I'm also trying to make Allegro work on Nokia 770:
http://www.allegro.cc/forums/thread/561300
http://www.allegro.cc/forums/thread/571721

One of the problems with allegro C code is poor performance with blitting. There is memmove patch integrated into latest allegro SVN that should improve performance (and it really does), but looks like the performance can be improved even more. Could you please test the following code on GP2X and report results:

http://maemo.org/pipermail/maemo-developer...rch/003269.html

If this code works fine on GP2X as well, I'm going to prepare and submit patch for Allegro, so everyone should benefit from that.
cool stuff B)
 
Last edited by a moderator:
Well, what I need is someone who can compile the source using -O2 or -O3 optimizations and run it from a telnet session with output redirected to a file. It takes several minutes to run. After that posting results would be welcome.

By the way, I got test results from some other ARM based devices:
http://maemo.org/pipermail/maemo-developer...rch/003373.html

It can be also considered as some kind of memory performance benchmark and could show how GP2X compares to other devices :)

Better utilization of memory bandwidth can improve nonaccelerated blitting mem->mem and mem->vram. This is probably not so useful as hardware acceleration, but may also help sometimes.
 
Bump. Well, it is just a matter of a few minutes to compile the test program, run it and publish the results. I wonder why nobody could do that yet.
 
Back
Top