I've been wondering about this for a long time.
Why do SDL and ClanLIB games look so much better visually then Allegro games?

Is there like some sort of built-in Anti-aliasing and Alpha blending engine?

PROOF (SDL):
[url http://www.podvlivem.net/glx/?lang=eng]
[url http://www.2dgame-tutorial.com/sdl/asteroids/asteroids.htm]
[url http://www.pompom.org.uk/mutantstorm.htm]
[url http://onsight.sourceforge.net/screenshots.html]

PROOF (ClanLIB):
[url http://clanlib.org/~sphair/gfx/doctorc++.jpg]
[url http://clanlib.org/~sphair/gfx/feuerkraft.jpg]
[url http://clanlib.org/~sphair/gfx/overload.jpg]

Seriously, these screenies look better then most of the games on our depot.

How can I get results like (or better than) this with Allegro?

EDIT: And please dont let this generate into a flame war. I REALLY WANT TO KNOW.

Chances are that these libs use 3d hardware - so yep, they'll get HW antialiasing - if the card supports it.

Use allegrogl to get the same effect.

Another option would be, that these games are hires, or simply have better artists

The answer is: You can. You just need good artists. Good graphics is not a feature of a particular library; with AllegroGL and some skilled artists, you can have this and much better.

If I used LibSDL and ClanLib, my games would look no better. The look of the game depends on:

• 3D vs 2D,

• Font Rendering (Bitmaps vs TrueType, etc), and furthermore

• The talent of the artists.

I don't see that as a big discussion point. To me, the better question is, "Why are the programmers who use those libs able to find better artists?"

That question (as with the original) both assumes that your belief that libSDL and ClanLib games look better than Allegro games is valid.

The way I figure it is:

There are more people using SDL. Therefor, there is a higher chance of someone putting real work into a game. There are quite a few (read: tons) of crappy SDL games. It's just that there are more, so it seems like it's better.

Just like the playstation 2. It has more developers, so it has a higher chance of actually producing a few good games every year than the xbox/gamecube.

[edit]

Also, anyone remember the Head Over Heels game done with Allegro? That was of professional quality (since it was done by professionals). Which proves that Allegro can be used to make high-quality games.

I agree with Chris on the point. It just makes sense that a library with a larger user base will have a greater chance of producing more excellent games.

The gfx quality of a game does not depend on the game library used, but on the skills of the gfx artists who worked on the game, period.
As for Allegro games having great gfx, have a look also at the following depot entries:

Sounds good.

Are there any 2D antialiasing libs for Allegro, that also maybe do alpha that any of you reccomend? (In 16-bit color or higher)

AllegroGL is your friend.

Anything not requiring a 3D accelerator?

I'd say the main reason is that those people actually code, instead of picking their noses and posting in off-topic ordeals.
Another reason might be that they are trying to code for todays hardware

I guess I should get off my lazy butt and fix AllegroGL so that Windows users can use multiplatform gangbanging?

Hey wait a minute. ClanLIB has a much smaller user base than Allegro. Yet, many of the games made with the library still look much better.

Could it just be just much EASIER to implement these flashy graphics in ClanLIB?

Has anyone here actually used ClanLIB? If so, what did you think of it? Is it easier to implement more modern/complex graphical items?

Some evidence would be nice. I haven't seen any spectacular games with clanlib.
[edit] the example pics for clanlib look rather ordinary. Simple sprites and so forth.

Trolling?
Perhaps you ignored the previous responses about gfx?

And no for something completely different: Ellelator go up, ellelator go down. My ellelator! I push teh button!

The Overload game looks very nice. But the rest of them don't look too special.

But there does seem to be a lack of graphic artists here. Maybe that's the biggest reason besides the fact that most allegro games don't use AllegroGL.

Looks like a POV-Ray job, or some other form of pre-render technology.

Note that it is not offered for free. Clearly, someone(s) with skill who thinks that their skill is worth something made it.

Crap. Pure and simple.

Oh look, someone clearly knows how to use POV-Ray. You, too, can create such wonderful graphics if you knew how to use POV-Ray.

This is a steaming pile of crap. It may have some "spify" (read: more than some indy-games try, but crappy by any real standards) effects going on, but nothing can erase the total craptasticness of the texture work. Programmer art + "effects".

Persistence-of-Vision, once again in action. Only this time they used a matte painting they lifted from somewhere for the ground.

Some of those games require them. Or a modestly fast CPU with good memory bandwidth.

As for the Allegro community's games... come on. We have debates regularly about whether or not to stray above 320x240, let alone into modern resolutions like 800x600. We have serious debates on whether or not an 8-bit palatte is a good idea. Both of these are an ananthema to modern graphics. Most of the Allegro community is only interested in replicating something SNES-level in terms of visuals. Also, the Allegro community is not very tied into artists. As such, most Allegro games use programmer art. Some of it is good programmer art, but most isn't.

Of course, SDL (and probably ClanLib) is highly integrated with OpenGL, which opens all kinds of doors in terms of high-performance features. And since Allegro 5 development is quite dead these days, AllegroGL is all we're likely to have in terms of OpenGL. While it is nice, it provides an additional barrier (an additional download and API) between the user and what he/she wants that doesn't need to be there.

I agree with you Korval regarding the lower resolutions popular with Allegro people. However I found your comments about those games particularly harsh. I'm sure some of those programmers (and us) would have loved to have a really talented artist or musician to work with them. But that's not always possible.

Pwucky go down the hooole!

At lest I gawt teh wobber!

Allegro, I think, stems from an earlier era. The default bpp is 8, and it has the best support for PCX and BMP, neither of which support transparency. (ok, TGA, but that isn't used often)

So, although it can do hi-res, true colour blits with transparency, those modes don't seem to get used much.

Another thing, Allegro is so easy to get started on, maybe a lot of its users are novice/amateur programmers who never progress (ahem, like me...)

Technically I don't see why SDL/ClanLib games should look better.

Pete

Ok, the collection of responses are now satisfactory.

What is a trolling?

Yeah yeah, blame it all on me now.

Too many people may think that Allegro is a newbie library, and can't even be used to make "real" games... That's a shame. Also, Allegro's alpha blender should be optimized enough to be even slightly useful - now, it's plainly too slow to be used.

Someone needs to merge fblend into allegro. That way we'll have way better Alphabet Soup.

That's for Allegro 5.0, IIRC.

Which is dead.

No, don't let it happen Bob. Someone give it mouth to mouth, Why Won't someone give it mouth to mouth!! FINE! I'll do it. Nurse, get me some breathmints, a drink, and a trashcan.
LIVE DANG IT, LIVE!

...to be continued

People need to work on Allegro 5. There was a brief surge of interest a few weeks ago, but it seems to have died down again.
The problem is that these things require expertise, which only a few people really have, and it requires a lot of time, which even fewer people seem to have.
Unfortunately.

What if the Allegro developers start working on a high-level layer on top of SDL instead?

Go ahead. It'll be just another system driver.

What if someone who wants such a thing were to write it?
I make minor contributions to Allegro from time to time, but I have neither the skill nor the time (neither to implement nor to learn the skill) to contribute large portions of code. Let alone something I have no use for personally.

Seems like Allegro is pretty dead anyway.

Too much work and too little interest..

Why is there so much talk about Allegro 5, yet those that keep bringing it up fail to say why they need it ?
What is it that Allegro 5 does, that you need ?

What? No "Allegro is dying" jokes? You guys disappoint me.

Rash: if you insist...

Netcraft officially confirms: Allegro is dying

Yet another crippling bombshell hit the beleaguered Allegro community when recently IDC confirmed that Allegro accounts for less than a fraction of 1 percent of all game projects. Coming on the heels of the latest Netcraft survey which plainly states that Allegro has lost more market share, this news serves to reinforce what we've known all along. Allegro is collapsing in complete disarray, as further exemplified by failing dead last in the recent Game Developer comprehensive programming test.

Satisfied?

Dropping compatibility, first off. And FAST alpha blending as an extremely strong second. You can do so many amazing things with alpha blending, but Allegro can't take advantage of the GPU.

This wouldn't be a problem if there was some open-standard way of taking advantage of the GPU. But no, we're stuck with OpenGL and DirectX. Don't get me wrong, I love OpenGL. But it's kind of like a monopoly. There's no way to make a new 3d/whatever library that's GPU accellerated without using OpenGL/D3D (unless I'm forgetting something).

p.s. Have they changed the pallete / palette thing or is that still in there? ::shudder::

I don't follow you here -- OpenGL is the open-standard way of taking advantage of the GPU ...

Edit: What palette thing? Do you take offense to the two spellings?

Ouch that hurts... really it does. Allegro has a great community base but if allegro dies then the community goes with it. Personally I'd hate to be working on projects using a library that comes in dead last with any competition. In other words if allegro goes downhill I'm moving onto other libs... fast

Yeah, but you couldn't use OpenGL features on the GPU from Allegro without using/initializing OpenGL, can you?

But what's the point in keeping a typo a part of Allegro? If you want to call it a pallete, typedef it. And I know, it actually affects nothing. But it's just an example.

And you can't use Allegro without initializing Allegro either. You can't have a library for drawing to the framebuffer that doesn't require initialization. It's nonsense.

Why does it matter to you what others think of your tools? Isn't the game itself more important?

Pallete is a backwards compatability feature by now, so I wouldn't expect it to leave the 4.0x branch ... ever.

I don't see why an Allegro-on-OpenGL could not be implemented transparently, but I see why it's a bad idea; it's simply not the best or most powerful way to go about things. The abstraction would be (1) misleading, as techniques that decent in software can be terrible in hardware, (2) underpowered, as allegro's command set doesn't encompass OpenGLs and so techniques would be missing, and (3) inefficient due to some fundamental differences between OpenGL and allegro -- 3D commands, for example, would probably require overhead to translate between matrix formats & such. Seems better to do what Bob has done with AllegroGL -- simplify the OpenGL initialization and rework a subset of allegro's functionality in OpenGL -- so that it is clear that OpenGL is being used and so the corresponding techniques should be practiced, so that the functionality is more complete, and so that methods that would not make sense to implement as allegro does them in software do not exist.

ST: I don't see any particular reason to believe Allegro 4 is dying quite yet -- it's got some good support libraries, is user-friendly, is maintained somewhat actively, has an active userbase which also serves as tech support, and seems decent enough at what it does. The only thing on shakey ground is Allegro 5, which is a nice but non-critical problem as far as I'm concerned.

I started using Allegro in grade 11 when my cs teacher introduced us to it for the C progamming class. My two current projects also use allegro, one is in just Allegro, and the other uses Allegro GL. I think that for my future projects I will be moving towards using opengl (with or without AllegroGL), because as a programmer I am growing, and the 2d Allegro API just isn't powerful enough for what I want to do. That isn't to say that Allegro is not a good library (in my opinion). It is a very good intoduction to game programming, and very good games can be made with it. It just takes the time and dedication of the developers (us!) to do it. So indead of talking about how Allegro is dying, how about we just go out and make some kick-arse games to change that.

Some ideas about Allegro 5:
- more direct support for FBlend, DUMB, and many other useful libraries
- drop some compatibility (we probably aren't going to do very good still having to support DOS, paletted modes could be supported less too)
- probably rename library to Allegro-Five due to previous point
- merge it with AllegroGL

• let Allegro community submit useful code snippets (like random generator, loading/rendering Quake models, collision detection, particle system)

The point marked with * is probably the easiest way to improve Allegro in useful way since coding with Allegro consists in most cases of coding common routines done earlier by many people. I think many of us have some useful bits of code here and there and be willing to support Allegro so most of the work is already done (writing and testing). I'm actually thinking about improving Allegro in the way as G3D is improving SDL.

Before anyone posts what they would like to see or not. Firstly realise that this discussion has come up many many times in the last few years.. Do a search on these forums..

Secondly, are you going to help make Allegro 5?

Surely. If only I knew how and what to do...

That's not what I'm talking about. I'm not nessicarily saying using OpenGL's library. I'm talking about using the hardware accellerated features on the GPU that aren't provided (to my knowledge) without using D3D/OGL. Like blending.

I would devote what time I could, assuming someone told me what to do.

Like has been suggested before by others:
Start with an API change ONLY. Then take it from there.

The stable version of FBlend doesn't still have an alpha blender (though for some people alpha blending and trans blending mean the same). But after all, file loading, FBlend and rotation routines are the only reasons for me to use Allegro...

Personally, the best solution for me is to use allegro for timer and input, allegrogl for initialization and texture loading, dumb or another library for sound and opengl for rendering (2d or 3d)

Richard is right. Allegro is pretty dead.

And while everybody says allegro is great for beginners... have you mentioned the many "how to install allegro" threads? How to use it with a proper IDE?

The point is that VC isn't very well supported - and since most coders use windows, that's a big problem.
Another problem is that allegro isn't that newbie friendly if compared with BlitzBasic, etc.
And finally... since we don't support modern hardware, most other languages have a big plus

That means we don't get too many new developers.

The few we get, ask questions here. Most get an answer like "use gcc and make" "use allegrogl", etc. Which are all valid answers. Problem is, that Joe Newb will in these cases prefer one of the other packages.
Ok, part of you will scream "yep, but we don't need those" - and he'll be pretty wrong. No new coders means that we'll die out.

No hardware blending, rotation and scaling means that the games can't use the optical fluff other games can use. Which means that SDL games will get some WOW effects, but allegro games won't - so chances are not that good that a player goes "I want to do that, too" and looks up the lib.

But, blah, who cares?

I agree with Spell as well.

I don't come from a linux background and to me setting up, building and installing Allegro should all be done through a GUI program. In this century I find it personally absurd that we have to make allegro via a CLI. I think it's about 20 years since the Mac, ST and Amiga were launched with a GUI system..

Unfortunately some people here have the attitude that newbies or people new to allegro (even if good programmers) are not worth helping or bothering with. That will only put people off and make the allegro community diminish. Good though the manual is and some people here are I think Allegro isn't easy enough for beginners to setup and use or powerful enough to satisfy people anymore.

I have no idea of how SDL handles the GFX card hardware, but I feel that unless allegro incorporates GFX card calls directly or AllegroGL is improved to the point where loads of people use it and make showcase games then Allegro will slowly die.

In 3-5 years it will become standard to have whizzy, fancy effects in games and even with the increased PC speeds this just won't be possible in Allegro.

Personally I wouldn't care if tomorrow everyone used ClanLib or SDL and allegro was dead... as long as the allegro.cc community stuck together. Once my GUI is "finished" or what I would consider finished I definately will be looking into other libraries such as ClanLib or SDL or OpenGL or DirectX... whichever is the easiest to learn with a nice help forum with friendly people. I think the allegro developers put off for too long updating thier API to include accellerated features or somehow thought they were not neccessary. Of course computer speeds and abilities doubled very quickly but you have to keep up with trends in technology or you go stale.

[edit]
Richard... I don't mind the comand line interface ... heck I still use notepad. Personally I like to know what is going on in the background and not have flashy interfaces or automatic parenthesies adding. I think that makes it more complicated because when the GUI fails to tell you why your project didn't compile and you didn't know what was going on in the background linking process you might give up. Maybe that is just because I DID come from a Linux background
[/edit]

As much as I hate to admit it, I'm beginning to fear that it's true. Allegro is dying if it's not already dead. And without that to hold us together, the community is likely to disband.

Only our love of Spam will hold us together brothers!

Does SDL have hardware rotation and scaling? Last time I looked it was very minimal - it doesn't even have putpixel

I hope Allegro doesn't die - it's problems seem to be more due to user perception than anything real.

Pete

Allegro shouldn't need to be built by user at all. Binary distribution with shiny Windows installer probably would be enough for most users. Thankfully Allegro.CC files page has Windows binary downloadable so setting up DevC++ with Allegro can be done within a minute.

Fine, let Allegro die, leave it as is. I believe Allegro is just fine where it is, it does its job of supporting basically everything that is old.
Now, how about we all work on Allegro-Phoenix. It will rise from the ashes of where Allegro died. It should support the new hardware. Allegro for old, Allegro-Phoenix for new. That way we can do whatever we want to the library, it isn't bound to Allegro's style, API, or anything. We'll meld it with AllegroGL for HW blending and 3D support, FBlend for "trans" blending (and whoever knows the difference can add some alpha support) in software, ditch 8-bit mode, ditch DOS support, work on ALSA support a bit, etc... Leave model loading, particles, etc... OUT. That's for you to re-invent or use another library.

Um... Do you know how much work that is? It sounds great, but who's going to do it?

Well, since you were the first to ask, I guess you get to do it

EDIT: anyway, how hard is it to remove things? That should be easy enough. Inserting AllegroGL shouldn't be so bad. Now inserting FBlend will be a bit harder...We'll leave that to Bob. Bob, you have a vacation any time soon?
EDIT2: And the Alpha blending is already there, it just needs to be optimized.

Give it a go William, and let us know how it goes.

(Some random ramblings)

Basically, we need more Allegro developers. We don't need more people to argue, we need people who actively contribute code. Eric is the one doing most of the work there, with ocasional (and noted) contributions from others.

Whatever time I have, I try to put it into AllegroGL. Sadly, there isn't much free time to go around.

8-bit mode is fine. DOS support is a very large limiting factor just about everywhere. It introduces restrictions that just don't exist in other platforms that make coding a pain.

What I do think would be nice for beginners is to provide an installer program for Allegro (for newbie developers), that contains the most-often used add-ons. Something that automatically installs prebuilt versions of Allegro, AllegroGL, DUMB, FBlend and perhaps some others.

That would be a good first step into getting other people interested.

Second thing would be to revive interest in Allegro 5. We need developers there! Someone should pick up Peter's code and start hacking at it. Getting the ball rolling is the hardest part.

Once that's done, however, I'd be glad to contribute to an existing codebase. But I don't have the time or energy to roll the ball myself, so this will definitely need to be done by someone else.

Also, Allegro is Open Source, which means that not only anyone can pick it up and work on it, but that there could be multiple divergent branches. Hopefully, they can be brought together at some point.

This is how Allegro 4 got started: There was a Windows port, and a separate Linux port (WinAllegro and XAllegro, respectively), separate from the main distribution. Once they matured, their codebases were merged into the main tree giving us Allegro 4.

I always wondered if I'd be good enough to contribute. Besides the fact I don't know its guts near as well as some others, it's got, like, assembly, and stuff. Is there a page with a) the thus far proposed API (or better, a finalized one) and/or b) what most needs dong next to proceed?

So why not rip it out? Who here actually uses DOS?

I'd be glad to make an installer. Just gotta go grab one of those pre-built ones If it needs to be custom, I can do one in MFC in no time, but I don't know any GUI coding for Linux so

Anyway, yeah, we Allegro hacking n00bs need an intro

Yeah, screw DOS. Everyone who comes here for help with DJGPP just gets told to switch to MinGW anyway.

well yeah, cause as I've heard DJGPP doesn't work with XP, and a lot of people use XP...although I remember using DJGPP under XP fine, shrugs.

I do! But I'm not against dropping DOS support since Allegro 4 seems to be enough for DOS.

Allegro isn't entirely assembly, there are higher level constructs. If you choose to develop for allegro you can just work on the C level functions and not worry about the lower level stuff. All you would have to know is what to call or how some lower level things were arranged, but not the internals of it. Besides if A5 is HW accellerated then there isn't much of a reason to use pure assembly because most of the stuff will be done through HW calls and not manual pixel manipulation or the likes. I would love to work on A5... in fact I'd contribute my GUI or my mouse routines as an enhancement for either the codebase or an add-on. I need to learn how to impliment HW accelleration either through DX or OpenGL anyway However wouldn't A5 have to use OpenGL otherwise we'd break the cross compatability or overcomplicate things by using say DX8/9 on the windows side and OpenGL or Mesa on the Linux side.

ZZZ: Bingo! DOS support can safely be dropped at this point IMO since there are plenty of earlier Allegro versions that cover that platform quite well.

bob: where do I find the allegro 5 code? I want to take a look at it

I say, don't limit what can be added to allegro for DOS compatibility, but you can still leave the DOS crap in, just don't add the fancy new features that would be (near/totally) impossible to add for dos.

But as Bob said DOS has complicated the code. It should be dumped and the code slowly reworked.

I agree. DOS should be dropped. Allegro 4 is already here for people who want to use DOS.

Yeah, that's me, too

I joined Allegro5 mailing list a time ago, and... heh, I don't remember when I received the last message

Probably, if someone puts all the current Allegro5 docs somewhere more visible, I'm sure some people would take a look at them

I don't think I can be a very active developer, but I sure can contribute some code

I disagree completely. Download this file and double click on the install.bat file. I'm not sure how more simple it could be.

Included readme.txt:

If you do not know how to link a library, then you should not be programming yet. This has nothing to do with Allegro.

The help document that is referenced even explains step by step how to set up MSVC for those who have pirated it. The download is clearly labeled in the Binary section as the easiest way to install allegro.

The binary files are downloaded 100s of times per week from a.cc, and I've never heard complaints about them.

I'm going out on a limb and guess that this lives on a CVS repository, yes? OK, can you point me to a decent CVS client (not command-line) and the location of said repository?

Binaries are one thing. Compiling the code under VC++ is impossible, thus provoking a download of a bunch of GNU tools. The code should, at the very least, be able to be compiled under Visual Studio. It should ship with an actual VC++ project file that works.

I really hate that part. Why doesn't it work? Is it only because GNU's assembler uses AT&T syntax, and MSVC's uses Intel? Or is it deeper than that?

Because if it's just the assembly, heck, I have a pretty decent change of fixing it.

Also, there are no windows binaries for the later versions (read: any WIP version). Which is bad, because 4.0.3 has some nasty bugs (like not properly shutting down the main thread in windows).

DOS should just be dropped. It adds limitations, and nobody else supports it anyway. Even windows 95 is unsupported. And how many OS generations behind is DOS from 95? If people want DOS, they can just use a older version. The 4.0.3 / 4.1.13 distros work fine.

Yes, but the quote was in reference to beginners and how easy (or hard) it is to "install" it and use it. They have no desire (or skills) to edit Allegro's source, so my point is still valid.

In light of the discussion, a project file would not make Allegro any easier to use for beginners. It would, of course, make it easier to compile Allegro, but that's not what a beginner even wants to do.

Uhm, that's pretty deep enough as it is.

Only a plain installation (with no updates) of the original version of Win95 is unsupported. Win95 OSR2 or one with any update or application that installs the updated C runtimes should work.

That said, no Allegro developer has Win9x, so finding and fixing bugs on those platforms is that much difficult.

Eric is the only one doing the releases. He does a wonderful job at managing the whole situation, considering he's pretty much solo on this. As I mentioned, there is a big lack of developers.

The API proposals are over here.

Peter's working Allegro 5 code is here. You may want to start from the CVS version, and not the packaged version.

I have my own CVS repository where I started on the basic graphics API, but it's not exactly in a working state. My CVS is offline, for now.

How can one figure out how to become one of the developers for Allegro (4.x anyway) because if I'm able to find time, I'm might help.

And like what was asked before, what's a good GUI CVS client?

I ask only because I have access to Windows 98 SE and can't seem to really get started on a project... I seem to be a person who has a hard time getting started on a project without some base or something.

Well, is DirectX supported by 95 OSR2? That aside, I meant to point out that 95 isn't supported by Microsoft (or most developers) anymore. And windows 98 won't be in a a few years (they extended it though). I wasn't talking about whether or not Allegro supported it.

I'm horrible at writing, I apologize.

Well, I've got copies lying around... but Win95/98 (IMHO) are such horrible operating systems compared to 2K/XP (I mean, can you imagine going back to having no task manager?). And you can't even browse in the same window in W95. (IIRC)

IIRC, DX7 is the last one supporting Win95, which is fine because that's all Allegro uses. In fact, it will even drop down to DX3 for supporting NT4.

Google for TortoiseCVS

Well, if allegro is dying, how hard would it be just to write a "ghost layer" that provides the same functionality as allegro, but uses SDL as the graphics/input api instead of directx? True, it would slow down some stuff, because your not using native calls, but then you would already have native opengl support, ttf font support, etc. About the only things that would really need to be ripped out of the current version of allegro would be the datafile routines.

My $0.02.

EDIT:
Heck, if you program it correctly, you could even keep compatability with the older versions of the lib (so you can compile older programs with the SDL Layer). Then Allegro 5 could just be a wrapper over the top of SDL. No reason to reinvent the wheel, after all. Plus, we could implement all sorts of stuff, like namespaces, classes, etc. while we are at it! Teehee... (end of rambling)

Seems several people are keen to contribute (me included) but we just don't know where to start. I'd love to be able to help (with the API, merging libraries, and other non-ASM related goodness) but someone has to make decisions about API changes, what goes in, what stays out, etc etc and that's the sort of thing that gets tricky

When it doubt ask. What you do will not be set in stone anyway, so it's ok to make mistakes.

never touched ClanLib..
but as said, it realy depends on the programmer/artists..
Alot Commercial Games has ports on SDL or SDL & OpenGL also,
so that might be a part to give that idea ( that sdl makes magic good graphics )
SDL Lacks some windows compability tho..
that allegro has

(well more like win32 API compability, barley used SDL..
SDL is more event driven so probaly why they dont have it.
just the windows specific parts alleg has that i rely on hehe)

Working on it.

I do, but I don't run it by default and I don't know enough about programming native Win32 applications. I could test things though.

There was a discussion on that a while back, [url http://www.allegro.cc/forums/view_thread.php?_id=333249#target] where this was discussed in more detail.

Now as Bob said, there is a lack of active developpers. Anyone who wants to contribute code to Allegro, subscribe to the mailing list. Propose what you want to do, ask what needs to be done. Do little things. You don't have to rewrite the DirectX driver from scratch, it's small things that make a difference. Adding an al_ prefix to exported symbols would be one thing.
I may have a little time over the weekend to do some Allegro-related work again myself. Have to dig up my todo list, I guess...

EDIT: About merging AllegroGL - wasn't there some discussion on AD for merging it with the WIP branch in the near future...? I'm not sure how feature-complete AllegroGL is at the moment, so maybe we should wait for it to be more mature...?

Personally I would:

• Remove Dos specific code.

• Strip out the GUI, Software 3D routines, 3D math routines and Datafile stuff and put that into another library.

• Integrate Bob's FBlend stuff and remove the default Allegro ones.

• Combine AllegroGL into this new Allegro and have new routines to make it easy to do 2D work, but with Hardware accelerated effects (alpha blitting, lighting, etc..)

Yes, breaking down Allegro into seperate chunks (datafile, graphics, sound), ie making it more modular, is one of the things that should be done.

I agree with everything RP said... and another question - are FLI files really used much? I'm just curious. Is there some niche in game programming that FLI fills that other video formats are not suitable for? (Getting slightly offtopic but hey)
If this has been answered before, just ignore the question and I'll quietly slip out of the thread to avoid looking dumb

I use FLI files for intro animations because Allegro supports them natively. Other than that... I'm not sure they serve much of a purpose nowadays.
Yes, FLI files should probably be moved to a seperate (or addon) package.

Jake: FLI's use Palettes IIRC. So they can be useful in 8-bit graphics modes.

I've always considered allegro good for coding classic games. It's not very good for much else - due to lack of hardware support.

Modularity would be a huge plus. In the rare occurances that I use allegro these days, I usually only use it for graphics, timing, input devices and packfiles. Pretty much everything else I do on my own... I've never used any of the 3D stuff, and don't use the built in blenders. Datafiles / Sound I find I rarely use, as well. (Partially because I never finish a project though, heh)

Where is Thomas Harte when you need him?
What about splitting up the Allegro Development forum into one for 4 and one for 5 to encourage discussion and development?

Heh, thats kinda cool...
My thread sparked a whole new drive in Allegro development.

Anyway, I got some spare time, I will try to contribute too. Im sure im not as skilled of a coder as most of you, but I will do what I can.

I agree with Rash here. We have the AD list, but for most people (including me) bothering to sign up to that thing is annoying. If it was more easily publicly available (like a forum here), I think more people would contribute.

Good point. I think it would be interesting to get the opinions of some SDL or clanlib experts to find out what they think is good and bad about their platform and why they chose it.

There's been a lot of mention that "Allegro is the worst" and "Allegro doesn't support modern hardware" - can anyone say more about that?

pete

What Allegro 5 needs is some single person to act as dictator and just get things done. Group efforts with everyone being a bit of equal don't get far until the project is already usable. The problem is, being the project dictator takes a lot of time, a lot of dedication, and a good bit of skill. It really wouldn't be that fun of a task either.

The dictator has to be someone with experience who is well respected and would make good decisions.

I nominate Y v e s!!!

Naughty c e n s o r s h i p filter..

I nominate George W. Bush.

I know those posts are in jest, but the thing is, no one has to be nominated. If someone is waiting around to be nominated, then they are the wrong person.

Pete, Bob, Thomas and Bruce come to mind directly.

Chris, he has the dedication to be an overseer..

Yeah, but no skill!

J/K

Bob == No time. what time he does have I'd rather have him spending on AGL/putting AGL in Allegro.

Har har.

I could do it, but that would mean compromising the time I spend on TMS and other things. I'll contribute if I can, but not oversee ...

It doesn't necessary have to be a dictator. It could also just be a general coordinator who lets decisions be made by some group of voters.

The problem is everyone has a different opinion on what should be in Allegro or what needs to be done.

And that's why you need a dictator or a group of qualified people to make decisions, and a large open forum for all these varying opinions to be discussed.

hence the need for a supreme dictator. If you don't like what (s)he likes, tuff cookies.

EDIT: beaten

That's a "problem" to the extent that the Allegro 5 developers care about satisfying the current users of Allegro. While they should take suggestions, they should not be bound to them.

spellcaster: That Thomas was for Harte no? You wouldn't like me as a dictator And besides, I'm a bit unstable, and lack the asm knowlege needed.

I think people like Eric Botcazou or Grzegorz Adam Hankiewicz are well suited to act as dictator because they know a lot about Allegro, have contributed a lot of the core code and are generally active. Elias Pschernig and Angelo Motolla are probably among the largest contribitors at the moment too.
I think Peter Wang held the largest vote after Shawn left, but I'm not exactly sure.

Generally, I think a public forum such as this is not suited for making disissions about the design and further development of Allegro. Everyone posts what they think should be done and has some vague notion of wanting to help but nothing ultimately happens. There's too much noice. So step one for anyone serious about contrinuting to Allegro: subscribe to the mailing list and say that you want to help and ask what needs to be done.

IMHO, things that need to be addressed (apart from bug fixes) include: library modularization, making the code thread-safe, namespace prefixing (although not an issue for me personally), merging of AllegroGL (as a module in the default distribution), native support for compilers such as MSVC in a portable way.

Each of these requires a lot of time and are not that easy to implement. Consider modularization. Say you want to remove the packfile functions from the core library. That means you're in trouble now since Allegro's file I/O (including support for bitmap and sample loading) depend on it. You could argue that those should be in a seperate module anyway. Fine. The Allegro config routines also depend on them. This is not so easy to remove from the core library, especially since the initialization code ties in to the configuration code.
The packfile code itself depends on the text encoding and unicode routines.
To untangle it all would be herculean effort.

Now, I need to finish my thesis in the next two weeks, so I may not have time to do anything at all personally as I had initially thought. After that, I may want to take a little break and do some work on Allegro. Taking on a problem such as this would be something I would like to do (because of the statisfaction when it's done), but at this moment I simply don't have the time. If someone else wants to step up and do it, by all means do.

I don't think asm knowledge would be really needed in Allegro 5 development since:
- most things are to be made HW
- there is FBlend for blending (probably part that needs asm most)
- there are other people who know it

Take a deep breath and read my post again.
Having a different opinion doesn't mean you can stop majority decisions.

But still, subscribing to the mailing list is too much to ask of someone who wants to submit a single patch. Forums are much better for that.

I said this in IRC, but I think it could be repeated here. Development on A4 should be the priority. It's a working system, and thus the easiest to work on. Current A5 development should be killed, and work with A4 should focus on adding (not replacing!) the functions and such that were to be in A5 (this includes FBlend/AGL integration). The current A4 functions would either be rewritten to use the new functions (compatibility layer), or kept as is for compatibility's sake. Then when it comes time to upgrade A4 into A5, drop the compatibility stuff and whatever would have been left out of A5, leaving the newly developed functionality.

Basically, is there really a good reason FBlend/AllegroGL can't be merged into Allegro 4 right now with the new functions taking on an al_ prefix, leaving the current API untouched? Same goes with the rest of what was to be in A5.

I don't know the details, but Bob has gone on record as saying FBlend can't be integrated into Allegro 4's code for some reason. It'll require a re-write of the code anyway, so instead of trying to duct tape the two together, it'd probably be easier to start from scratch.

The way I understood it, FBlend couldn't be integrated into Allegro, taking over the current blend functions. Both libs can be, and need to be, linked together for FBlend to work, so why couldn't they be merged into one lib?

FBlend isn't compatible with the way Allegro currently does blending. Integrating FBlend at this point would mean that there would be two blend APIs.

AllegroGL isn't mature enough just yet. Once we can run most examples unmodified in AGL, then I'd give it a go.

What? Do you want to start a revolt among the C programmers? If Chris did it, I'm sure it would use the SDL and classes and all of that C++ goodness... which would most definately be a bad thing

EDIT:

And what is the big deal about integrated FBlend? I heard that allegro 5 was going to break compatability with old versions anyway... Might as well go all the way and give it a refacing with our good friends C/C++, Fblend, and allegroGL, right?

EDIT2:
I'm dumb!... the support for C isn't a bad thing. It encourages readable code in the deep internal files of the program. However, I don't think it would kill us to at least make a class wrapper for some of the more commonly used datafile, bitmap, input functions...

Well, we're already dropping the ancient DOS support. Support for C would be next anyway, I'd think.

Well, I would nominate myself, but that would involve drastic changes like switch to a fully c++ API.

I'm on the mailing list, but no one posts at all there (there isn't enough press). So I second the Allegro 5 forum. Some way to cross reference it with the mailing list would be useful, but I do not know how plausible.

Marcello

I would rather have one good, fast blending API and one useable, but slow, secondary API, rather than just one useable-but-slow API.

I vote for keeping C. No need for C++.

I disagree with Kitty Cat regarding scrapping A5 - I think that at this point the best way is to reformulate a solid API from the start and get it right this time, and not hack on any features to A4. We already have lots of hack-on and legacy things as it is (draw_sprite anyone? The aforementioned blending system?).

As for C++, I think that the internals can be whatever they want to, but that the exposed API should be C, have C bindings, and that a C++ wrapper should be supplied for those who want that (#include <allegro> ?).

DOS support should be scrapped (another reason to have a new branch - so that A4 can officially support DJGPP, where A5 will officially not), and so should the GUI,IMO.

YES! Scrap the GUI, or at least remake the interface with agup.

Or maybe replace it with Miran's MASkinG? (From what I hear its easily skinnable too )

EDIT:
Oh yeah and the Allegro's current audio system sucks. More loaders should be written at least. Or maybe an FMOD wrapper would suffice (FMOD is NICE ).

You may not need Allegro 5 for that. That change could perhaps be made for 4.2, which will also support MacOS X, which Allegro 4.0 does not.

The GUI should be a seperate module. I for one would vote against it being removed altogether since I use it quite a lot.

And yes, the API should stay a C API. This is actually something I think all people working on Allegro agree upon.

EDIT: perhaps I should start by reposting summaries of AD here again... if time allows.

That's the thing, though. Restarting Allegro (as with what's trying to be done with A5 currently) is a very big task, and it doesn't seem as though there is as much incentive to do it. The internals would be changed to favor the new, better functions, and the older functions would be patchworked on top of these new functions where possible. Then when Allegro's version number changes from 4 to 5, all the old functions are dropped, leaving the new ones in place, and the new API cleaned and finalized.

Or they could do what was done for A3->A4. Start work on 4.9.x after 4.2 is finalized, do them both concurrently, but let 4.9.x change the API around while 4.2.x stays "pure"..

A good idea, but that would mean even pure-C programs would need to be linked against -lstdc++ or linked with g++.

Hmm... seem to have missed this bit:

I made something in that direction a while back (a header called callegro, similar to cstdio&co). It wraps Allegro into an allegro namespace. Needs documentation and further testing though. I probably also missed a few things too. Note that this doesn't thouch the API in any way. Anyway, attached.

Take a deep breath rash and read all the posts made after yours. See all the differing opinions on what needs to be done and who's going to do it?

Perhaps we should have a survey on this forum and whatever get's the most votes wins eh?

To be honest, I had thought about taking over a5 a while ago, but I dunno, noone seems to like my naming/coding scheme (thats not the real reason I never mentioned this, but whatever )

What is your naming/coding scheme then?

Thats sorta it... It sometimes changes. Oh, and I use hard tabs, and set the editor to use 3 space tabs.

Oh, and I used to be torn between:int some_thing_foo_get(); and int some_thing_get_foo(); I'm starting now to swing over to the first method.

edit: modified some stuff.

A bit different from me, but nothing too bad...

I've seen worse. The only thing I'd personally object to is the _t suffix for typedefs. I prefer CAPS (preference aquired from Allegro, oddly enough). I can't stand non-hard tabs though, like the Allegro's source uses. I set tabs to 4 spaces personally.

I used to be an ALLCAPS person, mainly because thats what I was introduced too. But that changed.
and the _t suffix is just because I like to name variables the same name as the type

edit: If you want to see the various ways I've done stuff... See that ViewSVN link in my sig? Clickie. Its got the latest source of quite a few projects, that (most) are all a couple years old, and have gone though a couple of my changes in coding.

edit2: infact, strangegame still has some ALLCAPS structs

I dunno why I changed. I just wasn't comfortable with the ALLCAPS for some reason.

SOME_TYPE some_type;works just fine for me.

See my edits

I can understand changing preference. And really, something like:
#define SOME_TYPE some_type_tcan't be that hard.

TF: That stile is very similar to mine. Only differences are: I put the t at the beginning (t_some_thing) and I write the open brackets in a new line. I prefer keeping upercase only for define's

WOW, you're fast of mind, aren't you?
However, I was thinking of a more sophisticated election method instead.

Actually I was being Ironic Rash..

*notes the capital I and lack of comma*

So, what's it like being Ironic Rash. anyway, Richard? Is this some secret identity? Are you ironic in general and Rash. is just your nickname? Is this some disease that you're more prone to the more steps you take to prevent it? Or is it more abstract, like the code name of a project to create a super-android to take over the world? Or maybe not androids (like the new Resident Evil game "RE: Code Name Ironic Rash.")?

It's a secret plan to spread irony through out the known world. With the only cure being repeated expose to my games..

Are you by any chance related to Alanis Morissette?

Nope..

Are you related to a Crash Test Dummy?

And another thing: what's with the second period? Is it part of the name, like the "the" in The Cheat, so you have to put it in there even when it doesn't make sense in context?

(edits old post for proper spelling of Ironic Rash.'s name)

And what's Alanis really like? Does she really always have one hand in her pocket?

Me thinks Chris has too much time on his hands..

I'm on my lunch break. Insanity ends in 13 minutes and counting ...

Still cutting wood?

... today's a holiday, dude. TMS work and Blender modeling day here in Canada ...

Aw crap; back to work.

All but gone from the Allegro community. It just doesn't do what I need. But, some random replies to things I've read here:

SDL contains full alpha channel support, and even has the highly useful function:

SDL_Surface *SDL_DisplayFormatAlpha(SDL_Surface *)

Which takes the specified surface, of any RGB colour format paletted or not and converts it to one, with an alpha channel, best suited to fast blitting to the current output mode, meaning that it uses any hardware acceleration available. The surface is moved to video memory if that makes most sense.

Perhaps it is because SDL offers more help in using the hardware effectively than Allegro that the SDL newsgroup almost never sees that Allegro.cc stalwart - the discussion of some 'technology' everybody else thought was ten years dead. Such as dirty rectangles. Or writing your own sprite blitter because the Allegro one is too slow.

This is pretty much like one of my API suggestions for Allegro 5, that the user should give hints as to what they intend to use a surface for, allowing the library to pick where to put it, etc, rather than having the user pick video/memory/AGP memory. Just the sort of thing I thought would make sense for the Allegro target community.

As I said, I barely use Allegro, but certainly until recently wasn't it stuck with VGA standard 18bit colour palettes?

No, it doesn't have either, unless you count its overlay surface support. Obviously those can be scaled.

Several years ago I wrote my own 'mini-Allegro' which replicated somewhere less than the SDL functionality (although SDL was version 0.1 at the time, and I hadn't tried it) in DirectX. That was very neat, but has alas disappeared into the ether of time. And in any case, SDL is so much easier.

The only issue I can think of is that the num and caps lock keys are programmed not to provide normal keydown/keyup messages, but instead effetively provides down/up messages with respect to the LEDs. This is to maintain compatibility with some esoteric UNIX systems.

That said, considering that the Allegro developers rejected threads because they couldn't be done on a DOS port, this imperfection appears minor.

I remember doing a little survey of Allegro programs available with source at one stage. Especially with respect to timers, almost none of them were DOS valid anyway.

I'm sure Allegro, its quaint syntax, its desperate support for ancient and useless technology (FLIs, LBMs, the provided GUI) and its complete lack of orthogonality will be remembered fondly.

As I've said before, I consider the 3d camera matrix generating function to be the quintesential demonstration of the Allegro approach. The docs state that the three supplied vectors must be orthogonal for the function to work. The code then expends several dot products and at least one square root assuming the programmer has been unable either to read the docs or conform to them.

My version five plan for Allegro would largely include:

• dump DOS

• dump timers

• dump GUI, all packfile stuff, all software 3d

• implement threads

• implement proper alpha channels

• orthogonalise

• access to more hardware - gamma ramps, overlay surfaces, etc

I'd probably try to go a '2d OpenGL' route (including in syntax - no more underscores!), with stacks all over the place and broad equivalents to display lists. But most of my ideas have been explicitly rejected at one time or another.

Why drop the timers? I like those . If you dump DOS support I'm sure the timers will work a lot cleaner.

Ooph! thenthisbecomesmuchhardertoreadthanforinstance, this_which_is_much_easier_to_read_because_the_brain_processes_the_underscore_as_whitespace.

I agree fully with dumping everything else you mentioned, though. DOS doesn't add anything useful anymore. You wouldn't even have to "lock" variables/functions. Which is only needed on DOS, isn't it? (to prevent disk swaps during an interrupt. i.e., read: BOOM) Though, it would need some mutexes (but it needs them anyway to begin with).

I'm sure syntax conventions are the least of the worries for A5....

Yeah, ummm, before you go off on a style, learn it first. What 23yrold3yrold did is the correct way of not using underscore. It is clearly just as readable as underscores and requires less space

With a nice set of defines this UpperCase / under_score issue is not important.

I'm afraid that I value Thomas Harte's experience and opinion and I think he is right that Allegro is getting badly dated and left behind.

I would say a priority would be to give it more 3D hardware power built in (merging with AllegroGL and extra blitting functions, etc..) to enable us to compete with SDL and to attract new programmers with the fancy effects and games we would then be able to do.

- dump DOS

Well, I'm not writing any DOS code. If anyone wants DOS support, they'll just have to code it.

- dump timers

Timers are somewhat useful, but they're a pain to support. Better to provide high-resolution timers. We've already agreed on that.

- dump GUI, all packfile stuff, all software 3d
GUI is not likely to go, since many of the Allegro tools use it. It would be nice to have it replaced by some leaner framework.

- implement threads

I'm not too keen on the idea. Perhaps someone should start an add-on first, and we can go from there?

- implement proper alpha channels

Alpha is already here.

- orthogonalise

See API proposals.

- access to more hardware - gamma ramps, overlay surfaces, etc

Overlays, yes. Gamma ramps, I'm a little reticent. I don't like it when a windowed app hijacks the global gamma settings, and then crashes, leaving the messed-up gamma.

You could lock gamma to fullscreen, couldn't you? Or something...

Marcello

I'm well aware of hungarian notation.

ThePointStillStandsThatThisIsn'tAsEasyOnTheEyes
as this_is_when_done_correctly_but_I_guess_should_make_this_one_a_bit_longer_as_to_not_seem_like_I'm_cheating.

And I was also thinking about the typedef idea. But that could add more problems. What if someone codes with the hungarian, and starts working on an already underscore-based one?

That wasn't Hungarian Notation. pstrThis uiIs hbmpHungarian m_pulNotation.

Bah!!!!!!

What Steve and Bob said.
Allegro currently needs less people volunteering their ideas and preferences and more people actually contributing code.

Very true. So why did I write Hungarian...

Well, I like the dictatorship idea. As bob said, it's opensource, there's branching, and it's perfectly alright to make mistakes. I think people interested in directing A5 should just start working on it themselves, and then let people decide who they want to work with/help.

How would one start, just writing up which API's are needed, then go into each one and write out the function headers? Seems reasonable to me... There is already a bit of that available, but I haven't looked at the latest stuff myself.

Marcello

Obviously, Allego 5 would now have to jump into a niche that was overlooked by SDL in order to actually become used.
TH, any significant shortcomings of SDL?

I could be easier to use Include most of what it does now, as SDL requires addons for just about everything.

d00ds. Get to work Start groking the allegro source, read the todo list and get cracking. Me? Oh...I'm busy finding a web host, maybe I'll start the Allegro 5 forums

I'm going as fast as I can with the mixer. I just hope when I'm done with it, it's accepted.

PS. What I'd like to see go the most is the DX mixer driver. That thing completely skips out on Allegro's mixer, thus introducing inconsistancies in mixing, and ignores a few of the config options. It's not the audio driver's responsibility to provide virtual voices, and you don't want a game to take up all hardware voices (of which there can be, and usually is, as few as 1).

But getting ride of DX mixer will prevent the usage of hardware mixing, won't it? And I think one of the things allegro 5 should do is more hardware acceleration support. I have an old SB128 and it has 32 hardware voices.

Only if you're getting hardware mixing in the first place, which I doubt most people are. It might be possible to make the mixer be instantiated more than once, with some tweaking, so you could take up as many or as few hardware voices as you want. Then you could make each mixer instance have 1 to however many virtual voices.

Because I'd have implemented threads, so a special case for timers would be unnecessary. Besides anything else, do you realise just how many magnitudes easier it is to write the equivalent of audiostream code in SDL because it is threaded?

But suggested elements of the API have been sucessfully argued against on the grounds that they wouldn't be DOS portable.

From which we can also impliedly conclude that modularity is out? Or else, if the GUI is an option then obviously this isn't really worth arguing.

I don't like it when the API designers decide I'm not to be trusted. That's the sort of thing that makes me find an API unafraid to treat me like an adult.

Similarly, I don't like it when I read that other hoary classic 'how do I get fast true colour fades' and watch people replying 'you can't get the hardware to help with that, so it will always be slow'.

ahem surprising that a member of allegro.cc would like the idea of a dictatorship.

Apart from the missing hardware functionality already mentioned (i.e. when not in GL mode, hardware scaling and rotation of ordinary bitmaps), I've always been a little annoyed that the overlay surfaces are dealt with as a separate entity to normal surfaces, with separate functions and so on. I know that some varieties of overlay surface are planar, but I still don't see why that couldn't be part of the normal surface definition.

Also, the out of the box sound support isn't brilliant. It's more or less OSS equivalent - i.e. one 'audiostream' and some mixing functions you can call if you want help - but abstracted into its own thread. This brings us to TF's point about addons though, things like FMOD are not uncommon to link with SDL, and it took me half an hour to hook it up to DUMB. Which is because I hadn't used DUMB before.

Conversely, I've become a big fan of the event based input method, and one of the main reasons I abandoned Allegro was that threads make things so much easier for the type of application I was writing: an emulator. That's why my CPU core can be paused at any cycle where most people's can only be interrupted inbetween any particular instruction, yet does not run significantly slower.

I think the overlay surface topic is one of the things being addressed for SDL 2.0, but don't quote me on that. SDL is pretty much run under the 'dictatorship' model through Sam Latinga if that helps the discussion at all. It helps significantly that SDL is included with most Linux distributions.

If it helps any, I gave up on GGI and SVGALib (the latter being particularly abhorent - look up the joystick calibration functions if you want a lesson in how not to do it) long before Allegro.

This is the modularity that people like me advocate. My current project uses the following:

• SDL

• SDL_ttf (truetype library for SDL)

• zlib

And I'm considering libpng. The only complexity that using addon libraries has added to my code is on the commandline sent to the linker, which pulls us back to an earlier subject of this thread - that being easy to use is not the same thing as teaching people how to use their build tools.

By the way: libpng could be significantly nicer also.

My .02 :

The call to 'modularize allegro' seems to defeat the purpose of an 'all in one game programming library'.

Drop timers. The way threading is used in sdl makes them transparent to user so this is a 'good thing'. A high res timer is definitly the way to go.

I think the goal for any further developement on allegro should be towards making it, Allegro, the new standard. Forget backwards compatibility. If Allegro really is in danger of dieing, why not?

Do something dramatic. Switch rendering to the AllegroGL style 2d in opengl. When you have 5000 rotating, alpha blended sprites on the screen at 500+ fps people will no doubt take notice. The core is already there in the allegrogl driver.

You guys (the dictator?) should figure out exactly what features you want to support and go from there.

Another thing that's needed is a high quality demo or game to show off the new performance. Maybe some of you guys who don't have the low level knowledge to work on the internals could work on that?

But I haven't used allegro in a while so maybe my .02 should actually only count for .005

Two ways of responding - one could argue that the extent to which Allegro is out of fashion due to its design as an 'all in one game programming library' is not to be underestimated, or alternately a challenge: find me one game that uses LBMs. A hint: its a graphic format. It seems to me that the ethos of an 'all in one game programming library' should not be used to justify things that simply aren't needed for games. How many people do you think actually find helpful the entirely control wrestling GUI of the present Allegro for their games?

A late thought on dictatorship - I remember around version 2.2 of Allegro, Shawn declared that he had perfectly working MOD code, but declined to incorporate it into Allegro because "it would make the code messy". To this day Allegro cannot MOD.

This is a brilliant idea. Imagine an ideal world where the developers were shadowed by the 'demo game' team, who with a direct interest in an efficient and easy to use library could provide useful empirical API and implementation feedback as library development progressed.

I agree with the majority here, Allegro has long ago been elbowed out of the market in terms of low level stuff (and was never that good at it anyway), so it should probably reposition itself as a game development library bringing the sorts of things 2d game developers want without trying to claim things like the game loop from the programmer as ClanLib does. With that aim it is perfectly acceptable that Allegro be built on top of SDL or whatever.

Some late thoughts on this. An extension of the same logic means that those working in a window shouldn't be allowed to modify the palette if a hardware palette is in use.

Alternatively, a feature of SDL appeals. It has a 'parachute' which (unless disabled) activates if your program generates an exception and releases as much as it can back to the operating system. Could we not have an Allegro parachute which, if the application crashed restored the gamma ramps to the settings they had when the application started?

An implementation of the latter would certainly defeat any argument with respect to the former about proportions of people likely to be affected.

Agreed.

Not at all. As I would see it, you would install the default packages, which builds the video, audio, input etc. modules. You then have the option of either #including <allegro.h> for the whole package as it is now, or #include <allegro/video.h>, #include <allegro/gui.h>, #include <allegro/packfile.h> etc. and only link against relevant sections.
Note that the header splitup has already been made a while back.

I know threading can be used to simulate timers or count game ticks. However, from a newbie perspective, I think it would be nice to have timer threads ontop of normal threads. For me at least it is a matter of great convenience that I can just tell Allegro to go run some_function() every 100 milliseconds.
Of course, this could be implemented as a seperate module yet again ontop of the threading API.

Oh, for everyone, making Allegro thread-safe is currently one of the priorities. This probably requires rewriting a lot of code, which means that now would be a good way to untangle some of the mess. I anyone want to help.

EDIT: as for dictators, I still say that Eric should be it, if he's willing. He more or less is in practice anyway at the moment.

Couldn't you also only have the DLLs you need, in the directory? (i.e., if you don't use sound, you don't need al_sound.dll) I don't personally know exactly how you would go about that. Just at thought.

Lastly, since the original topic had (almost) nothing to do with this, and this thread is getting very large... might I suggest making a new thread?

What is an overlay?

What is a "gamma ramp"?

A (usually YUV colour space) surface overlaid onto the displayed image at pixel output time. It never appears as part of the framebuffer and is intended primarily for video streams. If you have DVD playing software, it will almost certainly use an overlay surface to display the video image. If you use printscreen to capture the display, you should only see a colour keyed box in the DVD player window if this is the case.

The main advantages are:

• on some hardware the overlay surface comes from a different pixel clock, on all other hardware the pixel sampling is done at least bilinearly - so all resizes are 'nice'

• YUV colour space means either getting as good as 24bit colour in a 16bit/pixel mode, or if you go with the commonly supported planar modes, almost 24bit colour in 12bits/pixel

• separate Y channel means fast fading

First card I had that supported overlay surfaces was the S3 Virge that was in my P200.

Gamma ramps are sort of like palettes for colour channels. So your card will do something like this:

1) read pixel colour
2) split into r, g, b
3) put r value through 256 entry r lookup table
3) do same thing with g and b and their respective tables
4) output mapped colour

It means you get many of the benefits of a paletted mode without being paletted. For example, your game can change hue (e.g. day to night), can fade and can do some colour transplanting if you deliberately colour your sprites for that purpose all through ramp manipulation.

I've no idea when gamma ramps became common place, but the 'intel integrated graphics' on my current machine - a Celeron 533, does.

Yes, but I'd rather not have allegro.dll, al_sound.dll, al_graphics.dll, al_keyboard.dll, al_mouse.dll, al_joystick.dll, al_mod.dll, al_mp3.dll, al_ogg.dll, al_midi.dll, and whatever else packed into a program instead of a single allegro.dll. On systems where you release source-only, or static link, this wouldn't be much of an issue, but as the current binary releases use dlls, and the dlls need to be packaged with the program to make sure you have what's needed, it creates a lot of extra baggage. It would also be a problem when you add new functionality but forget to package the newly needed dll.

Are these facilities OS things that are layered on top of something like DirectX or OpenGL, or are they part of them? Certainly, I don't recall OpenGL having overlays or gamma ramps. How does one usually access them (without SDL or another library)?

Also, one other question. What hardware provides for hardware scaling/rotation/etc blitting without providing for 3D acceleration? You might get some basic alpha effects without 3D accel, but most modern graphics hardware relies on it's 3D systems to handle that kind of thing.

Why not just move over to the Allegro 5 Forums I'm putting up? I got them installed, I want to customize a few things, maybe make it look more like these forums or something, and get some mods installed. They will be located at [url www.progranism.com] when they are ready.

Agreed. I'm not sure how this impacts modularization though... perhaps the required symbols are only imported from the shared library if the relevant header file is #included or a relevant .a or .lib file linked to (ie, there is a static portion that gets linked in which contains a constructor that imports the symbols from the shared library)?

Because there's already a section of these forums dedicated to Allegro development and there's already a mailing list (which has indeed been quite dead for a while now). The last thing we need is to discuss things in a bunch of different places. Discussion needs to be centralized, if we need yet another Allegro 5 discussion at all.
Frankly, I think we're better of with people who write actual code instead of going through yet another lengthy discussion about what needs to be done.

Hardware features exposed by the OS however it feels fit. Definitely accessible through DirectX and I have a strong suspicion they feature in DGA 2.0 and above also. Not accessible from OpenGL in the strict sense because GL doesn't do any of that low down surface access stuff. In fact I believe OpenGL has something entirely separate it calls an overlay surface.

EDIT:
One quick check later, XFree supports YUV overlays through the 'XVideo Extension' and gamma ramps through something I can only find referred to as the 'XFree86-VidModeExtension' which may or may not be the same thing.

DirectX references, pulled from google: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_m/directx/direct3d/gettingstarted/direct3dsurfaces/gammacontrols.asp (gamma control), http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/ddraw_6x47.asp (overlays)

What does it matter if a symbol is loaded from a shared/dynamic lib? The point of modularization is to easilly seperate code from each other. It's good coding practice to do this, IMO, but when it comes to dynamic libs, it all needs to be there. Hsving seperate libs creates the need to package more files, which is a Not Good Thing(tm), and having them in one file is exactly what Allegro does now. And static linking is totally irrelevant to library modularization since it already strips out what's not used.

And as a note to TH: you can already use overlays in Allegro (Windows only currently, though: DXOV). Granted there's no way to really manipulate them other than as a sepreate RGB screen for window modes, but the basic code is already there and can be extended upon. And modifuying screen gamma is a Bad Thing since each monitor is different. Especially if there's fast blending (you can use AGL or FBlend for this), there's no need to modify the gamma. I know I wouldn't be happy if I ran a game and my screen suddenly became washed out or very dark. Let alone if it was a windowed app.

The symbol needs to be imported from the dynamic library. My suggestion was to have this done by use of a constructor in a library file which is static linked. That way, only symbols needed will be loaded from the shared library. Not sure if that offers a benefit over only loading part of it though.

Except when all modules interconnect, as is the case with Allegro currently. This is because all modules link to the system driver, which in turn needs to know about them too. (From my understanding).

exactly
But hey, I'll leave the boards there anyway. If people don't use them, I don't mind. I figured it'd be nice to have a seperate "centralized" place to discuss development of Allegro 5, ask programming questions, post code releases(including addon libraries which hopefully get merged), etc... If these forums are enough then I'll just take my forums down. I don't mind. BTW the boards are up and running [url www.progranism.com].

If all modules interconnect, it's not very modular code. Though I see your point. The system driver doesn't link to everything in every module, though. Besides, static linking isn't widely used at all anymore. Not since DOS. And afaik, not loading extra symbols from a shared resource doesn't offer any benefit to the program.

I think we need sources that can actually compile before we begin production I'm getting this error:
src/poly3d.c:32:35: obj/mingw32/asmcapa.h: No such file or directory
I got the sources right off CVS, module allegro_new. MingW 3.2.3.

As soon as I can get these to compile I'm going to go down the todo-list and proposals list and see what I can do to help.

I should add to what Thomas said: Gamma Ramps and Overlays are computed on scan-out, so the actual frame buffer is never modified. Instead, the RAMDAC does the combining/remapping.

In the case of overlays, this costs additional memory bandwidth if the frame rate is low, but ends up saving memory bandwidth if the refresh rate is high enough.

That's on top of the other advantages mentioned.

Gamma Ramps is something that's provided by the OS. Overlays is in DDraw, but can be accessed via WGL (if OGL rendering to overlays is supported).

It's more of an API problem than a hardware capability one. That said, video cards usually have at least two modes of operation: 2D and 3D. In 2D mode, most of the pipeline is shut down to save power/heat/fan noise. However, this 2D mode is more or less defined in terms what can be done via DDraw than anything else.

There are AUX buffer in GL, but that's not the same thing. Other than that, I'm not sure what you could be refering to.

But FBlend doesn't do gamma-correct blending

Like I said above, this is handled by the RAMDAC, so is essentially free.

Gamma seems like something you would want an option for in game, so the user can set the 'default' level to work with their screen... Then if you were to modify it, you'd base it off their default level.

I personally don't see these things as the main focus of A5 though, isn't the point for a cleaner yet more versatile API? That is, getting rid of global variables, moving stuff to namespaces, reducing number of redundent functions, closer integration of opengl, support for multiple displays/windows/screens.

Personally, I have recently been using full allegro C++ wrappers, so switching to A5 api is simply a matter of updating the wrappers. That will be pretty sweet. :-)

Marcello

It may be free, but it's highly dependant on external hardware. If you want it for fast fading, you should use FBlend or AGL instead. Gamma ramping only gives you two colors to fade to, white and black, and affects the whole screen (this is Very Bad for windowed apps). The other way gives you one of 16.7 million colors to fade to and lets you specify areas you want affected.

How do you generate an allegro.def file for mingw32? I fixed the compile errors I was getting(see the mailing list) but I don't know how to generate the allegro.def. I tried "misc/fixdll.sh" under cygwin but still no allegro.def.

Make depend.

that errors.

'sed' is not recognized as an internal or external command, operable program or batch file.

EDIT: Cygwin got further but errors too:
process_begin: CreateProcess((null), del _depend.tmp, ...) failed.
make (e=2): The system cannot find the file specified.

Then download sed.

Ok, got make depend to run. But still no Allegro.def in lib/mingw32

Funny, I don't recall inviting you into the design team for any of my projects. But that's cool. I'll stick with programming tools that treat me like an adult, you stick to designing tools that force everyone to agree with your design decisions. I'm sure they'll continue to be as popular as Allegro is now.

Depends how you define fading, really. If the blue channel can converge to one point, the red channel to another and the green to a third, why is this an any less valid fade than an 'every rgb converges to a particular rgb', given that the human eye is infinitely more sensitive to luminance than chrominance, neither of which are preserved in either scenario?

As already discussed, so does setting the palette in 8bpp mode. Will you be pushing for Allegro 5 not to allow palette adjustment?

Well neither am I. It really is just something someone said to me once, without really explaining what OpenGL people therefore tend to refer to as overlays. I'll take your word over that half gleamed piece of ancient 'wisdom' any day of the week.

Personal or well known wrappers? Popularity of different wrappers would be an interesting way to determine how people actually like their API to be (give or take C++ v C stuff).

Not exactly. In fullscreen applications, it doesn't matter at all, as long as your program doesn't crash (and if it does, it fixes it on exit). For windowed modes, either use a software method, or allow the user to decide. Nobody complained that Quake 3 allowed you to change the gamma in a windowed mode.

The only wrapper I've released is alBitmap, the rest are either under construction, or more specific to my style of coding (such as full game wrappers that handle timing, drawing, flipping, etc.).

I have also been working on ones for opengl/allegrogl (textures, fonts, and full game wrappers) as well.

I'm guessing, if I wanted to try sdl I could also modify the wrappers to work with that, although they are tailored for allegro's style of handling things.

Marcello

hey, you guys.

Check out the installer I made a few posts down. Go check it out. I really want feedback on it.

where is it exactly?

Bah!! You wrote posts not threads!!

Sorry, I had to vent after going through 8 pages of posts. It's here.

8 pages!? I only have 3...

Marcello

Unfortunately, it quite does. If someone has a monitor that's brighter than normal, the gamma will be lower than normal. And for a monitor that's darker than normal (which happens frequently with older/smaller monitors that are set near the max resolution), gamma will be set higher. Changing a user's gamma is akin to changing their brightness and contrast settings, IMO.

I think you misunderstood that that was my opinion. AFAIK, we're all entitled to one.

I never said the ability to modify gamma shouldn't be there. But to modify it for the purpose of screen effects goes a little to far, IMO. I won't play a game long if either a) it continuously messes up my gamma settings, causing me to reset them, or b) if the gamma settings aren't modifyable at all and I lose required screen effects.

Except that the palette is done on a per-program basis. The only time changing the palette effects anything is when Windows' desktop color depth is 8, which is rare enough as it is, and I believe there's even safegaurds for modifying too much of the palette in windowed modes under those conditions. Plus, it's easy to reset the palette if something does mess up, unlike the gamma settings which are set permanent once changed.

IMHO this discussion about gamma vs no gamma is useless. Adding gamma functions won't hurt anyone, and lets allow the game/application programmer decide when it's appropriate to use this functionality.

I agree that arbitrarily changing the user's gamma settings is wrong, because they vary per-monitor. However, it is not unreasonable to give the user an appropriate dialog or whatever so that they can determine what the correct gamma settings are. Then, these settings are saved with the regular configuration data.

However, I am fully, 100% against misuse of something. Like using gamma as an effect. Gamma is for converting from a non-linear colorspace to a linear one (or something like that. I don't fully understand it myself). The API for it would have to be explicitly designed to prevent pathalogical use of the gamma ramp. Like using a single floating-point value like most gamma correction settings do.

Just because there is a toy to play with doesn't necessitate that it ought to be played with.

I am also concerned about what would happen if an application crashes. You can catch crashes with a C++ exception, but only if you are higher in the call stack. In order to catch all exceptions, the library itself would have to, effectively, be main(), or somehow higher up in the call stack. Unless you expect the library itself to define main() and call some "AllegroMain()" function that the user writes, this is not possible.

Also, the library would have to be C++ to catch the exception.

Being an adult means knowing when to touch something and when something should be left alone. And if you don't know enough yet to know that improper use of the gamma ramp is silly, then you don't deserve to be treated as an adult.

Basically, the logic goes like this. If you have some need to fiddle with the gamma ramp in ways that it is not intended to be fiddled with (for effects rather than true gamma correction), then you are exactly the person who should not be allowed to filled with the gamma ramp. It has one specific purpose; just because you can finangle that purpose into some diabolical vision doesn't mean that you have the right to. It isn't your machine; it's the guy playing the game. And an API should have just as much respect for the player's PC as it does for the programmer.

That's one of the primary reasons why we have hardware abstraction API's. Because programmers can't be trusted to go poking directly at the hardware. Poking the gamma ramp directly is clearly poking at the hardware. There's a simple abstraction to this that allows the gamma ramp to be used for exactly and only the purpose for which it was designed. Ergo, that is the abstraction that should be used.

Uhm, isn't this what we are kinda doing already?

Only on windows, and only for compatibility.

AFAIK this is true on all platforms (except DOS).

About gamma, what about a restricted gamma - say between 0.5 and 3.0. This should prevent people from setting the gamma to zero or some really high value (and thus making it rather difficult to reset in case of a crash).

I don't like the idea of trapping exceptions - when my program crashes, I want to know where and how, and have the debugger pop up. I certainly do not to have it cought by some handler, that forwards the error as something like "Oups. I crashed. Oh well", and then don't leave me the option of debugging my code.

Bob: well, couldn't it be disabled when you compile in debugmode?

Marcello

Sure. Except that every time the debug build crashes, your gamma's screwed up.

Also, it is sometimes useful (re: necessary) to debug release builds. God knows I've had my fair share of wading through optimized code trying to figure out where my variables are...

BTW, on the gamma stuff:

So, it seems that an entire set of cards is "not for adults", to use Thomas Harte's phrase. You're not even allowed to set the gamma from a 3rd party application (ie, stuff we make).

I dont understand this discussion.
I mean, if I want I can delete stuff in the systems directory on windows. Why doesn't anybody force the allegro developers to make sure no "dangerous" system call can be executed?

Changing the gama ramps does allow for nice blending. On the other hand, I'd simply use a quad (or a bunch of quads) ontop of the current imahe and change the alpha value of it...

Same effect, less discussion trouble.

You'd have to really want it, because Win2k/XP' file protection will kick in and replace that file from a copy stored in a file cache...

Unless you've disabled file restore because it hogs system resources and hard disk space.

EDIT- Spelhing

The discussion, as far as I understood, was about using gamma to create screen fade effects. I don't think anyone's said you shouldn't be able to modify gamma, but you shouldn't do it just to create an effect.

My argument was for being able to modify it. Not necessarily for an effect (I mentioned Q3As gamma control). But if you can't modify it for an effect, you can't modify it at all. Which isn't something you should enforce on the developer, IMHO.

I was suggesting being able to modify it for actual gamma purposes. Which I think you should be able to do.

Okay, here is my $0.02:

DOS

DUMP dos for crying out loud. All it is doing is holding us back. Just the simple act of dumping dos should help increase our productivity. Supporting archaic operating systems is not going to help our cause

2d-OpenGL

This personally sounds like a brilliant idea, although by incorperating 2d-OpenGL we would be alienating those who do not have an OpenGL card. But this shouldn't be too big if a deal, considering that OpenGL has a software mode (correct?). Besides, by incorperating 2d-OpenGL, you would be at the same time incorperating support for 3d-OpenGL (well, not at the same time, but it would be easily added). I'm sure this would make life easier for bob (namely), who has been putting up with the pain for quite a while of writing a library (AllegroGL) that interfaces new hardware features with an old programming library.

Modularization

Good Idea, to a certain extent. Personally, I think this would be great to include if you wanted to make your program more "readable," so you could determine what exactly is being used in code. However, for newb-ized purposes, it would still be helpful to have something along the lines of a <allegro-all.h> or something to simplyfy the process for those who are less fortunate than us.

The GUI

Personally, I think the gui should be ripped out and reworked. I mean, it is ugly, the design system isn't exactly the most intuitive the planet has ever seen, and it just doesn't work the way some people think it should. I would include the gui as an optional addon download to the library. Those who want it, can download and install it. Don't make us suffer with an inferrior gui system because your too lazy to use Masking or any of those other great gui systems.

My Conclusion

My opinion is that, if Allegro is to survive, we need to get up with the times. First of all, start recoding from scratch. That way we can avoid having old code that is dependant on other old pieces of code somewhere else. Dump Datafile support-- who needs it? With zlib, you can just use ZIP compression (combined with some password protection) to store our files. One less thing to implement, one less piece of code off of our shoulders to maintain. The Timer system needs to be replaced with a threading system. The FIXED type, in my opinion should be dropped. It has really lost is usefulness. The Sound part of the library needs to be reworked for hardware support. Am I missing anything?

Basically, Allegro 5 needs to be a complete rework instead of an addition on top of allegro 4. Allegro 4 is a bit to much on the "legacy" side of the line. We need to move more to the "current" side of the line.

EDIT: Some grammatical errors fixed.

Something to put the DOS thing into perspective: Why are we no longer supporting the Atari? Allegro started out on that platform, you know. Also, if we're going to support DOS, why not also C64 and Amiga systems, SNES and NES consoles and other outdated platforms?

As for the GUI ... I don't think it should be a part of Allegro at all. The only argument for having it is so that we can have graphical tools like the grabber; but really, who says the grabber has to be a part of the core Allegro release? We might as well have a command-line utility for that and have the grabber be a utility for Allegro that you can download separately. It could then be linked to pretty much any GUI system you could think of and not be limited to Allegro or anything.

Exactly, X-G. Hence another good point in my argument that datafiles could be completely dropped to begin with. There are so many utilities out there that handle Zip Files, and with zlib out there, why complicate things by reinventing the wheel? I mean, it is way easier to click and drag the files you want to use to a zip editing program that trying to use the grabber...

It is, after all, one less piece of code for us to maintain. Let the Zlib people handle the zip compression/datafile stuff.

EDIT: Added some additional grammer fixes.

I agree with that point. Why make a datafile system of our own when there's a widely supported standardized storage system out there already that would work just fine?

EDIT: Another thing that definitely needs to be reworked is the way fonts are loaded.

Someone needs to be making a list of all of this stuff...

We need to do some things:

First of all, we need to settle on a style for coding. Personally, I would go with using fixed tabs so your not forced to use wierd tab sizes on different formats, and something along the lines of this for the API coding:

int g_int; // global integer
int m_int; // member integer
int a_int; // Argument integer
// etc.

Just something so we can make our code as readable as possible. Part of the problem with the current library is that it is too much backwards compatable bloat for what you get...

EDIT:

Yeah, the fonts should be fixed... Add it to the list!

EDIT2:

Another thing that should be fixed are the file formats that are supported. Maybe "broadening our horizens" and providing native support for jpg, png, gif, etc. wouldn't be too bad of an idea.

No problem there; just stick with Allegro 4 if compatibility becomes an issue. Same thing with DOS -- although I'm an ardent supporter of DOS, there's no reason to advance it beyond the already superb support present in Allegro 4. Stick with 4 if DOS is your thang.

So, anyone have any ideas on who the supreme dictator of this project is going to be? I'm excited... Let us blow SDL out of the water! Personally, I am going to have to be more of a grunt programmer than anything... I haven't taken a whole lot in the line of college programming classes (aka. none), and high school AP testing is going to have me busy for the next couple weeks...

Votes anyone?

EDIT: one more note about the "dictator" idea. It is great and all, but it may prove to be a bit of overkill on one person. If we can get 2-3 people who can agree on the format 100%, we could have a "counselship" of dictators on the project. That way, things get done faster because we are not waiting on one person to free up his schedule. Just make sure we have a web page/mailing list/something that can be used to keep track of the progress and keep everyone on the right page.

Yuk.

What about:

::some_global;
this->some_member;
some_argument_or_local;

Let the compiler do the work for you.

Finally, the coding style is pretty much described in the ahack document, so you can just look that up.

Hmm... I don't think I have personally ever seen that syntax before, I'm dumb!. I'm just saying, we need to have a common programming scheme.

Personally, in my functions I pass them with an a_something or a p_something so I know that the value I am using is the one that was originally passed to the function, not a copy of it. Either that or start them with an underscore, capital letter, something to signify that this variable will be effected outside of this scope (I usually only use these when a pointer is being passed).

Hmm... Hungarian notation is evil, eh? I actually liked it to a certain extent. (At least at the function level, anyway).

That was the idea. Note that both Bob and Peter Wang started on that, and that neither has any time to spare to continue and there are no other developpers who jumped in and took over. That's why development on Allegro 5 has come to a halt.

I use it regularly, thank you. That said, it could easily be an addon (which could then come with the grabber and dat utilities).

We already have: the dat utility. Beats the Grabber if you want to include a large chunk of bitmaps at a time.

I personally really hate pedantic coding conventions that insist on obscuring the variable name with information about its scope, type and whatnot. No offence, just my contribution to the discussion.

I agree with both of these statements.

I'd still say Eric, or at least someone with a good understanding of Allegro's internals and some experience in Allegro development (ie, someone with write access to the CVS repository). There's about twelve people that fit that description, which limits the choice. I do not consider myself the right person for that job though.

Right. Which is why I propose that if we are going to have a datafile system of our own, dat will be included and the grabber be a separate package; something separate from the core Allegro routines, but officially sanctioned by the same people.

But still... datafiles are great and all, but what exactly is the point of them? They do, quite literally, the exact same thing that zip files do, except that we are modifying them to do what we need. Which brings up my saying of the week... WHY REINVENT THE WHEEL. Just use Zipfile support instead for crying out loud. Not only do you get a plethora of editors you can modify your datafile.zip with, you have the wonderful feeling of knowing that your not the one maintaining that piece of the code! Heck, with Zip file support, we could do all sorts of interesting things like virtual file systems and stuff.

No more multiple datafiles! Just one zip file for everything! Yippee!

And I have to agree with X-G on this one. If keeping the Datafiles is an asolute must, by all means, just give us the command line utility.

Also, one other note. Has anyone found it annoying that the datafile routines are slightly less than well documented (aka. not documented at all). Just try writing your own datafile output routines without using the grabber's/dat utilties source. It is a pain in the butinsky. Yet another reason to use zip files for datafiles. Heck, we could even just rename the *.zip file to a *.dat file and WOW! It looks the same and does the same thing, for much less! Amazing!

Sorry, I'm in a very sarcastic mood right now

EDIT: Added some stuff

I for one would definitely like to see a good VFS; I'm not sure it should be a core allegro component, but I am definitely in favor of seeing an addon for this. It integrates especially nicely with .zip files as datafiles.

Exactly... not only that, if you were to use zip files, you have the option of loading parts of the datafile where AND when you want it to be loaded as well, instead of having to load the entire datafile to ram.

Once again, why reinvent the wheel when it is already invented for you?

Indeed - that's the whole point in using Allegro to begin with - so we don't have to reinvent any wheels.

cough*load_datafile_object()*cough

Call me a pessimist, but I believe that it could be quit a bit faster with a universal compression algorythm such as *.zip. Which would you prefer? A compression algorythm such as *.dat that is maintained by a few people, or *.zip which is accepted as an industry standard? At least with the industry standard library, it isn't yoru code to blame if the file isn't loading properly, it is theirs.

Despite load_datafile_object, there are so many more things to gain with using .zip instead of our own format, including, but not limited to:

• Standardized file format

• Lots of alternative editors with good support for it

• More versatile

• Inherent directory structures

• Easy to integrate with a virtual file system

• Good compression

• Well supported in existing libraries

And so on.

Well, I think the original idea of packfile is that it uses a very fast compression format which can work both globally and on a per-file basis. I personally gutted zlib a while back to see why gzseek was so fucking slow on pocket pc (ARM processor), and it turns out when gzseek is called for anything before the current location, it goes back to the beginning of the file and uncompresses everything until it gets to the point you want.

Hence I wrote up my own compression format (raz: random access zip) using lzo or whatever it's called (same one that allegro uses).

Granted, it's not really a problem on today's systems with loads of ram and fast processors, but zlib isn't the fastest pickel in the bunch. I think a packfile system could easily be offloaded to plugins (and come on, plugins can be included with the standard download, they just don't have to be compiled into your app). Another argument is that all of the file-related functions call the packfile routines just for general file IO access, but I believe someone started up a new io stream api for allegro 5 that would render that argument pointless.

Another vote for in favor of zlib: I think PNG should be setup as standard with the library. There is no reason to not push for more usage of PNG out there. A lot of people are still using BMP's in their test projects and whatnot because they don't want to bother setting up PNG support.

Definitely drop DOS support.

And on the programming style conventions, I think a convention for the public API is definitely required, but under the hood, I think it could be more general stuff like "indent your code!" and whatnot.

As for dictators, I vote again for myself (woo, 2 votes!), because if I were dictator, I'd implement strict style conventions and make everything C++. Maybe throw in some java. (j/k)

Marcello

Well, improper use of anything is axiomatically silly. But congratulations on having learnt the language.

But, just so as you know - the majority of Allegro.cc posters are Westerners living in predominantly Catholic democracies. One of the founding principles of such systems is the notion of 'universalism', which ties in with the mature recognition that a lot of people have a lot of different opinions and there is no such thing as universal truth.

Conversely, being childish is often associated with believing yourself to be right beyond question and stating that anyone who disagrees with you is necessarily wrong and deserves lesser treatment. It isn't only restricted to children though, its the sort of thinking that runs entire nations such as Zimbabwe.

Funny, most people seem to think that hardware abstraction APIs are to cover differences in hardware. Another strikingly funny thing is the way that hardware platforms with stable definitions never saw any significant abstraction APIs (I'm thinking Amiga, Archimedes, etc). A third funny thing: every other 'hardware abstraction API' gives you control over the gamma ramps.

We're still restricting people to its GUI practices...

I vote Grzegorz Adam Hankiewicz. He started at pretty much the same time as me, but has apparently become quite closely integrated. And always seemed reasonable.

When we discussed this before, whichever developer it was said that datafiles were originally implemented because zlib was too slow on 386s. Datafiles do not compress as well as zlib, skipping one stage or another entirely.

More recently this has been justified because the Allegro developers don't like the GPL. Even though zlib isn't GPL software...

EDIT:

To be fair, the docs do say w.r.t. gzseek "<i>f the file is opened for reading, this function is emulated but can be extremely slow."

I'm dumb! Marcello...

First of all, the internals should be C. No way around it. C is a bit easier to debug, not to mention a measure more easily ported than C++. Although I would have to say with the usage of C++ that is going on, it would be most definately nice to have a C++ wrapper class that you can use natively in C++ that COMES WITH THE LIBRARY. Such as a bitmap class, datafile (if they are kept) class, etc.

I would vote myself for dictator, but I'm a bit on the unexperienced end. I'm more than willing to help program the internals, but as for the fact that my formal programming education is near nonexistant.

One other thing that I had an idea for. Wouldn't it be nice to allow both high-level (current allegro) and low-level (sdl-like) actions? That way the newbs could use the high-level stuff, and those who prefer to optimize stuff could use the lower level APIs.

EDIT: Mr. Harte, since we are dumping support for dos, isn't that essentially dumping support for the 386 as well? I would be amazed to see a 386 run win98 semi-reasonably. If allegro is to survive, we need to make it look as attractive as possible to programmers. If programmers have to learn a completely new syntax for everything, such as our custom datafile syntax, restricting them to our custom 3d routines, etc. THey are going to be turned away because they don't want to waste time learning stuff. Productivity is the key to programming. Besides, by integrating Zlib, opengl, FMOD (maybe), etc., we give common functionality to new programmers; language experience that could be easily transfered from one library to another.

There are *nix systems that run swell on 386 systems, so no.

Dunno what you're going on about 386... what does that matter other than for optimizations that detect the cpu anyway?

As for C++, even bob has suggested this on the mailing list for the internals (instead of basically recreating vtables in c, to use c++'s for drivers), unless I'm incredibly mistaken.

It makes a lot of sense to me, I mean, name me a platform that doesn't have a c++ compiler that you actively are interested in having allegro compile on?

Marcello

FMOD doesn't have a compatible license to Allegro, unfortunately. It also doesn't come with source code. However, feel free to write an Allegro driver for FMOD.

As for computer support, I'd say supporting the top-end of 10 years ago as the minimum is a good target. That would be something like the Pentium 166MHz with 32MB of RAM.

zlib doesn't provide a VFS, only the compression routines. There's an example app, however, that does this (minizip?).

This is how Allegro is currently done.

I'd vote for dumping all image loaders from the core and putting them all into one or more add-ons.

Either that or supply a common API for the image loaders to follow, so it wouldn't be difficult to add them to the library.

We need to have some already supported with the download, for the newb-types. I would suggest these be the more commonly used, easier to edit file types (such as png, bmp). The rest could be implemented using add-on libs.

And, if we are going to implement addon libraries, which we have to in order to have a good library, it would also help if these libs followed a standardized setup plan. Aka... they all follow the fix.bat whatever, make, make install scheme.

Either that, or make a plugin directory under allegro that you can put all of your addins/plugins, and have some sort of orchastrating program to keep everything up to date..

Sorry, I'm kinda busy doing homework for other things right now, I'll hav eto put more thought into this later.

I'd say allegro should have some bare minimum file support - say BMPs and WAV files.
A good ZLib and libPNG integration would be great as well.

There is the question of how to handle the dll if we switch to a plugins based system. Should there be some type of multi-tier system:
1 - allegro raw dll, say allegro-raw50.dll
2 - allegro core "standard" plugins, allegro-core50.dll
Core standard plugins could be, for example, be the set of plugins most similar to the features allegro 4.0 has now that would be removed, such as packfile, png loader, DUMB, gui.
Then plugins could either be in dlls that work with both raw or core versions of the main DLL (for example, allegro-raw50.dll and allegro-dumb.dll; or allegro-core50.dll and allegro-software3d.dll), or compiled straight into your program (for example, allegro-raw50.dll with dumb compiled into application exe).

I can see the problem people have with tons of dlls in their system directory, but I see no problem if there is a standardized system. You can always include the dlls in the game directory instead of system. It is not uncommon to see applications/games with tons of dlls in their program directory. Likewise I think the plugin system should have a standard way to link statically and dynamically, so if you do not want any dll dependence (on any OS), you can compile it out.

If such a system is adopted, it would also be nice to have some kind of plugin repository with official DLL builds (done in upx, msvc++ or whatever gives you the smallest/most optimized dll) so conflict are minimized.

Any takes on that?

Marcello

I think that should be PNG and WAV rather than BMP and WAV.

If PNG is going to be included, PNG should be on top of BMP support. Not everyone needs, wants, or can, use PNGs. As open as it is.

Why can't you use PNG's? It can do everything bmp can do and more... pretty widely supported by drawing programs as well.

Marcello

Loading PNGs requires libpng, and that requires zlib. Allegro should build and run all by itself (without additional dependencies). We don't want people to have to download 4 or 5 packages just to get Allegro up an running.

But maybe you don't want or need compression. Or should we dump waves and all use monkey audio, which is lossless?

Well, wether or not you use PNG or BMP, it is quite trivial. We could simply do some sort of program design like this...

It would be a pain to get anything like that to compile though... Most of the common stuff should be integrated into the library, and the plugins should be able to seamlessly integrate themselves with the existing functions.

For example, if you have the *.png loader and the *.bmp loader, you should be able to do a call like this:

load_bitmap("whatever.png")
load_bitmap("whatever.bmp")

and the library should be able to handle the various file types. The only problem with this would be that you would need to implement some rather, how should I put it, interesting(?) coding styles.

EDIT: Bob, welcome to the world of scripting. Just write a python script or something that downloads those additional libs for you so you don't have to find them yourself. (I'm dumb!... great idea, but we don't want to force people to install python. Maybe the makefile could make a c/c++ getfile tool or something, then use that to retrieve the needed libs from the net?)

EDIT:

As for dll naming conventions, I would prefer something like this...

As for DLL clutter, can you load DLL's from a subdirectory? So, for example, you could do something like this

PROGRAM_ROOT:
      -Executable
      +all5plugin folder (or something.  Heck, it might even be possible to use a zip file for this)
            -all50wav.dll
            -all50png.dll
            -etc.dll

EDITED Again for clarity

How about:

load_bitmap("whatever.png", IMG_PING);
load_bitmap("whatever.dat", IMG_TARGA);

Then how come there are often newbies here who DO have MingW installed, but have problems installing Allegro? You're not going to tell me they ALL get it with Dev-C++, are you?
Downloading isn't hard, it's what comes after it.

That works, but it would be nice if the function could determine what type to use itself. True, this would cause lots of unnecessary forking, but it would be nice to newb's anyway.

EDIT:

Once again, another thought that I agree with. Sometimes people don't realize that there is a little thing called, hello... BUILD documentation files? We need a slightly better readme with our stuff too. If allegro is designed to be newb-friendly, we have to design the lib to be newb-friendly.

If we're dropping dos, we can write out the full name of allegro, I think.

Marcello

Yes, unless they are using win95... win95 still doesn't like long file names... it will handle them, it just doesn't like them very much.

Then again, Windows 95 is (and has been for a long time) officially depreciated.

When the developers of a product say "don't use this product," that should say something.

[appended]

Well, I've been thinking about it, and I have to begin to start agreeing with Marcello on this one. Interal drivers in C, external API for C++. Once again, C is great for speed, but the external API is going to be basically the same speed no matter what.

GHA! STUPID CHEMISTRY HOMEWORK!

EDIT:

I'm dumb!, yeah. Good Point Chris.

My tupence ha’peny - (sorry for the sideways direction)

Many new game programmers start with Allegro and then switch to SDL

This, to me, makes API issues trivial in comparison to AllegGL integration. The most important thing has got to be keeping programmers that face the choice of a steep learning curve with OpenGL+Allegro&AllegGL or a seemingly equally steep learning curve with OpenGL+SGL.

I can see it myself from that perspective at the moment since that's about where I'm up to now, I know I need to progress by using OpenGL and my perception is that it would be just as easy to choose SDL over Allegro+AllegGL.

I wont though because :-
I believe people here who say that there is little or no technical advantage.
I don't want the only game library that's good for beginners to die.
Although everyone is saying how dated Allegro is I think it's a strong advantage that my game can run ok (latest unreleased version anyway) under linux on an oldish pentium 333 Mhz PC with NO 3D acceleration either under X or on the framebuffer whereas Chromium and others run only under X and badly on the same machine (thanks knoppix). There's still alot of these machines about.

It doesn't bother me if the DOS drivers are scrapped and the focus be on OpenGL but (daft question) - you're still keeping the other drivers right ?, if not and you end up ripping out everything that makes it good for beginners then wont you be left with SDL?

Are there any completed quality games that use AllegGL ?, it's be nice to see it working well and if there isn't one it'd be worth porting either an OpenGL or SDL game just to avoid the vs threads.

There have been a few threads about using AllegGL for 2D games has anyone got any source for this or do I really need to go through all the NeHe tutorials etc?...

it's great that there is renewed interest in developing allegro 5 again IMHO the important thing is :-

need to integrate allegGL > need to make allegro more attractive == TRUE

casts maturing spell on AllegGL

Nonono... you got it all wrong. We are not going for an all-out opengl raw library thing. I was thinking more of having wrapper functions on top of open gl that does what the current functions do.

OpenGL is just another graphics library. Just like Allegro currently wraps around the directx 2d API, it shouldn't be to hard to wrap around the openGL 2d API. Besides, by wrapping around the opengl 2d api, you make it multiplatform compatable almost instantaneously--Even less code to maintain.

breaths again

good to here, I'd like to help but I think I'd be out of my depth, I'm close to v1 now of my game, I'll see after that.

I'm dumb!... more than I can say, I haven't really had time to do any game programming lately. Most of my game programming has been restricted to the TI-BASIC on my TI-89 Graphing Calculator. sigh, I wish I had more time. Oh well, I will in about a month and a half! WOOHOO! Highschool graduation! carrus85 does a little dance

I'm dumb!

Blah blah blah.
I've read quite a number of good ideas. A good start. But in the end all of these ideas are worth no more than the few kilobytes of space taken up on an 80 gig hard drive. (Or perhaps a a few KB on a <$1 DVD.)

It only matters where the rubber meets the road: Actual work (eg coding). Otherwise all we have is a disorganized wishlist. A w*t dream.

Pointing fingers and nominating people isn't getting anywhere either.

If you have the time commitment (e.g. months spending nights and weekends) and the discipline (e.g. no slacking or vaporware), step up to the plate with other people with the same passion and bandwidth, form a team, make some goals, and get it done. I don't care if you have little programming experience. You could learn. You could help with smaller programming tasks. You can do all the non-programming grunt work.

And you don't even have to listen to anyone. Now granted if you want to maximize the number of people interested in your finished project, you might want to listen... But those who do the work get to decide. Add Tandy support? fine. Program in Cobol? fine. Dump Linux? fine. It's your project.

I'm sure the Allegro community will cheer you on (assuming you in keeping in the spirit of the original Allegro library). And if you get enough steam, you might even get more help along the way. Myself, since I'm not going to contribute much, if anything to the Allegro 5 base and since no one working on Allegro 5 asked, no big wishlist from me.

Right now, all we have is Allegro V: Final Fantasy.

Hey, I'm more than willing to spend time on it. Truth told, I may only be able to contribute about 5-6 hours a week on it for the next month and a half, but after that, I'm pretty much without something to do.

Plucky, you do have some points. However, if the project is going to go anywhere quickly, it need someone (or a couple someones) in charge, otherwise people are going to waste their time reinventing the wheel, programming stuff that is already programmed, etc. There needs to be an orchastrator; someone to handle everything from a higher level, lest confusion ensues.

I'm not saying I'm not a programmer, btw. I'm just saying I'm not very experienced at programming, especially large, group projects. I would make a much better web maintainer, documentation maintainer, etc. than a programmer at the current moment. True, I like programming a lot more, but I don't want to hold anyone back.

EDIT: but if push comes to shove, I could do programming. I wouldn't mind doing some of the easier stuff, and I could always learn to do the harder stuff. Just whatever you do, don't ask me to do ASM yet; ASM is greek to me at the current moment...

Plucky: The problem is that if we start coding before we know what the hell we're making, it will all me wasted effort. Design and coordinate first, code later.

Design is already mostly done. Just pick up the mailing list discussion(s), or any of the documents on the Allegro web page.

So, I was wondering, does anyone know of any good, FREE programs that we could use to handle inhertiance diagrams for this whole deal? We need to get a design document going so we can see what exactly we are going to do.

Dia.

Haven't we already established that most people do not want to delve into the mailing list? I for one fear it like the plague. I would MUCH rather like an open discussion forum.

Seriously, mailing lists are annoying and outdated.

I have to agree; I hate mailing lists like poison. We need some medium that let's you interact via forums or mailing list at the same time.

I'd also like to point out this is probably the longest thread ever.

The problem with mailing lists is not only are they annoying as all heck, they have the tendency to be so unreadable, so unintuitive, you spend more time looking for infromation that getting the information you want! Allegro.cc's forums should provide a sufficient medium for us to coordinate with, coupled with email, of course.

In order to coordinate this, there should be a central person, but it should not be one that dictates decisions, but one that sets the agenda, i.e. he/she should be the only one to hold votes and will integrate code.

The core team decides what the decision making structure is. And there is a difference between coding/system decision-making and leading/driving. There's no point head-hunting for a leader or decision-maker without this core team in place. Those who will do the work decide on their own decision-making structure.

The core team decides what the goals are. Not us in the peanut gallery. Imagine the whole US congress trying to write a law rather than by a small committee. Also imagine the whole adult population of the US crying out ideas for a law in a public forum. How long would such a process take?

Form the team first. Make sure all the roles are identified. Fomr a decision-making structure. Make sure we have the skills to make progress. Make some goals. Then start on a design document and/or wish list, et cetera.

Then you nominate a leader and set up a vote or something. In the meantime, we'll be making a wishlist, thank you.

I'd contribute what I can (though I'm not terribly great), I just don't know what I should contribute. And I'm not exactly sure what areas of Allegro I could really help with. If someone would just tell me what to do, I could probably do it. But I have no clue where to start.

I guess I should just spent some hours going through all the future proposals, and coding what I can. If any of it turns out to be useful to the codebase, I'll submit it.

X-G, as I said, a simple wishlist is worth as much as its stored size on your hard drive. Not even a half-penny.

I was hoping to steer the discussion to nuts and bolts and spur action. But if you guys just want to prattle away and day dream, fine.

You just need a proper mail client. I use Pegasus Mail, and it can order the messages like in a forum. I attach an small screenshot so you can see

Hmm... interesting Oscar. Maybe there is value on mailing lists! I'm dumb!.

Okay, if plucky insists on finding a team, lets start the team! I'm in. Anyone else going to take up this charge?

That doesn't change the fact that you need to set up some kind of Allegro development "government" as soon as possible.

Plucky: My point is that it's too early to do code. We hardly even have a wishlist or a new dictator; this is no time to discuss implementation or actual code.

Anyway, I'd help out, but not if that means I have to start digging through mailing lists.

Personally, I say screw the mailing lists. We have tons of information in this thread on what we want. Lets just get a diagram/design document going so we know where we are headed before we jump the gun and go.

The mailing lists may be a good place to start for "ideas," But they are by no means where we should be turning for every little detail, judging by the number of people that dislike them.

Lets start by starting simple:

Figure out a portable way that we are going to use file input, that will handle endian-ness, and maybe VFS... I have a dia diagram of what I was thinking of, sorta...

I never said "start coding", though I used "coding" as an example of doing real work. I did say you need a team of sorts before you get started with anything. Of course the team could consist of one person.

Though we should be wary of those giving advice/suggestions when those people (like me) have little or no stake in the project, I'll suggest:
Contacting the Allegro code big-shots of yester-yore and seeing what sort of help they would commit to. Help is not solely coding but also understanding and maybe some direction and advice.
Understanding the Allegro 5 docs.
Understanding the Allegro code in the details. It's all there on your hard drive.
Understanding current DirectX/OpenGL/etc. architectures.
Understanding the "competition", like SDL.

Note that there should be a lot of learning first before the team gets started even with a design document (unless the team members are already quite knowledgeable.)

This is a very difficult undertaking. Which is why I have no interest in helping out other than to give suspect advice.

okay, so first things first, get the team going. I'll join, although I don't know what I will do as of yet. Maybe someone could start up a new thread to see some of the interest and to form a list of who is going to help?

EDIT: fixed some grammer crap

You do realize, of course, that since it's a completely new project, the code you start with, will be redone later, right? There's already been some design decision on the sound API, as well as some basic design stuff on the system API. Start with that, and as things progress, change it. The code you write now is not going to be set in stone for goodness sake, so why fear you'll screw it up?

Is this the longest thread ever? I mean, it's on page 12. It jumped like 3 pages today.(for default settings, btw).

Yes. Can we hit 300 before a) it gets locked or b) someone actually puts their code where their mouth is?

Don't threads get auto-locked or something? Or is it just the Hand of God/Our Benevolent Leader that does that?

Anyway, if we're going to coordinate things we'd better start by finding out what we've got already. Can someone more familiar with current A5 development sum things up for us? I'm talking code-wise, design-wise, and who-does-what-wise.

I will. I'll start a new thread on that.

Matt closes them. Mostly because according to his logic, by the time a thread hits that points, it's gone way off topic (Then again... Allegro 5 is off topic here if you think about it )

I'll second that.

I was thinking a good learning exercise/thought experiment would be to consider this question:

This is what I came up with:

1. Learn how to handle windowing/fullscreen on multiple platforms (Linux,Win,MacosX)
2. Learn how to handle Opengl on multiple platforms
3. Learn how to access the vram necessary to support the lowest common denominator of hardware you want to target (or not if you want to target more modern pc's)
4. Learn how to handle input on multiple platforms
5. Find helper libs that are compatible with your license for: Sound, pak files, and image handling/manipulation.

That would get you a start on a crossplatform game library.