Hello, everybody. I want to use Allegro for game programming for a while and grow comfortable with it. However, I understand that it hides a lot of work for me. I'm working on a Mac and am wondering where I should go resource-wise to learn the details and whatnot behind what's actually making Allegro work... nitty-gritty game programming, if you will. Reason I desire this is to grasp knowledge of what lies beneath when it comes to the programming so I can have a better understanding of the whole picture. Advice or info in the right direction would be much appreciated. Thank you very much :] Colton

Quote:Original post by Noegddgeon
Hello, everybody.

I want to use Allegro for game programming for a while and grow comfortable with it. However, I understand that it hides a lot of work for me. I'm working on a Mac and am wondering where I should go resource-wise to learn the details and whatnot behind what's actually making Allegro work... nitty-gritty game programming, if you will. Reason I desire this is to grasp knowledge of what lies beneath when it comes to the programming so I can have a better understanding of the whole picture.

Advice or info in the right direction would be much appreciated. Thank you very much :]

Colton

I haven't used Allegro, but from what I know of it I'd say that it's pretty low-level already.

Just to be clear, I don't intend to discourage you in any way from learning low-level game programming techniques. That said, I think it's probably worth asking *why* you think this is an important thing to do. Obviously those are valuable skills, but I just want to point out that if your interest is primarily in making games (rather than in writing low-level engine code for its own sake), it's very possible to create all kinds of games without digging down to the system level as you seem to want to do.

I guess what I'm trying to get at is that there's plenty of 'nitty-gritty' to game programming even when using a library like Allegro or SDL to do the real low-level stuff. Also, in most cases you kind of have to draw the line somewhere anyway. Even if you go lower-level than Allegro, you'll still be using libraries and APIs that take care of low-level details for you - they'll just be different libraries and APIs.

Anyway, as for your question, I think a fairly obvious place to start would be the Allegro source code (and/or the source code to other cross-platform frameworks such as SDL or SFML).

Source code for cross-platform frameworks of this type can get pretty involved, so it may not always be immediately apparent where to look. For Mac-specific info, you might check out idevgames.com. Information on low-level programming in Windows is pretty easy to come by - there are plenty of tutorials that'll show you how to set up a window and a basic message loop, etc. Not sure about Linux.

If there are specific things you're wondering about, maybe you could tell us what they are - that might make it a little easier to direct you towards appropriate resources.

jyk,

Thank you for your reply. :]

I was thinking about looking through the source code, and I have in the past but most of it didn't make a whole ton of sense (probably because I'm not as experienced with C++ as I need to be to comprehend it all). The reason I'd like to understand so much is that's the kind of person I am... I like to know the details and backbone behind everything I do and engage in, as it helps me to understand what I'm doing in the now. I may not really need it or get into studying it fully to the point where I know every detail behind Allegro's implementation (as well as what could be expected of existing in other library implementations), but knowledge in that sense is something I'll most likely always desire.

Thank you for your help, and I'll probably end up taking a good look through the source in an attempt to understand it once I am a better programmer. :] I can't provide you with any specific details I wish to know, but if I do realize any, I'll be sure to post them in a question on this forum sometime, where everyone is always helpful and understanding.

Colton

Heh abstraction is a blessing! Like "nobodynews" says, there are so many levels of abstraction already that your next question may as well end up being where do you stop.

The biggest problem with going low level is that you'll end up spending a large portion of your time learning platform dependent code. On top of this, you have to worry about all the different hardware configurations and provide a fall back for each of them.

Back in the old DOS days it was a pain testing to make sure your game worked on different computers (and I finding Allegro later and compiling it with DJGPP - aah that's when my life became more productive!).

Edit:
If you really want to proceed, one method is obviously as "nobodynews" says, look at the basic source code and see all the levels of abstraction.

Another method that you can use (depending on how you've compiled your game) is to step through using a debugger and debug symbols. That way you can see, line by line, exactly how or what gets called.

Finally if you really want to go low level, you can use the above method to look at the assembly code that is being generated and see how the individual CPU instructions are passed around (unfortunately not everything can be revealed due to certain restrictions in memory).

How come you are using allegro?

If you learned OpenGL it would probably take just about as long and after you learned it, you'd have a marketable skillset.

Nobody uses allegros to make games (that i've ever heard of) it's a learning library (like training wheels) but learning it is almost as difficult as just learning how to REALLY do things yourself so might as well just jump into OpenGL.

My 2 cents!

"nobodynews": I probably would want to end up writing my own OS, just for the experience. hahaha.... I want to learn as much as I can about everything related to programming. That'd be a big undertaking, though. And buggy as hell, surely.

"tariqwalji": I may end up looking at the Assembly and source code a bit to try and understand everything. At this point, I'm just trying to learn how to program games, but I do want to learn as much as I can about everything, even the underlying mechanics of the simplest things, and thus that's why I started this thread. :p ha

"Atrix256": Is it possible to do the same things with OpenGL as you can with Allegro, in the vein of 2D games? I intend to learn OpenGL anyway to develop 3D games, so if it's just as good with 2D games (I intend to learn Atari quality, then NES, then SNES, then Arcade, then N64, etc. etc.), I might as well learn it now and get good at it without learning Allegro because Allegro would have essentially just been a slight waste of time (minus the experience I would have gotten learning how to game program).

Thanks, all you guys, for your input!

Colton

Yep you can do 2d in OpenGL (and DirectX and basically all other 3d APIs)!

How do you think 3d games have 2d UI on top of 3d rendered screens?

To do "2d" in OpenGL, check out "orthographic projection".

Normal 3d rendering makes it so when things are farther away they get smaller.

Orthographic projection makes it so when things are farther away they stay the same size.

Using orthographic projection, you just draw rectangles that face the camera and on those rectangles you put a picture of a tree, or a bush etc and then you have your 2d game.

It sounds alot more difficult than it really is.

Here's a link to get you started:

http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=21

Thanks for the link, Atrix.... I actually plan on going through all of NeHe's OpenGL tutorials soon. However, I'm still working on my C++ and trying to get familiar with all of its object-oriented features and used to using classes and whatnot instead of procedural code for game logic. That way, I can do a lot more with a lot less.

I'm also working on using SDL right now instead of Allegro. I'm feeling it will work better for me. It seems to have more resources available tutorial-wise online. I think I might even learn it with OpenGL concurrently so that I can use the two together and then switch over to just OpenGL at some point, unless I need to use SDL for game coding purposes.

Thanks again and I appreciate the guidance. :]

Colton