|
|
|
| Some really obnoxious A5 questions |
|
Edgar Reynaldo
Major Reynaldo
May 2007
 |
As long as it's not #include <allegrue.h>
then I'm fine with it. And just why is it a stiletto can't kill a grue anyway? My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
|
Elias
Member #358
May 2000
|
Quote: Go with the Linux (well, I know they have it at least) library way of either file name or library version, and use allegro2.h as this is the second version of the API for Allegro. Then the next Allegro version that has to break backward compatibility can be allegro3.h I know the suggested way to handle libraries is like that somewhere... It's just what we are doing - only using 5 instead of 2. We could re-version Allegro 5 into Allegro 2, and retro-actively fix our versioning tree like this:
As you say, the fixed tree would better reflect the API changes. However, the versions historically are as they are, so Allegro 5 will actually be the 5th major API revision and using 2 as major version would just be confusing. -- |
|
Thomas Fjellstrom
Member #476
June 2000
 |
Quote: Go with the Linux (well, I know they have it at least) library way of either file name or library version, and use allegro2.h as this is the second version of the API for Allegro. Thats just plain confusing. And that "library version" is JUST for the .so files. Its not supposed to be taken up anywhere else. I think if we do change it, we go with allegroV or something. Unless someone can come up with something better. Quote: As you say, the fixed tree would better reflect the API changes. I don't think its a very accurate depiction. Allegro 3 was a fairly large change fwir, and Allegro 4 added actual OS ports. -- |
|
Evert
Member #794
November 2000
 |
I don't remember if the change from 8-bit only to 8-bit and high colour graphics happened between 1 and 2 or between 2 and 3, but that changed the API (a bit anyway). So really, from an API versioning perspective, 5 is entirely right. |
|
Elias
Member #358
May 2000
|
Yes, I meant, if the first number in the version is to reflect a major API change, then 4.x -> 5.x actually will be a much bigger change than any earlier versions. E.g. the 1.0 demo source looks like it could compile in 4.3.10 with only a few minor adjustments. Anyway, I think an Allegro 6 actually only would make sense if there was a similar big API change than with A5 - so it won't happen anytime soon. Once compatibility breaks (which shouldn't be soon either), we will switch from 5.0.x to 5.1.x and so on. -- |
|
Thomas Harte
Member #33
April 2000
 |
Quote: I don't remember if the change from 8-bit only to 8-bit and high colour graphics happened between 1 and 2 or between 2 and 3, but that changed the API (a bit anyway). Between 2 and 3, but the change from 1 to 2 was even larger. Prior to version 2, sprites were a separate data structure to bitmaps. The distinction is probably why we now have a family of functions named like draw_sprite and another named like masked_blit. EDIT: Version 2.0 was the first version I used, by the way. [My site] [Tetrominoes] |
|
axilmar
Member #1,204
April 2001
|
Quote: I hate it. What "ng" really mean anyway? (I know, it's meant to be Next Generation or something like that). What do you do when you make a new major revision? nng? Calling the new version of foo foo_new or new_foo or something like that not only looks stupid, you've painted yourself in a corner for when you have something even newer. I agree with you! my suggestion was a little joke...I was reading about Star Trek before posting that. Actually, allegro5.h is fine. |
|
Evert
Member #794
November 2000
|
Quote: Anyway, I think an Allegro 6 actually only would make sense if there was a similar big API change than with A5 - so it won't happen anytime soon. Once compatibility breaks (which shouldn't be soon either), we will switch from 5.0.x to 5.1.x and so on. Good points, I agree. Quote: my suggestion was a little joke...I was reading about Star Trek before posting that.
Well thank god you didn't propose Allegro Enterprise then. |
|
axilmar
Member #1,204
April 2001
|
Quote: Well thank god you didn't propose Allegro Enterprise then I thought about it though ;-). |
|
_XDnl_
Member #10,297
October 2008
 |
allegro_ng, allegro_ngx, allegroX, allegrou, or anything else, I think that developers must keep in mind that Allegro is the Italian for "quick, lively, bright". I prefer to use Allegro for its simplicity....
|
|
weapon_S
Member #7,859
October 2006
 |
Oh, good now you're talking about a subject of my level again |
|
ImLeftFooted
Member #3,935
October 2003
 |
I say keep it allegro.h. Make a macro ALLEGRO_PRE_5 or something when defined does whatever thing is causing this version incompatibility. Macros are better for versioning than header names. @weapon: You should be more grateful of the hard work these guys are putting in. This new version is going to do some very cool things. |
|
SiegeLord
Member #7,827
October 2006
 |
I think there is already an allegro.h and allegro5.h just includes that. So, if you wanted you could just use #include <allegro.h> and it should include the right header if you only have A5 installed. You should also be able to do #include <allegro5/allegro.h>. At the same time, I don't think you can do #include <allegro/allegro.h>... And yes, we should have an allegro dev appreciation day... "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
weapon_S
Member #7,859
October 2006
|
Whoa, where did I come over as ungrateful? I may not seem super enthousiastic over the new Allegro: but I guess that is because I don't use most functionality mentioned. (I don't even use add-ons right now.) |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote:
Things I like until now: integrated thread API/events API, "magical" optimizations for blitting (the bitmap-type-thingy), modular extendability, All of that stuff you say you like is pretty much the entirety of the Core part of Allegro 5. So it is a bit strange that you're unenthusiastic. Anything else is in addons like image loading, and sound loading/streaming/playing, etc. -- |
|
|
|
)
