GP2X Gp2x Allegro V0.3

[gfoot]

I've uploaded a new version of Allegro for GP2X. The main change is the addition of accelerated routines for filling and copying rectangles within video memory - basically, the routines paeryn wrote for SDL.

I wrote some documentation about the port too - what to download, how to install it, how to use it, and for the more adventurous, how to build the library yourself.

It's all here: http://www.glost.eclipse.co.uk/gfoot/gp2x/allegro.html

Let me know if you have any problems with this!

(edit: fixed url)

 

[g_sus]

I get a 404 error from your website

 

[Jarska333]

Just ad .html after it.

http://www.glost.eclipse.co.uk/gfoot/gp2x/allegro.html

 

[K0K0NUT_h3lmut]

Version 0.3?!!!!! Where the heck have I been?! If you've been at the forums for a while you'd know that I'm the Allegro enthusiast, even though I'm not even a moderately good coder...

I love you!


I just hope this will be easy to set up, I will probably need help...
-K0K0NUT_helmet

 

[chris_r]

The main change is the addition of accelerated routines for filling and copying rectangles within video memory

does this mean it uses the hardware graphics accelerator chip? I didnt know that anyone knew how to use that yet :blink:

 

[gfoot]

paeryn figured it out The stuff in Allegro is totally based on his code in SDL.

 

[Gridmark]

for the more adventurous, how to build the library yourself.

Source patched cleanly

patch -p0 < gp2xallegro-03.diff

Compiled cleanly with the following configure options (devkitPro/devkitGP2X under Linux). Will try compiling a few test apps and seeing how they run.

CC="arm-linux-gcc" CPP="arm-linux-gcc -E"  ./configure --host=x86_64-unknown-linux --target=arm-linux --prefix=/home/gp2x/devkitPro/devkitGP2X --without-x --enable-static=yes --enable-lgp2x=yes --enable-staticprog=yes --disable-mmx --disable-sse --disable-xim --disable-xwin-dga --disable-xwin-xcursor --disable-xwin-shm --disable-xwin-vidmode && make && make install

Thanks again gfoot, you are a credit to this community.

 

[gfoot]

Yes, it's fairly straightforward really. A lot of people still don't like building things themselves, though, as sometimes it's not so easy, and when things fail it's quite intimidating.

However, I'd suggest using the configure options I specified at http://www.glost.eclipse.co.uk/gfoot/gp2x/...building.html... in particular, you ought to use "--host arm-linux" and not specify --target. --host is the machine the binaries will run on, --target is the machine the binaries will generate code for - and is only used when building compilers etc.

If you do try it, please let me know if those options don't work with devkitGP2X. I use open2x but they still ought to work fine.

 

[JyCet]

Hi,

For all i build with allegro v0.3 i've black screen
No error at compilation.

Here a simple hello word:

#include <allegro.h>

int main() {
	allegro_init();
	set_gfx_mode(GFX_AUTODETECT, 320, 240, 0, 0); 
	clear_to_color(screen, makecol(0, 0, 0));
	textout_centre_ex(screen, font, "hello word", 100, 0, makecol(255,255,255), -1);
	for(;;)
	{
	}
	return 0;
}
END_OF_MAIN();

Today i find another person which have the same pb ... black screen

 

[luteijn]

Hi,

For all i build with allegro v0.3 i've black screen
No error at compilation.

Based on the information (not) given, I would guess the binary to not be statically linked.

It would be easier to say something helpful if you'd post your compiler settings, the output of the 'file' command and/or stdout&stderr (if any) from your program..

also, maybe you ought to fill the screen with a different color, in case things half work?

Maybe also just 'sleep (5)' instead of the infinite loop?
run the program from a script to easily redirect output and call the menu back up after exiting.

P.

 

[JyCet]

The allegro library is statically linked
I didn't change anything in gp2x-allegro-config file and inside it's configurate to be statically linked (line 19: static_libs=yes)

According to gfoot, his parallax demo dont need anything to work on gp2x but it doesnt work on mine

EDIT:
I use devkitGP2X and my makefile is here

PROG_NAME = hello_word
OBJS = hello.o
CROSS_COMPILE = C:/devkitPro/devkitGP2X/bin/arm-linux-
SDL_BASE = C:/devkitPro/devkitGP2X/bin/gp2x-allegro-config
LDFLAGS = -static

CC = $(CROSS_COMPILE)gcc
CXX = $(CROSS_COMPILE)g++
STRIP = $(CROSS_COMPILE)strip
CLEANUP = rm -f $(ALL_TARGETS) *.o *~
GPECOMP = gpecomp $(PROG_NAME).gpi $(PROG_NAME).gpe

CFLAGS = `$(SDL_BASE) --cflags` -O2 -Wall -Werror
CXXFLAGS = `$(SDL_BASE) --cflags` -O2 -Wall -Werror
LIBS = `$(SDL_BASE) --libs`

TARGET = $(PROG_NAME).gpi
SDLTEST_OBJS = $(OBJS)

all : $(TARGET)

$(TARGET) : $(SDLTEST_OBJS)
	$(CXX) $(LDFLAGS) -o $(TARGET) $(SDLTEST_OBJS) $(LIBS)
	$(STRIP) $(TARGET)
	$(GPECOMP)
	$(CLEANUP)

 

[gfoot]

Based on the debug tests you did for me, it's the hardware clear-to-color routine that fails (which is called internally in set_gfx_mode). I don't really see why it would work on my gp2x but not yours though.

 

[anatagp]

hello

i have the same problem, a black screen

the same program , compiled with the last allegro, and black screen.

 

[luteijn]

I've put (almost) the same test program together on my linux machine; I'm not using a makefile, just a oneliner to compile it, to make sure everything is set the way I want, and it can be easily reproduced. Using the libs from the file archive, but including checksums below, maybe they're no good?

luteijn@dollar:~/devel/gp2x/atest$ cat hello.c
#include <allegro.h>

int main(int argc, char ** argv) {
allegro_init();
set_gfx_mode(GFX_AUTODETECT, 320, 240, 0, 0);
clear_to_color(screen, makecol(255, 0, 0));
textout_centre_ex(screen, font, "hello word", 100, 0, makecol(255,255,255), -1);
sleep(10);
return 0;
}
luteijn@dollar:~/devel/gp2x/atest$ /opt/local/gp2x/bin/arm-linux-gcc --version
arm-linux-gcc (GCC) 4.0.2
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

luteijn@dollar:~/devel/gp2x/atest$ ls -l ../allegrov0.3/lib/
total 4880
-rw-r--r--  1 luteijn luteijn 3533200 2006-01-03 20:33 liballd.a
-rw-r--r--  1 luteijn luteijn 1452348 2006-01-03 20:33 liballeg.a
luteijn@dollar:~/devel/gp2x/atest$ cksum ../allegrov0.3/lib/*
2818701954 3533200 ../allegrov0.3/lib/liballd.a
2374036748 1452348 ../allegrov0.3/lib/liballeg.a
luteijn@dollar:~/devel/gp2x/atest$ /opt/local/gp2x/bin/arm-linux-gcc -static -g -I../allegrov0.3/include -L../allegrov0.3/lib -L /opt/local/gp2x/lib/ hello.c -o hello.gpe -lalleg -lpthread -lm -Wall
luteijn@dollar:~/devel/gp2x/atest$ file hello.gpe
hello.gpe: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, statically linked, not stripped
luteijn@dollar:~/devel/gp2x/atest$ ls -l hello.gpe
4216 -rwxr-xr-x   1 luteijn luteijn 4301938 2006-01-08 08:59 hello.gpe

Copied .gpe and .c over to sd card, fired up gp2x, connected to bash over usb, ran screen, then:

sh-2.05a# ./hello.gpe

Black screen on gp2x, so I press ctrl-C at this point.

Shutting down Allegro due to signal #2

sh-2.05a#

Now to try and find out what's going on, I ran it in gdb, and yes, it goes past the init, and seems to get in a loop when the mode is set. Haven't got thread debugging worknig properly , so I can't see what's going on but sending interrupt signal breaks the program in gp2x_gfx_rectfill_worker():

Program received signal SIGINT, Interrupt.
0x00048594 in gp2x_gfx_rectfill_worker ()

Maybe this is helpful anyway?

 

[gfoot]

That's where I got to - I think it's just getting stuck waiting for the hardware blitter to not be active. It's not a compilation error because it works on my gp2x - if the compiler was "optimising" the register reading out of the loop it wouldn't work for me, I think?

I'll double-check the code later. It would be really cool if you could have a play yourself though, since you're set up in linux and can build it yourself - the relevant code is in src/gp2x/gp2x_gfx.c!

Two other thoughts spring to mind - Allegro's routines wait for the blitter to be inactive before returning, which means the waits on entry are not necessary, except right on startup. We could probably do a dummy blit without the prewait, just to force the blitter through an inactive->active cycle. I dunno though, it doesn't make much sense.

 

[luteijn]

My biggest problem is lack of a proper timeslot to work on things; I do have small blocks of time in between work and RL-obligations that I can use to read the forum, but no 4 hour block to sit down and get something _done_ in one session... I'll try to build the lib myself, although it will probably mean I'll be trashing whatever is the RL equivalent of cache and swapfile, swapping this task in and out...



P.

 

[luteijn]

No positive results to report so far:
compiled allegro-4.2.0 with gfoot patches. compiled and linked the hello.c source again: (using debug version of the lib

luteijn@dollar:~/devel/gp2x/atest$ /opt/local/gp2x/bin/arm-linux-gcc -static -g -I../allegro-4.2.0/include -L../allegro-4.2.0/lib/unix -L /opt/local/gp2x/lib/ hello.c -o hello.gpe -lalld -lpthread -lm -Wall

again black screen:

Program received signal SIGINT, Interrupt.
mmsp2_waitidle () at ./src/gp2x/gp2x_gfx.c:76

I'm using version 1.1.0 of the firmware, I think I have installed those sdl libs for NK-games, but before the HW accelartion was 'figured out'.

gfoot, does your program work on a freshly rebooted gp2x? Maybe the blitter needs some more initialization, which it might get from anything run before this hello.c using the blitter (modified sdl libs invoked by the menu program, maybe)


P.

 

[luteijn]

I bluntly commented out the while loop to wait until ready from the library function... No more hangup, the text is actually drawn, although the clearing to red is not working properly, just a few rows are filled at the top of the screen (with clear to black this wouldn't have been noticable!).

P.

 

[gfoot]

Hmm, I've been testing only on firmware 1.1.0, maybe the version matters. JyCet reported his problems before the 1.2.0 release, so I guess it's not related to that.

I know what you mean about RL - I've got a one month old baby here, so plenty of obligations there.

Commenting out the loop would make it not wait for the previous blit to finish before starting the next one, so yes, you'd get partial results. Try commenting out all the calls to the waitidle function which occur before writing the status register - i.e. the start of the dummy_blit routine, the first two calls in gp2x_gfx_rectfill_worker (leaving the one at the end), and similarly the first two calls in gp2x_gfx_blit_to_self_worker. It ought to be safe to not wait in these cases... fingers crossed.

 

[luteijn]

Mine is two months old... I'll see if there's some free time between tasks at work to fit in some more fiddling with the library code.