Im currently trying to set up an opengl game/menu. Its going to be fairly basic in the beginning - the character just runs around on a plane - but I am currently working on the game''s menu. Basically, what I want is a nice simple background and then buttons with rollovers. Would it be easier to create a different .exe (ie "launcher.exe") and then call on the opengl game .exe? Or could I create the menu - even the basic layout without the buttons - in opengl? Thanks (Im using DevC++ BTW).

The easiest way for creating a more complex menu (with lotsa options) is using thw windows gui stuff. You should not compile a separate exe. You just write a launcher() function, that creates its own window, and destroys it before proceeding to the game. Of course having a separate launcher.exe has no drawbacks i think
The more sophisticated solution is creating a user interface with opengl (textures, alpha blending, etc.), but i think it doesnt worth the time in your project. I suggest building a launcher with delphi, its the fastest and easyest way i know (or with c++ builder if you are unfamiliar with pascal)

Hmm... I am unfamiliar with pascal but I probably could learn. Ill cehck into delphi - would you or anyone else have some good tut links?

Thanks a lot for the info.

Hmm I''ll copy a artical i wrote on gl GUI''s. It will have some helpfull hints. Read it if you like or ignore it.


Resolution Independent Dynamic GUI’s for Games

Open your mind
With advances in hardware and programming, games are now becoming more and more life-like. Realistic water rippling on lakes, leaves in trees move with the wind, and dynamic worlds where anything can change. With all of these breakthroughs there is still one thing that hasn’t change for years: the GUI system.

One of three things is most commonly done with today’s game GUI’s. There is a non dynamic GUI, the user can’t move and arrange windows to suit his or her needs. There is a dynamic GUI, but the user is forced to pick a resolution; changing the resolution messes with the customized GUI, and needs to be redone. On top of that, the font gets smaller and smaller the more a user raises the resolution. Third, a combination of the above, is the worse; the user can’t dynamically modify the GUI, and its sensitive to resolution changes.

There are a few causes to these horribly implemented GUI systems. First of all, in OpenGl and DirectX there is no built in tools for a user interface. This causes game developers to reinvent something they are all not to familiar creating. Secondly, for 2d drawing, pixel locations are entered for the vertices that make UI components. Programmers keep track of locations by pixels because of this, and when resolutions change so do the pixel location relative to the screen.

It’s important to get away from modeling an interface to follow the way it’s drawn in the code. Instead of thinking with respect to pixels, think relative to the screen or object. If something is in the middle of an 800X600 screen it’s not at (400, 300); it’s at (.5, .5) or (50%, 50%). This remains true regardless of resolution, even if it doesn’t maintain the 4:3 ratio.

Implementation
Before going into the implementation, some vocabulary:
• Component – any visible part of a user interface (window, button, scrollbar, etc)
• Per-pixel coordinates – Coordinates ranging from 0 to the screen width and height
• Relative coordinates – Coordinates ranging from 0 to 1

The easiest way to implement this relative method is to have a component keep relative coordinates, and every frame calculate the proper per-pixel coordinates knowing the resolution. This adds to the calculations done every frame, thus horribly inefficient, and contains many flaws. Another major problem arises because not every GUI component coordinates should be relative to the resolution, if a window containing buttons moves, the buttons should move with it. There are components that should remain relative to the resolution that may have components relative to itself.

This dependency from one component to another all the way down to the screen resolution (root) forms a tree. One way of implementing this is through a hierarchy of derived classes. With each component derived from the same base class each part of the tree can have pointers to its children and a pointer to its parent. This method has many other advantages such as one recursion call, for drawing, detection, and other functions, for the whole tree. The root of the tree would be a component that contains nothing more than the resolution numbers. There are other models that can be used to implement a relative dynamic GUI, but for this example we will use this method.

It is ideal if the calculations are made to convert from relative to per-pixel coordinates only during construction (loading the GUI), saving the GUI’s settings/coordinates to a file, and resolution changes. With a little math this can easily be done. Because these calculations are only done at these particular times each component will keep its real per-pixel coordinates.

When a new GUI component is created, the following calculations will find the per-pixel coordinates of this component knowing the relative coordinates.

top    = ( parent->Gbottom()- parent->Gtop()  ) * ptop    + parent->Gtop();left   = ( parent->Gright() - parent->Gleft() ) * pleft   + parent->Gleft();bottom = ( parent->Gbottom()- parent->Gtop()  ) * pbottom + parent->Gtop();right  = ( parent->Gright() - parent->Gleft() ) * pright  + parent->Gleft();

Shown above the ptop, pleft, pright and pbottom are the relative positions. Similarly for saving coordinates, the following calculations can be done to get the relative coordinates from the per-pixel coordinates.

ptop    = (top    - parent->Gtop() ) / ( parent->Gbottom()- parent->Gtop()  );pleft   = (left   - parent->Gleft()) / ( parent->Gright() - parent->Gleft() );pbottom = (bottom - parent->Gtop() ) / ( parent->Gbottom()- parent->Gtop()  );pright  = (right  - parent->Gleft()) / ( parent->Gright() - parent->Gleft() );

Being able to switch from relative to per-pixel allows the programmer to take advantage of having the simple per-pixel coordinates while keeping it dynamic and resolution independent. With these per-pixel coordinates functions, drawing the component and detection are a breeze. Actual coordinates are used and compared with, resulting with a less complex and faster running code.

The root or parent at the top of the tree will have a simpler constructor where the resolution is passed in. The equations are set up to follow the standard 2d ortho mode coordinates where the origin is in the top left.

top = 0;left= 0;bottom = screenheightright = screenwidth

As shown with a little bit of creative thinking and math it is not too hard to make a more vestal and dynamic user interface.

Ill have to take a closer look at it tomorrow, however I believe that i understand the basics of what your talking about... Though I still need to figure out how to implement it.

Anyway, Ill continue work tomorrow thanks for that other tid-but of info!

Nice speech... ORRRRRRR you could just set up an ortho view for some arbitrary resolution, say 800x600. glOrtho(0,0,800,600). Then just pretend your user is using 800x600 and warp your cursor position based on screen size. Problem solved. (Function call might be wrong, but the idea is there)

Yes there are cheap hacks like the way that llama said.

Just because you can do them doesnt mean they are better. For example you lose presision with his method.

Things like glUnproject get more complicated if you're not using the real cordinates.



[edited by - skow on January 9, 2004 1:29:00 AM]

Does anyone know why I keep getting a undeclaired CDS_FULLSCREEN error? It never appeared before but suddenly its coming up every time I try to compile...

#ifndef CDS_FULLSCREEN											// CDS_FULLSCREEN Is Not Defined By Some#define CDS_FULLSCREEN 4										// Compilers. By Defining It This Way,#endif															// We Can Avoid Errors

Taken from Jeff Molofee''s base code.

Hmm does anyone know how to make it so a bitmap will be a button? Ive never actually made a bitmap into a button before so its new territory for me.