|
|
|
| Allegro 4.9.20 released |
|
Karadoc ~~
Member #2,749
September 2002
 |
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" ..\ 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. ----------- |
|
Matthew Leverton
Supreme Loser
January 1999
 |
wav is the only built-in audio codec, so it can play them. |
|
kenmasters1976
Member #8,794
July 2007
|
Karadoc ~~ said: ex_draw seems to have "circles" and "filled circles" the wrong way around... Indeed!!!. Karadoc ~~ said: I'll look into how to compile the ogg / png stuff when I want to use it. You'll have to install the necessary libs (like libpng, libvorbis, libogg) and then rebuild Allegro.
|
|
Trent Gamblin
Member #261
April 2000
 |
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.
|
|
Mark Oates
Member #1,146
March 2001
 |
Thanks, Trent! Very helpful. Have you made any progress on the shader addon? -- |
|
Trent Gamblin
Member #261
April 2000
|
@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.
|
|
Mark Oates
Member #1,146
March 2001
|
Trent Gamblin said: If you want it I can upload it somewhere. yes, please! -- |
|
Trent Gamblin
Member #261
April 2000
|
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.
|
|
Michał Cichoń
Member #11,736
March 2010
|
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:
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 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:
Note: PhysFS header file was modified to honor ALLEGRO_STATIC definition. I'm interested about you opinion about this monolith build. "God starts from scratch too" |
|
Dario ff
Member #10,065
August 2008
 |
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. TranslatorHack 2010, a human translation chain in a.cc. |
|
Michał Cichoń
Member #11,736
March 2010
|
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. "God starts from scratch too" |
|
Evert
Member #794
November 2000
 |
Michał Cichoń said: This is a monolith build, that means only one DLL/lib is produced as a result of compilation.
Best to rename the library (the file) in that case, otherwise it'll get confusing at some point. |
|
Matthew Leverton
Supreme Loser
January 1999
|
Michał Cichoń said: Now I just click build and voila. 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. |
|
Michał Cichoń
Member #11,736
March 2010
|
Evert said: Best to rename the library (the file) in that case, otherwise it'll get confusing at some point. I have no plan to distribute further my compiled version at the moment. Evert said: 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. 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. Matthew Leverton said: Yes, CMake is basically just a nuisance under Windows / MSVC. Agree. Matthew Leverton said: Anyway, the best solution is to just not distribute a DLL for your monolithic build. But if you do, you need to rename it. 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. Matthew Leverton said: 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. 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. "God starts from scratch too" |
|
ks
Member #1,086
March 2001
|
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.
|
|
Matthew Leverton
Supreme Loser
January 1999
|
Michał Cichoń said: I have no plan to distribute further my compiled version at the moment. 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. |
|
Michał Cichoń
Member #11,736
March 2010
|
ks said: 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. I think there will be no problem with MinGW build. Matthew Leverton said: 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 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. "God starts from scratch too" |
|
Elias
Member #358
May 2000
|
Michał Cichoń said: I think there will be no problem with MinGW build. 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. -- |
|
Oscar Giner
Member #2,207
April 2002
 |
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> -- |
|
Trent Gamblin
Member #261
April 2000
|
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?
|
|
Oscar Giner
Member #2,207
April 2002
|
Trent Gamblin said: Did you try putting the example data in the right place? 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). -- |
|
Trent Gamblin
Member #261
April 2000
|
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?
|
|
Oscar Giner
Member #2,207
April 2002
|
a5teroids is a C++ project -- |
|
Trent Gamblin
Member #261
April 2000
|
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.
|
|
Oscar Giner
Member #2,207
April 2002
|
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 Trent Gamblin said: while not providing a patch for the problem and expecting me or one of the other developers to fix it. 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. -- |
|
|
|
. But va_start is a function of the C library. Maybe you should go check the code before posting?
). So yeah, I don't take very seriously someone that isn't taking attention to what I'm saying.