Sign in to follow this  
DerekBaker

"2D" Screens?

Recommended Posts

For my menu screens such as title screen, options, credits, etc, I have several helper classes, such as:

CMenuLink -- this is a clickable "link", which takes you from one menu state to another

CMenuTextInput -- allows you to type text into a text box

CMenuButton -- toggable button that has an on/off state

etc

All of the above classes derive from a CMenuItem class. To manage all of these menu items (CMenuItem), I have a CMenu class that holds pointers to them, and allows you to Add menu items as you see fit.

As far as the graphics go, I have a 2D Rectangle class, a font class for drawing font, a sprite class that wraps the functionality of a ID3DXSprite (sp) class, etc.

Hope this helps. Let me know if you need more specifics.

Share this post


Link to post
Share on other sites
Menus can be very diffrent from each other. Some games implement very complex menusystems while other rely on basic systems.

I have a simple yet effective menusystem where the base is a Menu-class. I let the Menu-class have attributes which keeps track of where the "cursor" of the menu is and where the in the menusystem that the user currently is.
And whenever the user press Enter I ask Menu where the cursor is, and menu answers me. This is basicly how it works (pseudocode):

while( true)
{
if( gamestate == menu )
_menu.update(); // this class checks for keypresses itself

if( gameState == inGame )
{
if( keypress == Esc )
gameState = menu;
_game.update();
}

if( keypress = Enter )
{
if( _menu.getNewState() == cursorAtNewGame )
{
gameState == inGame;
_game.newGame();
}
}
}

You can add complexity to this code to fit your needs. The good thing about this is that even though the user gets back in the menu, the state of _game will be the same, so you can easily implement a "Resume" feature in which you just begin updating the _game-class instead of creating a new one.

Then you have the standard render() methods etc so you actually see something [smile]

Share this post


Link to post
Share on other sites
Just to add what mcguile25 said.
I generally use textured quads or sprites as my menu controls. They are simple and easy to use and provide you with some flexibility and when using sprites you could dictate easily where on the screen they must appear rather than having to do calcs to place them in the correct location in your window.

Share this post


Link to post
Share on other sites
My sprite engine isn't finalized, but here's how I'm doing it: I used D3DXSprite for all 2-D graphics because it handles caching and optimization on its own, and that's fine by me. My GUI consists of a variety of control classes that basically work like ActiveX controls. They have scripts to define their behavior, and this ties into the scripts that control the game, so it all works seemlessly. The actual sprites used by these control classes are very generic and behave exactly like sprites in-game. Sprite behavior is controlled using states, which are issued by the game.exe itself, but the sprite manager is responsible for processing these states. I use XML-style definitions to describe the behavior of a sprite in a given state.

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