Wow! This looks like a reeeeally nice library. Much nicer than SDL. I can't wait to get dug into the API and try some stuff out :-)

Any ideas how fast it will be for blitting full screen/double buffered/lots of sprites etc at relatively high resolution? The reason I stopped with my current project was because SDL was simply too slooooow. I hope that I'll be able to do some much better stuff with Allegro. I'm really excited about the potential here.

joephish: thanks. About speed, Allegro gives you direct access to the screen in fullscreen mode, so if you want double buffering you have to code it yourself. It's not hard though: check the demo game, it allows you to choose among several screen updating techniques (double buffering, page flipping, triple buffering (not available on OSX) and dirty rectangles).

For any question/comments/suggestions/whatever you're all welcome to join the mailing lists (more info on the Allegro homepage here) or better to come on the #allegro IRC channel on EFnet, or simply use the forums on allegro.cc, where most of the Allegro developers hang.

I get the same error with the plugins.h file, however the library and some (most?) of the test programs are compiled by that point so it isn't a great problem at the moment (though it really needs to be fixed).

Could someone please tell me why the test application (in the tests directory) uses roughly 5% of my CPU time when it isn't doing any more than displaying a window with static contents?

To Feanor and Athomson: running "make depend" before "make" should solve the issue.

This will not be needed in the official releases (both Work In Progress versions and final versions); remember this is still a CVS snapshot you are testing...

The compile process should go painlessly if you do this in sequence in a clean CVS snapshot:

./fix.sh macosx
make depend
make
sudo make install
sudo make install-framework
sudo make install-template

And aftet this, if you want to create an application bundle for the demo program, use

make fixdemo

That's all you need to compile/install the current Allegro CVS snapshot. As already said, the process will be the same in official versions, except for the fact you'll not need the "make depend" step.

To ClosetPacifist: are you telling me gcc isn't available on the Dev Tools for OSX 10.1.x? I have no clue on how you could solve the thing if gcc is not there, sorry...

To Athomson: the 5% CPU usage could depend on several factors. Allegro is multithreaded under OSX, and while the user app runs in a thread, another thread fetches system events and updates the window as many times per second as the current refresh rate (of course only dirty areas are updated, but still if you move the mouse the area around it will need to be redrawn). So assuming your refresh rate is 70, the events handling/window updater thread will sleep for 1000/70 milliseconds each time... Then you have to consider how much the user app thread sleeps; most Allegro apps make sure they sleep sufficiently when there is little activity, but still you get some CPU usage.
I don't think this is a problem though... Even Safari, opened on this reply page takes 10-15% CPU...

Quote:Originally posted by lillo To ClosetPacifist: are you telling me gcc isn't available on the Dev Tools for OSX 10.1.x? I have no clue on how you could solve the thing if gcc is not there, sorry...

gcc is not called gcc in the 10.1.x dev tools, it's called cc. I believe the last set of 10.1.x dev tools (april?) finally called it gcc. It's 2.95 by default, but you can use gcc_select to switch to a beta of 3.1. Certainly in the last 10.1.x dev tools the gcc2 and gcc3 commands were present; these still work in 10.2 so it might be worthwhile changing the makefile to always use the gcc3 command...

Moreover, though I am a dolt with make, I know that you can make a variable for gcc and set it to cc on OS X if version is prior to 10.2 -- heck, cc is an alias for gcc, so it still works for backward compatibility.

Quote:Originally posted by lillo To Feanor and Athomson: running "make depend" before "make" should solve the issue.

OK, that did it. I did not see that in the build instructions. Anyway the fixdemo command doesn't work for me -- ah, and the demo won't run, either; it can't find demo.dat. Cleaning the project wouldn't delete the demo.dat file, I hope. Well, I'll report back in a few days after I have tried something out.

You can easily change this.
Open makefile.osx, and on the very beginning of the file you'll find

CC = gcc

Change this to suit your needs and it should work.
I'll update the CVS snapshot to always use gcc3, thanks for the clarification. I hope gcc3, at least as symbolic link, will still be present in future Dev Tools releases!

"The port is already "lightyears" ahead of SDL". Could someone please explain how the port is ahead of SDL if at all? Last time I used allegro for OS X(maybe a month ago) it was a cheapo xwindows port and didnt even support fullscreen. Also SDL with glSDL supports fully hardware accelerated blits. So in what ways is the allegro port ahead?
thanks

It had fullscreen, and everything I saw was easily on par with SDL. What was superior (that I saw) was that it had a lot more built in stuff like rotation/scaling of bitmaps built in (?) And from the API it has loads more functions and stuff. Sorry, this is really vague, but I just get the impression that it's just got more to it.

I don't know about speed yet really, but from what I saw it was pretty good - full screen 1024x768, double buffering and lots of sprites was 60-100fps. Quite a lot faster than what I've seen in SDL!

I may be wrong though, these are just the impressions I got from playing around with it for about 1/2 hour.