I have used allegro for a little while now and when i look around on the web many tutorials futures SDL.

Which pros and cons are there between allegro and SDL.

Im planing to learn OpenGL in a while.

Shall i go ahead with allegro or shall i switch to SDL.

PS. I like allegro a lot DS.

Noooo! Fool! You'll get us all involved in the Allegro vs SDL battle again

Anyway, my $0.02:
If you're using it and you like it - stick with it. If you like something, chances are you'll learn to use it better, and that's what counts in the end.

I don't think anyone will argue that Allegro is more "feature rich" than SDL. Allegro supports loading more image formats and one of the biggies SDL leaves out is rotating images. There are no functions in SDL to rotate an image, and with Allegro there is.

In short, use whatever your comfortable with and there is nothing from stopping you from using both (Not in the same project though!)

Do a search for "libsdl" on these forums and you'll bring up some discussions. (You cannot search for SDL, as it ignores words 3 characters or fewer.)

The main difference between Allegro and SDL is that SDL is designed only to be a thin layer between hardware and the programmer. This means that Allegro has more features, but that SDL is slimmer.

Allegro and SDL also do some things differently, but they both get it done.

We really cannot tell you which you'll like better. Try them both out and see for yourself.

Both SDL and Allegro works with OpenGL, by the way. And I'd say Allegro is best for beginners. You can always try out SDL later

If your looking for alternatives I would suggest ClanLib (clanlib.org) .. its very nice. I would say its much less old school in its approach thus has its pros and cons, because its very diffrent from allegro.

Ah! A new month! Nice! Thank you!

Clanlib seems to be overkill for the situation (learning OpenGL, etc.), although it is quite feature rich.

SDL supports OpenGL internally (it lets you initialise a OpenGL drawing surface directly) plus has routines to interface with OpenGL builtin. Since, you want to learn OpenGL eventually, it might a be a good option. But then Allegro does have a lot more functionality. Sound, Input devices, etc. can be quite painful to use in SDL. As said before, SDL is a layer between the hardware and you, so you have to write quite a lot of code to make it work.

BTW, the SDL documentation itself has quite a bit of tutorial stuff in it. Download the package and see if it meets your demands.

It's all about requirements.

I think I'll stay with allegro for a while. I also intend to d/l SDL and have a look.

And thank you all for the answers. This seems to be a good forum that may come in handy many times in the future.

Hmm... I think I should seriously take a look at SDL, just so I can formulate an opinion when this topic comes up again.

Then again, I barely have time to work on my Allegro projects...

SDL has a complete mac port afaik... allegro's is still incomplete (right?)

Marcello

SDL supports 2d hardware a little better than Allegro, but not enough for anyone I've ever mentioned that to on here to care in practice, whereas Allegro does indeed offer many more "features" in terms of out of the box support for file formats etc. With SDL you get BMP and WAV and not much more. With Allegro you have at least (off the top of my head) LBM, PCX, BMP, TGA, VOC and WAV plus those datafile things that some people seem to actually like. For OpenGL purposes, the only benefit AllegroGL has over SDL is that the usual 2d functions continue to be emulated in GL mode. With SDL you must download an add on library to achieve the same thing. If you're a heavy advocate of modularity as I am, you might prefer to see this as a benefit of SDL over AllegroGL. Case in point : I recently wrote a remake of the old ZX Spectrum game Cannonball, the main reason being to play around with volumetric shadows. My .exe was 8kb. It would have taken about 1 minute to change the code from being SDL based to being AllegroGL based or vice versa. So my real decision was whether I wanted a ~450kb DLL or a ~90kb one.

SDL is probably more popular because it follows market forces. The Allegro developers seem to believe that Allegro has a divine right to exist and that decisions on its future should be made based on what they personally would prefer. If that makes a user unhappy, then that user can go find some other library. For example, take the decision to stick with underscores in function names for the forseeable despite this not being the case in either of the big 2 game related libraries (DirectX and OpenGL), the standard C/C++libraries (stdlib or STL), or almost any other popular game library (I had a glance at ClanLib, CDX, SDL ...)

For the record, SDL has a complete Mac port, and I think I read somewhere either already comes with all new Mac's on the CD that includes GCC, or will in the future. In addition, SDL is bundled with Kylix and the PS2 Linux kit.

It would be stupid to try to get into a popularity contest. After all if every lib did everything the same why bother? It's good to see differences in libs - that lets people use what best suits them.

I personally prefer Allegro over SDL (thus allegro.cc and not sdl.cc), but I really don't let that get in the way of recommending to someone to give both a shot.

Here's something: Allegro supports DOS, SDL doesn't. Ok, not that I really even care about that, but some people do.

SDL can be used on delphi/kylix? Curious...

I have faith that allegro 5 will blow SDL away. ;-) Especially with c++ wrappers I've been messing around with...

Marcello

Heh. I think there might be a Delphi binding for SDL. Not sure though...

Or, to put it in the thoughts of the developers : it would be stupid to listen to public opinion (we automatically know what is best).

This is indeed probably the route of the problem. In a world where fifteen different incompatible SVGAs existed and games ran in a severely backward OS with no decent hardware interface for this sort of thing, Allegro clearly had a mandate. Now it does not.

It has been questioned by people other than me why Allegro doesn't just have, e.g. an SDL target and therefore concentrate on its benefits over SDL (greater support for file formats, more of the features Shawn thought we might like such as the GUI, etc), instead of trying to compete when there is no reason and in a situation where SDL seems to be winning the popularity contest. The big bonus would be that Allegro would no longer restrict people who want good hardware access by not supporting any hardware which the developers decide we don't want to use.

Since at the end of the day you'd still be able to just download a single Allegro ZIP file, which would compile and offer the Allegro API across all the previous targets and many new ones - although Mac is the only one really significant - I don't see why this is a problem. Maybe after so many years of seeing people reproduce (often simply as a good education for themselves) Pac Man, Space Invaders, Pong, etc ad infinitum they've lost sight of the vast benefits of not unnecessarily splitting the market?

Okay. But conversely, SDL supports multithreading, so we can use our modern operating systems in a modern fashion, rather than pretending they are just DOS in new clothing.

As I said, SDL comes with Kylix, so you'd like to think so! Seriously though, from the little I know, I've seen Delphi/Kylix wrappers for most popular C/C++ libraries so I have no doubt you can use Allegro also.

SDL comes with Kylix? w0w.

You want a SDL target? You are free to write it, And it'll probably be included. The only reason It doesn't exists Is because noone has needed it badly enough to consider writing it.

It's really a case of 'you say tomato, I say tomato' (hmm, that doesn't work without sound )
You can take allegro and add some libraries, or take SDL and add other libraries, to end up with the functionality you want (pretty much, no doubt there's something that one or the other won't do)

I do think SDL seems to be used in more commercial products, and maybe is better known. But allegro has a more 'fun' community, that's my opinion.

Thomas H's arguments don't all make sense - Allegro does have a right to exist, for as long as the developers want to work on it. And, they're doing it for free, so it is up to them what goes in, surely. Is the SDL development process more open? I don't know.

For me, I know allegro, and I like allegro.cc. I have no reason to learn SDL.

Pete

Allegro.cc really makes allegro the place to be for a newb. I know I learned huge portions of my programming skill through this community, and have watched many people do the same; allegro users, especially newbies with easy questions, get so much support and help that it's hard not to recommend this lib as a good one to start on.
That, I think, is one of the most compelling pro-allegro arguments.

Yup. I learned most of C hacking games and utitlities together with allegro

With all due respect, I didn't say that Allegro didn't have a right to exist. I implied disagreement that it has what I would describe as a divine right to exist, and argued that it has no mandate.

It is up to them, but that misses the point I was making which is that Allegro has become the less popular option partly because of their decisions. I was mostly interesting in addressing David's observation "when I look around on the web many tutorials feature SDL".

This is true, but if I wrote an SDL target for Allegro that still wouldn't mean that I could safely assume the functionality exposed by SDL but not by Allegro was present if I wanted to write what would be considered Allegro applications.

Then write that too. nothing complicated there. the only reason the Alsa rawmidi driver for allegro (in linux) exists, is becasue I had a need. Look at the AllegroGL project, they saw a need wrote the code, and modified allegro to work with it. Someone just needs a big enough reason to do the work.

But that's what I mean... If you write everything for the majority all the time, then the minority never have anything to work with. Perhaps the developers of Allegro don't like SDL, so they come up with their own lib (Allegro 5).

• Let's say that SDL is what the majority want, as Thomas is suggesting.

• Then let's say that the Allegro developers don't like SDL for whatever reason. (If they did like it, they would develop for it.)

Given those two 'facts', it's only logical to assume that Allegro will be different, and most likely less popular.

Just because SDL may have more tutorials - doesn't mean it is more popular. Maybe that just means it's harder to use, and that people don't need as many tutorials for Allegro?

Allegro is more popular than SDL on this site (obviously), so it definately is hitting a fair-sized crowd. Allegro.cc has 250 different people who actively participate (member logon) in the site weekly.

If SDL is more popular than Allegro than I would say that the primary reason is because Allegro started out as a DOS lib and took too long to work well on other platforms (namely Windows). SDL was viewed as a cross-platform lib from the start, whereas some people still think today that Allegro is a DOS only lib.

Basically a lot of words just to say: I think it's good that the libs differ in areas. It gives people more choose that which best fits their style.

Listening to public opinion ?
What do you think ?
If you want it, code it. If you don't, you'd be arrogant to expect others to code it how you like.
But you can still voice your opinion, of course, like I do

This is an allegro site after all, so criticism of allegro was never going to be greeted with approval. However, Thomas makes a valid point if he is saying that he would like to contribute his ideas and experience to the project, but is not being recognised. There should be other ways to contribute, not just coding.
I have great respect for the allegro developers and I trust that the decisions they make are as a result of much debate. But I find that following big5 or the forum here to be too confusing. I don't know if there is something like this already, but I would love to see a kind of FAQ laid out like this:
1a.proposal
b.arguments for
c.arguments against
d.decision
2a. ...
Then, people would feel happy that the process was right, and we wouldn't see the same things coming up again and again. And, I could get really excited about Allegro5

Pete

Sure he's being recognized. Just noone on the dev team currently wants to code it. (they have no need) If he really wants it done (as I keep saying) he will have to find someone willing to code the needed code.

Currently I don't think there have been any (real) arguments against adding a SDL driver, and any extra features that that driver might provide.

You want me to adapt the Allegro API? In which case I can hardly claim to be writing an Allegro driver, surely? I'm thinking of some of the things I usually mention which I've found desperately useful but which other people seem able to dismiss out of hand - e.g. overlay surfaces (which are coming in Allegro 5) and gamma ramps (which weren't, last time I checked).

Thats true, and something I had not taken into account. Although it would be impossible to argue that Allegro was 'more popular' (i.e. more used) amongst companies, I must admit that my statement that "SDL is probably more popular" was based on fuzzy information sources such as the number of web sites, the number of posts here versus the SDL mailing list / usenet group. Also, I assume that if you find yourself in a situation where SDL comes with your compiler, you will almost certainly turn to SDL by default, meaning that increased popularity amongst companies filters down to increased popularity amongst users.

In terms of the sort of projects that used to make it big so that I noticed from the Allegro camp - emulators and remakes - the former market has more or less reached critical mass and the latter has been eaten away by Blitz and Dark BASICs.

In the short term Allegro is no doubt loosing out due to its horrible API, but on this topic I am towing the party line and of course, we are all aware that version 5 will fix the problem.

You'll agree though, that there is a line between providing tools for a minority and trying to create a minority? How about a new poll on the front page :

"
Which function naming scheme would you prefer for Allegro 5?

Another problem with the developers is that they seem to assume they can state the opinion of the Allegro users without actually asking them. I'm not expecting such a poll to deliver them any sort of sudden shock, and only a fool would expect them to stage a U turn if it does, but since you don't seem to have much else to put in the polls do you not agree that it would be very healthy to use it as a simple forum to allow the expression of wishes for the new API by the majority of users where the developers cannot simply pick us off one by one?

This is another area I hadn't thought too hard about. I would be perfectly happy to, and am abstractly capable of, developing an SDL target for Allegro, but for two problems :

I am aware that the reason Allegro does not build on MSVC is that it still has a large quantity of AT&T type assembly which MSVC does not support. I am also aware that the developers have at some stage taken on board that switching to intel syntax assembly for version 5 would not limit target platforms in a world where NASM exists, so I assume that will happen?

I agree. What we need is a formal, public, convenient means to openly discuss these things. The mailing list is hell for dialup people such as me, and has the disadvantage of not having a means to get any sort of consensus amongst anything like a good cross section of the Allegro user base. Could we not have some sort of forum here where people can post ideas, give the developers (or whoever) the right to reply for a short while, then move to a vote on the issue if required?

I like the idea of hosting some better way of discussing such things; the allegro 5 dev process is important to lots of people, and it's good to be able to see majority opinions on many things.

Erm, although one must remember that voting systems can be tampered with, probably, I'm pretty sure matthew said his front page poll thing was not so hard to cheat on (was a while ago though, I don't know currently ...)
But anyway, that probably won't be too much a problem. I guess it's mainly an issue of whether those intimately involved with development would care, and whether matthew feels like doing the extra work to create such an interface.

Oh, and a stupid question from me: I thought allegro could be built on MSVC? At least, I know I've compiled allegro programs frequently, using MSVC! What do you mean, is this a new problem, or something that for whatever reason only bothers one when modifying the lib?

I wouldn't call it 'horrible', but 'inconsistant' and suffering a bit from legacy. Part of what makes Allegro nice is that it's API is simple. If all the functions were renamed, the Allegro 4 API would actually be pretty nice. (Yes, it still wouldn't support some things that today are nice to have, but it would be nice nonetheless.)

Actually I'm currently working on a survey system for a commercial website I'm doing, and I plan on making it available on Allegro.cc so that certain developers can set up surveys and ask a bunch of questions at once, instead of a limited fashion from what the polls provide. At that point, I/they could take suggestions for questions to ask. Doing it in a survey fashion would allow the results to be easily believed (ie, only one response per member) and tallied.

The majority of Windows users, no doubt. But, can one even build SDL on Windows/MSVC? Last I checked, I thought the SDL build process (on Windows) looked much more complex than Allegro's.

No, last time I checked, the Allegro DLL and/or static libraries could not be built in MSVC, but instead you had to go sit through a GCC for Windows download and use that to generate the DLL, then use an import tool to make the DLL linkable from MSVC.

Yeah, SDL can be built on MSVC*. But that isn't the point really, I just would have thought that the compiler used by the vast majority of the vast majority (happier with that description?) would be one the Allegro developers would be keen to support.

Presumably you can set build options to build the pure C version of the library under that platform? (Ha: now I suddenly ask a programming question)

• a direct quote from the SDL install instructions :

Compare and contrast with Allegro :

Therefore, to build any of the various builds all I require is MSVC + DirectX libs, and I do everything from the IDE. To build Allegro I require MSVC + DirectX libs + DJGPP + GNU make, and I have to use the prompt. Perhaps this is yet another reason why, as far as my anecdotal observations show, SDL is the more popular option for so many?

A few points:

The underscore thing I really don't understand. The idea that one library should use a naming convention because another one uses it is surely fatuous.

Please don't have voting for the allegro development process. By all means gather opinion, but doesn't experience show that you need a dedicated person or small core group to really deliver a great product (think Linus Torvalds, Wozniak/Jobs, Shawn Hargreaves, Sam Latinga if you will, or even Ma****ew Le****on )

As for the build process, what's the process for SDL/Linux? Or MinGW? One benefit of Allegro is that if you use a free cross-platform compiler (i.e. gcc, mingw, or djgpp) to build a free cross-platform library, the process is almost identical.

Lastly, I'll say it again - a focussed method to get opinion on development questions and a way to feed back the decision would be great.

Pete

Thomas Harte: Regarding the SDL build, on second thought I think I was trying to build for MinGW32 on Windows. If all you need is to load the project workspace for MSVC, then obviously you cannot get any better than that.

For version 5 of Allegro, it would be nice to be able to build natively for MSVC. I don't know how much of the assembly is going to be re-written though. Again, this is a legacy issue - not a "we hate MSVC" thing. DJGPP and DOS a popular environment during the early days of Allegro. If I had the skills to do the proper assembly code for MSVC I would.

That's not what a survey would be for. It would be to "gather opinions", as you said. I agree that in most software a "dedicated few" is better at making decisions than the mass population. (Mostly because the mass population is full of dumb people )

However, a survey would be nice for things that are nothing more than personal preferences or to gauge interest on something.

For all that is good and holy, keep it at alternating_underscores. The other schemes actually give me a headache (and yes, I used them in the past).

If this is such a big issue, the solution is simple: provide a wrapper header consisting of static inline functions that changes from the one to the other. Do you know I seriously considered doing that for OpenGL because MixedCaps conflicts badly with my own coding style.

Just voicing my opinion, of course.

Note that SuSE Linux comes with Allegro on the CD. I'm not sure, but I think it doesn't include SDL. I could be wrong though.

erm... [AD] generates less than 10 messages per day on average, I think. I'm on dialup and find the mailing list far more convenient than these forums, for instance. I'm not sure why it's hell for you.

Well, there is the Allegro development forum? I'm not sure how many of the developers read the forums, but I see Bob, Vincent, Peter (Wang) and Grzegorz around here regularly at least.

Oh, and I agree with Peter Hull: voting would be a bad idea IMHO.

That isn't the point. Firstly, the underscores were just a particular example of how the developers like to ignore the users. However, more on topic, Allegro stands alone in using the underscores seperate to not one library but every other library that 99.9% of all game programmers will come into contact with. Perhaps this doesn't matter to you, but it makes everything look very ugly when you use more than one library at once. Common examples of when this is true include absolutely anything written in AllegroGL, anything also linked to zlib, or more or less any other library you care to mention.

If code is ugly, it takes longer to read. This is a genuine usability issue. There will never be a consensus among users, but surely it is smarter to go with the same scheme as everybody other library than to go it alone?

Evert puts it nicely when he says how annoying having to deal with a library that contradicts what you are already working with can be :

Anyway:

Linux : To compile and install SDL: Run './configure; make; make install'

MingW32 is more complicated, as Matthew points out. Specifically :

Step 1. Download the msys package, version 1.0.8 or newer, and install it.
Step 2. Download the latest stable version of the MinGW package.
Step 3. Run the msys shell. Further instructions assume you're in this shell.
Step 3. Unpack the MinGW package in the /mingw directory.
Step 4. Move /mingw/bin/make.exe to /mingw/bin/mingw32-make.exe as directed.
Step 5. Extract the SDL source into a directory and run: ./configure && make && make install

I guess most people who download MingW32 don't bother grabbing msys, but if we return to direct comparisons with the Allegro build instructions for MSVC, then at least we can say that msys is actually a part of the MingW distribution (it is included on the MingW sourceforge download page http://sourceforge.net/project/showfiles.php?group_id=2435), and that the total download for msys seems to be a little less than 3mb - less than half what you'd have to download for a minimal working DJGPP.

Finally, in defence of being able to vote on some development related topics. The problem at present is that if one person raises an issue which the developers don't like, all that happens is that the developers come out and say either "we don't agree", or if they've already said that in the past "this has been discussed". This makes it near impossible to gauge whether a majority of the users want a particular feature which the developers have just flatly rejected. Since the developers seem to justify every decision with "we do not think the users would like that" or "this would not benefit the users" (or even, in the case of why they are sticking with underscores "you'd be surprised how many people ask us this") without having done any actual research or anything, voting would presumably therefore just offer those developers - who seem to be entirely community minded - a better information resource.

What!? Personally Im not a allegro developer, But I deffinitly prefer the underscores... gives more contrast than the CUpperCaps method. (or worse yet, szv_CUperCapsBlahJoe)

What is ugly to one person wont be to another. I find that UpperCaps crap fugly as he11. But thats my OPINION.

Want lots of examples where underscores and no caps are used? libc, libstdc++, libvorbis, libogg, libvorbisfile, lua (Im sure theres a TON more...). Now tell me that the majority of APIs that (PC) game developers come into contact with don't use underscores. heh. more like APIs that are DX or based on DX. hmmm... weird no?

[edit]

what? for allegro I just download Mingw v1 and everything is peachey. why msys? and make should be make... not this mingw32-make stuff.

Now if youre thinking, oh but my MSVC or borland or whatever make is going to conflict with it!!! that means you havent setup your system correctly. you setup a runner batchfile for each compiler and away you go.

[edit2]

Wana know what? screw this... The developers are doing it all in thier spare time. you dont like a decision? you have two (valid) options. You can ditch allegro, or you can do something about it. Even if that means forking allegro, go right ahead. uggghhh. Quit making such a fuss.

Some more libraries are: zlib, libpng, the Matrix Template Library, the Standard Template Library, and Boost. I'm sure there are many others. Out of all that Thomas Fjellstrom and I have listed, which ones are broken from a usability standpoint, which ones are not widely used, which ones would actually benefit from a mixedCap naming convention, and why?

How is that different from Allegro's Linux build process? Sure, you can (but don't have to) pass more options to ./configure, but that's about it.

I already did.

Oh, yeah, and APIs which are OpenGL or based on OpenGL too. If you like I could carry out a statistical test by heading down to my local game shop and working out the proportion of games based on either DX or GL versus the proportion not based on either of those.

Indeed a long list. But I notice that the one library I know well from your list doesn't actually use underscores at all, so you'll excuse me if I don't take your word as bible. Or perhaps you can point out the underscores in :

zlibVersion, deflateInit, deflate, deflateEnd, inflate, inflateEnd, deflateInit2, deflateSetDictionary, deflateCopy, deflateReset, deflateParams, inflateInit2, inflateSetDictionary, inflateSync, inflateReset, compress, compress2, uncompress, gzopen, gzdopen, gzsetparams, gzread, gzwrite, gzprintf, gzputs, gzgets, gzputc, gzgetc, gzflush, gzseek, gzrewind, gztell, gzeof, gzclose, gzerror, adler32, crc32

It looks to me like they've stuck to the stdio naming convention for functions which are pretty much stdio equivalents and branched into capitalisation elsewhere. Mind you, TF Sees underscores in libc, so perhaps that is what was confusing you?

Well, off hand I'd have to say that I've never heard of anyone using much of BOOST before, but to claim as such was truth would be to fall into the trap affecting some of the developers : assuming I know things for which I have no evidence.

I don't see why this is a relevant question in a thread principly about why SDL seems to be more popular than Allegro, and using underscores as a particular example of how Allegro differs from the sort of thing that would make it more popular. Unless you want this answer :

But I fail to see how you won't have picked that up as my opinion already.

It isn't, but why do you ask? And who suggested it was?

I notice that you draw a distinction between 'doing something about it' and 'making such a fuss', which shows you probably haven't realised that most changes in this world come about only when somebody makes a fuss. And if you think that arguing for a better source of information from which the developers can digest the opinion of users is not helping them then I think you might want to address that belief also.

DID YOU look at the link? No? didn't think you would.

why did you mention it? (and I quote: )

I am unwilling to enter into personal attacks, and would kindly request that you assume the same position. Directly answering the question, yes I did. And I overwhelmingly saw functions such as :

tolower, fopen, cfsetspeed, memcpy, pclose, printf, setgid, signal, umask, wordexp

And only very few functions such as :

va_end, fgetpwent_r, inet_ntop

Which don't even conform to the same underscore system as Allegro anyway. Did you post the link you intended to?

I answered the question asked by Peter Hull. I have this bad habit of doing such things.

that wasn't a personal attack. I could, if you want.

wow. printf, signal, and fopen don't have an underscore? w0w.

It especially pertains to the fact that they overwhelmingly DONT use the UpperCaps stuff.

I hope you can understand why I mistakenly took the suggestion that I had not bothered to read the links and furthermore that I was almost certain not to as a personal attach. Apologies.

Indeed I now realise that you have a point in that instance, however I would argue that you would not have a point were you to instead argue that Allegro takes its cue from such things as libc, since to my mind there is a gulf of difference between the two naming conventions. Also, I must question why you then attacked whether I'd seen the link or not when I clearly stated that I didn't see how you saw underscores in libc, when surely you wanted to attack me for not having properly digested your post?

Speaking of which, much as I enjoy talking about naming conventions, and making it explicit that I am not shying away from my belief that Allegro is the 'odd one out' in this respect amongst popular game related libraries, how about we return to a conversation about the possibilities of finding a better way to gauge opinion amongst Allegro users for the benefit of the developers?

Do people agree or disagree that currently the developers seeming to just assume they know what people want is not necessarily going to produce the best output?

I repeat that I favour the idea of polls that could be opened on development 'hot topics', so that the average user could more easily and fairly express their opinion, and more users could be conveniently surveyed than via mailing lists. Obviously there is absolutely no binding reason why the developers need ever look at or take part in these polls, but it would provide a useful statistical argument for those who do actively take part in development discussions.

How bout the fact that Im too darned tired to think let alone argue? Maybe later...

I'd just like to say:
STOP IT NOW
Please, Thomas F and Thomas H, do you really think that underscores or not underscores should be the priority for Allegro development?

Pete

ps. there are underscores in SDL, aren't there sorry sorry sorry

hear, hear.

If you truly care so badly about your code looking bad, write the wrapper I mentioned. In fact, this might be a good thing regardless, as Allegro would then fit the coding style of any user.

I'm not sure if this would ever be included in the distributed version of Allegro, but I wouldn't be opposed to such a thing. In fact, if it does some people a favour, I'd write it myself.

Personally, one of the reasons I didn't do it for OpenGL was that the change in style makes it easy to spot where I'm doing OpenGL stuff and where I'm doing my own stuff or Allegro stuff.

Regarding the compiling Allegro on MSVC issue. The problem is the AT&T syntax. True, nasm would make it possible to switch to intel syntax instead, but this is not going to happen for the 4.x series. However, if someone were to do a port of the AT&T assembler routines to intel syntax specifically for the MSVC build, I'd be in favour of that being included in the Allegro distribution.
Does anyone know if you can compile the C only version (without the asm routines) with just MSVC? If so, this could be a starting point.
TH: could you look into this? If it's possible, we could distribute a project file (?) for MSVC in the Allegro WIP distribution with the note that it can be used to build Allegro, but that the build will not be optimized (yet).

EDIT

I disagree to some extend. I'm mainly an Allegro user, but I voice my opinion on the mailing list regularly. I made a few changes to Allegro that were relevant for me and submitted them. I made some suggestions that influenced the development of Allegro.
You're free to join the mailing list and give feedback on current issues. IIRC, [AD] is archived now, but I don't have the URL. There's Allegro's page on sourceforge where you can post feature requests and report bugs. In my experience, it isn't used very well.
There are ways to give feedback to the developers, but you need to actually do it rather than place comments on the forums here and complain you're being ignored. No pun intended.

Dose it realy matter wever youTypeLikeThis or like_this? I think that if it dose then you need to get out abit more(e.g. get a life) or like Evert said ...

I can understand that you want your code to look good so should any self respecting programer but if its good code then the proth is in the binary. And lets face it even if you write shaby code as long as people like it and can play your games its good.

Anyway to sum up Allegro vs. SDL round 1200:
Try both! Make your own mind up.

If your a biginer Allegro is sugested as many of us managed to start and learn C while messing around with Allegro.

If your a person that likes good looking code then it realy is a personal thing as some ppl like:
ALDrawBitmap
al_draw_bitmap
AlDrAwBiTmAp <--- i think this is realy artistic but dumb as hell.

Nice to see we all agree.

Will do. I have MSVC 5, so while later versions can happily read the same workspace information, people with MSVC 4 might have a problem.

I agree. Which is presumably why I engaged in several conversations on the big5 mailing list before forming an opinion about the general nature of what was going on and departing.

http://sourceforge.net/mailarchive/forum.php?thread_id=1076372&forum_id=11854, for example, is a snippet of conversation that followers of this thread will find very familiar, from September. To sum up the totality of that thread and its various branches - Robert Ohannessian (Bob) prefers underscores, as do Thomas Fjellstrom and Matthew Leverton, so : decision made, regardless of people such as Javier Gonzalez calling for a vote to properly settle the matter.

Anyway, to make clear that I thoroughly agree : talking further about naming conventions will achieve nothing. I just seem to be unable to leave aspersions cast on my character unanswered. And, before anyone attacks me further, notice that I have quoted from no earlier messages than the one where Peter Hull stopped it now.

Don't take it personal If I'm arguing, I'm arguing about what you say (and perhaps the way you say it), not you personally.

There's no such thing now, so from that perspective having anything is better than nothing. It's a long road to a native MSVC build anyway.
The main issue I can think of with switching to seperate assembler code for MSVC is that there are two assembler code bases for one platform. I imagine this will be a source of discussion yet.

The c++ wrappers I've been messing with use the alBitmap naming convention, seeing as most OOP stuff is like that... (maybe I'm wrong, but I personally prefer that style, whether or not allegro uses it, doesn't really matter to me-- it is an extra 1-5 keys on every function (al_blit...alBlit...))

Marcello

al_blit has a tendency to be mis-typed as al_Blit, and is more keystrokes than alBlit, as Marcello said; but yeah, this really don't make that much difference.

Anyway, I realize what you meant about MSVC; for some reason I was thinking build FOR msvc, not build WITH, and, um, I dunno; I'm fine now
It would be cool to see a better build process for allegro & msvc; yeah, I guess it would.

It's cool that Matthew intends to set up something like that ... maybe we'll see some interesting data when he does! Yay to Matthew!

And to Evert: the wrapper idea thing sounds cool! Heh, and we'd have one less silly argument ...

I didn't really expect to be obeyed

Look on the +ve side, folks: we'll soon have an MSVC project for allegro (I'm really surprised there wasn't one, actually)
And, am I detecting some agreement that we general users would like to feel more in touch with Allegro development? What if someone (could be me, maybe) subscribed to big5 and AD, made a weekly summary and posted it here? Would that be good? I'm thinking something like the weekly sprout on netbeans.

Pete

SSSSWWWWWWWWWWWWWWEEEEEEEEEEEEEEEETTTTTTTTT!
;D

Like.. mega sweet :)

....although, the newer WIP's have been pretty unstable compared to 4.0.2. I stopped using 4.1.4 because it couldn't use windowed modes in XP for some reason, among other problems.. :(

Me and Matthew are just users. Not developers
It just so happens that the majority of the developers (if not all) preffer the current naming scheme. I'll bet if they prefered the AlBlit method that would be used. I ask you to code an entire project in someone elses coding style. It's like writing in a language you don't know.

I think thats a great idea, then more people might be 'spurred' to join the lists to help things along.

AFAICS there really are about (maybe) 4 people working on allegro5, (one of which I hear probably won't be working on allegro4 much anymore), and Those 4 people are working on seperate parts, and slowly so [uncle sam]Allegro Needs YOU[/uncle sam]!

note: AFAIK, the developers are doing it for fun. Once it stops being fun, they will stop. like the person I mentioned above...

I was going to suggest that myself actually. I like the PHP Weekly report. I'm not subscribed to any of the PHP dev lists, yet I can feel like I know whats going on. If someone can weekly come up with a similar style report for Allegro, I'd be glad to host / promote it.

Yes, I know there are the mailing lists, the archives, the digests - but nothing (except maybe google ) compares to a summary prepared by a live human.

I could do that for AD. I already read it and it wouldn't be much work most of the time. I don't care enough about the Allegro 5 API yet to subscribe to that - the current API is fine with me and even if Allegro 5 comes out, I may decide to stick with 4.

Anyway, a summary of AD since november 25:

-----------------
There was some discussion over plugin scrips in Windows that were given the .scm extension. This conflicts with Sceme. The DJGPP port uses .scr, which conflicts with the default Windows screensaver extension.
Don't ask me what this is about, though.

Eric (Botcazou) announced the 4.1.6 WIP on the mailing list and proposed to try for 4.0.3 beta before the end of the year (with backported bugfixes from the 4.1 branch).
Following up on BP's remark on the forums that the change of the close button API breaks DUMB, I proposed that the old API be restored for 4.1.6. I also proposed to backport the fixed closebutton behavior for the 4.0.3 API. Eric called for a poll among the other developers which hasn't generated much discussion yet.

A bugfix to datedit.c was commited, as was a change to the timer synchronization code.
A modification was made later to fix a bug that caused programs to hang if a key was held longer than one second.

Vincent (Penquerc'h) reported a problem with the mixer on one machine, which is still being investigated.

Elias (Pschernig)'s xkeymap utility was included in tools/x11.

The old close button API was reinstalled in the CVS code and tested.

Then Ben Davis posted a long message about the breakage of the close button in the new WIP and that it broke DUMB. There was some discussion afterwards, and the conclusion was that strict API compatibility cannto be guarenteed during development, something which wasn't clearly stated in the documentation. The docs were subsequently changed to make this explicid. The bottom line of this discussion is: a WIP is a WIP, not a stabel release. If things are broken, well, too bad, but that's why it's called a WIP.
Ben promised to flame Eric in the release nots for the next version of DUMB.

A documentation change was made to make it clear that video bitmaps are lost after a call to set_gfx_mode().

There's a crash issue (from 4.1.4) on w2k (related to the switching code, I think) that is under investigation.

Matthew reported the broken build of 4.1.6 for MinGW, which was promptly fixed in CVS.
Eric announced a quick release of 4.1.7 to remedy the problem.

aj requested an additional flag to the Windows window creation code. I'm not sure for what, but I think he wants to be able to use drag and drop to an Allegro program.

Finally, Hein Zelle inquired if the new textprintf_ex family will be re-named to textprintf, but notes that api.txt probably implies that they cannot be. He also requested some clarification about the function renaming scheme.
-----------------

There, you're all up to date now

I'm not sure when I have a MixedCaps conversion header, but I'll try to have it sometime next week. No hard promises, though.

EDIT:

I could do that. It may be saver to have two people for the job, though. Just in case one of us is eaten by real life issues

Has anyone ever tried SDL_net? Opinions?

did u guys ever notice that when we talk SDL vs Allegro, TH ends up being attacked some way or another! I think it's pretty good that the guy has knowledge of both kits...

Erm, well, THarte writes things about allegro's interface and such that some people disagree with, and often introduces "another side" to the discussion, which is GOOD, and it is also GOOD for people to challenge what they do not understand as this is the way that discussions like these can teach people and open minds ... so I would not really say it's a Bad Thing that TH ends up defending his views more often than not.

Of course, any attacks on TH as a person are immature, and while they may be an offspring of debate, ideally would not happen. TH is a good person with some good points, and even if he were not there would still be no excuse to abuse him. Thankfully, this tends to be kept to a relative minimum, I think... I do hope he has not been too offended!

I don't know... I find that everytime theres a Allegro vs. SDL discussion, someone ends up whining about the api or the naming convenstion. Its really anoying. and serves no purpose in these threads.

[edit]Or someone starts whining about how the developers NEVER listen to anyone, i mean even though they work on allegro in thier own time, they should OF COURSE bow to the whims of every single user. Yup. thats what we need. We need to integrate AllegroGl, alogg, allegpng, libnet, mpg123, pthreads, etc, all while supporting: windows, unix, linux, dos, MacOS 9, MacOS 10, etc....

I think that would lead one to believe that perhaps that Allegro then could use an API clean-up? If someone asks what does SDL have over Allegro, an obvious response is going to be "a cleaner API"*. So, whether you like it or not, it is relevent, and it's going to be brought up.

Does there need to be much discussion on that point? Not really.

~~~~~

• I'm not refering to NamingConventions, but just consistancy in names, parameter order, etc.

Been discussed muchly on the lists (IIRC). And will probably come up again But things like that probably wont change in allegro4. You should see some of the stuff they are working on for allegro5. neat stuff. like filters. no files. just filters you setup a chain of filters and away you go. ie: one filter reads from the disk, the next is a bzip filter, the next could be anything!

I don't want to put too much weight in the poll, but right now (at 106 votes), unders_score, smallCaps and CapitalizedWords all have roughly one third to one quarter of the votes, with under_score having a slight majority.
So I'd say that the claim that Allegro is bad for using under_scores because everyone uses AlternatingCaps has been refuted.

I agree with Zaphos' remarks about TH having good points and being a valuable contribution to the discussion.
I also somewhat understand the annoyance in TF's posts, because TH has a way of hammering his points down that annoys me as well from time to time.
This, I think, is simply due to a difference in personalities and I try to look beyond that.
I stress again that I have no problem with TH as a person and that I value his input and views.

Er, well, the smallCaps and CapitalizedWords styles are similar enough to me that I imagine them to be essentially the same category - essentially, it's splitting the votes on that. If you artificially "unsplit" the votes, it looks worse for teh under_score. Furthermore, since many people seem to learn C along with Allegro, Allegro teaches some the under_score, thus perhaps giving a skew from what one might see if, say, GDNet were surveyed. ANYWAY, your thingymajig would be the ultimate solution, Evert ... and furthermore, this is a point not entirely worth arguing about. It's mainly a personal preference, to me, and if it's the only problem with allegro 5 then the developers should be darn proud!

Well, as of this post, ~50% is for SomeSortOfCaps and ~50% is not. But I must stress that this poll does not accurately represent all programmers.

Let's say there were no duplicate votes, no cheating, no lieing, etc. The most the poll could do is show the preference of Allegro.cc visitors. If the same question were to be asked on a site like gamedev (mostly Windows/DirectX people), then I think under_score would be soundly beaten.

If I were to disallow non-member votes on this poll, the under_score jumps to nearly 80%.

All of this said, I think we can safely assume that no one style is going to cover the over-whelming majority.

However, we can be assured not not many people would be pleased with ArTiStIc(). (Sorry, PyroBoy)

hehe. For the SomeKindOfCaps method the only reason people code that way is cause that is what they learned. I happened to learn the under_score method. Now, everytime I try and code in C++ I keep wanting to use the SomeKindOfCaps for classes and such cause thats how I learned C++. But it looks ugly with a mix of both.

I'd sum it up like this (with 195 votes cast) :

39.49% prefer a scheme with underscores in it. 58.46% prefer not to have underscores. I think that result speaks for itself.

50.77% prefer a scheme with some capitalisation, with 47.18% opposed. Which doesn't really reveal a lot, but I guess some capitalisation nominally wins the argument.

Only 26.67% prefer a naming scheme where the first letter of a function is capitalised, leaving a very clear majority of 71.28% opposed to capitalisation of the first letter.

Therefore, it seems that even on a site which, as Matthew Leverton suggests, is probably biased towards the existing system, the statistics at this stage suggest that the best compromise would be no underscores, first letter lowercase, every other word given a capital.

As has been pointed out, the underscores would win in a 'first past the post' type system.

Therefore, given that we all accept that there is unlikely to be a consensus, the remaining question is surely whether it is better to compromise and try to offend least people, or to stick to the single majority winner. Notably the single majority winner is very nearly (i.e. give or take the issue of first letter capitalisation) the exact opposite of the compromise scheme.

What about people like me, who may have voted on arrival at the site, and then later logged in? How can you tell whether a vote in that circumstance is a member vote or not?

If you arnt loged in you arnt a member. Or at least theres no way to tell.

The poll also asks "which most closely resembles your coding style", not "what would you prefer Allegro to use". To some of us, there's a difference...

True, but on the other hand it definitely isn't safe to say that the front page poll strongly backs underscores as the function naming preference of all, and it would probably be naive to say that that this thread didn't in some way influence the choice of poll.

Hehe... next year I'm planning to train in law. No, seriously. I'm England/Wales based and intend to be a solicitor so won't (without further training) have rights of audience above the magistrates court, and probably won't be in court much at all, but in that and other mediation matters I'm just going to have a great time!

go for it. You'd be great.

My brother was the same way... He'd win an argument even if it took him years. (and he'd have valid substantial proof... always hated that about him )

Actually I could easily tell by IP Address and member location 'habits', but it doesn't mean enough to me to do the calculation.

I think the split between: smallCaps() and CapitalizeWords() is interesting. Lets say Allegro (or any library) were to choose some form of the above. Now you would have arguments against those two.

Then furthermore, you would have arguments against:

LIBNAME_FunctionCall()
LIBNAME_functionCall()
libname_FunctionCall()
libname_functionCall()
LIBNAMEfunctionCall()
libnameFunctionCall()

And so on... I think it would be easier if it were like a C64 where you only had (realistically) one case and eight (I think) characters for naming.

Yeah, the naming argument is endlessness, although a large amount of surveying of various internet populaces might give some basis to a decision. At the point where you're adding the libname on, it seems kinda arbitrary (except that ALLCAPS almost never wins anything, heh), though ... and most of the people will be satisfied just ignoring the issue. Oh well; one does what one can and then moves on, no use dwelling on irrelevancies.

Hmm .. single case computer systems ... I bet that's why COBOL uses the ALLCAPS convention ...

Anyway, be interesting to see if you can get some more significant survey data on api user preferences with that discussion-group-idea-thing!

Eek! I'm suddenly reminded of QuickBASIC's IDE. It used to change all the keywords to UPPERCASE. shudder

Work on my wrapper is going smoothly, though I'd like someone else to try it before releasing it. The MixedCaps positively hurt my eyes, though

<offtopic>
TH: well for goodness sake don't become a statistician!
Seriously though, have you ever thought of being a patent attourney? It's kind of legal stuff, but highly technical too, and ideal for those skilled in the devious arguing style .
</offtopic>

SDL SUCKS... !!
I tried it for a week and i could not get anything to work..

Allegro never gave me any problem....
and it's rocking fast..and easy to learn..
even an idiot can work with it !!!

So that's why my games sucks....