Yes, BP, a thought: Make sure you pay attention to your chapter on classes. Some of it is not as easy to truly "grok" as it is to go "mmhmm, mmhmm *flips page*". For instance, it took me the longest time to grasp the concept of polymorphism and I still have trouble using it sometimes.
That said, I'm learning SDL and game programming in general as well and I'll give you "advice" (Can it really be called advice if I've developed it for my own use, yet it remains untested? I guess I'll just say I Think This Stuff Is A Good Idea Based On Intuition Formed By Years Of Non-Game Programming And What I've Read About Game Programming, Combined.)
One of the things you'd want to do is build a very light, very simple "game engine". Do this for a simple project so you don't have to do it fifteen times while you're writing a serious game.
If you're planning on doing any networking between games, extend one of your demos (How about the car one?) to use networking. Do something like developing an interface class, separate from the Car class (which each Car owns at least one of), to send commands to the car ("Driver"), and writing three base child
[oops] classes, "HumanDriver", "CPUDriver"; "NetworkDriver"). I'm thinking of doing something like that myself, very soon.
Also, ensure that you remember to regulate your game's timing
separately from the framerate. Due to the ever-changing state of your game, you don't want to draw the screen for every single movement-- the frame rate requirement would then approach infinity and your (and more importantly, your
user's) graphics card's ability is... not infinity. Also, you don't want your framerate dictating the speed of your program-- not only will the speed jump back and forth as CPU frequency scaling, other applications, etc. change the amount of cycles your program has available, but the game will also run faster on one machine than it does on another. Use clock ticks to regulate speed, not "loop iterations per second".
There are more, but I'm sure you've got enough to start with, and I'm sure there are more informed people that would be of much more help than myself.
Oh, and be prepared to run into disappointments;
be prepared, as a rule,
in general! For instance, I am writing a game right now that is
just a simple board game, yet it's taken me a couple of months past my self-imposed deadline. Why?
- It turns out SDL is entirely retarded (according to what I thought it could do; I use the term in jest... but I truly thought it when I was having all these issues!).It cannot rotate an image. At least, not fast enough to render it real-time. I ended up using a combination of trigonometry and no less than 15 pre-rendered images to "simulate" rotation, and it is not a project-portable solution (I can't just re-use the function; it was built specifically for this game).
- It has no idea how to flip an image either. You have to do this yourself, by individually manipulating the pixels.
- There's no concept of "moving" an image around; you actually change where you "blit" it onto the background, and repeat the entire process whenever you want to draw a frame. This seems like common sense now, but it really puzzled me a couple months ago.
- SDL can render images. SDL can respond to clicks. But SDL cannot automagically create a button and assign some action to it (Can anyone more advanced tell I'd worked with a GUI framework like WxWidgets after this one?). You have to do this yourself by keeping track of where the button is and checking to see if any given click event happened in that range.
- Pretty much: SDL will not hand-hold; SDL will not sugar-coat. SDL is pretty much raw interaction with the basic ideas of drawing frames and handling events, and that's it.
[*]Computers are a
lot slower than we think they are. Millions of instructions per second does not mean millions of
lines per second. Things like blitting frames and manipulating pixels have at least O(n) complexity which doesn't sound bad but it certainly slows things down when you are drawing/manipulating 800X480 = 384 000 = .38 million.[*]I just didn't have a solid
plan. I thought I could just jump in... and I'm kinda glad I did, because I'm learning from it. Still, before I start another project, ever, I will put in substantially more planning time-- no code, no drawing, no composing music or sound effects...
just planning until planning is done.