I'm relatively new to game programming (although well versed in programming). My experience thus far extends only to Allegro and DirectX (DDraw, more specifically). In looking at DirectX, I see that gaming libraries take care of most of the startup, management, and cleanup of the necessary infrastructure to run games as well as providing a simple interface. My question then is what are the advantages of programming in DirectX/OpenGL as opposed to alternate libraries? There definitely are advantages; otherwise everyone would be using solely the alternate libraries. What are the disadvantages? More importantly though, who would benefit most by learning DirectX/OpenGL (graphics programmers are one, I would guess). My purpose is not to determine which one is best, but what each one is more appropriate for (especially since my goal is to study AI in games more so than the entire field). Any comments appreciated.

Quote:

Original post by TheWanderer My question then is what are the advantages of programming in DirectX/OpenGL as opposed to alternate libraries? There definitely are advantages; otherwise everyone would be using solely the alternate libraries. What are the disadvantages?

Advantages to DX/OpenGL:
-Speed for one. If your graphics card does all the rendering, then your CPU can do all your game logic. Using Hardware Acceleration is especially important since you mentioned you want to go into AI. If your CPU is wasting loads of time with the graphics, it won't have much time to spend on the AI.
-DX can also easily take care of Graphics, Networking, Input, and Music all in one library.

Disadvantages:
-Complexity. Some new programmers might be intimidated by the powerful libraries, but from my own experience using OpenGL, things have been rather easy to set up. They are, however, not as easy as setting up SDL or Allegro, but I would say much more easier than DirectDraw.

Quote:

More importantly though, who would benefit most by learning DirectX/OpenGL (graphics programmers are one, I would guess).

Graphics Programmers would go in-depth learning the API, but I would think that all programmers would have some knowledge of at least one of the APIs. If you want to make a Physics or AI demo, it would help if you had a visual representation to go along with it.

Depends exactly which library you mean.

If you use software rendering with Allegro or SDL_gfx, performance is likely* to be worse than if you used hardware rendering with Direct3d or OpenGL.

If you just use the library to do input handling and setup code, its overhead will probably be negligible.

Likewise with sound libraries, if you spend the majority of your time rendering, the audio processing performance doesn't matter too much.

* Hardware rendering is not *necessarily* faster than software. Just mostly.

Mark

Quote:

Original post by markr If you just use the library to do input handling and setup code, its overhead will probably be negligible.

It'll probably be comparable with YOUR own input handling and setup code... assuming you write that code with the same care as the library writers.

The thing that really caught me by surprise when I was studying DDraw was the lack of primitive drawing functions. Now, iirc, Allegro is built to use DX if it is available (OpenGL can be used alonside it). It made me wonder whether I wanted to spend the time creating my own graphics library (something that I will do anyways, just for the learning experience) and optimizing it(something which I might NOT do). Surely the guys (or gals :D) who developed the libraries can do a much better job than I.

Quote:

...but I would think that all programmers would have some knowledge of at least one of the APIs.

More than agreed. I would go even further and say that if one wanted a good shot at getting into the game industry one should know both.

Allegro uses the older DirectDraw interface. This is intended to speed up predominantly software rendering applications by providing them with low level video access.

It's largely incompatible with Direct3d, insofar as, I believe you can't very easily use them both at the same time (nor would you likely want to).

Until Allegro is rewritten to use Direct3d (if that ever happens), you won't get better performance of its primitive operations on win32 than you have already.

If you want to utilise hardware rendering on PC hardware, (which can be used for 2d work too), you will HAVE to hit either Direct3d or OpenGL. If you use Allegro or SDL in conjunction with them, that's fine, but you will still have to use the hardware rendering routines.

That's not to say that fairly fun games can't be made with software rendering - they can. It's usually easier to code for.

Mark

Probably the creators of Direct3D/OpenGL have access to almost all brands of hardware, because of their history and name. These graphics API's get the newest technologies. Does Allegro have easy GPU programming interfaces?

Quote:

Original post by Pipo DeClown Probably the creators of Direct3D/OpenGL have access to almost all brands of hardware, because of their history and name. These graphics API's get the newest technologies. Does Allegro have easy GPU programming interfaces?

I think there's some misconception there. OGL is controlled and reviewed by a board of developers (ATI, NVIDIA, ...) who decide what goes into the API and what doesn't. Hardware manufacturers are then free to implement the features of the API - not vice-versa! OGL allows for custom additions through its extension mechanism, but these extensions are not part of the official API specs.
It is similar with Direct3D (though there's only one manufacturer who controls the API).ATI and NVIDIA decide which part of D3D they implement in hardware and which parts are emulated by the driver - never the other way round (with the exception of things like supported file and data formats perhaps).

Therefore Allegro can just rely on the presence and specs of any of the two APIs and use that for the implementation of its layer of abstraction. No need for low level access (that BTW not even these APIs have - it's totally transparent to the system which parts are actually performed by the hardware and which parts are emulated by the driver).

Quote:

Original post by darookie Therefore Allegro can just rely on the presence and specs of any of the two APIs and use that for the implementation of its layer of abstraction. No need for low level access (that BTW not even these APIs have - it's totally transparent to the system which parts are actually performed by the hardware and which parts are emulated by the driver).

If I understood you correctly, Allegro can use either API to inteface with the graphical environment, thus allowing programmers to use either API through its interface. This brings me back to my original question of what is the advantage of directly using the unerlying API's (as opposed to the "wrapper" libraries) is. (Granted, some of the capabilities of the API might not be implemented in the library)

One advantage I see is that you can adjust the higher level interface to the underlying API to your needs and general style (e.g. using a procedural wrapper for D3D or writing an OO interface for OGL).