Allegro


F

fogobogo

Still Fresh
Joined
Mar 23, 2009
Messages
16
Hello,

I want to ask if anyone knows whether the allegro library will be available. I tried the Angstrom package browser but it seems there is nothing. Google wasn't really helpful either. It seems there is an ARM port on debian though, would be nice if anyone with a beagleboard/devboard could try a build. Please keep the guesswork to a minimum, thanks.
 
I don't know of a version, but if there isn't one and no-one is working on one I'll look into it. I've not used Allegro for over 14 years - back on the Amiga I think - I'm sure it was while I was at uni, and definately not after about a year from finishing.

If no-one replys saying it's being worked on in the next few days I'll start - I have a beagleboard (albeit an old B5 with only 128MB) which is equivalent enough (in regards that I can alter any differences (input/audio) when my Pandora arrives).

External factors (work & depression) limit my time but there shouldn't be too much to alter seeing as the 3530 doesn't have any 2D acceleration (it's faster to use NEON/DSP than via the 3D in most cases - AFAIK NEON is effectively a co-processor with it's instruction set embedded in ARM code, and if the DSP isn't in use it can be set up to do 2D blits, fills and lines in parallel). Although I'm looking to use the DSP for audio/video decoding.
 
Yes, the speed of the whole thing might get an issue too, as it looks like the DSP is the guy sitting in the same room but never talks or does anything. NEON might be able to speed up some operations though. I've noticed there is an port for the gp2x and there is indeed a Debian package for allegro. Thanks for the effort by the way.
 
Apologies to all for the thread necromancy*, but I'm actually beginning work on this now (for A4, not ready to attempt A5 yet)...

I know that at least the joystick code will have to be rewritten - ljoy.c seems to expect to be able to just read /dev/js<joystick_num> rather than the event interface (as documented on http://pandorawiki.org/Kernel_interface ), and, ideally, we should make use of the hardware scaling for games that run full-screen at 320x240, but other than that, it looks like we might be just one makefile away.

I'll report back after lunch with the results, good or bad. Please bear in mind that I am a completely talentless newbie, so it might take a few tries to get right.

*It seemed more polite than spawning a new thread.
 
Okay, I've finally had a chance to do some work on this. Here's what I know so far:

With 4.2.3.1, compiling with Stuckie's toolchain-in-a-pnd:
  • 'configure' was run with the options --disable-color8 --enable-static --disable-shared --without-x
  • Although 'configure' seemed to be able to tell that we're on a little-endian machine and to find stdint.h, it is failing to set some vital bits in alconfig.h, so when we get to actual compilation, it fails miserably. (I got around this by manually #define-ing ALLEGRO_LITTLE_ENDIAN and the various uint_t<blah> types, but this really should be done the right way)
  • There are several places where 'configure' tries to set permissions to something, but can't and errors out; perhaps this is a result of me working on a FAT-formatted SD card?

I was able to comment or hardcode most of these out of existence and get the dependency generation to finish, but I have yet to 'make' all the way) - there are some problems with ufile.c and lmouse.c. I'm at work at the moment and can't look at the unit, but I'll post the actual errors after lunch.

4.3.11 and 4.4.1 didn't seem to work at all - 'configure' got confused too badly.
 
paeryn said:
seeing as the 3530 doesn't have any 2D acceleration
Click to expand...

You can use DMA to perform 2D blits, with optional color keying and enough stride support to perform multiple of 90 degree rotations and flip/mirror. Not a real feature set for graphics (forget arbitrary scaling, rotation, and blending) but it's enough to get you the basics w/o tying up the CPU. But I don't know what Allegro supports for setting up blits asynchronously - SDL doesn't have some kind of support for this - still, if you put a thread to sleep while you wait for the blit to finish then maybe you can gain back a little having the blits in another thread.

Since DMA sits straight on the L3 interconnect and doesn't have to go through any cache subsystems and instruction issue it might have higher throughput than software routines on the CPU or DSP. On the other hand, if your source material stays in L2 cache it'll be faster in NEON. I don't think using the DSP to offload is ever that great of an option until you start doing math on the graphics, and then SGX might be a better option. Does Allegro have support for 3D backends?
 
Last edited by a moderator:
Hi Exophase,

I don't know how to implement what you're proposing (yet!), although it does look like draw_sprite(), blit() and masked_blit() would benefit from those, and that might be plenty of acceleration for a lot of games.

Regarding 3D backends, A4* does not, although there is AllegroGL which lets one use 'desktop' GL for drawing and Allegro for everything else, which I had planned to attempt reworking to be GLES-friendly if I ever got Allegro itself working.

*Allegro 5 does, but it isn't a drop-in replacement for Allegro 4 and isn't finished yet, as far as I know.
 
Okay, I see what's happening - some settings from 'configure' aren't getting carried over, although it isn't clear why yet. Things like ALLEGRO_HAVE_DIRENT_H and ALLEGRO_HAVE_SYS_TIME_H aren't getting #defined somehow, but it looks like one can work around this for now by manually defining them and/or forcibly including the appropriate headers oneself.

The next problem area is usigalrm.c, and I'd be willing to bet it's the same kind of problem.

I have time for one last stab at this before I have to go back to the salt mines for the afternoon, hopefully I'll have a little luck here.

EDIT: Same kind of problem - the officially-blessed way to do what the functions in this file do is via libpthread, but ALLEGRO_HAVE_LIBPTHREAD isn't #defined, even though 'configure' picks up on its presence.

EDIT #2: I just had a look at makefile.dep, and it looks like a lot of options 'configure' chose didn't take (huh, that's weird). I have to go back to $HORRID_DAY_JOB for now, but it looks like we are -very- close to having a (completely unusable rough-cut) build of Allegro 4.2 :) . If I get it working later today, I'll post complete setup steps.
 
el_pango said:
Okay, I see what's happening - some settings from 'configure' aren't getting carried over, although it isn't clear why yet. Things like ALLEGRO_HAVE_DIRENT_H and ALLEGRO_HAVE_SYS_TIME_H aren't getting #defined somehow, but it looks like one can work around this for now by manually defining them and/or forcibly including the appropriate headers oneself.
Click to expand...

Good news: I have gotten it to compile successfully, including everything in /examples, dat2s and the grabber.

Bad news: it doesn't seem to be able to set a graphics mode (maybe something weird in fbcon.c or I somehow made a mess of things when trying to sort out the autoconfig issues), and I don't seem to get any error output or anything from the examples.

I'll work on this some more tonight, but if someone on here with a linux-hosted build environment and a little more experience has the time and/or inclination to do so, can you grab Allegro 4.2.3.1 from http://alleg.sf.net/ and see if 'configure'ing produces correct results on your end?

...so close.
 
Last edited by a moderator:
I'm just waiting for this to try to compile Zelda Classic for the Pandora :D
 
Hitnrun said:
I'm just waiting for this to try to compile Zelda Classic for the Pandora :D
Click to expand...

Oh, you got the sourcecode?
Are you the one that made the GP2X port? I forgot who it was - but it was one of those ports I was always waiting for. :D
 
Last edited:
EvilDragon said:
Hitnrun said:
I'm just waiting for this to try to compile Zelda Classic for the Pandora :D
Click to expand...

Oh, you got the sourcecode?
Are you the one that made the GP2X port? I forgot who it was - but it was one of those ports I was always waiting for. :D
Click to expand...

? Isn't ZC Open-Source? I'm still waiting for OpenZelda 7 to get completed so that we can work on getting a port of that. :D

-God Ginrai
 
Last edited by a moderator:
Hitnrun said:
I'm just waiting for this to try to compile Zelda Classic for the Pandora :D
Click to expand...
That would be nice. Only thing that actually interests me about Allegro on Pandora. :)
 
Last edited by a moderator:
EvilDragon said:
Hitnrun said:
I'm just waiting for this to try to compile Zelda Classic for the Pandora :D
Click to expand...

Oh, you got the sourcecode?
Are you the one that made the GP2X port? I forgot who it was - but it was one of those ports I was always waiting for. :D
Click to expand...

Yes it was me who did it on the gp2x. Now doing it on the Pandora.
The source is closed, but it is available on a lot of torrent sites. Even so, I asked the Zelda Classic developers before making any release.

I must say that it is already running on my Pandora :)
 
Last edited by a moderator:
Was there any problem compiling Allegro for the Pandora? I just compiled 4.4.1 which uses CMake, and it compiled easily. And it works, Zelda Classic is already running with it.
 
very good news, thanks !

EDIT: did you succeed to enable the fullscreen mode using this allegro version ? (it doesn't seem to work for me ...)

EDIT2: It works fine, it's only that i had to put the window in fullscreen using Alt+Space
 
You must log in or register to reply here.

Similar threads

G
GP2X Allegro Patches For Gp2x
Replies
4
Views
3K
paeryn
paeryn
E
Help With Autoconfig And Allegro 4
Replies
2
Views
831
el_pango
E
Miner49er
GP32 Bombjack Emulator
Replies
15
Views
2K
fdave
F
D
Looking For Oe
Replies
4
Views
2K
drumpi
D
M
Pandora Opengl Es 2.0 Header And Libraries For The Pandora
Replies
6
Views
1K
lulzfish
lulzfish
Back
Top