Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 5.0.0rc1 released!

This thread is locked; no one can reply to it. rss feed Print
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,
Paul Suntsov, Peter Wang.

Graphics:

- Make al_resize_display keep the original resolution (or change back) if it
can't set the users request, on Windows.

- Do not emit ALLEGRO_DISPLAY_RESIZE events from the Windows and X11 display
drivers when using al_resize_display.

- [X11] Make al_get_num_display_modes and al_get_display_mode work if the
adapter is set to default. Right now there was no way to query the modes of
the default monitor.

- [X11] Use _NET_WM_STATE_FULLSCREEN hint for "true" fullscreen displays.
Enable mouse grabbing in fullscreen modes.

- Added ALLEGRO_EVENT_DISPLAY_ORIENTATION and implement it on iOS.

- Dennis Busch fixed a problem with displays not showing up on the
primary display by default in some dual head setups, on Windows.

- Increase the precision of texture coordinate deltas in the software triangle
renderer, from floats to doubles.

- 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
pointer inside, or if the mouse routines are installed after a display is
created (X11, Windows).

- 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
work reliably. User event sources must be destroyed manually.

Filesystem:

- Make al_get_fs_entry_name and al_get_current_directory return strings
instead of ALLEGRO_PATH.

- Make al_make_directory create parent directories as needed.

- Fix al_create_fs_entry to not trim the root path "/" down to the empty
string with the stdio backend.

Path routines:

- Remove al_make_path_absolute and replace it by al_rebase_path.

- Remove undocumented behavior of setting a default organization name of
"allegro" for all apps.

- 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
loop. It's a requirement of D3D, else you can get crashes as I was when
resetting the device (like tabbing away from a fullscreen app).

- Add some missing standard entries to the OS X menu bar (the "hide", "hide
others" and the window list, mainly).

Audio addon:

- Automatically stop sample instances which point to a buffer of a sample
which is about to be destroyed with al_destroy_sample.

- alsa: Resume properly after suspending.

Image I/O addon:

- Make GDI+ support compile cleanly with the headers that come with MinGW
package w32api-3.15.

- 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
portability.

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
recent version of Pandoc on Windows.

- 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
avatar

Quote:

Furinkan increased to level 5.0.0rc1!

Furinkan is trying to learn A5,
but Furinkan can only learn 4 gfx apis!

Forget an older gfx api to learn A5?
>yes no

Which one?
Alleg4 GL
>DX3D GX

Furinkan forgot DX3D and...

Furinkan learned A5!

;D

Karadoc ~~
Member #2,749
September 2002
avatar

milestone.

-----------

Thomas Fjellstrom
Member #476
June 2000
avatar

Achievement Gained: Allegro 5.0rc1!

video

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Mark Oates
Member #1,146
March 2001
avatar

We should all drink a beer in celebration.

Quote:

Report correct initial mouse position if a display is created with the mouse
pointer inside, or if the mouse routines are installed after a display is
created

nice. 8-)

furinkan
Member #10,271
October 2008
avatar

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

Allegro needs more public exposure.

@Thomas:
Nice choice on the foamy!

Elias
Member #358
May 2000

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 :P

--
"Either help out or stop whining" - Evert

Trezker
Member #1,739
December 2001
avatar

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

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

Thomas Fjellstrom
Member #476
June 2000
avatar

Trezker said:

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

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

tobing
Member #5,213
November 2004
avatar

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

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

tobing
Member #5,213
November 2004
avatar

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
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

tobing
Member #5,213
November 2004
avatar

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
avatar

Seems Allegro 5 might be released before DNF after all. 8-)

(Febreaury/March 2011)

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

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?

--
"Either help out or stop whining" - Evert

tobing
Member #5,213
November 2004
avatar

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
avatar

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
avatar

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?

al_get_path_extension

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

tobing
Member #5,213
November 2004
avatar

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
avatar

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.
It's true that you don't get default values, but it's very easy to emulate Allegro 4's config routines on top of Allegro 5 functions if you really want that feature - and in fact, I've done that for a project I'm porting from Allegro 4 to Allegro 5 (have a look at the demos/speed/a4_aux.c file for the basic idea).

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
avatar

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
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730



Go to: