Different Screens

[Nick]

I'm working on splitting up my program in a small sense. I'm trying to set up my project so I have different files to handle the various screens (main menu, in-game, and paused/inventory) of my game. Any advice or ideas on how to handle this task? Each file either needs to have it's own rendering function or somehow set a global setting to control the main rendering function. The way I'm thinking this will work is a simple global variable in my main.cpp that keeps track of the screen and right before rendering it simply decides which screen to draw based on that variable and responds by running a function in another file. After the function has run through the game then cycles back through main collecting keypresses and such and returning back to the switch where it will do all of this again. Is this a good way to go?

[Sohta]

Yep, that would be a way to go at it. You could go a little farther and use classes for this. It's a prime example of a good situation where to use polymorphism IMHO.

You would have an abstract class from wich derives all the "screen" classes ( I personnaly call them "control owners" ). Your global variable would then be a pointer of the abstract class.

[Josh]

I think this is essentially what you're describing, but I'll tell you what I do anyways :p

In my GLView I have a pointer to the current rendering view. In GLView's redraw method I call [currentView draw]. I handle events in similar fashion. I just forward all the info on to the current view and let it decide what to do.

Seems to work fine for me. Initially I was afraid the extra overhead would hurt, but it isn't a factor so far.

[Nick]

Sohta, Could you explain that a little bit?

[arekkusu]

It's a state machine. I just use a global.

[Sohta]

Just for the record, my lack of answering Nick's question is due to the fact that I went to meet him on AIM to discuss it.

[BeyondCloister]

Just for the record, my lack of answering Nick's question is due to the fact that I went to meet him on AIM to discuss it.

Would you mind doing a short summary of the answer so that when other people come along and read the thread they too will get what you were explaining? Thanks

[Sohta]

Of course, my pleasure...

As mentionned in my previous post, the way I do this is via polymorphism. I have a base abstract class: SDControlOwner. It looks somwhat like that:


//simplified
//NB the default behavior of the methods that aren't virtual pure is just empty
class SDControlOwner
{
public:

virtual void ComputeNextPhysicalFrame( ) = 0 ;
virtual void DrawNextGraphicalFrame( ) = 0 ;
virtual void ExecuteKeyEvent( char inKey ) ;
virtual void MouseDown( ) ;
virtual void MouseUp( ) ;
virtual void RightMouseDown() ;
virtual void RightMouseUp() ;

//N.B. there is a separate init function, because it is to be called
//once we are sure to have a proper GL rendering context
virtual void Init( ) ;

} ;


Then I create a subclass of SDControlOwner for every "behavioral context" of my game. i.e. one for the splash screen, one for the main menu, one each of the game's states, etc.

I then have a global variable:
SDControlOwner * kCurrentControlOwner ;
wich contains the current control owner. So my engine's drawing function is:
void DrawScene{
//some drawing initialisation code here...
kCurrentControlOwner->DrawNextGraphicalFrame();
}
the same applies for physical updates and event management.

edit, added: This way, the code that gets called is the code associated with the current game behavior class. For those who are worried about the polymorphism involved, keep in mind that these functions are not called very often every frame. So the overhead is pretty negligeable.

There was a bit more to it ( mainly a control owner stack ), but this should pretty much cover it. You'll be able to find the whole source code for this in my UDG entry ( or earlier if anyone feels like they could use it ).

Also, for those coding in Obj-C, a protocol is what you need to implement this

[Josh]

I am essentially doing what Sohta does, but in Obj-C and w/o a protocol.