|
|
|
| Allegro 4.9.20 released |
|
Thomas Fjellstrom
Member #476
June 2000
 |
Oscar Giner said: ok, next time I won't report a bug I find. That's what you preffer? He'd prefer you didn't insult people. Quote: 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. That was only mentioned because you were being insulting. -- |
|
Trent Gamblin
Member #261
April 2000
 |
Oscar Giner said:
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. 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.
|
|
Dario ff
Member #10,065
August 2008
 |
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. References
TranslatorHack 2010, a human translation chain in a.cc. |
|
Oscar Giner
Member #2,207
April 2002
 |
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. -- |
|
Trent Gamblin
Member #261
April 2000
|
I had originally used wavs for the music, someone else suggested it or changed it themself.
|
|
Thomas Fjellstrom
Member #476
June 2000
|
First you ask for a cooler demo, then say that addons are off limits... You need most of the addons to do anything useful. -- |
|
Dario ff
Member #10,065
August 2008
|
Thomas Fjellstrom said: 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. TranslatorHack 2010, a human translation chain in a.cc. |
|
Oscar Giner
Member #2,207
April 2002
|
I edited my post after you posted. Anyway, the function should be changed to this: 1void debug_message(const std::string* fmt, ...)
2{
3 /*
4 Configuration& cfg = Configuration::getInstance();
5 if (!cfg.debuggingEnabled())
6 return;
7 */
8
9 va_list ap;
10 char msg[1000];
11
12 va_start(ap, fmt);
13 vsnprintf(msg, (sizeof(msg)/sizeof(*msg))-1, fmt.c_str(), ap);
14 printf("%s", msg);
15}
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] -- |
|
Trent Gamblin
Member #261
April 2000
|
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 *.
|
|
Michał Cichoń
Member #11,736
March 2010
|
Oscar Giner said: Anyway, the function should be changed to this: 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. "God starts from scratch too" |
|
Trent Gamblin
Member #261
April 2000
|
The whole point is that va_start doesn't work with references. I changed it to a const char * in SVN.
|
|
Michał Cichoń
Member #11,736
March 2010
|
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. "God starts from scratch too" |
|
Elias
Member #358
May 2000
|
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. -- |
|
Michał Cichoń
Member #11,736
March 2010
|
Elias said: That's really nice.
I agree. Elias said: 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. 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. Elias said: Also, in my test, ex_draw_bitmap does not depend on many add-ons so not sure if the monolithic DLL works in all cases... but I hope it does. 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. Elias said: 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. 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:
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: 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++
"God starts from scratch too" |
|
Elias
Member #358
May 2000
|
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 -- |
|
Trent Gamblin
Member #261
April 2000
|
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.
|
|
Michał Cichoń
Member #11,736
March 2010
|
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 I will try to compile regular Allegro release. EDIT: "God starts from scratch too" |
|
Trent Gamblin
Member #261
April 2000
|
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...
|
|
Michał Cichoń
Member #11,736
March 2010
|
Ok. I "had fun" with CMake. Everything is compiled with /MT flags (static run-time). There it is (almost) regular build of Allegro: There is monolith build in ZIP archive: 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 starts from scratch too" |
|
Evert
Member #794
November 2000
 |
Michał Cichoń said: Are there some plans to reconfigure build system? God, I hope not. Quote: Now it is pain in the ass if you try to build more than one version of same library. At the same time? Maybe. One after the other is very easy though. |
|
Michał Cichoń
Member #11,736
March 2010
|
Yes. One by one is easy and annoying. This kind of job should be done by machine. Well, at the moment builds are ready. Elias said: God, I hope not. Well, I understand. ;-) "God starts from scratch too" |
|
Peter Wang
Member #23
April 2000
|
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.
|
|
Michał Cichoń
Member #11,736
March 2010
|
Peter Wang said: Write a batch file / shell script. Not sure if that is possible with MSVC. 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. Peter Wang said: 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. Brilliant! This is what I do for dependencies. I use this approach also for add-ons. Thanks. "God starts from scratch too" |
|
Japa Illo
Member #11,661
January 2010
|
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)
|
|
Elias
Member #358
May 2000
|
Quote: Elias said: God, I hope not. 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. -- |
|
|
|
