Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


OOP Theory


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Dante12129   Members   -  Reputation: 1172

Like
0Likes
Like

Posted 06 April 2013 - 07:22 PM

I am creating a simple framework in C++ to help me use RAII with SDL and make some functions easier.

 

  I am wondering about some classes and the Single Responsibility Principle, however. I have a screen class that basically encapsulates and SDL_Surface for the screen, but I'm wondering whether to have a function to access this pointer and then have a renderer class apply an image to that or have a function to put an image on the screen and have the renderer class use that. I'm also wondering whether the user should call an update function in the renderer class that calls an update function in the screen class, or just have the user call the screen's update function.



Sponsor:

#2 EWClay   Members   -  Reputation: 659

Like
0Likes
Like

Posted 07 April 2013 - 12:51 AM

In terms of the basic rendering, I would just have a function to set the screen as a render target, and then functions to render to the current screen. There isn't much reason to link these things together.

What do you mean by updating the screen? It's a good idea to have a framework that allows you to plug different sections of the game such as menu screens into the main update/render loop. In this case the call to update would be coming from the application, not the user code.

#3 Dante12129   Members   -  Reputation: 1172

Like
0Likes
Like

Posted 07 April 2013 - 01:49 PM

What I mean by screen is the window that SDL creates, so updating it is basically calling SDL_Flip on it. I'm thinking of having a gamestate abstract base class upon which to build the different things such as the menu screen and actual gameplay and have the renderer render the parts associated with each state.

#4 EWClay   Members   -  Reputation: 659

Like
0Likes
Like

Posted 08 April 2013 - 02:43 AM

Then in terms of OOP theory, the design pattern you want is this:

http://en.wikipedia.org/wiki/Template_method_pattern

SDL_Flip is needed for every game, so factor it out and don't have the (derived) game state class even be aware of it.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS