Sign in to follow this  
Noegddgeon

Lower than Allegro

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
The platform specific code for allegro is broken up by subdirectory in the src\ folder. So for MacOSx you would look in the src\macosx\ and the lowest level code will be in those files. For example, this little file is the one that does just about all graphics processing. Just 10 functions. Most of the functions are just for loading and unloading of BITMAPS and some sort of video file. The one that copies the images from A to B is osx_qz_blit_to_self.

From what I can tell all of the MaxOSX functions used in this file are: LockPortBits, QDDone, CopyBits, GetPortBitMapForCopyBits, UnlockPortBits, DisposeGWorld, NewGWorld, GetPixBaseAddr, and GetPortPixMap. Everything graphical done in Allegro 4.4 on MacOSX is done using those functions, more or less.

Lower level than that and you'll need to write your own graphics driver.

Lower level than that and you'll need to write your own OS.

Lower level than that and you'll need to build your own CPU/GPU.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
"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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by nobodynews
The platform specific code for allegro is broken up by subdirectory in the src\ folder. So for MacOSx you would look in the src\macosx\ and the lowest level code will be in those files. For example, this little file is the one that does just about all graphics processing. Just 10 functions. Most of the functions are just for loading and unloading of BITMAPS and some sort of video file. The one that copies the images from A to B is osx_qz_blit_to_self.

From what I can tell all of the MaxOSX functions used in this file are: LockPortBits, QDDone, CopyBits, GetPortBitMapForCopyBits, UnlockPortBits, DisposeGWorld, NewGWorld, GetPixBaseAddr, and GetPortPixMap. Everything graphical done in Allegro 4.4 on MacOSX is done using those functions, more or less.
Be aware that this is a very bad way to learn the basics of Mac game programming!

This version of Allegro is implemented against the Carbon framework, which is deprecated, and not available for 64-bit programs.

Share this post


Link to post
Share on other sites
After some research, I think I've decided I want to learn to use SDL and OpenGL instead, so I'm not sure whether I'll be diving into the Allegro source or not. Also, I'm not entirely intending to pursue solely Mac game programming, but rather game programming in general. I probably should have clarified this from the beginning, haha. Anything I learn is knowledge of a higher amount than I have right now, though, so I guess it doesn't matter as long as I learn something. Thank you for your responses.

Colton

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this