Sign in to follow this  
phil67rpg

splash screen

Recommended Posts

Dragonsoulj    3212

It should be OK but, if I'm not wrong you need virtual keyword before void's :-)

 

You only need virtual if you plan on overwriting the function in child classes. "void" works if you are not returning anything from a function.

 

 

how do I actually implement this code, I have 14 pages of code, where should I start

.

 

I am assuming you already have some game code? Perhaps a running game? Since you want to run the splash before opening any real window (assuming you are using a windowed design), you could just create a splash screen window that does not have any windowed effects (ie title bar, minimize button, close button) to show your splash screen, and while that is displayed, load your resources. When your resources are loaded, call the rest of your already established code, for instance your game window that does have a title bar and a close button.

 

With the structure you posted*, just put the splash screen code in your init() function, at the start, show a splash image, then start loading resources and data. When it finishes, start the game code.

 

* - edited

Edited by Dragonsoulj

Share this post


Link to post
Share on other sites
Dragonsoulj    3212

 

It should be OK but, if I'm not wrong you need virtual keyword before void's :-)

 

You only need virtual if you plan on overwriting the function in child classes. "void" works if you are not returning anything from a function.

This is not an accurate way of thinking about it.  First you can overwrite a method in a child class without virtual, however to call it you must have a variable or pointer to the child class.  Virtual is for polymorphism.  If you wish to call a method on a parent class but have the method called for child class of the runtime type.  To get this to work you must use the heap, and there for pointers, and inheritance.

 

I was thinking more along the lines of interfaces when Damian. mentioned virtual. You are right.

Share this post


Link to post
Share on other sites
Dragonsoulj    3212

assuming you are using a windowed design

 

Forgot to mention:

If you are doing just a full screen game you don't need to create a new window/change styles, just draw the splash screen, handle loading, then clear the screen and start running/drawing your game.

Share this post


Link to post
Share on other sites
JTippetts    12950
As indicated, you need a way to manage game states. A game state represents a given "phase" of the game's execution: playing the intro video/splash screens for one, displaying and interacting with the opening menu, playing the game. Each of these states includes their own code/data for doing what they do. States typically encapsulate a set of input/update/render operations. (Though some state management can get more difficult than that, it amounts to about the same idea.)

A commonly-used paradigm is that the update routine of a given state, when called, will return a pointer to the state that should be executing next.

Consider the following rough interface for a game state:
class BaseState
{
	public:
	virtual ~BaseState();
	
	BaseState *update(float dt)=0;
	BaseState *handleInput()=0;
	void render()=0;
	bool shouldExit()=0;

};
Any given game state would derive from this interface and implement update, handleInput and render. In the case of intro/splash stuff, the update method would advance the movies, advance timers on the splash screen, or whatever; render would draw the image, and handleInput would listen for Escape or other keys that can be used to early-cancel the splash and dump you to menu. Either of update or handleInput can return a new state. In the case of the splash state, update would return a pointer to a new instance of a MainMenu state as soon as the internal timer runs down to 0 (meaning the splash sequence is ended). handleInput would return a pointer to a new instance of a MainMenu state whenever it indicates that a key press is received to cancel the splash sequence.

Similarly, the MainMenu state would implement its own versions of those three methods. Update wouldn't really do a whole lot, since there isn't much in the way of action going on in a main menu. Update some animations if you have an animated scene for your background. Update some particle effects, whatever. render, of course, would draw the menu. handleInput would listen for mouse clicks, and pass appropriate input to the various UI widgets comprising the main menu and any associated sub-menus or screens. The Start Game menu button (or equivalent) would be attached to a process that would, when clicked and handled in handleInput, construct a new Game state. The Exit Game button would similarly construct an ExitGame state that would shut down all systems and terminate the loop.

And so on.

At the heart of the system is your game loop which operates something like this:
void loop(BaseState *startingstate)
	BaseState *currentstate=startingstate;
	Timer timer;
	
	if(!currentstate) return;
	
	float currenttime=timer.getCurrentTime();
	float elapsedtime=0;
	while(currentstate && !currentstate->shouldExit())
	{
		BaseState *newstate=currentstate->update(elapsedtime);
		if(newstate) currentstate=newstate;
		
		newstate=currentstate->handleInput();
		if(newstate) currentstate=newstate;
		
		currentstate->render();
		
		float nexttime=timer.getCurrentTime();
		elapsedtime=nexttime-currenttime;
		currenttime=nexttime;
	}
}
It's rough, but that's the gist of it. The loop just executes until it's told to stop, and each time through it calls update and handleInput on the current state. If those methods indicate that the state needs to change (a button was pressed, a timer ran out, whatever) then they will return a pointer to the state that should be executing next. Otherwise, they return 0.

After that, it's really just a simple matter of implementing your handleInput, render, update, and shouldExit methods appropriately for the state they represent.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this