Here: http://sourceforge.net/project/showfiles.php?group_id=5665&package_id=40805&release_id=645744

[EDIT] MSVC/Windows users should get 4.9.7.1 here:
http://sourceforge.net/project/showfiles.php?group_id=5665&package_id=40805&release_id=645947

Note there is a known minor problem with the ex_blend2 example on X.

It doesn't show up in Windows? Weird.
It does show up in OS X as well, so I just assumed it was a general problem that showed up everywhere.

It does. It's a general OpenGl problem.

Awesome! So two more releases and then 5.0 will be out? At this rate that will be in March 2009?

4.9.9 + 0.0.1 = 4.9.10

Nope, at that point we'll hit 4.9.10.
We'll hit 5.0 when all features are implemented on all platforms (getting there), all standard addons are present and functioning (getting there too), after several rounds of bug fixing (loads of that going on) and after the documentation is somewhat comparable to the 4.2 documentation (I don't think it'll be quite up to that level initially; the 4.2 documentation is the result of more than 10 years of improvement, but it should be usable).
So it's coming, but it's done when it's done.

That entirely depends on the rate at which some things will get done. Things tend to speed up and move quickly and then slow down again for a while. It's hard to predict.
There is a target date that's been discussed. You'll find out what it is if we meet it.

Yeah, I really need to get the fs docs done and the X multi monitor stuff as well The good news is nvidia might get XRandR 1.2 support before we have to release. Which would be nice.

For those who would prefer binaries for Windows, I have MinGW files up at http://www.allegro5.org. MSVC files will come soon.

Is it safe for Allegro# to start targeting A5 yet?

I hate to hazard a guess, but I'd have to say yes. I don't see any obvious large changes coming. Maybe additions, maybe some removals, but no large wholesale changes of the api.

Probably. The big API change this time round is the renaming of functions in the kcm_audio addon, there might be a few more but there shouldn't be too many major changes coming up. If you're fine with possibly having to redo some minor things like that I don't see why you couldn't get started.

Trying to build it with msvc, I get some errors from kcm_audio:

Anyone know what this is about?

It seems to not be linking in kcm_dtor. That's a new file, I think, but not sure what would cause it to be included for MinGW but not MSVC.

I think you need to add aintern_dtor.h to misc/scanexp.c and rerun fixdll.

If that's the only problem I'll release 4.9.7.1 later.

Sorry for the delay. That fixed it. Cheers.

My first Allegro 5 game:

{"name":"597251","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/5\/c55173368bd27bf0b0a0a5b2e1271a7f.png","w":656,"h":516,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/5\/c55173368bd27bf0b0a0a5b2e1271a7f"}

What's the status of the drawing primitives? There didn't seem to be any filled polygon routine, so I wrote my own outline polygon function by piecing al_draw_line()s together.

If you need a filled polygon, use GL its natively supported.

Or wait a bit, the next release should have some allegro api like functions for primitives. Everyone is pressuring SiegeLord as much as they dare to at least get what he has in svn, so others can start looking at it.

edit: Can you post source for the speed a5 port? I'd like to see how it plays on my desktop and laptop

Should be listed here: http://wiki.allegro.cc/index.php?title=NewAPI/Primitives#Status

I guess it might be useful to contribute code for that; best to ask SiegeLord though, he's doing the primitives addon.

http://wiki.allegro.cc/index.php?title=NewAPI/Primitives#Status
I'm working on it!

EDIT:
I wasn't planning on making general polygon routines, sort of planning on telling the user to triangulize the outline himself and then use triangles. This might be useful, I guess.

Actually, if someone has the time, a set of tessellation functions may prove very useful to many Allegro 5 users. That way no-one has to depend on glut or d3dex stuff directly (or at all).

I have a piece of code somewhere that computes the Voronoi tessellation for a collection of points; one of the intermediate steps is to compute the triangulation of a graph. I don't know how well-written that piece of code is (it might be horrible for all I can remember), but if someone thinks they have a use for it as something to get started on, let me know.

I think all of Allegro 4's drawing primitives are useful enough to be included in either the base distribution or as a bundled add-on.

Some other notes converting Speed to A5:

Window resizing works great (a little lagged) in OpenGL, fails in D3D.

Is there any default font with the font add-on or must you load one from file?

Can I manipulate voices / samples as with Allegro 4? Basically I need to create a few samples (e.g. saw or sine wave), and then play them back at different frequencies to get different notes.

It looks like everything (regarding to sound) is implemented based on a quick look at the documentation, but I don't want to get started if it won't work.

No default font, you'll have to load one from file.

Should work, I think. Have a look at ex_saw.c
However - the method for getting/setting the frequency (or other sound-related settings) is still on the list of API changes to be made.

What do you mean by that? al_resize display or dragging a resizable window? Do ex_multiwin, ex_resize, and ex_resize2 also crash? If so what do you get in allegro.log when linking with a debug lib?

Those programs don't crash. SPEED works if I don't acknowledge the resize event, but then it just stretches without updating the resolution.

If I acknowledge it, the screen stops updating and the Visual Studio log says "The thread 'Win32 Thread' (0xe5c) has exited with code 0 (0x0)."

ALLEGRO_SYSTEM_INTERFACE created.
al-winput INFO: Input thread started.
Render-to-texture: 1
faux_fullscreen=0
Normal window
BeginScene succeeded in create_device
Success
_al_d3d_sync_bitmap (system) ref count == 1
_al_d3d_sync_bitmap (video) ref count == 2
_al_d3d_sync_bitmap (system) ref count == 1
_al_d3d_sync_bitmap (video) ref count == 1
d3d display thread exits
calling dtor for object 02278A38, func 10022030
calling dtor for object 04930DF0, func 10022030
al-winput INFO: Input thread quit request was sent.
al-winput INFO: Input thread closed.

Can CMAKE be set up to have MSVC build the pdb files? Right now the "debug" Allegro libraries are built with optimizations enabled and debug mode off.

Got the SVN version tonight and ran the examples. Everything worked fine on my iMac 3.06/OS X 10.5.5 box (er... flat slab). I had no problems with the new examples: kcm audio, keyboard state (don't really know what it was doing even after looking at the code , resize2, config, or blend2 (ran the sliders in all situations).

Great stuff guys!

-Paul

Edit: dumb question: can I use the new TTF routines within an OpenGL context?

One thing you could try very quickly is to set the CMAKE_BUILD_TYPE variable to "Debug". This uses the CMake native support for build types, rather than the thing we hacked together ourselves (which emulates the A4 system which lets you build multiple configurations with a single configuration step, but was only done properly for gcc flags).

Matthew, can you send me the sources and I'll try to debug it if I have time?

The latest changes to SVN fixed it.

Is the D3D additive blender hardware accelerated? With the OpenGL driver, I get 1800 FPS at 640x480 fullscreen under Vista. But with D3D, I only get around 275. Windowed mode is similar.

I got 600/1100 D3D/OpenGL on my desktop. Not sure why D3D is slower. All blending modes should be accelerated. The draw_line functions are almost identical between D3D and OpenGL. Also not sure why but it crashes in OpenGL mode on my laptop.

Probably bad OpenGL drivers by your video card. Happens to me as well, it has an ATI chipset. I haven't tried it on my nVidia card yet.

none of the audio examples are working on linux.

getting these errors:

Using ALSA driver
Could not create ALLEGRO_VOICE.

Using ALSA driver
Could not set up voice and mixer.

here is the cmake result:

In allegro.cfg you can choose another audio driver.
There should be some info on the failure in allegro.log. Also you can run a debugger and see where it fails exactly.

these functions:

al_setup_simple_audio(RESERVED_SAMPLES);

al_create_voice(44100, ALLEEGRO_AUDIO_DEPTH_INT16, ALLEGRO_CHANNEL_CONF_2);

[EDIT]
nevermind.
worked after dowload and install the new version of ALSA.

Why does linking the demo fail under Ubuntu during 'make'?

system_new.c: undefined reference to `_al_register_system_interfaces`

Is there a way to determine that foreground display window? Last I checked, you could do it by reading the keyboard state. I still stand by my opinion that that is a terrible API decision.

I got it working after installing close to fifty development libraries, none of which were ever explicitly named as being required in any place that I could find.

It mostly works. The biggest problem is that none of the windows as created by Allegro have frames...

You could always catch the switch-in/switch-out events.

You can - which makes semantic sense if what you want to know which window is receiving the key presses. If you want to know for whatever other reason, no, it doesn't make sense (presumably the mouse state has a similar field that tells you what display the mouse is on, but I've never checked this personally; if it doesn't have that it probably should have).

EDIT:

Care to mention what they are so we can mention them in the future?

Huh?
That one I haven't heard before.

I don't know which ones they were. I kept installing libraries until it worked...

The first error (linker) was due to libx11-dev missing. I only knew that because of past experience with Allegro 4. There was no warning that no systems were detected.

Then once I installed that, cmake told me that OpenGL was required. At that point, it was just downloading dozens of libraries as recommended by Google. Eventually it stopped complaining and compiled.

I'd take a screenshot, but it's self explanatory. Just the inside of the window is shown. No window title, frame, etc.

Edit: It only happens when compiz is enabled.

I bet they included some of these:

libc6 (>= 2.4)
libx11-6
libx11-dev
libxcursor-dev
libxcursor1 (>> 1.1.2)
libxext-dev
libxext6
libxpm-dev
libxpm4
libxxf86vm-dev
libxxf86vm1

Many of those libraries are supposed to be optional, which is why we don't just abort when they aren't detected. Even X11 would be optional, if we had a non-X11 backend for Unix (not any more). But okay, I'll try to stick in some warnings.

EDIT: Ok, now it will give a fatal error if X11 is missing and a warning if XF86VidMode is missing. We already aborted if Xcursor is missing. Xext and Xpm don't seem to be used any more. Anything else?

EDIT2: now also warns about JPG, PNG, FreeType, etc. if missing and the WANT_* option is enabled.

I had to do a couple: build-essentials is the first for any debian-derivative, which is a meta that is pretty much essential for everything. Then I had to do the xcursor one and some others required for the addons.

build-essentials as CGame's said, and xorg-dev are two packages you want for allegro on a Debian based distro.

And then some extras for the addons like libpng-dev, libjpeg-dev, libasound-dev, etc.

I can confirm that.

So Compiz is broken, good to know, but was already aware of that fact. Works fine in Kwin4 with its compositing enabled.

Making a compositor is easy. Making a Full window manager is hard. Compiz took the long way around.

Or Allegro is broken, since no other applications exhibit the same behavior.

Please read my entire message. Compiz is known to be buggy, and still isn't a full window manager yet.

KWin4 just works. So its obviously Compiz's shortcomings causing this. We don't need to work around another project's bugs.

edit: someone at the very least should figure out what it is that Compiz doesn't like that KWin4 has no problems with, and report it to the Compiz dev team.

Searching for "compiz glut" shows other people having similar problems. I'm not going to do any further research, but that's where the disconnect appears to be.

I wasn't aware we used glut. I know we don't use it's window creation or input callbacks. So I really don't think its glut's or allegro's fault. Seems more like a bug with compiz than it did before.

I've used other OpenGL applications with Compiz before without problems, so I wouldn't dismiss it as Compiz's fault right away, even though it probably is.

I was only partially sure it was a compiz issue on the first report, but with glut causing issues as well? I'm pretty sure now.

Just tested the released 4.9.7.1 with these results on my iMac/3.06Ghz/Intel/2GB/NVIDIA GeForce 8800 GS machine:

- ex_fs_resize buggered my desktop icon placement (squished them up).

- ex_mouse_cursor has no different cursor for keys 1, 2, or 3

- ex_ttf - when I substituted a fix-ed width font (monaco) the letters were unusually wide apart.

- ex_noframe[4291] *** Assertion failure in -[ALWindow _changeJustMain], /SourceCache/AppKit/AppKit-949.43/AppKit.subproj/NSWindow.m:8598
[4291] Invalid parameter not satisfying: [self canBecomeMainWindow] 12/16/08

- ex_threads[4309] *** _NSAutoreleaseNoPool(): Object 0x1aeea0 of class NSConcreteValue autoreleased with no pool in place - just leaking (x 5)

- ex_winfull did not work at all

I think my last testing focussed on the new stuff so I didn't check the whole WIP.

Serious question: I am converting an old flight simulator of mine to use OpenGL and wanted to avoid using a bunch of different libraries for text/image-loading/saving/sound which is why A5 is so appealing to me. However, in the few tests that I have done, it is not clear to me that I can use those Allegro routines within an OpenGL context (my quick experiment with the TTF addon and OpenGL failed). Is there a simple way to incorporate the new text and image routines within OpenGL?

Thanks for your hard work!

-- Paul

I don't think fullscreen resize (on OS X) worked at all at the time the WIP came out; it works in current SVN though.

Cursors 2 and 3 are the "busy" and "question" cursors if I recall correctly. OS X has no separate cursors for either of those.

Weird. That's something that someone should try to reproduce on another platform as well.

Ah! Yes, I noticed those too, but forgot to comment on them. Thanks for pointing them out again.

It should be fixed in current SVN.

Here's what it looks like on my Linux machine. Is that how it looks for you?

I also noticed for DejaVu Sans Mono (and also DejaVu Sans) that there are extraneous dots at the bottom right of some words. Any ideas?

There will be a function to directly get the OpenGL texture id from an Allegro bitmap, so image loading for use in OpenGL should be very easy. You can of course always get the contents of a bitmap as RGBA data and pass to glTexImage to transfer to an OpenGL texture, that's also only a single line of code.

As for TTF, someone was working on a TTF renderer which renders to triangles - I think it would be really nice to have one or two OpenGL specific functions who translate directly to OpenGL shapes. Or maybe we can be even more advanced and have some kind of callback mechanism where the callback gets passed triangle data for a glyph, so you could easily make things like a vertex array version or even DirectX version for glyph rendering. In any case, need to wait for the triangle-font addon to be done.

With the bitmap-based ttf addon, I'm not sure how to expose the internal data. Could maybe also have some kind of glyph-rendering callback:

void opengl_callback(float x, y, int gl_texture_id, x, y, w, h)

And for each glyph to render, the callback would be passed the coordinates, the OpenGL texture and the rectangle within the texture where a rendering of the glyph is cached.

EDIT:

Fixed in SVN. When the change was made to cache multiple glyphs in one texture, they were put a bit too close together. (Or alternatively, there's some clipping bug which allowed overwriting neighbor glyphs. Adding a 2 pixel space between glyphs fixed it in any case.)

I guess that would work the other way too: get an OpenGL rendering to RGBA data and make a bitmap of it for conversion to an image file for saving?

Perhaps for the TTF rendering of canned strings, I could make bitmaps of the text I need, then pass the RGBA version as an OpenGL texture? For I/O I suppose doing the same thing on the fly would be more expensive, but in my sim at least, there is no need for speed when asking for text input from the user. I'll try that as an interim solution... thanks.

--Paul

When?

Is this a different one from the drawing primitives addon? Hoe many planned addons are still missing? I thought the list was just

• Drawing primitives addon (SiegeLord)

• A4 compatibility layer (I'm working on this)

are there more?

Maybe it's there already. Otherwise the function would be quite simple, something like:

int al_opengl_get_texture_id(ALLEGRO_BITMAP *bitmap)
{
   return bitmap->opengl_texture;
}

Well, I was thinking of Thomas Harte's font rendering code..

I tried a bunch of other mono fonts and none of them exhibited that wide spacing. Must have been my monaco.ttf file.

--Paul

Could be. I tried on my Mac and I got the same output as Peter.
I think there are two versions of monaco.ttf floating around: one that works in Linux, one that works in Windows (go figure). Do you have any idea which one you have?
Attached is the one I have, which is the one that works on Linux.

I downloaded a Monaco_Linux.ttf file (I don't get the forum through my e-mail) and the spacing problem was resolved (although the 12 point font was messed up). ex_ttf seems to work fine with proper .ttf files though.

--Paul

Oh? Do you have a screenshot?
Also note that you don't need e-mail for attachments from the forum (I'm not even sure you can still post to the forum by replying to e-mails... used to be possible).

It's probably a problem with FreeType, which is what Linux and Allegro both use to handle .ttf files.

Additional:

Ok, I'll check.

Ah, right! Sounds good.

I used your monaco font file (finally saw the paperclip, duh..) and the "linux" one I tried. You can see the results. Either too wide or can't do the small fonts. I installed the linux font file on my system and it shows okay at the small fonts. It's also 4x the size for some reason. I'm running 10.5.6.

Urgh - can't upload multiple files go here:
http://www.pfinspace.com/allegro/

I can confirm the problem with the file you linked to (iBook running 10.4.11, but I don't think that matters).

You can attach multiple files by uploading them one at a time.

Is an A4 compatibility layer even a good thing?

I think it might serve as an excuse to not make A5 as easy to use as it should be.

Yes, lets rip out the event system and replace it with A4's key[] array and mouse_ variables.

(thats essentially what the compatibility layer is providing, some things to ease initial ports, but it won't be fully compatible, some things in a4 just won't work even with the compatibility layer)

This thread might be a good place to gather opinions about something I brought up a while ago: How do users feel about the idea of linking all of the bundled add-ons into one binary file? This would primarily serve to shorten the length of the linker line, but would also mean that there were fewer DLLs to distribute. It would still maintain the same level of separation that the add-ons afford now, because the only connection would be that the add-ons are linked into the core.

Yes - as long as it doesn't detract from making A5 as good as it can be.

Those excuses will not be accepted.
Besides, you won't be able to make use of (some) of A5's new features if you stick to A4. Mixing the two in one application won't be very nice or necessarily work well.
Besides, I expect this will be the last thing to be finished, after the rest of A5 has been finalised.

Just static link them. Why bother with linking all of the addons into core when that affects Binary Compatibility?

It doesn't affect binary compatibility as long as all of the add-ons maintain binary compatibility themselves.

We'd have to have some magic script that builds the windows DLL in the proper way, in the proper order each release, and thats just a pain in the ass. The current allegro.def generator is already annoying, imagine extending it to include 5 extra libraries?

I'm all for it. And as far as I can see, this mainly would need someone volunteering as Windows packager who creates this DLL in addition to the separate one (which we should keep as well). Maybe some code changes are necessary as well, it seems in Windows you need to alter function declarations depending on if they go into a DLL or not. Also the build will need an extra option for this, but if cmake is as good as they say, it probably is easy.

How did you read that into my post?

[Disclaimer: some method names / properties may be wrong.]

Eg., as a programmer, say I just want to add a "wait for any key" at the end of some miscellaneous function:

ALLEGRO_KEYBOARD_STATE key_state;
bool keydown = false;

while (!keydown)
{
  al_get_keyboard_state(&key_state);
  for (int i = 0; i<MAX_KEYS && keydown == false; ++i)
  {
    if (al_key_down(&key_state, i)) keydown = true;
  }
}

or

ALLEGRO_EVENT_QUEUE *queue = al_create_event_queue();
ALLEGRO_EVENT event;
al_register_event_source(queue, (ALLEGRO_EVENT_SOURCE*) al_get_keyboard());

while (al_get_next_event(&event) && event.type != ALLEGRO_KEY_UP) {}

Here's what will happen:

#include <allegro5/allegro.h>
#include <allegro5/allegro-compat.h>

int main()
{
  // lalala, use Allegro 5 normally.

  // boy this function sure was a simple way to wait for a key press, let's bring in the compatibility layer!
  while (!keypressed()) { }
}

When, perhaps a native solution could simply be:

#include <allegro5/allegro.h>

int main()
{
  while (!al_keypressed(NULL)) al_poll_keyboard();
}

Now we've eliminated the need for a compatibility crutch by just making A5 easier to use. Events are still there. The only thing that is different, is now Allegro has a default key struct that can be populated by polling.

I just don't know why it has to be treated as a second class approach.

And furthermore, I don't see how an A4 compatibility layer will solve a lot of problems, as you'll still have to go through your code and make sure it all works. I think a better use of time would be to write a conversion upgrade guide.

Correct me if I'm wrong, but all you have to do is static link the add-ons objects into the DLL's core objects. That means you only need to have the .def generator include the source files for the addons. Should be relatively trivial. Since everything is going into one library, you don't need to worry about the order of linking.

Allegro is supposed to be easy to use. Forcing someone who's never used a compiler before to figure out the proper order to linking 10 or so libraries together is not conveying a good message.

-lalleg -lkcm_audio -licodec -lacodec -lpng -lz -lGL -lGLU ...

It probably is normally, but allegro uses some pretty hacks to get multiple builds of the lib on a single configure (cmake really doesn't know how to do that by itself, which imo is a mistake).

static linking into the core lib may not actually get those symbols exported. You generally have to give windows a special declaration to have it export symbols.

Library order doesn't matter in MSVC...

But the order of each symbol in a DLL matters. Also the combined dll and regular setup will be incompatible (most likely).

I'm not in favor of creating a huge DLL anyway. I'm okay with a monolithic static library, but I think doing that with the DLL is asking for trouble.

I agree, but as always with open source projects, you have to wait for contributors to spend time on what they like, and you never can tell them what to best spend time on. Someone even re-worked the A4 auto-tools build for example

I have no problem with that.

In case it wasn't clear: the purpose of a compatibility layer is not to make A5 easier to use.
If there is a situation where "it was much easier to do X in A4 than it is in A5" the fix is to improve A5. The audio API is a clear example.

It's not meant to solve "a lot of problems" and people are not supposed to mix and match A4 and A5 functions; whether it works or not is not in the hands of whoever wrote the code using it, but in the hands of whoever writes the addon. The purpose is (mainly) some support for legacy code.

Don't worry, you don't have to write the addon.
Yes, a guide "A5 for A4 users" would be very useful.

Do you have any information to back this up? I'm pretty sure you're wrong about the first point, however Allegro's stance on binary compatibility has always been that you can add symbols with no problem, but not remove or change them.

What sort of "trouble" are you anticipating? If the combined dll has a separate name, there should be no trouble at all.

Don't worry, it won't hurt my feelings if somebody (else) writes an A4 compatibility layer. I'm just offering my perspective on its usefulness.

Maybe "trouble" isn't the right word, but we are talking about newbs here. They won't be able to build Allegro anyway.

I have no problem offering a standard, official binary DLL called allegro-4.9.7-everything.dll that nobody but the Windows binary distributor ever creates or distributes. But asking the newb to get all those libraries together and build it using the Allegro build system is not going to do any good (regardless if its all-in-one or not).

That is, I don't see this as a core Allegro issue, but simply as a distribution one.

Its how Windows DLLs work. Symbols are linked to by an integer index, if the symbol at an index changes or is removed, bad things happen. You are indeed right though, you can add, but new symbols have to be added to the end of the monolithic DLL, so new symbols for each addons have to be managed in some way as to make them fall into place in the right place. If any symbol moves in that monolithic DLL it will break binary compatibility. You'll start seeing symbols from various addons interleaved with the core lib in the .def file. I imagine it wouldn't be the easiest thing to manage.

That's ok. I have a specific use for it myself. That alone is reason enough for me to make it useful.
If someone else finds it useful, good for them.

EDIT

As I remember, this came up a while back. From what I remember, there are actually two ways to do symbol lookups in DLLs in Windows. One is as you describe, the other is by name.

Yes, thanks to misc/fixdll.sh script. It's ugly and all, and yes, it will be extended to addons if we want to keep them ABI compatible too.

The problem with the fixdll.sh script is if you ever re run it, it potentially breaks the order. its only supposed to be run once for major releases and symbols are to be added manually to the def file afaik. At least thats what the very large warning it prints out leads me to believe.

Uh? No. I think fixdll.sh does it all for you.

Ah, you are right, but make sure you don't tell it to regenerate the reference list And don't use fixdll.bat.

Best would be to simply have a completely separate DLL for each release I think. Something like: allegro-big-5.0.1.dll. There would be no possibility for any version problems then. If someone makes another DLL of the same version but which includes even more addons, like some external networking library, they should name it differently again, something like allegrozilla-5.0.1.dll.

[edit:] And if one of the external addons has a new version and the big DLL is recreated, maybe indicate that as well, so in the previous case if the networking library releases a new version, the re-compiled DLL would be named allegrozilla-5.0.1b.dll. It would not allow any compatibility like the standard A5 DLLS, but the use of the big DLL would be to distribute it with the .exe anyway so it should be fine.

Unless all you wanted was to update the dll. Now you have to update the DLL and exes using it.

True. But it would get clear from the version numbers contained in the filenames, so at least nothing would be confusing about it.

int main()
{
  // lalala, use Allegro 5 normally.

  // boy this function sure was a simple way to wait for a key press,
  // let's bring in the compatibility layer!
  while (!keypressed()) { }
}

I hesitate to wade into this important discussion, but I might be a typical newbie/intermediate user of Allegro. For me there is a threshold where an API is too complicated and I am spending most of what little extra time I've got to use navigating the tool rather than expressing the action I need my program to follow. Allegro 4 is wonderfully easy to use. If the graphics were as fast as OpenGL, I'd just use it now. I'm even considering abandoning that high performance eye-candy, just so I can concentrate on the sim part and let the user's imagination fill in the craters with rocks (it's a lunar landing sim).

while (!keypressed()){... } is like breathing.
while (!al_keypressed(NULL)) al_poll_keyboard(); is like breathing through scuba gear.
while (al_get_next_event(&event) && event.type != ALLEGRO_KEY_UP) {} is like using an iron lung.

I just want to breathe - but not at the expense of the serious game programmers for whom the latter >is< breathing. I know that's your dilemma but here's a vote for perhaps ease of use over >super< high-performance.

--Paul

No, it's like running a marathon that doesn't end no matter how far you go. From the CPU's perspective. Try readkey().

It's pretty easy to make a readkey function in a compatibility layer, actually. You just need to create an input queue, attach the keyboard, and wait for an event. 10 lines if you're judicious with spacing

There could be an addon which provides simple shortcuts functions - anyone can write one. Just like there hopefully will be things like a C++ wrapper. It is not what the compatibility layer is for at all.

The addon could have a function like this:

al_wait_for_key();

Again, add-ons (compatibility layer or otherwise) shouldn't be used as crutches to simplify the core API. It's silly to put something like polling based input in an add-on if it is trivial to add to the core, not very high level, and likely to be used by a lot of people.

Do you really want allegro-polling-keyboard.dll?

There comes a time when ease-of-use trumps modular purity.

Well, I don't really think it matters where the function resides, as long as I can use it without any additional hassle. Maybe a file simple.c in src/ instead of addons/ would do.

I think we actually said on the mailing list some time ago that there should be something like:

ALLEGRO_EVENT_QUEUE *q = al_simple_init(640, 480);

And it would call al_init(), create a display with the given size, install mouse/keyboard/joystick and initialize all possible addons.

The main loop of:

while (1) {
    al_wait_for_event(q, &event);
    ... examine event and react ...
}

is easier to remember for me personally than all the various ways to get a mainloop going with A4, so I feel no urge for adding "polling" wrappers.

I agree.
The core API should offer power and flexibility for advanced users as well as simplicity for beginners/people who don't want or need the extra complexity.

And again, I think (the reworking of) the sound API is a good example of making the API simple for those who don't want or need the extra flexibility and yet offer the flexibility for those who want it without requiring them to jump through hoops to get it.

For this smart bunch, no question. I couldn't do it without a lot of RTFM-ing and cutting and pasting which I don't want to do. I'm not a tool-maker (a hard job) so I lean on you folks!

--Paul

Sure. Here's what it looks like at the moment:

int readkey(void)
{
   int ret;
   while (!keypressed()) al_rest(0.001);

   ret = readkey_buffer[readkey_buffer_start];
   readkey_buffer_start = (readkey_buffer_start + 1) % READKEY_BUFFER_SIZE;
}

with

int keypressed(void)
{
   return readkey_buffer_start != readkey_buffer_end;
}

Here's a quick (ugly) test I did with Allegro and OpenGL - I just hacked out a version of a NeHe tutorial with the rotating pyramid and cube but multiplied them by 750 (7500 polygons) all rendered in immediate mode without proper depth tests. (I was thinking of exscn3d). However. I managed to get FTGL and SOIL (Simple OpenGL Image Library) working with it and they are remarkably easy to use. The saved images are only in .bmp, .tga, and .dds, so I converted this to a .png.

Ideally, it would be great to figure out how to incorporate the ttf and image addons to do this, but there is at least an easy solution if you're using allegro with opengl and you need text and image capture.

--Paul

Trying to build under OS X 10.4 gives me this:
allegro/addons/kcm_audio/openal.c: In function '_openal_get_voice_position': allegro/addons/kcm_audio/openal.c:644: error: 'AL_SAMPLE_OFFSET' undeclared (first use in this function) allegro/addons/kcm_audio/openal.c:644: error: (Each undeclared identifier is reported only once allegro/addons/kcm_audio/openal.c:644: error: for each function it appears in.) allegro/addons/kcm_audio/openal.c: In function '_openal_set_voice_position': allegro/addons/kcm_audio/openal.c:657: error: 'AL_SAMPLE_OFFSET' undeclared (first use in this function) make[2]: *** [addons/kcm_audio/CMakeFiles/kcm_audio_shared.dir/openal.c.o] Error 1 make[1]: *** [addons/kcm_audio/CMakeFiles/kcm_audio_shared.dir/all] Error 2 make: *** [all] Error 2

Is it possible your version of OpenAL is outdated? What update of 10.4 are you on? Do you have the Fink package installed as well? If so, try moving it out of the way so /Library/Frameworks/OpenAL is used instead; check CMakeCache.txt to find out which version of OpenAL is being used.

I'm on 10.4.11. I tried downloading and installing another version of OpenAL from here but that didn't help much. I do not have the fink package.

Don't install OpenAL from a different source! you should use the version from Apple's install CD. See also http://www.allegro.cc/forums/thread/598146/780898#target, where something like this came up as well. We may need to add a note about this to the documentation.
What version of OpenAL do you have? Mine seem to be 1.1.

That should have been System/Library/Frameworks/OpenAL.framework

Looks like I have 1.1 as well. Doing

$ grep -r AL_SAMPLE_OFFSET .

in OpenAL.framework gives

Binary file ./OpenAL matches
Binary file ./Versions/A/OpenAL matches
Binary file ./Versions/Current/OpenAL matches

which reveals that the symbol should exist but it's nowhere to be found in the headers...

AL_SAMPLE_OFFSET is a macro defined in the al.h header. It's part of the OpenAL 1.1 spec (which isn't that new..), so if that's what OSX reports, that's what you should have.

Hmm, OK, I got it to work by pasting the following lines into my altypes.h, from some altypes.h I found by googling.

I tried a few examples, most seemed to work okay and I think I got about the same results as someone else earlier in the thread (i.e. NSAutoReleaseNoPool-stuff for ex_threads etc.).

I don't like that solution, to be honest. As I said, it works out of the box for me so it sounds like something got broken on your system. I'm not sure this is the correct way to fix it.
Well, anyway, if it works, it works.

No, I agree that it is hardly the best solution, but it won't break anything so it will have to do until I can try building on my iMac with 10.5.