Elysian Shadows

Well I was thinking a couple of days ago if a made a class that calls SDL_Init() and SDL_Quit() automatically... Is this a good idea? Or just a waste of code and plain lazy??

Here it is:

SDLAutoInit.h SDLAutoInit.cpp

A single class to initialize SDL? I don't understand why you would do that.
It's just a few lines to set up SDL. It's like adding a class that only adds two numbers together.

Sorry if I have misunderstood something. I just woke up.

I was just wondering if it was a good idea to or not to, doesn't the destructor get called once an object goes out of scope? So if I forgot to call SDL_Quit() at the end of my program it would do it automatically? Also, I was wondering if your program crashes does it just crash and die or does destructors get called then it crashes and dies?

This class would be better if you rename it, to say, something like InitShutdownManager. Then you could put more than just SDL init / shutdown in it. If one day you decide to throw away SDL and put something else in, you can just put into your class the new code for init / shutdown for DirectX, OpenGL, Ogre, OpenAL, networking .. whatever.

About crashing - I guess, it does not matter, if you have or have not your destructors set up. If your app crashes with some memory corruption, then there is almost no chance to shutdown SDL and everything else correctly.

But be careful, where you create the variable for your InitShutdownWhatever class - do not create it outside of main or in some DLL because there is no strict guarantee in what order your global variables will get initialized. This is one of the reasons, why it is NOT recommended to do some critical stuff (like initializing) in constructors - you cannot fail gracefully if constructor cannot init for some reason, because constructor itself cannot return any value.

The author of "Game coding complete" also recommends to use dedicated Init() method for various game systems. Init() returns some useful code so you can detect early if initializing went wrong, and you can show some meaningful message to the user. Solving initializing failures in constructors would be messy, you then need to add some flags to the Initializer class to find out, if constructor did (not) fail.

Shorter advice: refactor your class into some general purpose InitShutdownManager, create methods Init(), Shutdown(), which return some success/failure codes, and you are good to go!

midix wrote:This class would be better if you rename it, to say, something like InitShutdownManager. Then you could put more than just SDL init / shutdown in it. If one day you decide to throw away SDL and put something else in, you can just put into your class the new code for init / shutdown for DirectX, OpenGL, Ogre, OpenAL, networking .. whatever.

About crashing - I guess, it does not matter, if you have or have not your destructors set up. If your app crashes with some memory corruption, then there is almost no chance to shutdown SDL and everything else correctly.

But be careful, where you create the variable for your InitShutdownWhatever class - do not create it outside of main or in some DLL because there is no strict guarantee in what order your global variables will get initialized. This is one of the reasons, why it is NOT recommended to do some critical stuff (like initializing) in constructors - you cannot fail gracefully if constructor cannot init for some reason, because constructor itself cannot return any value.

The author of "Game coding complete" also recommends to use dedicated Init() method for various game systems. Init() returns some useful code so you can detect early if initializing went wrong, and you can show some meaningful message to the user. Solving initializing failures in constructors would be messy, you then need to add some flags to the Initializer class to find out, if constructor did (not) fail.

Shorter advice: refactor your class into some general purpose InitShutdownManager, create methods Init(), Shutdown(), which return some success/failure codes, and you are good to go!

Thank you very much!!!! )) and I should really stop playing games and work on coding hahaha :P. But once again, thanks for the reply, helped a lot

Like he said, make a class out of it that does some other useful stuff. otherwise dont bother.

I would rather have a class for the window itself, where you have your buffer, screen with/height variables, and such things. There you could have your SDL_Quit() function as well, in the destructor.
like:

window.h window.cpp

superLED wrote:I would rather have a class for the window itself, where you have your buffer, screen with/height variables, and such things. There you could have your SDL_Quit() function as well, in the destructor.
like:

Code: Select all

//window.h
class Window {
public:
	Window(string mName, int mWidth, int mHeight, int mBpp);
	~Window();

	int getWidth();
	int getHeight();

	SDL_Surface *getBuffer();

private:
	int width, height, bpp;
	SDL_Surface *buffer;
};

// window.cpp
#include <string>
using namespace std;

#include "window.h"

Window::Window(string mName, int mWidth, int mHeight, int mBpp) {
	width = mWidth;
	height = mHeight;
	bpp = mBpp;

	SDL_Init(SDL_INIT_EVERYTHING);
	buffer = SDL_SetVideoMode(width, height, bpp, SDL_HWSURFACE | SDL_DOUBLEBUF);
	SDL_WM_SetCaption(mName.c_str(), NULL);
}

Window::~Window() {
	SDL_Quit();
}

int Window::getWidth() {
	return width;
}

int Window::getHeight() {
	return height;
}

SDL_Surface *Window::getBuffer() {
	return buffer;
}

That is actually what I had done before, then I thought to myself that I would like both Software Rendering and OpenGL Rendering, which I have just about done, but I have not implemented the OpenGL Rendering for a window. What I basically did was: Make a BaseWindow class that has basic window properties, like height, width, BPP etc. And then I made two separate classes one called SWRWindow and OGLRWindow and both inherited from BaseWindow. And then I think I made a global pointer to BaseWindow in a namespace, in a separate file. Oh and I forgot to mention BaseWindow has virtual functions like Render, Create and stuff like that, Polymorphism ftw? IDK if that's a good way to do things, but it seems to be working and I kinda like the flow of it tbh.

Oh and btw I think SDL has a function to get the current video surface. Called SDL_GetVideoSurface(); I'm pretty sure. Oh and btw, why not use the initializer list? Or were you just rushing things S:?

Pornomag wrote:Oh and btw I think SDL has a function to get the current video surface. Called SDL_GetVideoSurface(); I'm pretty sure. Oh and btw, why not use the initializer list? Or were you just rushing things S:?

Yeah, I kinda rushed it :p

I don't have much experience with OpenGL or other graphical libraries, so my method may not me efficient for your needs.

superLED wrote:

Pornomag wrote:Oh and btw I think SDL has a function to get the current video surface. Called SDL_GetVideoSurface(); I'm pretty sure. Oh and btw, why not use the initializer list? Or were you just rushing things S:?

Yeah, I kinda rushed it :p

I don't have much experience with OpenGL or other graphical libraries, so my method may not me efficient for your needs.

Neither do I, but I know for a fact that I will be need OpenGL in the future.