aka. Allegro 5.0 beta 1

Probably what that means is "we'll try harder not to break your stuff from now on".

http://sourceforge.net/projects/alleg/files/allegro-unstable/4.9.20/

That's a lot of stuff. Good show.

Is this not a backward step in terms of performance and reliance on Windows GDI+ being the same across different platforms?

Is there reason to think that's a problem?

GDI+ is used to load and save images. It has nothing to do with run time drawing performance.

And yes, there's the possibility that a JPEG image will work on GDI+ and not libjpeg (or vice versa), but that's not likely to be an issue, especially as you control your media files.

It would be good more information about the iPhone library...

Great!. Downloading.

[EDIT:] Got some warnings building on Windows with MinGW, gcc 3.4.5. No big deal. Just in case the devs want to fix it.

G:\allegro-4.9.20\src\win\d3d_bmp.cpp: In function `void d3d_blit_real(ALLEGRO_BITMAP*, float, float, float, float, float, float, float, float, float, float, float, int, bool)':
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:731: warning: passing `float' for converting 1 of `virtual HRESULT IDirect3DDevice9::CreateOffscreenPlainSurface(UINT, UINT, D3DFORMAT, D3DPOOL, IDirect3DSurface9**, void**)'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:731: warning: passing `float' for converting 2 of `virtual HRESULT IDirect3DDevice9::CreateOffscreenPlainSurface(UINT, UINT, D3DFORMAT, D3DPOOL, IDirect3DSurface9**, void**)'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:738: warning: converting to `LONG' from `float'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:739: warning: converting to `LONG' from `float'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:740: warning: converting to `LONG' from `float'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:741: warning: converting to `LONG' from `float'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:749: warning: converting to `LONG' from `float'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:750: warning: converting to `LONG' from `float'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:751: warning: converting to `LONG' from `float'
G:\allegro-4.9.20\src\win\d3d_bmp.cpp:752: warning: converting to `LONG' from `float'

[EDIT 2:] Looks like we have this bug again:

{"name":"601415","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/a\/ba54058c02bcc34089a5cea2b4f4ee6f.png","w":648,"h":672,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/a\/ba54058c02bcc34089a5cea2b4f4ee6f"}

It seems to be present only when using D3D. Can someone confirm it?. As before, drawing thick primitives works fine; it only appears when thickness is 0.

al_init_primitives_addon() is new, right?. Either that or I've been skipping it all this time.

Yes, it's new.

And I'll look into this bug this evening. Does ex_prim work for you by the way? I changed some things that may have broken the addon for older Intel cards again...

EDIT:
But of course, how could I forget... it's the same problem as before, I just forgot exactly how much Intel cards suck...

Should have read the changelog more carefully.

Yes, it works just as before. And by that I mean... the Indexed Primitives tests seem broken and framerate drops in the Custom Vertex Format test but it has always been like that and since these are advanced features, I wouldn't expect for them to be implemented for low end cards, seriously. That's why I never reported it as a bug or anything.

All other tests work fine. And seriously, just a note in the documentation indicating that Indexed Primitives aren't guaranteed to work on low end cards should be enough.

This is how the Indexed Primitives tests look:
{"name":"601418","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/6\/a6543c74d5d0876f5b8c2e0510f834c2.png","w":811,"h":634,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/6\/a6543c74d5d0876f5b8c2e0510f834c2"}

[EDIT:] Oh, also, I just checked with OpenGL (never did it before) and all tests work fine. The Indexed Primitives tests display correctly and framerate doesn't suffer as much in the Custom Vertex Format test.

I'll add a fix making indexed primitives work for your card. It obviously won't be as fast as if they were supported natively, but the performance hit should be minimal.

The custom vertex one is slow because I made it fall back to software drawing for older cards.

Oh, OK. Everything's perfect then.

Okay, should be fixed in Rev. 13356. Sorry that I keep breaking the addon on your card like every time I do something

Fine, I'll check the latest revision.

Sorry for keeping you fixing the addon just for me... who else can be running on such ancient hardware?.

Actually, the primitives addon stopped showing textured primitives here as well, so I guess I'll update to the latest revision too.

Textured primitives work fine on my machine on 4.9.20. The problem is only with Indexed Primitives.

I haven't tried the latest SVN as my usual source for SVN revisions is Thomas Fjellstrom's SVN Snapshots page.

Sorry that it hasn't updated in a couple days, it seems the vm had a fit and the root fs remounted read-only. Fixing it now.

The fs actually seems to be quite badly corrupted.

append: Its back up, hopefully nothing is damaged

Upgraded to the latest SVN. The problems with some primitives were fixed... but the textured primitives don't work anymore.
{"name":"601427","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/e\/fe577a498c3eb97f1d2806f65fd13c42.jpg","w":801,"h":605,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/e\/fe577a498c3eb97f1d2806f65fd13c42"}

My specs have been always the same:

You've posted the correct output of ex_prim... and are saying that they don't work anymore?

Try pressing 'S' in that (and any other) screen. If the output does not change appreciably, then all is well.

Oh, sorry. It seems I forgot how the example worked. I isolated the code and it worked fine, but for some reason, it isn't working anymore in my game? I'm sorry for the inconvenience. >_< I'll have to debug it a bit more.

EDIT: I don't really know what could be messing with it. Drawing without a texture doesn't work. If I isolate the example, it works alright... What could've changed lately to do this? There's surely no memory overwriting at all, but something did change.

Are you using OpenGL or Direct3D? One big change that affected both was the changing of the color type. In 4.9.19 it was 4 bytes, while now it is 4 floats. Most other changes affected Direct3D only, however.

I'm using OpenGL.

Before doing anything, I've found some other strange problems. I must compare some things in both .9.19 and .9.20, testing both drivers and etc. I'm sorry for bringing a possible false alarm.

Hey, don't worry about it.
It's better that we have a false bug report than that people don't test things before we release 5.0!

Thanks, Thomas Fjellstrom. I've updated to r13356 now and, SiegeLord, I can confirm that ex_prim is working perfectly now on my machine, Indexed Primitives and all.

Ok, I'm sorry, it seems I panicked because it turned out, the D3D driver wasn't being set really. (Again with an stupid problem of mine)

The problem was that a lot of weird behaviour appeared when using the D3D driver in Arkab. Luckily, the same thing occurs in both .9.19 and .9.20, so I guess it has nothing to do with a problem on this update, but rather an old problem of mine that I never seen because the D3D driver wasn't being used at all.

The problem turned out to be the following. I'm using cgD3D9BindProgram to apply the CG shader. For clearing the usage of any shaders, I use cgD3D9BindProgram(NULL). Calling the latter only doesn't have any effect whatsoever, but setting an own fragment shader program with the former, produces all kinds of weird behaviour on Allegro5. The most noticeable was ignoring Alpha channels completely, which kind of panicked me. Even calling cgD3D9BindProgram(NULL) after it won't fix the problem either.

I don't really know what to do with this.

I just got the latest version from svn. It compiled and installed without complaining.

I didn't test everything, but I have encountered a few problems.

The a5teroids demo doesn't work. It says "Error loading sample C:/Programming/allegro5/build/demos/a5teroids/data/sfx/big_explosion.ogg". big_explosion.ogg is where it says it is looking for it, and it plays ok in winamp.

The following example programs didn't seem to do anything at all: ex_audio_props, ex_audio_simple, ex_acodec, ex_acodec_multi.

ex_draw seems to have "circles" and "filled circles" the wrong way around; (and some of what is drawn is slightly different for hardware vs software, but this is probably to be expected).

ex_fs_resize goes into full screen mode with a picture, but then crashes when I press space or esc. (program has stopped working, inform microsoft etc.)

ex_draw_bitmap says that there is error loading data/mysha256x256.png.

ex_drawpixels seems to work alright, but it doesn't exit when I press the close button. It only exits when I press esc.

That's all I have to report for now. I hope that this information is useful.

Did you compile the Ogg Vorbis codec?

Did you compile any audio codecs? (By the way, many of the console examples on Windows send their output to nowhere.)

Did you compile the PNG or GDI+ extension?

Alright, well I suppose I didn't compile any of those things. Sorry for the false alarm. I only compiled whatever is compiled by default with the following commands:

cmake -G "MinGW Makefiles" ..\
make
make install

I just assumed that since the audio examples are there then I must have done all I was meant to do to make them work. A bad assumption, apparently.

I'll look into how to compile the ogg / png stuff when I want to use it.

wav is the only built-in audio codec, so it can play them.

Indeed!!!.

You'll have to install the necessary libs (like libpng, libvorbis, libogg) and then rebuild Allegro.

4.9.20 binaries for MinGW are now available on http://allegro5.org. I'll make some MSVC binaries soon probably. These ones are not using dynamic loading for the audio codecs, but I'll try to get that into the next release. There are dynamic, static, and dynamic debug libs in this archive.

Thanks, Trent! Very helpful.

Have you made any progress on the shader addon?

@Mark, Yes, it's pretty much functionally done. It may need some usability tweaks so it interacts with the rest of Allegro and its addons better. I planned on bringing it back up after 5.0 was released as this addon will not be going into 5.0 but 5.1 (to become 5.2). I'm using it in my game and I've tested it on all platforms so it's in a "decent" state, meaning no bugs I know of. If you want it I can upload it somewhere.

yes, please!

I'll just attach it here. I attached the example I was using too. None of this is integrated with Allegro yet, except in my own code, so you have to do your own drawing if you use this. In my branch of 4.9 I have it setup so all the drawing will use the shaders if you have one set, but only on iphone 3gs for now. I think one of the things that needs to be added is an ALLEGRO_USE_SHADERS flag or something like that, that would tell the Allegro core to always use shaders internally for its own drawing, then you could override the shaders it uses. But that's for a bit later.

I have build which may or may not be useful for users of Allegro. This is a monolith build, that means only one DLL/lib is produced as a result of compilation. All dependencies are, let's say, compiled in final library. Those libraries are used:

• dumb-0.9.3

• flac-1.2.1

• freetype-2.3.12

• jpeg-8

• libogg-1.1.4

• libpng-1.4.0

• libvorbis-1.2.3

• openal-soft-1.11.753

• physfs-2.0.0

• zlib-1.2.3

In case of DLL version all we got are two files: allegro-4.9.dll and allegro-4.9.lib. That's mean you care only about one run-time file and link only one lib file.

Static version works in similar ways, you need to link allegro-static-4.9 and all core dependencies: opengl32.lib, winmm.lib, d3d9.lib, dxguid.lib, dinput8.lib, dsound.lib, psapi.lib. All those are in Windows and Direct3D SDKs.

I created this build for two reasons. First of all I often had problems with missing Allegro dll file. My old applications refuse to work because I updated
Allegro or DLL just vanished after system re-installation. Then I had to compile
everything from scratch again. Since such situation was a result of my mistakes I decided to do something to prevent similar situations in future.

Second reason is convenience. That was something I love in Allegro 4.4.x. You got single DLL file and you don't need to care about anything else. In Allegro 4.9.x this is no longer true, all those add-ons produces extra libraries, some of those libraries have additional dependencies that I need to remember about. Believe me, this is not on what I want to focus. I'm not neglecting add-ons idea, those are great. The only thing I miss is the possibility of compiling them in if necessary (including dependencies).

At the bottom of this post you will find an link to binary version of Allegro. There is what you can expect:

• \bin\allegro-4.9.dll - build with /MT

• \bin\allegro-debug-4.9.dll - build with /MTd

• \lib\allegro-4.9.lib - import library for allegro-4.9.dll

• \lib\allegro-debug-4.9.lib - import library for allegro-debug-4.9.dll

• \lib\allegro-static-4.9.lib - static library build with /MT

• \lib\allegro-static-debug-4.9.lib - static library build with /MT

• \include\allegro5* - all Allegro headers

Note: PhysFS header file was modified to honor ALLEGRO_STATIC definition.

I'm interested about you opinion about this monolith build.

Warning! This link lead to my private build of Allegro. It is not official nor WIP. So if you decide to use it you are doing this at you own risk.

Michal, that's an interesting work from your part. That reminds me of a debate that happened in one of my earlier threads about A5 and separate addons.

My question is, how long does it take you to do these builds? I'm interested in doing it myself as well for personal use.

Initial setup take ma quite long time, because I had to configure projects for all external libraries. Configuring and fixing this workspace consume a day of work. But it was worth it. At the moment I perform update on Allegro repository. I had to manually add/remove files to the project that was added/removed from repository. Now I just click build and voila. In 10 minutes I have all four versions compiled.

Best to rename the library (the file) in that case, otherwise it'll get confusing at some point.
As to how useful or in demand something like that would be, I don't know. Wouldn't use it myself is about all I can say about it.

Yes, CMake is basically just a nuisance under Windows / MSVC.

Anyway, the best solution is to just not distribute a DLL for your monolithic build. But if you do, you need to rename it.

Also, some of those files (particularly debug and/or static) will only work with whatever version of MSVC you used, so you should let people know what you used.

I have no plan to distribute further my compiled version at the moment.

I don't know either. I know my expectation, maybe someone just think in similar way. It is you choice to checkout the approach or not. I respect that.

Agree.

Don't afraid. This DLL will not spread. If someone wish to use this binaries I will definitely rename final libraries. At the moment there is no point to do that.

You are right.

Everything is compiled using Visual C++ 2010 compiler. /MT and /MTd run-time libraries are used (static version) that means there are no need to include vc_redist in distribution.

DLL version should work fine with every visual studio version. Static libraries will link only for Visual C++ 2010. I had tested that on a5steroids.

Michal, though currently not using the 4.9 branch my preference is indeed for a monolithic library. I use MinGW which may pose a problem for your distribution. Even so, on that last point, I see absolutely no reason why you could not maintain a separate distribution. No doubt a subset of the user base would benefit.

But if you ship allegro-4.9.dll with your game, then people will assume it's compatible with the official version.

Personally, I think it's useful enough to warrant semi-official status. If you were willing to maintain your project file, and binary builds, I'd set up space here on a.cc for you to put them on.

My only requirements would be that a) the library is renamed to something like allegro-panoptic-4.9.dll (alright, I don't have a good name) and b) it supports every official add-on.

I think there will be no problem with MinGW build.

I use dll version only in developer builds so I don't care much for name. Release is compiled with static version, so finally I had only executable and data.

Idea is not bad. I have to prepare environment and script for builds. This may take a while.

Yap. I will rename those files and all add-on's are included now.

I will let you know when everything will be ready.

Indeed, mingw supports directly linking to .dll files (just specify allegro.dll, without the need for a liballegro.a or liballegro.dll.a). Can't say if it works with your .dll though, someone might want to try.

Compiled with VS 2010:

The demo a5teroids crashes. The debugger says it does at the call to svnprintf in debug.cpp. At that time msg[1000] contains "Error loading sample ". So vsnprintf crashed when trying to put the filename in the string.

<edit>
After a bit of search, the parameter passed to va_start cannot be a reference, so that's the bug.

Did you try putting the example data in the right place?

Speaking of MSVC and MSVC binaries, anybody willing to compile some for allegro5.org?

It shouldn't crash in any case (and from previous posts I guess it doesn't load because I haven't compiled in the ogg add-on). And again, the problem is that it's against the standard passing a reference parameter to va_start (at least in C89, but MSVC doesn't support C99 if that's allowed in C99).

What do you mean by a referene? C doesn't have references.

Assuming you're using it the same as pointer, my man page doesn't say anything about a pointer not being allowed, and it says it's C89... what are you referencing?

a5teroids is a C++ project . But va_start is a function of the C library. Maybe you should go check the code before posting?

Thanks very much for reporting the bug, giving only a vague idea of where it is, and then insulting me while not providing a patch for the problem and expecting me or one of the other developers to fix it.

Have a lovely day.

Well, you certainly didn't even looked at the file I said where the bug is. You didn't even know it's a C++ file (go figure, a file called "debug.cpp" is a C++ file ). So yeah, I don't take very seriously someone that isn't taking attention to what I'm saying.
That file only contains a function consisting of 5 lines, so I don't think I need to give the line number, do I? The problem is that fmt is a reference, and it should be a pointer.

ok, next time I won't report a bug I find. That's what you preffer? Because I'm not a developer of A5. It's the first time I read someone say that in order to report a bug I should also make a patch to fix it.

He'd prefer you didn't insult people.

That was only mentioned because you were being insulting.

You didn't specify what file it happens in. debug_message in debug.cpp is called from about 20 places. Assuming I had to read 20 lines of context to figure out if it's the call you're talking about, I'd have to read 400 lines when you could have just given a line number. I don't take you very seriously if you can't see THAT.

Just a curious question, is there any plans on making a cooler game demo^[1] for showing off Allegro 5 when it's finally released? Because that's one of the main things people use to look for to check if the library works ok. (I certainly do)

Also, I think the main demo shouldn't rely on an OGG codec. Maybe a low quality .wav could be used if there's no OGG support. I don't know if the filesize would increase much in that case, but it certainly seems a bit off that a user can't load the Demo because he didn't choose building one of the addons that require other dependencies.

Where did I insulted him? I said he should read the source I'm refering to before posting. I think that's pretty normal.

Trent: the bug is inside the function itself. It doesn't matter from where it's called. The first time it's called it'll crash that's all.

I had originally used wavs for the music, someone else suggested it or changed it themself.

First you ask for a cooler demo, then say that addons are off limits... You need most of the addons to do anything useful.

I prefer to think otherwise. You can achieve cool stuff with the bare functionality. The speed demo is certainly a step in the right way.

I edited my post after you posted. Anyway, the function should be changed to this:

and all calls to debug_message changed accordingly passing a pointer to a std:string instead of a reference (I'm sure someone with the right tool can automatize that change).

[edit]
Oh and of course debug.hpp should be changed to reflect the change of the function prototype.

The strings are mostly literals ("%d %d" or whatnot), so we can't use a std::string pointer (&"%d %d" doesn't work). It'll have to be changed to use char *.

The code you had posted is very ill. First thing you will see after executing it access violation (if you are lucky).

Don't use std::string in such way. Pass it by constant reference if you must, but you should never have to use pointers.

The whole point is that va_start doesn't work with references. I changed it to a const char * in SVN.

I prepared monolith MSVC build for VS2005, VS2008 and VS2010 in DLL and static versions. Everything was compiled using static run-time libraries (/MT{d} switch).

Final library name was changed, now it is called: allegro-monolith-4.9.20.dll. All add-ons including dependencies are build-in. DLL library have 2MB, after packing using upx size was reduced to 0,9MB. Quite good in my opinion.

Binaries can be downloaded from there.

That's really nice. I can confirm now that it does work with MinGW:

gcc ex_draw_bitmap.c -o ex_draw_bitmap.exe -s -I mingw-includes allegro-monolith-4.9.20.dll

./ex_draw_bitmap.exe

Basically, I don't need to specify any libraries to gcc at all, just my sources and your DLL on the command-line and it magically produces a working .exe. The resulting ex_draw_bitmap.exe was only 13kb and found the allegro-monolith-4.9.20.dll next to itself. So, I'm amazed. None of the compilation hassle you get with static linking (specify 100 different libraries) and very easy runtime distribution (one single DLL).

Can you maybe describe the steps how to create this DLL on the wiki? I think it would be really great if we could distribute something like this for future releases (especially 5.0), for all the lazy people out there.

One problem for MinGW are the include files, the VC ones in the .zip obviously cannot work (things like alplatf.h are all setup for VC with it). So in my test I linked against Mingw includes from a previous install. Not sure how to properly solve this... the mingw headers I used were not in sync with the used DLL but it still seemed to work. Ideally we could make cmake output a set of headers which work with MSVC as well as MinGW, but it requires to get rid of things like alplatf.h.

alplatf.h is a mechanism we retained from A4, but it seems we mostly don't need it any longer. For example instead of #ifdef ALLEGRO_MSVC we could just use #ifdef __MSVC__ (or whatever the standard compiler define is). That way the same header would also work with MinGW.

Also, in my test, ex_draw_bitmap does not depend on many addons so not sure if the monolithic DLL works in all cases... but I hope it does.

I agree.

In fact alplatf.h is the only one file which varry between various compilations. Maybe I do a little hack and I create my own with #ifdef's. So all binary version can share same header files, as you said. I think all recent compilators/platforms can be detected in such way. I know how to do that for MSVC and MinGW, all remaining platforms should be investigated.

That's the reason I used a5teroids for testing. I think it is good idea to create complex test program like in Allegro 4.4.x, which will cover most of the functionality in one pill.

I'm not sure if article on wiki is necessary. Procedure is rather simple but time consuming. Steps are as follows:

1. Download source code for all dependencies. I will list them together with version which I use. At the moment they are:

• physfs-2.0.0 - virtual file system (allegro_physfs.h)

• freetype-2.3.12 - support for various font formats (allegro_ttf.h)

• jpeg-8 - support for JPEG I/O (allegro_image.h)

• libpng-1.4.0 - support for PNG I/O (allegro_image.h)

• libogg-1.1.4 - support for OGG (allegro_audio.h)

• libvorbis-1.2.3 - required by libogg

• flac-1.2.1 - support for FLAC (allegro_audio.h)

• dumb-0.9.3 - support for IT, XM, S3M and MOD (allegro_audio.h)

• openal-soft-1.11.753 - OpenAL an alternative audio library (allegro_audio.h)

• zlib-1.2.3 - required by libpng, physfs and probably one more library

2. Create directory for build and unzip sources to separate directories. In my case dir tree looks like:

\src\physfs-2.0.0*
\src\freetype-2.3.12*
...

3. Now the hard part. We need to browse every library and create our own project/makefiles manually. Some libraries are simple (ex. zlib, ogg), some are not (ex. openal). We need to track down all required preprocessor definitions, setup include, lib, output and intermediate directories.

4. Time for fixes in those libraries. We need to take care of import/export declarations, because only static versions is required.

5. There are special fixes in a few libraries. Detection of integer types should be fixed in OGG. PhysFS would use our zlib library. OpenAL have initialization in DllMain(), it was moved to Allegro.

6. Create project for Allegro which include source of core and all add-ons. Link with all those static libraries and all external dependencies.

7. Build and jump to step 3 until for next iteration.

8. If you are lucky, you have your own monolith build.

This is very brief description of required work to prepare monolith builds. Good news is you need to do this once, later you need only update Allegro sources.

Preparing detail walk-thought is time expensive job, because all work which is already done should be repeated from scratch. I don't have a wish of doing so, because it is repetition. I may consider preparing article while creating automated build process.

Edit:
There is a problem with TLS in latest SVN version of Allegro. a5teroids under Windows and D3D crashes at exit at tls.c:399. That's because there is a try to restore state after driver was freed.
There is callstack:

	a5teroids-debug.exe!al_set_target_bitmap(ALLEGRO_BITMAP * bitmap=0x02b261e8)  Line 399 + 0x1a bytes	C
 	a5teroids-debug.exe!al_restore_state(const ALLEGRO_STATE * state=0x0018f50c)  Line 553 + 0xf bytes	C
 	a5teroids-debug.exe!_al_convert_to_memory_bitmap(ALLEGRO_BITMAP * bitmap=0x02ed9a50)  Line 789 + 0xc bytes	C
 	a5teroids-debug.exe!d3d_release_bitmaps(ALLEGRO_DISPLAY * display=0x02b26000)  Line 1089 + 0x9 bytes	C++
 	a5teroids-debug.exe!d3d_destroy_display_internals(ALLEGRO_DISPLAY_D3D * d3d_display=0x02b26000)  Line 1130 + 0x9 bytes	C++
 	a5teroids-debug.exe!d3d_destroy_display(ALLEGRO_DISPLAY * display=0x02b26000)  Line 1152 + 0x9 bytes	C++
 	a5teroids-debug.exe!al_destroy_display(ALLEGRO_DISPLAY * display=0x02b26000)  Line 112 + 0x12 bytes	C
 	a5teroids-debug.exe!DisplayResource::destroy()  Line 10 + 0xc bytes	C++
 	a5teroids-debug.exe!ResourceManager::destroy()  Line 18 + 0xe bytes	C++
 	a5teroids-debug.exe!done()  Line 185	C++

Yeah, Tomasu reported possible problems with TLS destruction on the mailing list recently as well, this might be related. We need to go over the destruction code and

a) make sure everything is properly freed (in case someone wants to call al_init() multiple times in the same process).

b) more importantly, destroy things in the right order so nothing causes a race condition or crashes.

Not something very hard to do, just boring and needs a bit of time

Michał, would you mind if I hosted your binary package on allegro5.org? We're still in need of a 4.9.20 package for MSVC and this would be good.

I updated build. zlib project had wrong configuration, causing linking failure for static version of library. Now everything should work fine.

There is the link to updated version: allegro-monolith-4.9.20-msvc-bin.7z
MD5: dc8fe3f12cf52076913617da436b6c17

I will try to compile regular Allegro release.

EDIT:
I almost forgot. Yes, you can host those binaries if you wish.

Thanks. Some people (myself included) had problems with an "unknown compression type" when using 7-zip to extract it. I don't know if it's the same with this version. I suspect it's a problem with having too low a version of 7-zip, maybe without some necessary compression method built in...

Ok. I "had fun" with CMake.

Everything is compiled with /MT flags (static run-time).

There it is (almost) regular build of Allegro:
allegro-4.9.20-msvc-bin.zip
MD5: 22aa8a01fb75a4110a08fa0267002b56
All dependencies for static version are linked with related add-ons. The exception is zlib, which is linked with core (because two add-ons use it).

There is monolith build in ZIP archive:
allegro-monolith-4.9.20-msvc-bin.zip
MD5: 8a6f2caa76bccc3096400e4289bbe06a

Are there some plans to reconfigure build system? Now it is pain in the ass if you try to build more than one version of same library.

God, I hope not.

At the same time? Maybe. One after the other is very easy though.

Yes. One by one is easy and annoying. This kind of job should be done by machine. Well, at the moment builds are ready.

Well, I understand. ;-)

Write a batch file / shell script. Not sure if that is possible with MSVC.

I don't think you need to do this, at least with gcc: "6. Create project for Allegro which include source of core and all add-ons. Link with all those static libraries and all external dependencies."

Just build a static configuration of Allegro, then combine the separate liballegro*.a files together with ar.

It is possible. MSVC 2010 uses MSBuild to perform all compilations. Earlier version just wish to use it but still there is no problem.

Yet, for me this is not the case. I have all projects configured in Code::Blocks.

Brilliant! This is what I do for dependencies. I use this approach also for add-ons. Thanks.

Got an issue pop up in this version.

calling al_get_separate_blender when ALLEGRO_SUPPORT_SEPARATE_ALPHA is 0 causes a crash. (I'd hate to go through all my code to add special cases, please fix this)

I did not say that. Myself I actually still have hopes for another build system as I don't like cmake one bit. It's much better than autotools though in every respect and also slightly better than scons. The latter mostly because scons just isn't mature enough (or at least wasn't when we had it as build tool for A5). Most of our scons scripts consisted of stuff which should have been in core scons and not have to be written by us.

Uh! Evert did say that. Sorry Elias.

Nevertheless, I agree with you. I wish to see simple interface to prepare builds. I will checkout scons, maybe some progress has been done.

I think it's already been decided that scons is out, since python is too heavy a dependancy for a build system.

No, Python was not the problem, we actually had a scons build system for quite some time. It is out though for the reasons I said above (I don't think much has changed about that since then).

I'm sure python is and was part of the problem. Install python just to compile Allegro? That's a bit crazy, especially on Windows.

What I meant is, fidling with the build system now that we have something that works well and works well on all platforms (issues with recent versions of MSVC and iPhone not withstanding) is not something we need to worry about (or should be worrying about) at the moment.
If, at some point, we find it better to replace it with something else, we can worry about that when the time comes. For now, the build system we have does the job, does the job well and does the job well on all platforms. Replacing it for the sake of replacing it is a waste of time.

As to CMake, I never was a big fan of it myself. However, having tried it out with some of my own code, I have found it to be ridiculously easy to set up a build system for it that worked properly across different platforms and was easy to maintain and extend. And that's for a project written in FORTRAN, which is generally less well supported than C.

What's wrong with the CMake gui?

No, we had it for some time and it always worked. CMake is a heavier dependency (e.g. on OSX Python is pre-installed with the OS but CMake is an extra download).

With GUI? Nothing that I can complain at.

To prepare release I need to set path to every library by hand, now multiply that by three (three compilers). I hope I don't lose those setups until next release.

Probably I should write script to do such things, but I'm not experienced in CMake and/or shell scripting.

There are some issues in *.cmake scripts:

Where is FLAC_STATIC option? Could it be restored?
I had to dig into *.cmake file to see that library should have '-static' suffix in name.

DXGUID_LIBRARY and VORBISFILE_LIBRARY are ungrouped.

I don't know what CMake gives you on the Linux side of things, but for Windows it would be easier to just write a script that generates project files (like I did for 4.2).

Elias, I know we had it working, and it came up often in meetings that scons would not be the default and one of the reasons was it depends on Python.

Matthew, isn't that exactly what cmake does?

In theory, yes. But CMake is ugly on all platforms and produces horrible MSVC project files (and broken MSVC 10 project files). Basically, if you want something that works well, you have to make it yourself.

Creating an Allegro project builder for MSVC in PHP would only take me a few hours. Learning how to use CMake and fighting with its ridiculous syntax has already taken me more time than that.

Or instead of reinventing the wheel, yet again, you can try and help fix cmake.

I'd much rather have cmake generate projects than some fugly php script.

I'm quite sure the idea was from the beginning that at the time we release A5 there would be only one build system, not multiple ones. CMake won over scons and that's why we removed scons... otherwise we would have removed cmake.

It's not about reinventing the wheel. It's about implementing what you need precisely for the task at hand. Recreating a high-level CMake would be foolish, as I would probably end up with the same set of problems.

From my perspective, it's less effort to write a working build system directly for Allegro than fix CMake. Of course it's better for CMake if I were to fix it, but I would be doing this to make my life easier, not all of humanity.

My PHP program is far less ugly than CMake and easier to maintain, even for somebody who knows nothing about PHP. Even a well written Perl script would be better than CMake when it comes to generating MSVC files for Allegro.

I always thought, CMake is good for windows people . Because Autotools did the job fine on unix systems. But they didn't support MSVC.
Scons is my personal winner, because it uses python and is a Makefile replacement and not a generator.
But the community isn't very active and there are a lot of features missing, CMake supports. So I think CMake is the best choice for the moment.

And KDevelop projects, and Code::Blocks projects, and Makefiles, and XCode projects? That much better eh? Its better to have one system, than several.

Allegro 4.2 and older had several build systems. what a nightmare to maintain. At least with CMake we have one thing to maintain. One. And in general, it just works. If not, we report a bug to CMake, and wait till they fix it (they are pretty good about fixing bugs afaik).

My goal is to make building MSVC binaries as easy as possible. Where have I even hinted at replacing Allegro's current system with a PHP build system that only supports MSVC or introducing multiple build systems into the official Allegro source?

My point is simply for somebody like Michał or me, it is probably less hassle to just write a MSVC specific build system than mess around with CMake or some other general purpose tool. I did it for 4.2, and it was trivial.

This is indeed annoying. The main problem is the Windows practice of separating files by package, rather than by function.

I have an idea to support a 'deps' directory under the main Allegro directory, where you could dump in any dependencies and CMake would be told to search in there. Any volunteers? (see below)

It is supposed to be set automatically now (addons/acodec/CMakeLists.txt line 97).

I think I built a static FLAC library with the provided MSVC project file, and it was named with a _static suffix. If there is a better way to tell the difference between static and import libraries with MSVC, we can do that.

EDIT2: tested with MinGW cross compiler under Linux only.

I tried running a program that would create and save a bitmap but the program would crash whenever I tried to draw to the bitmap. Even if I passed the ALLEGRO_MEMORY_BITMAP, I would still have to create the display to prevent anything from crashing. Is that the correct behavior?

Ah, that's a good reminder. We were supposed to add a dummy graphics driver so you could make command line tools. Some change (I forget which) made a display necessary.

Wait... I found an actual bug?

It's my first. Sweet.

This doesn't solve the problem entirely. In case of static libraries you need to compile them with specified compiler, so I need to put there binaries from VC8, VC9, VC10 and which one will be choose to link with?

It is not if someone compile libFLAC by itself. I didn't have a clue that Allegro require from dependencies to use strict naming scheme.

I don't know any method to distinguish between import and static libraries. They have even same format. Maybe using dlltool such detection is possible.
I have custom builds for all Allegro deps, just to make sure what I'm going to get finally. Maybe I will rename those libraries in future.

The deps directory can either be in the source directory, or in the build directory. i.e. if you have a build directory for VC8 called Bvc8, then you would create Bvc8/deps. Under there you can have Bvc8/deps/include and Bvc8/deps/lib (or if you want, Bvc8/deps/<foo>/include and Bvc8/deps/<foo>/lib for any <foo>).

Yap. This works for me in similar way. In my case all headers are in the original directories:
\src\dumb-0.9.3\include*
\src\freetype-2.3.12\include*
..
That's for two reasons:
- I can quickly do fixes in dependent libraries.
- I don't have to care about copying headers/libs of those libraries. Those are used only while compiling Allegro.

Libs are compiled to:
\build\win32_vc8\lib\

Finally I got:
\build\win32_vc8\bin\allegro-monolith-4.9.20.dll
\build\win32_vc8\bin\allegro-monolith-debug-4.9.20.dll
\build\win32_vc8\include\allegro5*
\build\win32_vc8\include\physfs.h
\build\win32_vc8\lib\allegro-monolith-4.9.20.lib
\build\win32_vc8\lib\allegro-monolith-debug-4.9.20.lib
\build\win32_vc8\lib\allegro-monolith-static-4.9.20.lib
\build\win32_vc8\lib\allegro-monolith-static-debug-4.9.20.lib

This work similar for other compilers/platforms.

So you can see that simple 'deps' directory don't work very well for me, because I already have more complex situation.

I think 'deps' will work if users download precompiled versions of dependent libraries.

If you read a little more carefully, you'll see that it supports a deps directory in the BUILD folder as well. So you can put a deps dir inside \build\win32_vc8, and inside \build\win32_vc10 etc.

Allegro 4.9.20 crashes when I start to use primitives addon. It happens in different places, but always related to operations with default_shader. The following code, which combines video mode change and drawing primitives crahses after first change on al_draw_filled_rectangle.

Crash callstack:

>  allegro_primitives-4.9.dll!_al_setup_default_shader(void * dev=0x001c1f00)  Line 713 + 0x12 bytes  C
   allegro_primitives-4.9.dll!_al_draw_prim_raw(ALLEGRO_BITMAP * texture=0x00000000, const void * vtx=0x0012fd74, const ALLEGRO_VERTEX_DECL * decl=0x00000000, const int * indices=0x00000000, int num_vtx=4, int type=5)  Line 224 + 0x6 bytes  C
   allegro_primitives-4.9.dll!_al_draw_prim_directx(ALLEGRO_BITMAP * texture=0x00000000, const void * vtxs=0x0012fd74, const ALLEGRO_VERTEX_DECL * decl=0x00000000, int start=0, int end=4, int type=5)  Line 440 + 0x26 bytes  C
   allegro_primitives-4.9.dll!al_draw_prim(const void * vtxs=0x0012fd74, const ALLEGRO_VERTEX_DECL * decl=0x00000000, ALLEGRO_BITMAP * texture=0x00000000, int start=0, int end=4, int type=5)  Line 91 + 0x1f bytes  C
   allegro_primitives-4.9.dll!al_draw_filled_rectangle(float x1=200.00000, float y1=200.00000, float x2=300.00000, float y2=300.00000, ALLEGRO_COLOR color={...})  Line 298 + 0xc3 bytes  C
   A5_FullScreenTest.exe!main()  Line 37 + 0xa5 bytes  C++
   A5_FullScreenTest.exe!__tmainCRTStartup()  Line 582 + 0x19 bytes  C
   A5_FullScreenTest.exe!mainCRTStartup()  Line 399  C

Final crash place:

void _al_setup_default_shader(void* dev)
{
   IDirect3DDevice9* device = (IDirect3DDevice9*)dev;
   setup_transforms(device);
   IDirect3DDevice9_SetVertexShader(device, default_shader);
}

On line "IDirect3DDevice9_SetVertexShader(device, default_shader);"

If it's my code, can you tell me what am I doing wrong? And if it's a bug... Well, it's a bug

You are right. There are also non-variable dependencies, for example D3D SDK. Those although can be copied in some pre-build action into deps.

I can rearrange my build directories to take advantage of deps.

Yeah, it's a bug. I'll work on a solution today. For now, a workabout should be to re-init the primitives addon after the mode change, I think. Do that by calling these:

al_shutdown_primitives_addon();
al_init_primitives_addon();

Incidentally... is it in our spec to be able to call al_init_whatever multiple times with no error?

Thanks, SiegeLord! Also, my other program crashes with 4.9.20 when I exit it without even changing video mode in

void _al_destroy_default_shader(void)
{
   if(default_shader) {
      IDirect3DVertexShader9_Release(default_shader);
      default_shader = 0;
   }
}

at "IDirect3DVertexShader9_Release(default_shader);". I can't reproduce it now, because I reverted back to 4.9.19 for release of my own version, but I will try to supply more details later if you need them.

Heya folks,

I've been working on getting back into things and I'm messing around with Allegro 5. I have been working on a simple window for some tests, and up until today everything was compiling fine. Actually it compiles just fine, except that I started getting some warnings that I did not get before. The thing is I moved my files over to a new project, and I'm thinking I just missed something in the project settings.

I'm using VS 2008 on windows Vista, and have built allegro and installed from SVN.
For the Inputs in the linking area, I use:

kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib allegro_image-static.lib allegro-static.lib allegro_main-static.lib allegro_dialog-static.lib winmm.lib psapi.lib "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x86\dxguid.lib" "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x86\d3d9.lib" "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x86\dinput8.lib" opengl32.lib glu32.lib $(NOINHERIT)

I also define ALLEGRO_STATICLINK

the warnings I'm getting are:

1>user32.lib(USER32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>user32.lib(USER32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>gdi32.lib(GDI32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>gdi32.lib(GDI32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>winspool.lib(WINSPOOL.DRV) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>winspool.lib(WINSPOOL.DRV) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>shell32.lib(SHELL32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>shell32.lib(SHELL32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>ole32.lib(ole32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>ole32.lib(ole32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>oleaut32.lib(OLEAUT32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>oleaut32.lib(OLEAUT32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>uuid.lib(msp_i.obj) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>uuid.lib(seo_i.obj) : warning LNK4006: _IID_IEventDispatcher already defined in uuid.lib(iid.obj); second definition ignored
1>comdlg32.lib(COMDLG32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>comdlg32.lib(COMDLG32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>advapi32.lib(ADVAPI32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>advapi32.lib(ADVAPI32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>winmm.lib(WINMM.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>winmm.lib(WINMM.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>psapi.lib(PSAPI.DLL) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>psapi.lib(PSAPI.DLL) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>d3d9.lib(d3d9.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>d3d9.lib(d3d9.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>dinput8.lib(DINPUT8.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>dinput8.lib(DINPUT8.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>opengl32.lib(OPENGL32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>opengl32.lib(OPENGL32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible
1>glu32.lib(GLU32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored
1>glu32.lib(GLU32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible

I pulled the libraries for input out of one of the examples, so I am thinking I don't need the allegro_dialog lib, and if I do not need that do I need GLU32?

My project is a small library that I will import into my bigger project.

I must have missed something when I moved everything into a new project. Appreciate any ideas.

By the way, I notice on the wiki there isn't a page for installing Allegro 5 from SVN using cmake for VS, but I had absolutely no problems with it here.

thanks

WG

wiseguy: if I understood you correctly, your project is just a static library, isn't it? In that case you don't have to put anything in the input area of the linker. You link against all libraries you use when you create an executable (or a dll). So when you use you lib in a project that generates an executable, it's then when you put all those libraries (and your) in the linker input.

Ah, man now I feel stupid. Like I said I'm just getting back into things after having a lot of time off from programming. Thanks for the help.

WG

Well, I was able to solve my problem with the D3D driver and CG.

Apparently, calling CGD3D9BindProgram(NULL) doesn't do what I thought it did. It doesn't set the actual vertex/pixel shader program as NULL, unlike the CGGL call with NULL. The Shader program was being used throughout the whole program, which provoked really weird behaviour. You need to manually set the actual VertexShader and PixelShader program by hand with the D3D9Device with al_get_d3d_device(). Just letting people know about that, and I don't know if TrentG ran into a similar problem.

I use effects in the shader addon, they're easier to work with I think. You just do something like this:

      // set shader variables
      UINT required_passes;
      effect->Begin(&required_passes, 0);
      effect->BeginPass(0);
      // draw
      effect->EndPass();
      effect->End();

Of course if you actually have an effect which requires multiple passes you just loop from BeginPass to EndPass (including drawing). But since OpenGL shaders don't work like that (it's a higher level abstraction and you can get the same effect, though), neither does the shader addon.

That was one of the main reasons I didn't use the effect in the first place. Since there was no "pass" concept on the GLSL shader and it needed to maintain platform AND display driver neutrality, I ditched that off. I gave support for taking the Vertex/Pixel shader program out of the effect file, and using it individually.

To solve your problem, well, you could provide an specific function, like al_use_shader_pass(int) or something like that. You should just need to document that it only works for CG effects, and are provided in case the user wants them.

I don't think there's really a point in keeping things as neutral as possible between CG and GLSL. It should be neutral depending on the display driver, but not between different shader formats. Mostly, because CG users can use it for both Direct3D and OpenGL(I just did this with Arkab, now it works well on both drivers).

Just my 2 cents. It's your own add-on after all, unless you need it, you don't really need to do this.

It seems to me that in OpenGL, locking bitmaps does not work properly. For example, take this code:

This prints -256 for region->pitch, which does not seem sensible to me! In Direct3D it works fine and prints 256.

At first I thought it was a problem with my wrapper, but it's not. Sorry if it's fixed in SVN.... I don't have any SVN tools on this computer.

-256 is the correct pitch. OpenGL textures are upside down (i.e. pixel 0/0 is the bottom-left pixel instead of the top-left pixel). So to avoid a CPU intense flip of the whole texture, we point region->data to the end of the buffer and use a negative pitch. Accessing the pixels with data[x + y * pitch] will still work.

I've always wondered why Allegro bitmaps are upside down (0,0 being top left instead of bottom left), it is always annoying because you would generally want the bottom to be 0 (so that someone starting on the bottom of the screen [which is where you usually start] can start at 32,0)

I see! Sorry for the confusion on my part then

(PC) computer graphics memory addresses the top left pixel as 0,0. Has for the past 30 years at least.

That's because the old time PC people were used to starting at top left for text screens, where it made sense.

I just want to bump one bug.

Currently D3D driver crashes while closing display. Elias said something about revisiting destruction order. I'm don't know internal Allegro design, so I don't think I'm good man for the job.

You can find more info there.

I haven't forgotten about that one

It's next on my list as soon as the primitives issues are taken care of.

I got around to building some 4.9.20 binaries for MSVC tonight. They're up at http://allegro5.org.

I tried swapping in this latest build (MSVC) and am getting some unique compile errors:

1>------ Build started: Project: A5Template, Configuration: Release Win32 ------
1>  main.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(27): error C2059: syntax error : '__cdecl'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(27): error C2091: function returns function
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(27): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(27): warning C4183: 'int64_t': missing return type; assumed to be a member function returning 'int'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(28): error C2061: syntax error : identifier 'int64_t'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(58): error C2143: syntax error : missing ';' before '__cdecl'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(58): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(58): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(59): error C2061: syntax error : identifier 'int64_t'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(63): error C2143: syntax error : missing ';' before '__cdecl'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(63): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(63): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(17): error C2146: syntax error : missing ';' before identifier '__pad1__'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(17): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(17): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(18): error C2146: syntax error : missing ';' before identifier '__pad2__'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(18): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(18): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/events.h(173): error C2146: syntax error : missing ';' before identifier 'count'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/events.h(173): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/events.h(173): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/timer.h(58): error C2143: syntax error : missing ';' before '__cdecl'
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/timer.h(58): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/timer.h(58): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/timer.h(59): error C2061: syntax error : identifier 'int64_t'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I'm sure I've heard that MSVC 10 can't build or use Allegro 5 yet, without difficulty... I haven't tried it yet myself.

I haven't had problems with any previous A5 builds.

Should I just stick with 4.9.19? It worked pretty well.

Are you using the binaries or did you compile it yourself?

I'm using those binaries from allegro5.org

Wow that's weird. I didn't do anything differently. I've compiled with MSVC 9 2008 all along. I need to install 2010 and see what's wrong.

Yea. I just overwrote the previous files like I would with any other of your new builds. Peculiar.

Ok, here's a patch that should fix it. I'll see if it's been done in svn and apply it there if not.

Isn't stdint.h included elsewhere?

Apparently not, because it doesn't work.

If you have a better solution, by all means... I avoid MSVC when I can.

I think all he needs to do is this in alplatf.h:

#define ALLEGRO_HAVE_STDINT_H

Since you created it with MSVC 9, it is left commented out. (I guess ... it's in 10.) It's not really a bug... the headers aren't guaranteed to be compatible across different compilers or platforms.

Edit: Or maybe MSVC 9 has stdint.h too? I don't remember for sure, but it seems like it shouldn't be a new problem to 4.9.20. I'm pretty sure I've compiled for 9 and 10 without problems.

Yeah, that sounds about right.

Well, base.h includes alconfig.h which includes astdint.h which conditionally includes stdint.h.

For MSVC 10, ALLEGRO_HAVE_INTTYPES_H should not be defined and ALLEGRO_HAVE_STDINT_H should be (in alplatf.h).

Edit: Yeah, your file is missing that define. If you change your alplatf.h in the binary package to look like:

#if _MSC_VER >= 1600
#define ALLEGRO_HAVE_STDINT_H 
#endif

it should work for 9 and 10. Although, I thought MSVC 9 had stdint (but was missing int64/uint64)... Can you check your VC\include folder for it? (Nevermind, it was introduced with 10.)

Edit 2:

What's confusing is why almsvc.h has:

#if _MSC_VER < 1600
#define int64_t      signed __int64
#define uint64_t     unsigned __int64
#endif

I know I added the #if _MSC_VER < 1600 check, but it seems if those two #defines were with the rest of the guesswork in astdint.h, it wouldn't even be necessary.

Anyway, the proper thing for Mark to do is add ALLEGRO_HAVE_STDINT_H to alplatf.h.

K, that did it. Thanks, guys. I was also getting GLINT errors when including allegro_opengl.h, also related to the int not being defined.

MSVC 2010 in fact do have stdint.h, all previous version does not.

That's main reason why I provided different headers sets in my builds.

This should be fixed in the SVN now... although upgrading to SVN might be troublesome since we just... broke every single A5 program out there

I've haven't had any D3D crash. Am I missing something? I have noticed that I am unable to create an OpenGL display, though. I need to spend some time on it before I can report exactly what's happening with that.

Nice, I will check it out. : )

Wow. Nice crash. Allegro now crashes on destroying dummy display in al_uninstall_system. I tried both: D3D and OpenGL, same result.

Can you try that again? I put the free too late.

Now it is OK. Thanks.