game loop help c++

Started by
3 comments, last by dAND3h 11 years, 6 months ago
Hi, I want to make a game loop in a nice way, where I can use polymorphism to call the correct Update, draw and HandleInput.
What I am thinking is to have a base class Scene, which will have the virtual functions Update,Draw and HandleInput. I will then create separate classes for each of my games states/Scenes. I.e. Login , options, pause, main game which will inherit from the base Scene class.

What I would want to do is this:

Scene* currentScene;

...GameLoop
currentScene->Update()
currentScene->Draw()
currentScene->Handlenput()

But wouldn't I also have to initialise the other scenes? Such as:
Login login;
Pause pause;

And then to change the currentscene, I will do something such as: currentScene = &login;

This part is fine, the problem lies in where to put the Scene* currentScene variable and all of the other scene variables such that I can switch to any one of the scenes from INSIDE another scene. So say I was in the login scene, and pressing escape inside this scene means I change it to the MainMenu scene, how can I do it so the Login has access to the Mainmenu variable and also the Scene* ?

Sorry if that didn't make much sense.
Advertisement

But wouldn't I also have to initialise the other scenes? Such as:
Login login;
Pause pause;

Not if you use (smart) pointers and create (and destroy) the scenes only as needed. Then your Login scene can return a [font=courier new,courier,monospace]new MainMenu[/font] to signify the scene change (or [font=courier new,courier,monospace]NULL[/font]/[font=courier new,courier,monospace]nullptr[/font] if there is no scene change).
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]
I generally use the run and return successor pattern with state objects like what you call your Scene objects. Basically every function called on a state object returns a smart pointer to the state that the system should be in now. This can be a pointer to the original state. This allows inter-relation of states to happen without whatever is holding the state to explicitly know what's going on. One thread where I talk about this in more detail.
The method I explained here is basically similar to what you are doing.
Each state (or scene in your case) inherits from a base state CStateBase.

The article provides code for managing these states, creating states based off ID value, and transitioning between states.

Additionally, it is generally a flaw to pass input to a state as an event. Inputs should be buffered and later accessed by the states when it is time for them to perform a logical update. The buffer should have a sequential and time-stamped history of inputs lasting at least 12 seconds long for the average use case.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

Thanks for the replies everyone. I ended up doing something very similar to L. Spiro's method. Although I am now looking into smart pointers as I had not heard of them before, so thanks for that research topic!

This topic is closed to new replies.

Advertisement