Need some help choosing a good graphics library

[dead_cell]

Hey all,

I've been getting bored with console-based C++ programming lately and was thinking about doing a little bit of grahpics work in C++ before I move on to full-fledged windows apps and the like (maybe moving on to Perl...). The only problem is, however, that I don't have a graphics library. I've heard some good things about allegro, but I'm wondering what you all think is the best library (for an intermediate coder).

Thanks again,

Dead Cell

[Hunter2]

To choose from:

OpenGL - Cross-platform support, only graphics, supposed to work great with SDL (i.e. SDL for input).

SDL - Cross-platform support, supposed to works great, supposedly used to port some Windows games to other platforms

GDI - Built into Windows, only graphics, very slow, counter-intuitive, but still useful to learn. Not sure if it's a "library".

Allegro - Heard it's really easy to pick up, can do lots of neat stuff really quickly, and the documentation is good.

BGI (?) - No idea what it is, or if it's a library.

DirectX (directdraw) - Not sure if its a library, but very good for graphics. Not good for beginners though.

Those are the ones I've heard of, and I've given my personal opinions about them. :)

[frenchfry164]

I do believe BGI is Borland Graphics Interface. I don't think they ever made a windows version.

I used to recommend Allegro to beginners, but now I don't. Why? Because it teaches bad habits in programming, that could mess crap up in windows. Especially in handling messages. I would recommend learning the Win32 API before you start using anything like Allegro or SDL. Although Allegro requires no knowledge of windows, I would still learn Win32 b4 Allegro. I learned Allegro first, and now I am slapping myself silly trying to forget all the crap that in regular programming you should never do.

[Hunter2]

Nice to know that I did something right for once :D

[Liger86]

hey dead_cell!

If you think you know consol-based programming well, and you had a bit experience in VC++ then you go to try OpenGL!

I'm currently going therough an OpenGL tutorial on http://nehe.gamedev.net/ and they explain stuff so its easy to understand! Well to me, however you should choose wisely becasue ones you get adicted to OpenGL you wont want to go back and vice versa!

But make sure you know C++ good before you gothere, you won't know a **it what the're are talkin about.:D

[dead_cell]

Thanks everyone. I've been getting bored with C++ for the last little bit (they're making me learn VB @ school... bletch!!!). Anyway, I think I'll try my hand at a little bit of allegro, then some OpenGL - then I think I'll be ready for the win32 API.

Thanks again everyone!

[Coder]

If you decide to choose between DirectX Graphics and OpenGL, make sure you read this document here : http://www.xmission.com/~legalize/d3d-vs-opengl.html which is a straightforward comparison between the features provided by the OpenGL 1.2 core ( i.e. no extensions ) and Direct3D 7 and 8.

[Liger86]

Learning OpenGL is harder then I thought!

Oh god, nooooooooooooooooooo:eek:

[Leeman_s]

if you ask me, learn windows API before opengl or directx

[Hunter2]

Indeed. After all, DirectX needs Windows to work...

[frenchfry164]

You have to have Win32 knowledge to do anything in DirectX because you have to use Win32 to use DirectX. I would learn GDI or GDI+ b4 DirectX as well.

* To use GDI+ you have to have the new Platform SDK and the dll for it. WinXP and I think 2k come with the dll.

[cozman]

making a good game in OpenGL generally requires a bit of math (collision and stuff)

if you want to start in 2D i'd recommend (shameless plug: http://zengine.sourceforge.net) It uses SDL and OpenGL, and it's real easy to use, and I offer personal support for it (seeing as I wrote the entire thing)

[Flikm]

another one is clanlib(clanlib.org). cross-platform, and works better with ogl than sdl. bgi is slow.... dont use it.

[Winston]

As allegro is all i've ever known, i'd be interested in knowing what bad habits it teaches you.

[frenchfry164]

well, just to name one, it teaches you not to even bother with windows messaging (not MSN messenger, actual messages that tell programs what to do). Sure it handles it for you, but in a real windows application you would never use readkey(). You would lose a bunch of messaging. Now unless you want to use Win32 API mixed with Allegro which really kills the whole concept of simplicity, you are going to be confused when you start windows. I think SDL is like this as well, but I'm not sure. SDL is also a LOT better organized. Some people won't really develop this habit in Windows, but some will. NEVER make a blocking function in Windows unless it can do a message loop within itself.

Here are some things I DON'T like about Allegro besides the bad habits (yes I only named one, but it's the only thing I can think of off the top of my head)

1. Lack of organization and consistency
2. Not very flexible. Although they think it is, just because they support a bunch of obselete file formats nobody uses anymore
3. I HATE the function names. Everything is lowercased and words are seperated by underscores. example: draw_sprite(). Someone asked one of Allegro's dev'ers one time to change it to Hungarian Notation, or at least LikeThisToSeperateWords and he said "No, because I like this way better"
4. The attitude with the developers is "This is OUR library meaning what we want goes in, what we don't does not. Just because everyone wants something doesn't mean we're actually going to put any effort into it". They actually said that in some form on the message boards.
5. THEY MAKE EVERYTHING GLOBAL! They have a bunch of crap declared global, and they have a bunch of crap you could crash your program with right out in the open for Joe Schmoe to change. They need some sort of organization. At least use a structure for the things that were global.
6. Speaking of global things, I think they should have the allegro library packed up in a class. Sure you lose C support, but most people who use Allegro use C++ and not C. C is dieing day-by-day. There are some people still using it, but I think it is more of a drawback, because a lot of API's take OOP out of the API just so C coders can use it.
7. It's slow and kinda bulky. Sure it uses DirectX, but I think it uses like DirectX 5 or something. Even if it is 6 or 7 or something, it's just slow. Just to make alpha blending not take you down 10 FPS you have to download a whole new plugin just for blending crap, and don't get me started on how ugly coding for FBlend is.
8. No consistency on function names. I know Allegro 5 will have al_ in front of function names, but that's years in the future, and it'll be more behind if they are going to be as lazy with that as they were with 4. I don't think they spent much time designing Allegro, they just threw it together as they went. You can tell if you look at the logs on Allegro's past. That is part of the reason some of the crap is so crappy, they just threw in what worked that moment and forgot about it.
9. Organization problems
10. Organization problems
11. Lots of glitches
12. 600K DLL file, bad for someone like me who's limited to 24K connection. And usually a full-sized Allegro game is less than that because it is mostly n00bs doing their first projects (there are some GREAT programmers using Allegro, but they have their own opinion, and I respect that). I never have finished an Allegro game, a lot of times because I have to search around for a plugin just to do something that was supposed to already be in Allegro, but really isn't.

Now don't get me wrong, I couldn't make something as large as Allegro, simply because I could care less about all those DOS drivers and all the other platforms, but I can probably make a better DirectX Wrapper than allegro is. I know it is made for Multiplatform support, but SDL is multiplatform, and I've heard has great support for DirectX (note: SDL = Simple DirectMedia Layer). I'm not saying Allegro is a bad library, they just need to clean out the s***, and fix their attitude. If you are making a library, supposively for the people, make it designed for the people, not for your sole-benefit.

People will probably ***** about this, but I have my own opinion on things, and you probably have a diff one as well.

PS: Sorry for long post

[cozman]

Look I dont like Allegro either, but a lot of your points I really disagree with, this isn't meant to antagonize you, I just think there should be some defense for something that a lot of people have put a good amount of work into, even if it isn't the best.

2. Not very flexible. Although they think it is, just because they support a bunch of obselete file formats nobody uses anymore
Allegro supports most file formats through it's extensions, last I checked so do OpenGL, SDL, DirectX and almost every other API I know of, most don't concern themselves with file formats.

Someone asked one of Allegro's dev'ers one time to change it to Hungarian Notation, or at least LikeThisToSeperateWords and he said "No, because I like this way better" The attitude with the developers is "This is OUR library meaning what we want goes in, what we don't does not. Just because everyone wants something doesn't mean we're actually going to put any effort into it". They actually said that in some form on the message boards.
These two comments combined show that you fail to recognize it is their library.. and Hungarian Notation is much worse in most people eyes, and as for the CapEveryWord versus use_underscores debate it is split as much as emacs vs. vi is. And it is their library, and the developers dont have to add stuff they dont want.. but keep in mind it is open source and you can add whatever you want to it, but they dont have to do it for you.

As far as C vs. C++ support goes.. some people will tell you that they should just rewrite allegro in C#, but they are the ones using C#, C is still very popular, and if you want an OO wrapper write your own (SDL is C, as is OpenGL, and if they weren't they'd lose a good chunk of their users)

7. It's slow and kinda bulky. Sure it uses DirectX, but I think it uses like DirectX 5 or something.
SDL Uses DirectX5 as well.. and DirectX's speed does not change much from DirectDraw 5 to 7

Just to make alpha blending not take you down 10 FPS you have to download a whole new plugin just for blending crap, and don't get me started on how ugly coding for FBlend is.
Alpha blending is slow in DirectDraw no matter what... if you need it that much you probably shouldn't be using a 2D API.

The fact that 1,9,and 10 were all the same takes validity out of your message, seeing repetative complaints shows a reader that you have less of a point.

11. Lots of glitches
And DirectX is well known to have none so it must be just the Allegro code :)


12. 600K DLL file, bad for someone like me who's limited to 24K connection.
Most people are past the point where we can really worry about 24k users.. I feel sorry for you, but a 600k DLL is not large at all, and worrying about making a 600k DLL smaller so that <1% of the users can have an easier time getting it isn't going to happen often.

[frenchfry164]

the basic allegro package has a bunch of old formats like FLC. if they took them out it would shrink size. If you really want FLC you can make it a plugin.

I can see you like the ***** attitude, that is okay with me. I just thought if you were making a library for people to use that you should at least listen to what the people want.

I didn't say it was slow because of DX5, now did I?

And you're saying I don't know allegro too well? They could cut the DLL file down very easily, they are just to lazy to do it.

Everyone is entitled to their own opinion though.

[Hunter2]

I would tend to lean towards FrenchFry's opinion, since he used to be the great Allegro-er of the forum (at least in my opinion, looking at his avatar), and at one point he was a great help in my debate for the usefulness of the Windows GDI :D Besides, I find his points convincing enough...

[fry]

Well, i thought i should post a few things here, jsut for the sake of it :)

just because they support a bunch of obselete file formats nobody uses anymore
600K DLL file, bad for someone like me who's limited to 24K connection
I found it interesting that you argued that it still uses old formats, and should rid them in order to keep up to date, and then also argue that they should be weary of 24K users for their file sizes.
So in one sense, you want the latest and greatest, while in another area, you want it cut down to suit you?

I HATE the function names. Everything is lowercased and words are seperated by underscores.
Function names are personal preference. I for one, use the same standard as Allegro anyway, but i know that everyone is different, and its hard to use another format. But you cant use this as a reason for downgrading it.

The attitude with the developers is "This is OUR library meaning what we want goes in, what we don't does not.
cozman: And it is their library, and the developers dont have to add stuff they dont want.. but keep in mind it is open source and you can add whatever you want to it, but they dont have to do it for you.
Makes sense to me. Would you want to add in a bunch of stuff that doesnt appeal to you? People can contibute their own parts though. Its just that people dont want to go out of their way for more specific stuff.

but most people who use Allegro use C++ and not C. C is dieing day-by-day
I am a c++ user. But, im pretty sure that the split of allegro users is fairly even between C and C++. As cozman said, OpenGL and SDL and compatible with C as well. Thats how things are at the moment. It isnt a specific Allegro problem.

I respect your opinions, because they are your opinions. As are mine. As long as you don't try and pass things off as fact (which aren't), then you can say what you like :)

Allegro has its fair share of problems, true. But i feel some of your arguments were slightly misleading :) cozman answered everything pretty well, so i will leave it there for now :)

[Leeman_s]

i just want to add in that i absolutely HATE allegro!

HATE HATE HATE HATE HATE!!!!!

I don't like the bad habits it teaches, and how it takes you away from how windows programs really work. I like to think of it as "fake". Allegro is more for the "average" user, if you get what I'm saying.

(geez now watch some dudes gonna flame me or something)

[Travis Dane]

Well, allegro is for the people that used to program console apps,
and got tired of the forever text crap, allegro is for those people
easy to pick up, i used to use allegro and found it very easy to
switch to from console applications, however im now a
100% win32 person because i know that if you ever want to
make a proffesion out of programming youre going to have to
learn Win32, though i still stay at my opinion

Allegro is for C++ programmers who are tired of text based
programs but dont want to go trough too much hassle for
Graphics

[TechWins]

I don't like the bad habits it teaches, and how it takes you away from how windows programs really work. I like to think of it as "fake". Allegro is more for the "average" user, if you get what I'm saying.

How is it that Allegro teaches you bad habits? Allegro introduces you to basic techniques used in game programming. Allegro makes it possible to take out a lot of unneccesary work from the programmer and allow the programmer to spend more time on the important aspects. Granted Allegro isn't the greatest API out there, but that is not Allegro's purpose nor intention of it's creators. Allegro is meant to simplify the task of creating 2d games. It is not complete library, by no means at all, which is why there are so many extra add-ons to the library. Once Allegro fully incorporates a lot of these other libraries then Allegro will become even more popular. However, even then I don't think Allegro will be meant much more than for creating 2d games that don't require a lot of intensive graphics.

1. Lack of organization and consistency

Where is the lack of organization? The documentation for Allegro is very well written along with the explanatory examples. What more do you expect from a small library that is NOT meant to compete with DirectX nor OpenGL.

2. Not very flexible. Although they think it is, just because they support a bunch of obselete file formats nobody uses anymore

How is it not very flexible? What kind of flexibility do you want? It supports all the graphics modes and file types you could possibly ever want. What sort of flexibility are you looking for?

3. I HATE the function names. Everything is lowercased and words are seperated by underscores. example: draw_sprite().

I personally like the function name layout. Like Fry, I make my own personal fucntions the sameway ( my_function() is easier to write/read than My_Function() or MyFunction() to me ). Not to mention that the names of the functions fit the description very well which simplifies things quite a bit.

5. THEY MAKE EVERYTHING GLOBAL! They have a bunch of crap declared global, and they have a bunch of crap you could crash your program with right out in the open for Joe Schmoe to change. They need some sort of organization. At least use a structure for the things that were global.

This seems to fall under your organization argument but regardless of that it still isn't correct. The global variables provided with Allegro help out a lot (i.e. SCREEN_W, SCREEN_H). What's wrong with that?

6. Speaking of global things, I think they should have the allegro library packed up in a class. Sure you lose C support, but most people who use Allegro use C++ and not C. C is dieing day-by-day. There are some people still using it, but I think it is more of a drawback, because a lot of API's take OOP out of the API just so C coders can use it.

What does it matter how the layout of Allegro is just as so it provides the same ease and efficiency? Not to mention that there are so many C coders still out there. Even though, some people may be using C++ they still may not be using OOP, just to let you know.

7. It's slow and kinda bulky. Sure it uses DirectX, but I think it uses like DirectX 5 or something. Even if it is 6 or 7 or something, it's just slow. Just to make alpha blending not take you down 10 FPS you have to download a whole new plugin just for blending crap, and don't get me started on how ugly coding for FBlend is.

As I said above, Allegro is not meant for graphicaly intense games; it is meant for simple (with little emphasis on simple) 2d games. Again, as I said above, many new features will be including in Allegro as time goes on. Allegro has not had enough time to establish itself yet, whereas, OpenGL and DirectX have been around for years.

8. No consistency on function names. . . .
9. Organization problems. . . .
10. Organization problems. . . .

Repetitive mentioning of problems on your part again...

11. Lots of glitches

Care to list any, because in my time with Allegro I haven't found many.

12. 600K DLL file, bad for someone like me who's limited to 24K connection

Hmmm...have you thought about dynamically linking the executable. Yes, the exe grows in size when you dynamically link, but the use of the grabber tool should compensate for that. Basically Allegro is the best API out there, that I know of, for making small file size programs because of the grabber tool.

People will probably ***** about this, but I have my own opinion on things, and you probably have a diff one as well.

Well, I didn't mean to "*****" about your post, but your lack of support for your reasons left me no choice. Don't buy a canoe expecting it to take you across the Atlantic, just as you wouldn't use Allegro expecting it to create flawless 3d games. Use the product as it was meant to be used. When the product doesn't fit the need it wasn't meant for don't complain.:)

Also, Allegro is very good for someone wanting to use graphics but still isn't completely comfortable with C/C++.

EDIT: Ha, my last comment was pretty much what Travis said, and I hadn't even read his comment because I was still in the midst of writing my post (I sort of took a break in between lol).

[Travis Dane]

Originally posted by frenchfry164
6. Speaking of global things, I think they should have the allegro library packed up in a class. Sure you lose C support, but most people who use Allegro use C++ and not C. C is dieing day-by-day. There are some people still using it, but I think it is more of a drawback, because a lot of API's take OOP out of the API just so C coders can use it.

Watch that 'C is obsolete' aditude, just for the reminder Quake3
was written in C, so dont go yelling that C is dieing!

[ggs]

doom 3 is written in c++ dude :cool:

[Hunter2]

doom 3 is written in c++ dude:D

The documentation for Allegro is very well written along with the explanatory examples.Sorry, but I don't think he was talking about the doc when he said "organization"...

This seems to fall under your organization argument but regardless of that it still isn't correct. The global variables provided with Allegro help out a lot (i.e. SCREEN_W, SCREEN_H). What's wrong with that?Well...they have a bunch of crap you could crash your program with right out in the open for Joe Schmoe to change.

Not to mention that there are so many C coders still out there.True. Besides, I heard that C is faster than C++...

Again, as I said above, many new features will be including in Allegro as time goes on.I don't think that was the point either... the point was that the features already there are slow, not that they're missing. Still, not a bad point.

Repetitive mentioning of problems on your part again... Maybe he just wants to stress them?


Fry:
I found it interesting that you argued that it still uses old formats, and should rid them in order to keep up to date, and then also argue that they should be weary of 24K users for their [large] file sizes.
So in one sense, you want the latest and greatest, while in another area, you want it cut down to suit you?Sorry, you've got yourself mixed up. By "ridding them", it will both "keep up to date" AND cut down the "large file sizes". Thus, it's not a contradiction.

Sorry, i actually have no personal experience with Allegro, but I felt like pointing out some logic stuff ;)

[fry]

Just to quikly mention about that last point, He said that he wanted flexibility. That could mean many things (he didnt specify), but one major one would be supporting many different formats, systems, etc. which increase the dll size. Dropping support for a number of file formats wouldn't really drop the dll file size all that much, unfortunately :(

[TechWins]

Sorry, but I don't think he was talking about the doc when he said "organization"...

Then what is he talking about? What is it about Allegro that is unorganized? What sort of organization is there supposed to be?

Well...

The quote of yours under that makes no sense at all. Shouldn't Joe Schmoe know a few things about programming and Allegro? The quote made no sense what so ever.

the point was that the features already there are slow, not that they're missing.

Well, as I said before, Allegro is not meant for graphically intensive games, but as time goes on more features will be added/improved so that better graphics can be possible.

Maybe he just wants to stress them?

Yeah, but all of us should be able to get the point the first time.:)

By "ridding them", it will both "keep up to date" AND cut down the "large file sizes".

You're wrong. The two have no corralation with each other at all. This statements shows why you are wrong...

i actually have no personal experience with Allegro

Allegro supports a lot of different file types for what you can use with your program which is a plus. The large file sizes does not have to deal with these file types. The large files size that you're thinking of is the appromixate 600kb dll file called allegro04.dll (whatever version of allegro you have). Ah, you know what I'm not going to explain it anymore, because it doesn't matter *. But you were wrong with what you said and Fry was right. Sorry.:)

* = it seems that Fry explained the file situation to you already.

[Hunter2]

Shouldn't Joe Schmoe know a few things about programming and Allegro?Yes, but things should always be designed to be as idiot-proof as possible, just in case.

Well, as I said before, Allegro is not meant for graphically intensive games, but as time goes on more features will be added/improved so that better graphics can be possible.That's why i said "still, not a bad point". Bad wording, that's all ;)

You're wrong. The two have no corralation with each other at all.Oh. :(

[Frobozz]

6. Speaking of global things, I think they should have the allegro library packed up in a class. Sure you lose C support, but most people who use Allegro use C++ and not C. C is dieing day-by-day. There are some people still using it, but I think it is more of a drawback, because a lot of API's take OOP out of the API just so C coders can use it.

Heh... dying? I don't think so.

C is faster than C++... that's why most (if not all) operating systems are being made with it. I think Linux is made with C and not C++, but I may be wrong. Windows is so buggy its a wonder they didn't make it using BASIC, but I believe it's C also.

[no-one]

if im not mistaken windows is C++ GUI built on C built on Assembly.

[fry]

Yes, but things should always be designed to be as idiot-proof as possible, just in case.

If everything is designed to be as idiot proof as possible, you just end up with something that is useless to most people, as it isnt very flexible, it is slow, and it can only do a small number of things. Think about why C/C++ is so popular.

Hint: It isn't idiot proof.

As for the last comment, i dont want to start a new argument, but C is no faster than C++. It all depends on how you program. But lets leave it there shall we :)

[Hunter2]

Ok.