|
Allegro 5.0.0rc1 released! |
Peter Wang
Member #23
April 2000
|
http://sourceforge.net/projects/alleg/files/allegro-prerelease/5.0.0-rc1/ Quote:
Changes from 4.9.22 to 5.0.0 RC1 (November 2010) The developers this time were: Trent Gamblin, Evert Glebbeek, Elias Pschernig, Graphics: - Make al_resize_display keep the original resolution (or change back) if it - Do not emit ALLEGRO_DISPLAY_RESIZE events from the Windows and X11 display - [X11] Make al_get_num_display_modes and al_get_display_mode work if the - [X11] Use _NET_WM_STATE_FULLSCREEN hint for "true" fullscreen displays. - Added ALLEGRO_EVENT_DISPLAY_ORIENTATION and implement it on iOS. - Dennis Busch fixed a problem with displays not showing up on the - Increase the precision of texture coordinate deltas in the software triangle - Remove al_get_frontbuffer(). It wasn't implemented anywhere. - Implement min/mag filter and mipmap flags for Direct3D. Input: - Report correct initial mouse position if a display is created with the mouse - John Murphy fixed improperly mapped axes on the Windows joystick driver. Events: - Do not register user event sources with the destructor system as it cannot Filesystem: - Make al_get_fs_entry_name and al_get_current_directory return strings - Make al_make_directory create parent directories as needed. - Fix al_create_fs_entry to not trim the root path "/" down to the empty Path routines: - Remove al_make_path_absolute and replace it by al_rebase_path. - Remove undocumented behavior of setting a default organization name of - Correctly return standard paths as directories on OS X. Threads: - Rename al_wait_cond_timed to al_wait_cond_until to match al_wait_cond_until. Config routines: - Add a blank line between sections when writing out a config file. Other core: - Move the Windows event loops back into the same thread as the D3D event - Add some missing standard entries to the OS X menu bar (the "hide", "hide Audio addon: - Automatically stop sample instances which point to a buffer of a sample - alsa: Resume properly after suspending. Image I/O addon: - Make GDI+ support compile cleanly with the headers that come with MinGW - Speed up PNG and BMP saving, and NSImageFromAllegroBitmap loading. TTF addon: - Add a flag for loading TTFs without anti-aliasing (ALLEGRO_TTF_MONOCHROME). PhysicsFS addon: - Make PhysFS implementation of al_get_current_directory return "/", not NULL. Primitives addon: - Fix several failed sub-bitmap related unit tests on Windows. - Made thick outlined triangles look nicer when the triangles are very thin. - Add a debug-only check for primitives addon initialization to aid in code Examples: - Added example demonstrating the effect of premultiplied alpha. - Make 'F' toggle fullscreen window in SPEED (in-game). - Minor improvements to the a5teroids demo. Documentation: - Many documentation updates. - Add list of contributors and a readme for packagers. - Make make_doc tool build cleanly on MSVC, and work around a problem with - Improve styling of PDF output. - Add generated man pages to archives. Bindings: - Implemented array types in the Python wrapper.
|
Japa Illo
Member #11,661
January 2010
|
thank you! will give it a go.
|
furinkan
Member #10,271
October 2008
|
Quote: Furinkan increased to level 5.0.0rc1! Furinkan is trying to learn A5, Forget an older gfx api to learn A5? Which one? Furinkan learned A5!
|
Karadoc ~~
Member #2,749
September 2002
|
milestone. ----------- |
Thomas Fjellstrom
Member #476
June 2000
|
-- |
Mark Oates
Member #1,146
March 2001
|
We should all drink a beer in celebration. Quote: Report correct initial mouse position if a display is created with the mouse nice. -- |
furinkan
Member #10,271
October 2008
|
I should get on Mr. Harbour's forums and pester him to update his book! Allegro needs more public exposure. @Thomas: |
Elias
Member #358
May 2000
|
Mark Oates said: We should all drink a beer in celebration. I'll save that for when the final 5.0.0 is out, RC1, RC2, RC3, ... is just a different way of naming versions -- |
Trezker
Member #1,739
December 2001
|
Well, RC should at least mean no more API changes right? Adding functions after disallowing changes would be rather risky though. |
Thomas Fjellstrom
Member #476
June 2000
|
Trezker said: Well, RC should at least mean no more API changes right? 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. -- |
tobing
Member #5,213
November 2004
|
Alas, I hoped that ALLEGRO_VERSION would be 5 now. When will that be changed? |
Thomas Fjellstrom
Member #476
June 2000
|
tobing said: 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. -- |
tobing
Member #5,213
November 2004
|
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. |
Thomas Fjellstrom
Member #476
June 2000
|
tobing said: 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. -- |
tobing
Member #5,213
November 2004
|
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. |
Dario ff
Member #10,065
August 2008
|
Seems Allegro 5 might be released before DNF after all. (Febreaury/March 2011) TranslatorHack 2010, a human translation chain in a.cc. |
Elias
Member #358
May 2000
|
tobing said: 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. 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? -- |
tobing
Member #5,213
November 2004
|
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. |
kenmasters1976
Member #8,794
July 2007
|
Nice. Downloading.
|
tobing
Member #5,213
November 2004
|
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. |
SiegeLord
Member #7,827
October 2006
|
tobing said: I'm wondering... where have pack files gone? Am I supposed to use zip files instead? Yep. With the PhysFS addon. Quote: What about the nice config file routines, it seems that I have to re-implement things using the new functionality? Is this not good enough for you? Quote: Why are useful functions like get_extension not there any longer? "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
tobing
Member #5,213
November 2004
|
Zip files are OK, but I liked pack files a lot, too. Quote: Is this [alleg.sourceforge.net] not good enough for you? 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. Quote: al_get_path_extension [alleg.sourceforge.net] 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. |
Evert
Member #794
November 2000
|
tobing said: 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.
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. Quote: 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. 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). |
SiegeLord
Member #7,827
October 2006
|
tobing said: 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. Yes. The new way is more powerful (marginally) but less convenient, no argument there. Quote: 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. 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. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Thomas Fjellstrom
Member #476
June 2000
|
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. -- |
|
|