Dilemma with SDL screen surface

[hurstshifter]

Hey Everyone,

So lately I've been running into a design problem that I can't seem to figure out a solution for. In all the games I create with SDL/C++ I'm never able determine the best way to implement my 'screen' into the code so that it makes for a well-organized and easily accessible setup. In my very first game I had a set of header and source files called 'globals' and ended up instantiating an SDL_Surface* screen within that and including it in every source file that needed it. UGLY!!! My solution the 2nd was to instantiate the screen within the main() and simply pass a reference to it into any function that needed to draw to the buffer. At first this was ok because I had like one or two functions calling all the drawing, but over time I kept needing more and more access to the screen until eventually I had a shitload of screen arguments getting tossed around like a salad. Once again, UGGGGLLYY!!!!

So here I am...stuck. I was hoping someone might be able to point me in the general direction of what might be a better (not necessarily the best) design pattern to follow here. I remember a couple months ago there was a thread about creating the screen as a singleton but that seemed to get shot down as another bad design. Thanks in advance for any help.

-hurst

[GroundUpEngine]

This is how I do my thang

Code: Select all

class Window {
	SDL_Surface* MainWindow; // for SDL
}
class Video {
	SDL_Surface* screen;

	void registerRenderer(WindowManager* wind) {
	    // "register" renderer
	    screen = wind;
	    ...
	}
}

Code: Select all

class Game {
	Video* subsystem1;
	Window* renderer;
	
	void Initialize(...) {
		renderer->Initialize(...); // init window
		subsystem1->registerRenderer(renderer); // register window
		subsystem1->Initialize(); // init graphics
		...
	}
	void DrawPlaya(Sprite& sprite) { // remember this?
		subsystem1->DrawSprite(sprite);
	}
}

[lotios611]

You don't even need to have an SDL_Surface for the screen. All you have to do is when you initialize the screen, do "SDL_SetVideoMode(args);" then when you want access to the screen, you do "SDL_GetVideoSurface();"

[dandymcgee]

You don't even need to have an SDL_Surface for the screen. All you have to do is when you initialize the screen, do "SDL_SetVideoMode(args);" then when you want access to the screen, you do "SDL_GetVideoSurface();"

It's much more efficient the store a pointer to the screen surface than to query SDL for it every single time you want to render something...

[Ginto8]

You don't even need to have an SDL_Surface for the screen. All you have to do is when you initialize the screen, do "SDL_SetVideoMode(args);" then when you want access to the screen, you do "SDL_GetVideoSurface();"

It's much more efficient the store a pointer to the screen surface than to query SDL for it every single time you want to render something...

Well, even though global vars are bad, you could store the screen surface as a global var in a single source file. This source file will have all the necessary functions to render to said screen surface, without giving direct access. It's sorta like a singleton... but not quite.

[dandymcgee]

You don't even need to have an SDL_Surface for the screen. All you have to do is when you initialize the screen, do "SDL_SetVideoMode(args);" then when you want access to the screen, you do "SDL_GetVideoSurface();"

It's much more efficient the store a pointer to the screen surface than to query SDL for it every single time you want to render something...

Well, even though global vars are bad, you could store the screen surface as a global var in a single source file. This source file will have all the necessary functions to render to said screen surface, without giving direct access. It's sorta like a singleton... but not quite.

I've tossed it into my singleton 'Renderer' class in the past.

[XianForce]

I I just have a renderer named VideoSystem, and the Window is stored in that. I never have need to access the window directly, because everything is rendered through the VideoSystem, and any events that affect it are passed straight to the window by my InputSystem...

[hurstshifter]

Lots of good stuff here guys. Thanks for the helpful comments.