I figure it is about time I get to talking about some of my plans and goals for learning SDL in C++. If you have been reading and keeping up with what I do (which I don't know why you would bother), you'll know I've been going through Lazy Foo's SDL and Game Programming tutorial series.
I'm not too far deep into the series, I think I'm still on Timing, but like any eager scholar it is natural for me to daydream about a cool little game that I would have made myself in the hardcore and professional C++.
Throughout my journey across the SDL Sea ( Get that pun? C ) I've seen some people happier with SFML-- which I kind of know absolutely nothing about.
Obviously I would like to learn about it and give it a try, but I really ought to limit myself to learning one thing at a time. SDL keeps me busy enough and I still want to get the hang of that library before I just suddenly jump to something new.
I really don't exactly know the pros and cons to both SDL and SFML, though. I'll just have to save that all for later.
When I have completed the series and have found method and style of working with SDL and game programming, I'd really like to build a simple platformer. Obviously the goal is to get me away from Game Maker and Pygame.
But I'm picturing like a real classic, dull, bland, black and white platformer that focuses more on gameplay and mechanics than it does graphics. I want it to be fast paced and aggressive, with an active protagonist. I guess I don't know, for sure, I just like thinking of what can make with SDL and how I can make it in code. Even the thought of game programming is fun.
Don't forget I am still a novice in this subject, so never take my word for anything, but realize I still enjoy pondering "game development theory" and how I can make things easier in code. So I thought about collision detection for a little bit.
Now at where I am in my life I am under the impression collision detection is really just testing pixels and seeing if multiple entities share a coordinate. If this is true, we know there is a collision.
But what if we want more information than that?
The player ( or any other object for that matter ) usually has different actions performed upon collision with different objects. That just plain old makes sense, right? We will want to be able to see what the 'other' instance is that our object has collided with.
Immediately I think about a list, vector, or array that holds all the objects that are actually drawn and visible on the screen. From there, we can loop through it and check their coordinates. If their coordinates happen to match up with the point where we found a collision- we've found the 'other' object. This could potentially let us throw a specific function exclusive to that instance type, which would really kind of make programming a lot easier depending on the logical structure of your code and design. Making things work well in an understandable manner can be difficult when you have a complex object-oriented design, so we will work to prevent that.
Let everything be known.
Remember these are still all just ideas and thoughts that come to my mind when I am working in that environment. A lot of this could very well be flawed. Any things is worthy of consideration, though.