Forums Archived

The forums are being archived. See this topic for more information.

Is there a benefit to passing in a Screen?

Get help and support with Rubygame

Is there a benefit to passing in a Screen?

Postby cgmjr » Mon Feb 01, 2010 5:44 pm

I'm noodling on good assignment of responsibilities. Is there an advantage to creating an instance of Rubygame::Screen in a "main" script and passing that to your game's instances? Or is it a better design to keep the "main" script ignorant of any details like the screen.

I pause because of this line in the docs:

Code: Select all
Please note that only one Screen can exist at a time, per application; this is a limitation of SDL.


Does that imply that an instance of Screen must be global to all instances that act upon it?

I've run a little test when my "game" classes deal with their Screen on their own, and my "main" script simply calls them in succession. Worked fine. My instincts say that is the right way, but I'd like to hear some other opinions.

Hmm...
User avatar
cgmjr
 
Posts: 39
Joined: Mon Jan 11, 2010 6:41 am

Re: Is there a benefit to passing in a Screen?

Postby jacius » Mon Feb 01, 2010 8:50 pm

There are several ways you could approach this, it's up to you.

That note in the documentation was meant to explain that you can't have two separate Rubygame windows open in the same application. So, calling Screen.new a second time will actually change the first window, which might confuse people.

But, it's perfectly safe to have multiple references to the Screen. In fact, you can even use Screen.get_surface to return a fresh reference to the existing Screen. If you wanted, you could use that instead of passing the Screen around. E.g. you could do "@image.blit( Rubygame::Screen.get_surface, @rect )" in your sprite classes. That's valid (but not necessarily the wisest program design).

My own style these days is to create a Game class which holds a screen, clock, event queue, and other "central" things like that, and also defines methods for the basic game loop and event processing. It also has access to all the sprites in the game (either directly, or through a sprite group, or whatever). Then as part of the game loop, the Game class passes its screen to each of the sprites's draw methods.
User avatar
jacius
Site Admin
 
Posts: 131
Joined: Fri Feb 06, 2009 11:13 pm


Return to Help & Support

Who is online

Users browsing this forum: Bing [Bot] and 1 guest

cron