SDL: Global screen surface?
Hopefully this hasn't been asked too many times before.. I made a few searches but I couldn't find what I was looking for. Now, we're making a game and we're planning on dividing up everything so that we have separate .cpp and .h files for every aspect of the game. The problem is that we want a global screen surface that can be accessed from any function in any file without having to make a pointer in every single function that points to the surface. Is this possible? God I hope so... Edit: sorry if I'm not using the correct terms for everything but I hope you understand.
Yeah. The screen surface is probably a decent variable to make global.
stick
SDL_Surface *screen; in some .cpp file and
extern SDL_Surface *screen; in some .h file, and go.
stick
SDL_Surface *screen; in some .cpp file and
extern SDL_Surface *screen; in some .h file, and go.
SDL_GetVideoSurface() returns the current display surface, at least this will save you from having a global screen surface.
Hey, yeah! That DID work. [wow]
I'm not sure exactly what extern does because I'm still learning c++ but I'm sure I will understand it later. [lol]
I'm not sure exactly what extern does because I'm still learning c++ but I'm sure I will understand it later. [lol]
Quote:What's so bad about having it global?
Original post by Spudder
SDL_GetVideoSurface() returns the current display surface, at least this will save you from having a global screen surface.
Quote:
Original post by Broccoli
Hey, yeah! That DID work. [wow]
I'm not sure exactly what extern does because I'm still learning c++ but I'm sure I will understand it later. [lol]
Compilers will compile one .cpp file at a time. Extern tells the compiler: "I know you may not see (insert variable externed), but you'll find it when you link everything together".
Quote:
Original post by Broccoli Quote:
Original post by Spudder
SDL_GetVideoSurface() returns the current display surface, at least this will save you from having a global screen surface.
What's so bad about having it global?
Overuse of the extern keyword can lead to spaghetti code. Why, because most of the time people expect that a variable will be declared in the source file it is found in - in real large projects you may not know where you originally declared a variable that you have externed in a file.
Just another tip - when you use extern, make sure your variable names don't collide - for it will cause many headaches trying to figure out why the code doesn't work. What is recommended in most advanced game programming books is to put global data in one static structure.
In your main header file you would have something like:
struct GlobalData
{
static SDL_Surface* screen; // Our static variable
};
In your main .cpp file you'd have:
SDL_Surface* GlobalData::screen; // Defines our static variable of the class
Whenever you need to access the screen now, you use a syntax of:
GlobalData::screen // We want to access the variable of this class
This may seem weird and impratical at first, but after time you'll discover of some neat stuff you can do with it ;). Goodluck.
In your main header file you would have something like:
struct GlobalData
{
static SDL_Surface* screen; // Our static variable
};
In your main .cpp file you'd have:
SDL_Surface* GlobalData::screen; // Defines our static variable of the class
Whenever you need to access the screen now, you use a syntax of:
GlobalData::screen // We want to access the variable of this class
This may seem weird and impratical at first, but after time you'll discover of some neat stuff you can do with it ;). Goodluck.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement