Sign in to follow this  

SDL OOP

This topic is 4247 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Trying to be all Object-oriented. But for example in my Pong game that I am starting out with while learning SDL, I have a bunch of globabl variables of type SDL_Surface* which are all the images/backgrounds/fonts and such used by the program. Then in the main, I instantiate two "Paddle" objects to represent each paddle. The Paddle class has a copy constructor which initializes the x and y values of the paddle and then dislays it and such. It also has a hadle_input() function. My question is, is this a good approach for the input, or should I handle the input in a standard function outside of the class. Because if I do it this way, I don't know how to tell the function what keys to use to move the paddle. I am using SDLK_UP and SDLK_DOWN for one of the paddles, and SDLK_s and SDLK_x for the other. Is there any way to pass these values through parameters? I don't know much about enums. I tried using the integer equivalent of those, but the paddles became all jittery when moving so that doesn't work. BTW, this is my first game in SDL, really my first game, so just wondering what the standard method is, and if this is a good approach or should I just not have a Paddle class since I know there will be two paddles. Even still, can those enum values be passed through parameters?

Share this post


Link to post
Share on other sites
having global variables its not a good approach. It is common to create a class named game and put there all variables you need like screen surface, fonts, backgrounds, etc and you can put your input function there too. You should put your paddle surfaces in the paddle class and write a function to render a paddle (just pass a screen surface to it function so it can blit the paddle surface to screen function) So when you call a render function from you main loop. (this function may be in game class) the render functions of each paddles and ball are called.

Share this post


Link to post
Share on other sites
Your paddle objects should have very explicit interfaces, much like a car does. A car has functions like Start(), Shift(), Accelerate(), Brake(), and Fillerup(). A car would NOT have public functions like InjectFuelToEngine(), or IgniteSparkPlug(). Those are internal sorts of things the driver ought not to be worrying about.

Now consider a Paddle object. What does a paddle *do* that a client would care about?

MoveUp()
MoveDown()

And that's about it really. So your event handling should be in more a global area. You decode the incoming events and pass them to the appropriate object/function. Like so:

// pseudocode
Paddle p1();
Paddle p2();
while (event e) {
if (e.type == button press && e.button == SDLK_UP) {
p1.MoveUp( some_amount );
}
}

Share this post


Link to post
Share on other sites
Nice, that more than answers my question, exactly what I was looking for, leiavoia. thanks, will do that.

yeah, but it is so tempting to have global variables for like picture names which you might want to change to something else, so you don't have to look through all your code to find where it is. Also, the constats like X_MIN or X_MAX and such, I make those globals.

Share this post


Link to post
Share on other sites
Quote:
Original post by Lanky007
Also, the constats like X_MIN or X_MAX and such, I make those globals.


You could easily make those defined constants in a header file so that you can easily reuse them all over without them being runtime variables (constant or otherwise). Now, if you do ever want to change them during the game for some reason, then using a global variable may be a good way to go.

Share this post


Link to post
Share on other sites
Quote:
Original post by Lanky007
Trying to be all Object-oriented.

This may be silghtly off-topic, but there's absolutely no reason you have to be "all Object-oriented". OO just isn't the best paradigm in a lot of situations, and nothing is stopping you from using more than one paradigm. C++ or any other language does not limit you to OO, it simply provides facilities that make OO progamming easier.

Don't go out of your way to avoid globals where they're necessary. There is absolutely nothing wrong with using globals when they make your code easier to understand, especially in small projects such as this one.

Quote:
Original post by freenity
having global variables its not a good approach. It is common to create a class named game and put there all variables you need like screen surface, fonts, backgrounds, etc and you can put your input function there too.

There's no reason, right now at least, to write your entire game in a class. The only thing you'll gain is a little encapsulation, meaning members of your Game class won't be available throughout your program, but in some cases this can lead to workaround code that wouldn't be necessary if you just used a global in the first place.

Don't avoid globals when they're necessary and useful. Making your code "pure OO" isn't necessary at all and there's no poing in wasting the effort. Languages are not restricted to one paradigm and you shouldn't restrict your code to one paradigm. Use the right tool for the job.

Share this post


Link to post
Share on other sites
Trying to be all Object-oriented is sounding like a willingness to learn and I think Pong is a good starter.

Begin with a small game like Pong and put everything inside the Game class (Not Object Oriented) and when you have your game working in the non OO style you can move portions of code to other classes and fix the code to work with these new classes

Once you have done that you can get into inheritance and make Paddle and abstract base class and derive some funky paddles and then you can spice the game up with little effort.

OO may not be the best paradigm in all situations agreed, but I think that even simple games benefit by using OO because it allows you to add new features (like the pong I suggested above) which would have been very ugly to do without using OO. And in all this you learn the very essence of OOP.

Share this post


Link to post
Share on other sites

This topic is 4247 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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