Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Some really obnoxious A5 questions

Credits go to Dustin Dettmer, Edgar Reynaldo, Elias, Evert, Johan Halmén, Kitty Cat, Matt Smith, Milan Mimica, SiegeLord, Thomas Fjellstrom, and Thomas Harte for helping out!
This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Some really obnoxious A5 questions
Edgar Reynaldo
Member #8,592
May 2007
avatar

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:

  • 1.0 -> 1.0.0

  • 2.0 -> 1.2.0

  • 3.0 -> 1.3.0

  • 3.12 -> 1.3.12

  • 4.0.0 -> 1.4.0

  • 4.2.0 -> 1.6.0

  • 4.3.10 -> 1.7.10

  • 4.4.0 (not released yet) -> 1.8.0

  • 4.9.5 -> 1.99.5

  • 5.0.0 (not released yet) -> 2.0.0

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.

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

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

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

Evert
Member #794
November 2000
avatar

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).
I'm sure there's some significant change between the other release as well, a look at the change log should clear that up.
The change 3->4 changed the API in the sense that there were new platform specific functions and some new platform neutral functions (display colour depth, windowed mode, close buttons, lock_bitmap()).

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.

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

Thomas Harte
Member #33
April 2000
avatar

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.

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
avatar

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
avatar

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
avatar

Oh, good now you're talking about a subject of my level again :P
I think I caught somewhere the phrase "if you want to do that, keep allegro 4". So maybe really rename the library. Allegro Live Library? AlLive? ALL?
(That is soo fucking gay >_<) Crescendo? Power Allegro? (Pall >_< I'm going gay again) But that would imply prolonged maintenance of the "allegro 4 branch". And I guess, the developers being fed up with that, is the reason, they changed it.
So why wasn't the naming an issue in the past???
Because they didn't have a kickass forum ;)
BTW Dr. Vannerhouer's DFR is outdated. He doesn't clearly separate heredity and environment, which is very important for error correction. I'd measure in good old stupidity. (Speaking of which: GNU stupid-eval totally chokes on this thread :-/)

Dustin Dettmer
Member #3,935
October 2003
avatar

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
avatar

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... :D

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

weapon_S
Member #7,859
October 2006
avatar

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.)
Things I like until now: integrated thread API/events API, "magical" optimizations for blitting (the bitmap-type-thingy), modular extendability,
better GPU support and I think I like the new way screen updates are handled.
Yes, I appreciate all the work done in the past, all the work being done now, and the folks here explaining about it!

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Things I like until now: integrated thread API/events API, "magical" optimizations for blitting (the bitmap-type-thingy), modular extendability,
better GPU support and I think I like the new way screen updates are handled.

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.

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

 1   2   3 


Go to: