http://sourceforge.net/projects/alleg/files/allegro-prerelease/5.0.0-rc1/

thank you!

will give it a go.

milestone.

Achievement Gained: Allegro 5.0rc1!

We should all drink a beer in celebration.

nice.

I should get on Mr. Harbour's forums and pester him to update his book!

Allegro needs more public exposure.

@Thomas:
Nice choice on the foamy!

I'll save that for when the final 5.0.0 is out, RC1, RC2, RC3, ... is just a different way of naming versions

Well, RC should at least mean no more API changes right?
I don't mind if you add functions, but if you change existing functions from now on it's just not right...

Adding functions after disallowing changes would be rather risky though.
So I recommend sticking to bug fixes.

This means 5.0 won't have any removals, or renames or arg changes.

5.0 is frozen now, fixes only till 5.0.0 is released.

5.1 however is open, and additions can be made there. I'm not sure if we guarantee strict source compatibility between 5.x releases, but I think we might? In that case, only additions can be made between 5.x releases.

Alas, I hoped that ALLEGRO_VERSION would be 5 now. When will that be changed?

It is as far as I know. Versions in 5.0 and 5.1 branches have been properly changed. Even 4.9 should show 5.0.

Append: It is in the zip on sourceforge as well.

Ha, seems that I was too quick. NOW 4.9 is 5.0, and I didn't realize that I have to get the 5.0 branch from SVN.

It should be 5.0 in the old 4.9 branch as well. Thats where peter changed it first, then tagged RC1, and branched 5.0 off of.

Now got it all right.

There's one thing I would like to make in a different way, but I'm not sure how to do it cleanly...

I'd like to build the core allegro library as DLL, but all addons as static libs, in fact I'd like to include the required sources into one bigger static library.

Seems Allegro 5 might be released before DNF after all.

_{(Febreaury/March 2011)}

Why would you want that? If you link the addons static, you may as well link that main dll static, as the addons depend on it. Or do you mean you want something like the allegro-monolith.dll, i.e. just one big DLL which has allegro and all addons and their dependencies?

Well, doing everything static would be one solution, yes. With allegro4 I had allegro DLL, lpng and zlib DLLs, and almost everything else packed into one static lib. There are two game projects sitting on this, so they both took from the static lib only what they need and import the DLL stuff they use. This gives only few DLLs, but has allegro (and lpng and zlib) as shared library...

So, this is perhaps mostly a matter of taste here. One of the nice aspects of using DLLs is that global variables are lock in there... which is not the case for static libraries.

Definitely not a mega DLL including everything.

Hmmm... maybe I should take this as opportunity to switch to all static libraries after all.

Nice. Downloading.

I'm wondering... where have pack files gone? Am I supposed to use zip files instead?

What about the nice config file routines, it seems that I have to re-implement things using the new functionality?

Why are useful functions like get_extension not there any longer?

I'm really missing a lot of convenient functions, which looks like I have to re-implement things that have been present in allegro 4.4.

Yep. With the PhysFS addon.

Is this not good enough for you?

al_get_path_extension

Zip files are OK, but I liked pack files a lot, too.

Well, that is pretty suggestive. It's not good enough, in some way, yes. I can implement what I'm using with those functions, but I have to implement all parsing, handling of default values and more than one config file at a time all by myself, whereas allegro 4's functions did a lot of that work for me. That's why I'm asking.

Sorry, I missed that one. Ürobably because I didn't think of doing it that way - I have a file name and want to get the extension, or cut the extension off to show only the file name in a list. Now, I have to create an ALLEGRO_PATH object, find the basename and destroy the object after that. To me that seems overly complicated.

Please don't understand me wrong here. I don't mean to criticize everything, mainly I want to know why certain things have been dropped or are done in less convenient ways than before. On the other hand I appreciate the nifty new things, like threads and all the hardware acceleration stuff.

I find it's actually easier to use multiple config files with A5 than it is with A4, but that's probably just a matter of taste.
It's true that you don't get default values, but it's very easy to emulate Allegro 4's config routines on top of Allegro 5 functions if you really want that feature - and in fact, I've done that for a project I'm porting from Allegro 4 to Allegro 5 (have a look at the demos/speed/a4_aux.c file for the basic idea).

I think the reason it's done this way is to accomodate different encodings in the filesystem and in the Allegro strings (which are always UTF-8), but I didn't follow that discussion in a great amount of detail (basically because I didn't personally care about the issues that were raised).

Yes. The new way is more powerful (marginally) but less convenient, no argument there.

How would you get that filename in the first place? The native file dialog addon returns ALLEGRO_PATH for example. The filesystem functions don't... but I think that's a problem of those functions, not of the ALLEGRO_PATH concept.

Not to mention that when you're messing with path's in A5 you really want to be using an ALLEGRO_PATH rather than a char* or a std::string. ALLEGRO_PATH is much handier, and you don't have to worry about unicode.

Yes, I have seen that.

Ah, right, files are UTF8 on modern systems, so things tend to be more complicated. Sigh.

Well, good point. I think I get the file name from a function which traverses a directory and calls a callback function for each file name that matches a simple pattern, like "*.lua". Inside I have a ALLEGRO_FS_ENTRY from which I get the path name...

After all, it might be necessary to change more code than I anticipated. There's a lot of small things that pile up.

I really would have liked there to be functions to get an ALLEGRO_PATH from an ALLEGRO_FS_ENTRY as well as from al_read_directory. Would have made everything nice, but It never got done.

If only. In that case things would be easier.
As I recall, it's UTF8 on OS X (or at least the interface lets you pretend its all UTF8), but it's UTF16 (?) on Windows, and whatever you want on Linux.

Yes.
I've kept notes of my porting effort for my game, which I'll clean up and post here at some point (sooner rather than later, I hope).

No reason we couldn't add those in 5.1, right?

Most times on linux its some ASCII code page, or UTF-8. More modern systems will choose UTF-8.

And since Allegro 5 has gone for "All UTF-8 all the time", it accepts ONLY valid UTF-8 for its own strings, and will convert to UCS-2 or UTF-16 on windows.

I would've LOVEed it if the versions that handle char* were never added to begin with. But that may have made more people un-happy. But yeah, they can probably be added in 5.1.

Great job you guys! Even the readme_msvc.txt build procedure is manageable. I would just add:

• When converting an MSVC 9 project to MSVC 10 (to work around the CMake naming bug) several compiler errors will result related to int64_t. To fix this, uncomment the line: #define ALLEGRO_HAVE_STDINT_H in alplatf.h.

• Another option is to alter the CMake file so the Allegro DLL's don't have dots in their names. In the common.cmake file change: `SUFFIX -${ALLEGRO_SOVERSION}.dll` -> `SUFFIX -${ALLEGRO_DLL_SHORTVER}.dll`. Now CMAKE will generate valid MSVC 10 project files. Note this is not a good option if you want your Allegro programs to dynamically link to the Allegro library files built and shared by everyone else.

• Running the examples. There are two other options:

  1. Build the INSTALL project. This copies the library files into MSVC's search path (%VCINSTALLDIR%\bin). Then you can select a startup project and run it with F5 (from within MSVC).

  2. Copy the Allegro DLL files to a new directory (like C:\ALLEGRO_BIN). Then append that directory to your system %PATH%. Now you can run Allegro 5 programs from any path on your system (including from within MSVC)

I made a cursory survey of all the example programs, and I found some things that might need fixing:

• ex_utf8, ex_ttf, ex_font and ex_config fail to compile with warning C4819 if the default locale is not set to English (mine was set to CP949, Korean). The work-around is to set the system locale to English.

• The Windows taskbar is rendered over ex_dualies. This problem is common to most of the dual monitor/fullscreen window examples. In addition, ex_dualies has some intermittent problems:

  • Occasionally causes explorer to crash on startup.

  • Sometimes the Mysha display only shows a solid green color.

  • Sometimes the Windows taskbar is not restored to its original size+location.

• ex_fs_resize does not work very well with a dual monitor setup. It fails to change the resolution; it just sits in a semi-opened state (the log window is open, but the other window is just a sliver in the taskbar.) ex_fs_resize works if the monitors are duplicated, showing the exact same thing at the same resolution.

• ex_threads sometimes results in one of two types of errors:

  1. When starting: fatal error (Callstack attached.)

  2. When closing: First-chance exception at 0x7741f49f in ex_threads.exe. (Callstack attached.)

• ex_winfull taskbar also has some issues with the Windows taskbar being rendered over the Allegro display. On a dual monitor setup, I actually see two windows: the regular one on one monitor, and fullscreen window on the other. Clicking on the regular window causes the taskbar to occlude the fullscreen one. Works fine if the monitors are set to duplicate eachother instead of extend the desktop.

• speed also has a problem with the Windows taskbar covering the Allegro window when switching to fullscreen mode with "F". The work-around is to click the taskbar, then click the Allegro window. I do not see the "regular sized" window with this one (like ex_winfull)

• Building the run_tests projects results in several failures. These tests all passed in a previous SVN version of Allegro. List of failed tests attached.

Environment:

• Ran all examples from within MSVC; RelWithDebugInfo

• Allegro 5.0.0rc1

• MSVC Express 2010

• Windows 7 32-bit

• Lenovo X301 laptop

• FS-HS240LEDT external monitor

Regarding CMake and MSVC 10, you can:

• use nmake instead of project files, or

• use my patched copy of cmake

That's assuming they haven't fixed the big in CMake yet.

Thanks for testing!

• Does this mean MSVC 10 has stdint.h?

  
  

• ex_utf8, ex_ttf, ex_font and ex_config: unfortunately I can't find a decent solution to this. I don't really want to externalise the strings or use hex codes as some of these are meant to be readable examples. Apparently MSVC will treat these files are UTF-8 encoded if they have the stupid byte order mark (BOM) at the start; can you test if that works? I can't believe there is no command line option to force the input encoding.

  
  

• I believe the failing test cases are related to r13800. I did not have time to investigate whether the library or the test suite is at fault.

Yes, MSVC2010 has stdint.h.

Yes, and Allegro supports it correctly. The problem is CMake does not build proper MSVC 10 files, and the MSVC 9 ones are not compatible.

Would an option be to just rename the DLLs for windows to use the dll short version rather than SO version?

Yes, it compiles... but it doesn't quite fix it. The BOM introduces compilation warnings in the English locale, then! There are still (different) warnings for the Korean local, too. The Unicode literal outputs of both programs are not properly printed; the UTF tests fail and/or hang.

Sample warning when compiling BOM file in Korean locale (CP949):
warning C4566: character represented by universal-character-name '\u25A2' cannot be represented in the current code page (949)

Sample warning when compiling BOM file in English locale (CP1252):
warning C4566: character represented by universal-character-name '\u25A0' cannot be represented in the current code page (1252)

I tried several other encodings, too: Unicode, Unicode Big-Endian, UFT-7. The only combination that worked was UFT-8 without signature compiled in English Locale.

Ok, thanks. What happens to wide character strings, L"€"? If we can convince MSVC to use UTF-16 encoding for those, we can do a runtime conversion to UTF-8. With a C++ class it should be relatively painless.

And of course build for Windows:
allegro-5.0.0-rc1-mingw-3.4.5.7z
allegro-5.0.0-rc1-mingw-4.2.1-sjlj.7z
allegro-5.0.0-rc1-mingw-4.4.0.7z
allegro-5.0.0-rc1-mingw-4.5.0.7z
allegro-5.0.0-rc1-msvc-10.0.7z
allegro-5.0.0-rc1-msvc-8.0.7z
allegro-5.0.0-rc1-msvc-9.0.7z

This I'm looking forward to, I guess that it will be of great help for newbies to A5. One of the big things I'm going to port next is the game loop, which I think will have to look very different from the previous implementation.

I forgot to mention I tried L"", too. MSVC complains about incompatible types. I also tried the "_T()" macro without any luck.

I suppose it might work if we modify Allegro a little. Is that what you mean by runtime conversion? I was reading the L"" macro messes up non-MSVC compilers, though...

Allegro would remain the same. In the one or two examples, we would write U("føø"), where U(s) is a macro that expands to convert(L"føø") on MSVC, and "føø" everywhere else. convert() would return a pointer a UTF-8 string. This just requires that MSVC consistently output a UTF-16 string whenever we use the L"" syntax, which surely it does?

EDIT: attached a patch you can try (specifically ex_ttf).

L"" convert to UCS-2, not UTF-16.

I ported the 4.4 skater demo to the 5.0 API and it's true to some extent. Basically I had to spend most time in unexpected places, like string/path handling and config files. In my case for the config files I used the versions from a4_aux.h with builtin types and default values. For path handling i changed to using ALLEGRO_PATH, which was some work but made the code more readable than the original. All the old u* functions need to be replaced with ALLEGRO_USTR, which actually has more convenience functions than the old ones.

Replacing all the messy code which randomly queries key[] and uses a timer and rest() for timing and implements 3 different double buffering methods was rather easy on the other hand. And the new events code is more reliable (e.g. no key presses can't be missed like with key[]), and it's also shorter and easier to read.

Yes, I have seen the stuff in a4_aux* already. I think I'll do similar things for config files, I just have to add support for override_config_file to what you have already done there.

Path and file system handling is an issue. For example, I have a function in place that takes care of auto saves. So all auto saves are collected from the file system, then the oldest are deleted, such that only a given maximum number of such auto saves exists. This requires matching file names, using a pattern like "auto*.vacs", then sorting the entries by modification date. Sure, this is possible with the new interfaces, except for the pattern matching... how would I do that? Which library to use here, that doesn't come a with massive overkill?

For the game loop and display stuff, I think I'll just re-write those parts. Will hopefully result in less and cleaner code. And yes, there's an occasional access to key[] and mouse_b...

I was dreading this part, but in the end, it was all very painless. The way I'd set up the code probably helped here though.

Yes, that was just like my experience with the skater demo. I have to praise whoever wrote that demo for doing input handling the way it was done. Also for not using the A4 GUI, in which case I'd not have attempted the port.

Guess what my project was using for the menu screens...
Actually that bit also wasn't so bad; A4's GUI is reasonably self-contained, so I ripped it out of whatever Allegro 4 version I had installed at the time. Then it's just a matter of replacing/emulating all the input code in there (fairly straightforward) and getting the widgets to compile (again easy with a tweaked version of a4_aux). Not that I haven't actually tested most of them, since I'm using custom widgets for most things.
There are a few glitches here and there (and some things I changed that didn't work the way I wanted to to begin with) but overall that was also more tedious than painful.

The patch seems to do the trick. No MSVC compiler warnings in US or Korean locales, and the UTF output looks good in both the resulting executables.

Congrats to Allegro team on their impending 5.0 release.
I love Allegro, old and new.

Will support for stencils make it in to the next release, or are
there already commits? What new features are planned for 5.1 branch?

Wishlist:
I do wish support for at least 8-bit memory bitmaps had remained.
along with some blit/mask wrappers to transfer to ALLEGRO_BITMAP.
I found them particularly useful not just for sprites, but for world maps, etc.
For my project, I ended up ripping out the api from a much earlier
version or allegro and just slapping in C code to reimplement bitmap
creation and drawing primitives.
Obviously the performance is much worse than assembly.
Am I the only one living in the past.

Cheers.

Thats something I really want, so I might help with it. Well see if I have the knowledge and skills

The only way that's happening is if someone who wants it, writes the code. I don't have anything against that feature, I just don't want or need it I do believe that the loaders will load 8 bit bitmaps, but up convert on load (not entirely sure).

Yes, they do.

If I were to add 8 bit bitmaps to Allegro 5, I would probably make the palette a property of each bitmap (you'd be drawing them to a higher-colour depth display anyway) and do on-the-fly conversions when needed (so you don't get penalised more than once if the palette doesn't change).

8-bit doesn't necessaily mean palette. I think it would make sense to support something like GL_LUMINANCE in OpenGL ES 2.0:

It could save a lot of texture space for e.g. fonts. Saving texture space reminds me, we should add an example how to use texture compression (OpenGL only - unless someone wants to make an addon which wraps around D3D as well).

Just installed this version. I have a problem with the native filechooser. It freezes the program.

I'm on Ubuntu 10.04.

There were no changes to the native dialogs addon from 4.9.22

Can you get a backtrace by running under gdb?

Hmm, I've never tried getting a backtrace for a program that freezes, only for crashes. How would I go about doing that?

Testing ex_native_filechooser.
It starts 5 threads, and when I click open it starts another thread then the log window goes grey and it's all frozen. It starts a thread and freezes no matter where I click actually.
Even if I don't click at all it freezes in less than 30 seconds.

When it hangs, press ^C in the gdb window and you will get the usual gdb prompt. You can get a backtrace of all threads with: thread apply all bt

Most debuggers can attach to running programs. With gdb on unix you hand it the program's pid.

With threaded applications you want to run this in gdb: "thread apply all bt full" confusing, but it tells gdb to output a full backtrace for ALL threads.

#0  0x0012d422 in __kernel_vsyscall ()
#1  0x00ae2015 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0x00197478 in _al_cond_wait (cond=0x834511c, mutex=0x8345100)
    at /home/anders/allegro/allegro-5.0.0rc1/include/allegro5/platform/aintuthr.h:81
#3  0x00193594 in al_wait_for_event (queue=0x83450d8, ret_event=0xbffff070)
    at /home/anders/allegro/allegro-5.0.0rc1/src/events.c:354
#4  0x0804a0f1 in main ()
    at /home/anders/allegro/allegro-5.0.0rc1/examples/ex_native_filechooser.c:228

Seems to be stuck in al_wait_for_event.

Oh, perhaps all threads is a good idea.

Can you also post the contents of allegro.log?

Attached

EDIT: So A.cc doesn't finish uploading after pressing submit post.

I think it will be a bit easier to debug with more logging. Please post the allegro.log again after applying this patch.

Here you go.

Thanks. Does this help?

No it did not.
Attached new log and backtrace.
New behaviour though, when running in gdb I only get the log window and it freezes there.

I'm not sure what the problem is, but it could be a GTK bug. The implementation was bugging me anyway so I changed it a simpler, message-passing type structure, instead of trying to find the bug.

And it works!
I like the humor when I click anywhere.

Great. I've committed a more complete version of the patch.

The native filechooser in A5 returns absolute paths, but I want relative paths.

What's the simplest method for removing current directory from the path?

I noticed that al_get_current_directory returns a string that must be freed. Why? I would prefer to have freeing that off my hands when I need the cwd.

On a slightly related note, I don't know if this is a big problem (probably not), but al_get_current_directory returns a path without a trailing / (or \). My colleague wrote some code that turned out to be messing up because he assumed there was going to be a / at the end. So I had to create a temporary string and add the / then add the rest of the path.

Just out of curiosity: why?
I can't think of a use case where absolute paths would be bad. Arguably you want to base things off the current directory with the idea that you can still find the file if you move the whole directory tree, but that only works for files under the tree...

Probably using al_remove_path_component (by the way, it'd be neat if Acc's markup started recognising A5 functions).

EDIT: could someone clarify the distinction between al_join_path() and al_rebase_path()? From the description it seems that they do more or less the same thing, except one modifies the first argument and one modifies the second argument...? The example at al_rebase_path() does what I'd expect al_join_path() to do (which doesn't have an example an dprobably needs it) while I would expect al_rebase_path() to more-or-less allow you to do what the OP wants here.
I'm confused now...

I want to save the paths in a level file so they can be loaded no matter where the game is installed.

If a file is not under the tree, I'm considering importing it by copying the selected file to a folder where the game would want those files to be.

Perhaps I should just get the filename part from the path, prepend expected folder and check file existence. If it's not where it's supposed to be then I copy the file selected in filechooser.

Yeah, I think we should add an `al_path_make_relative(ALLEGRO_PATH *working, ALLEGRO_PATH *path)` or something along those lines. This would take path, and remove "working"'s path components from "path".

Its not that hard to do yourself though.

That's not how things work in C. Look at this:

al_change_directory("blah1");
str1 = al_get_current_directory();
al_change_directory("blah2");
str2 = al_get_current_directory();
printf("%s %s", str1, str2);

If you do this in a loop a few 1000 times it would mean a lot of strings which have to be kept... only way around that is to free them. What we could do is have you pass in a buffer and length where the string gets written to though, but that would be awkward as you now have to deal with arbitrary buffer lengths. More annoying than adding a free call I think.

The name would be confusing. For example if I'm in "/home/blah1" then want the relative path to "/home/blah2", I would expect to get "../blah2".

Other A5 functions that return strings don't require the user to free.

http://alleg.sourceforge.net/a5docs/refman/path.html#al_path_cstr
"The returned pointer is valid only until the path is modified in any way, or until the path is destroyed."

http://alleg.sourceforge.net/a5docs/refman/utf8.html#al_cstr
"This pointer will only be valid while the underlying string is not modified and not destroyed."

Thats a bit of a special case, the ALLEGRO_PATH structure stores a cache of the c-string so it doesn't have to keep re-making the full string each time al_path_cstr is called, and thats what it returns.

I assume al_cstr is the same. Most times with a current dir string, you wan't to keep it around, not have it disappear just because you changed dirs and called al_current_dir again.

Those are "object-oriented" and have some place to stash the string buffer. The only such place for al_get_current_directory() is in a global variable, which introduces problems with threads. Then we would need to make it thread-local, which introduces its own issues.

Just make a function that copies the string to your preferred location, and free Allegro's string immediately. You can make assumptions in your application that Allegro can't.

I was just fiddling around with this version of Allegro and I found a problem. Probably on my end, but the behavior is still strange regardless.

I have this simple program:

Running it endlessly tries to create windows until the program crashes. I attached the log and am using the RC1 release from Allegro5.org. I figured al_create_display would fail gracefully instead of getting stuck in an endless loop.

That problem seems to happen on some computers.. It should be known that there is no loop in the display creation code AFAIK. So whatever is happening is a driver or d3d bug.

So far we have no idea what causes it.

Adding some logging in the loop around d3d_disp.cpp:1809 should help to debug it.

Well, the attached log does suggest some kind of loop. I added a bug report for it so we won't forget before the final 5.0, but hopefully we'll be able to fix it right away.

Is it related to D3D or to OpenGL? (see the ALLEGRO_OPENGL in al_set_new_display_flags)

If it is related to OpenGL, I think that "display_thread_proc" in "wgl_disp.c" needs a review, because there are an ugly hack/loop for DInput (which is not used anymore).

It's a D3D bug. It has to do with matching the best display format.

Except it seems he's setting ALLEGRO_OPENGL?

Hmm in that case I don't know

Thanks for the info. I won't use that code myself (as I said I was just fiddling with it).

I found another crash that only happens occasionally. Basically, when my program exits, it crashes some place in d3d_shutdown. The exact place tends to be rather random. The example is as follows:

Sorry for any inconvenience!

edit: Seems to only happen due to al_toggle_display_flag. Without it I haven't encountered a crash yet.

Ohh.. I noticed something quite wrong in your code.

Do not use & to combine flags. use |.

Please re try both of your examples!

I think you want an | there not an &. However, this may be a legitimate bug. Thanks.

Oh duh! Sorry and I'll try it again.

edit: Yea that seems to be the problem (same with the previous one, probably). Sorry for wasting everyone's time! (my excuse is I haven't used bit operations in a long time, but that's a rather lame excuse... "Oh, I haven't ridden a bike in four years! How will I remember?")

edit: Actually that really should have no effect. ALLEGRO_OPENGL & ALLEGRO_WINDOWED is 0. Would that not be a valid input? After all, it'd just default to the regular settings (or am I wrong?). In any case, I encountered a crash again after doing some other stuff, tried the code previously with the fix, and lo and behold it happens. So I guess I wasn't wasting anyone's time.

So let me get this straight. It's crashing when using the OpenGL driver and when using the D3D driver, or is it one or the other?

I haven't had it crash yet with OpenGL, just Direct3D in d3d_shutdown.

If you're using ALLEGRO_OPENGL then you're using OpenGL not D3D. Memory corruption could cause it to appear to crash in the d3d driver. I just want to make it clear, so could you please post the code that crashes?

By Direct3D I mean when I do not set any flags (through al_set_new_display_flags).

When I use Direct3D it crashes (by using the code below) at the end of the program:

al_set_new_display_flags(0); /* Or just not calling it at all. */

And this does not crash at the end:

al_set_new_display_flags(ALLEGRO_OPENGL)

The example I am using is just this:

By default, this would use the Direct3D driver on Windows, or am I wrong?

Yes, that's right. But since you were using ALLEGRO_OPENGL in all of your previous examples I had to verify.

I really don't mean to be a pain but I found a problem with getting display modes in OpenGL. The "height" member in ALLEGRO_DISPLAY_MODE is never set. I looked at the source and understand why the pixel format is not filled, so I ignore that for OpenGL contexts, but the height is important. Code is like so:

ALLEGRO_DISPLAY_MODE mode;
al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_SAMPLES, 16, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_STENCIL_SIZE, 8, ALLEGRO_SUGGEST);
al_get_display_mode(0, &mode)

printf("%d %d", mode.width, mode.height) /* Prints 640 0 (for example). */

Aaron was not using OpenGL really, see the Thomas Fjellstrom comment, he was using:

(ALLEGRO_WINDOWED & ALLEGRO_OPENGL) = (1 & 4) = 0 (& instead of |)

  al_set_new_display_flags(0);

I missed it too.

I noticed that but assumed he was still using OpenGL after correcting that.

Aaron, if you're able to repeat this bug, could you please try adding a delay (Try Sleep(1000) on windows) after al_uninstall_sytem and before returning from main? I think it's a race condition. I was only able to reproduce it once though so I'm not sure.

I started using the filechooser in Cumulate and I'm annoyed by this error that shows up every time I use it.

** (<unknown>:16706): CRITICAL **: giop_thread_request_push: assertion `tdata != NULL' failed

I've tried to replicate it in a small example program but can't make it happen there. But in Cumulate it happens even in the simplest possible use of filechooser, create, show and destroy.

Usage can be found in this file.
https://github.com/trezker/Cumulate/blob/master/editor/file.cpp

Aaron, for the second bug about OpenGL display modes, try the patch attached to this post.

The patch worked; thanks a bunch!

YW. What about the delay I suggested a couple posts above?

Oh, I just tried that now after seeing your post and first run crashed still. Seems to crash during the call to al_uninstall_system, not after (when returning from main). Sleep never gets called.