   Question about Pause Window
  I've noticed that in some games there is a pause window, that you can produce, by some shape or form in the game, usually a dedicated button. The same goes for general menus, while in-game.My question is, what exactly occurs? I've figured that in your game loop, you will likely have some sort of states; such as GAME ACTIVE, or something, and corresponding with that when pressing the input key, you will toggle to perhaps a GAME PAUSE, where you can likely stop whatever is going on from happening.Do you create a separate "window" for those menus? or is it just a quad drawn on the screen? Is it perhaps true that it is a static window, at which interactions toggle the return to game? ieie. changing settings, from this "menu" perhaps, can be done in this state, but the game can remain active. "The only problem I see with a secondary window, is what happens if the game is fullscreen and you are showing this other window on top of the current window - wouldn't the game window lose focus and therefore act as if you were alt-tabbing?Technically, I am also assuming that you would not change anything from your graphics calls, and all the gameplay is under this game state.After this whole jumbled mess of a post, my only real concern was the question about if the window that comes up is an actual quad just drawn on the screen or a static second window, where you just toggle the visibility.Thanks.   
  Well i can not say that this is how all people do it but this is how i do it.I have something called a game State engine witch in essences tells that game what it is currently doing and when the game pauses it renders the pause screen but does not clear the screen so that the background still looks like what was previously rendered and the pause screen is just rendered over top.Regards jouei.   ;  Well if I understand what you're trying to say then the answer is simple, all that is really going on is that the program goes into a second render road. For example:INT Render(){ if(Pause == TRUE) RenderPauseMenus(); else LoadGameNextFrame(); RenderFrame();}What happens is that every frame the game goes into the function Render(), the game then checks to see whether or not the game is paused (through the variable Pause which is of BOOL type), if it is then the game goes into the pause menus otherwise if the game was not paused (Pause = FALSE) then the game loads the game's next frame information which basically sets the character's new positions or changes weapons or updates money variables and whatever. BUT no matter if the game was paused or not the game will still display the frame that the game last loaded, if the game is paused then none of the variables that have to do with the game will have a chance to change meaning that when the game is paused (Pause = TRUE) LoadGameNextFrame() is not called but RenderFrame() is, this displays the last loaded frame while also rendering the pause menus.I think I explained extremely badly but I tried my best to help you out :).EDIT - To be honest I don't really know if games do it like this... but using my experienced sense (as opposed to common sense) I came forth with this solution :D. I hope someone else comments to because now I'm curious on how its done :)... but I'm pretty sure I'm correct.Second EDIT - It seems me and Jouei have cross-posted :), but what he has said seems to be the same as what I tried to say only simpler :D.   ;  Well, I realized that you would use some game states. My dilemma is that I would have no idea how to create the "window" that spawns over the game-window, with the menu options on it.I can create windows normally, however, if you just CreateWindow, right on top of a fullscreen game - wouldn't the game force itself to window mode?orShould it rather be just a textured quad of some sort, just drawn 2D on the screen, and somehow, apply the buttons or what not to it? If this is the option, how would I draw the buttons in the presumed places, without having some window handle?Thanks.   ;  Yet again, I make myself look stupid. I also just realized the second option would probably be better, because I could make some sort of input method, somewhat relating to an onMouseClick type event, to handle "buttons" made of textured quads as well.   ;  Oh if that's what you meant then yeah :) I can confidently tell you that most programs infact use that method.   