Menu Screens...

Just load in the graphics for the menu like you would in your game and display them to the screen. You could show an arrow at the right place, depending on what item is selected (maybe stored in cursor_pos). This cursor_pos can be incremented or decremented depending on the button thats being pressed. If the user presses ENTER say, you could do something like the following:

switch(cursor_pos)
{
case 1:
//do stuff for new game
break;
case 2:
//do stuff for controls
break;
case 3:
//do stuff for quit
break;
case 4:
//do stuff for about
break;
default:
cursor_pos = 1;
}

I hope that helps in some way.

- Daniel

Ive just recently done the front end for my racing game...
You will be suprised how complex these things get. I declare a new class called MainMenu which handles the graphics and the input for that screen. by wrapping it all into a single MainMenu object you can keep it much tidier, and when you spruce up the game later (or reuse your engine) its easy to just change the front-end. This keeps all the menu graphics and text hidden from the rest of the app as well, which can only be a good thing.
Hope this helped!

http://www.positech.co.uk

This actually confuses me a lot, how to design these things. How would u go about knowing when to display the menu, and when to display the game stuff itself, etc. I usually make that "state" varible. At the beginning, it''s 0, which means menu. Once the user clicks on "Start Game", it becomes 1, which means game. In the game loop I have a switch statement that executes particular code depending on the state. This is my solution, and to be honest it can get really ugly, because you could have a lot of states (game, main menu, settings menu, etc).

I agree with kill. I have made the function for the Title Screen, but I am not sure if I need to make another switch for the function. I am also not sure where I would put the switch.

Please help!!!! AHHHHH!

Thanks!
-Alex

You can download the quake source to see how it was done back then. Menu.c It''s old code, and not in C++, but it definetly seemed to work =)

Hope that can help you.

-Snowman

Ok, I have the function that makes the menu, but I am not sure how I would use it in the game loop. Can you please help???

-Alex

In a DirectX game, I would keep things linear and forget about the message loop all together unless you use some flags... but when you do that the code tends to get messy. Keep it
in one function and stay away from the "test flags in the message loop and keep going through until the gatekeeper lets you pass". It only caused problems for me.



Edited by - goofprog on June 22, 2000 9:30:09 AM

I''d do something similar to:

while (game_still_running)
{
    // Collect input

    if (!menu_visible)
    {
        // Do game logic (process AI / playerinput)
    }

    // Render screen
    
    if (menu_visible)
    {
        // Render menu
        // Process menu-relevant input
    }
}
 

This would be if your menu overlays your current gameplay window. To have a menu which only appears before or after a game, you probably need some sort of game state variable, which you can use in a switch statement, calling either your menu loop, or your game loop, depending on which state you''re in.

I also had difficulty with this issue. I ended up using WM_USER messages to signal state changes, and a switch on a global PgmState variable within the WM_USER case to initialize each state.

For example, states were defined as...

enum ps { atInit, atMain, inSim, atExit } pgmState;

and processing in WinProc as...

case WM_USER:
switch( pgmState )
{
case atInit:
ShowOpeningScreen(); pgmState=atMain;
SendMessage(hWnd,WM_USER,0,0); break
case atMain:
MainMenu(); SendMessage(hWnd,WM_USER,0,0); break
case inSim:
StartSim(); break;
case atExit:
xDDClose();
DestroyWindow( hwnd );
bQuit=TRUE; break;
}

Each stage sets pgmState according to what''s next, and issues a WM_USER message somewhere. In reality there are more states than shown here, and atMain can "jump" to several depending on user selection. Anyway, this is one way to do it I guess, hope it helps...

I see no problem with having things set up like this;

GameProc()
{
switch(gamestate)
{
case PLAYING:
HandleGameInput()
DoGameLogic()
DrawGamplay()
case MENU:
HandleMenuInput()
DrawMenu()
}
}

Like I said earlier, My menu is a seperate class which has its own internal state, so i have one game state that says its menu time, and the menu object checks its own state to see if its time to draw the choosegame menu, the changecontrols menu blah blah...

Im now 75% through the third game ive written with this method, it has no drawbacks i know of.
Happy Coding, Dont forget to check my website...

http://www.positech.co.uk

Keeping track of the menus you''ve navigated through is pretty simple. When you move to a new menu, just push a pointer to the current menu onto a stack, and when you select ''go back'' on your menu, the menu on the top of the stack is where to go. So display that menu, and pop it off the stack again. (This is computers tend to keep track of function calls, too.)