alright, one last thing that im concern about... when dealing with a lot of rollover options... I mean 100s if not thousands.... wouldn’t be faster to use os control widgets rather then opengl? I have always been facinated by the incredible speed os came up with concerning rollovers... I wonder how they do it...

I'm sorry but I don't understand what you mean by "rollover options" (my native language is French).

As for speed: a GUI will very rarely be the bottleneck. Most UI use dirty rectangles as to redraw only what needs to be redrawn, and only after an event occured(*). Drawing non-transparent widgets front-to-back to avoid overdraw is also an option (hardware z-buffering makes this easier).

(*) I guess it's a bit more complex if you need animated widgets, but it's nothing unmanageable.

If I were using OpenGL for every platform I'd recommend CEGUI.

Agar is not simple to install. The author said he tested it with MSYS and MinGW.

I've been trying for days to get this to install from the source. I think I've got it now but I still can't figure out how to build the demos.

Here's a few tips:

If you're using Visual C++ instead of any MinGW version, then you're in sad shape. It doesn't matter if you use Code::Blocks or DevC++ as your IDE as long as you're using the free MinGW compiler.

Once you've got MSYS installed and MinGW, run the postinstall/ps.sh script that tells MSYS where MinGW is located. Remember this directory name because you'll have to use the --prefix=/c/MinGW or whatever directory your path name is on the configure script later on.

Use the latest beta release of AGAR because there is a name conflict between a macro in SDL 1.2.10 and later with AGAR-1.2 .

Don't use any spaces in the directory names containing either the source code or the compiler or MSYS. Spaces aren't allowed in directory names in OpenBSD so using them only confuses the build process immensely. (Agar is developed natively in OpenBSD and ported from there to any other platform.)

Be sure that when you've installed SDL into the MinGW's directory structure that you put the sdl-config script in /usr/bin and make sure it has the default prefix set to the directory where you installed MinGW so it can find the lib and include directories.

MSYS installed change to the agar directory using MSYS-style paths. If your DOS path is C:/agar, enter cd /c/agar and make sure the name of the root directory is called agar because there is a shortcut file that gets created in the Agar-1.2 directory that isn't recognized by the MSYS version of BASH.

Type "./configure --help" without quotes to show all of the build options. The ones your concerned about are --prefix which will let you set the path to MinGW, --enable-debug which allows you to use a debugger with the code and, if you don't have FreeType or SDL_ttf installed, --without-freetype, and --no-manpages because MSYS doesn't include a man page viewer anyway.

After the configure script is done running type "make depend" and let the makefile run.

After that type "make" to actually do the compiling. After that type "make install" to attempt to move the files to the places they are supposed to be in.

If make install fails in one directory, try typing "make install" in all of the subdirectories of agar. This allows you to have all of the libraries built even if the build-script can't figure out how to make man-pages out of them.

Stuff I haven't figured out yet:

Why the configure script doesn't succeed in finding OpenGL in my MinGW install even though I have OpenGL32 in the lib directory and GL/gl.h and GL/glu.h in the include directory.

Where to find the unistd.a file since it's needed for unicode support or something similar. (The example codes include unistd.h but only assume that you have the appropriate library in the Makefile.)

How to get the demo programs to build.

[Edited by - samuraicrow on June 9, 2007 2:02:10 PM]

Quote:
I'm sorry but I don't understand what you mean by "rollover options" (my native language is French).

Well im french too so my explanations could be a bit clumsy… what I mean by rollover option is the constant check to know if the cursor is over a button… to display a tip at cursor position for instance… so you cant really rely on events… maybe on cursor motion…. However, the way I do it with opengl button is that a check if the x and y position of the cursor is it is over a button… when you have 100s of buttons it could be expensive… especially when you use justification, left, right, top and/or bottom of the screen… anyways, im not sure how it could be made otherwise… the trouble I find with this technique is that you can only work with rectangular buttons… it is still a mystery how web browser can support custom rollover shapes and run so fast.

As for Agar… im sorry but in my book… having to go through all the gymnastic to compile a lib at not having touch a single line of code makes me nervous… honestly, im not even interested to look at their code… maybe my lack of knowledge but I find this ridiculous… definite turn off for me… way to go is to double click the .sln and press build… how hard is that… if you want some options, knock yourself out but at least provide a quick startup. I know it is a free lib and not everyone are MS lovers but im always amazed to find myself spending precious time over so basic stuff… seriously.

Quote:
If I were using OpenGL for every platform I'd recommend CEGUI.

Im still not convince I want to use opengl for this… I wont if I don’t have too. Being trap in a single opengl window for widgets makes me claustrophobic... but i ll look at CEGUI for sure. I m Still digging.

Thx guys!

well, pretty much the same scenario with CEGUI... freetype compiled like a charm but the pcre.lib is required to compile the CEGUI lib...

Quote:
The simplest way to compile pcre.lib is:

1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system.

there ya go again... I guess im going to do step by step what samuraicrow explained and get my hands dirty... sigh... why aren’t they providing CEGUI.lib in the first place? those are world war II coders or am I taking crazy pills?

Quote:Original post by golgoth13
what I mean by rollover option is the constant check to know if the cursor is over a button… to display a tip at cursor position for instance… so you cant really rely on events… maybe on cursor motion

Cursor motion is an event. In SDL specifically:

void handle_mouse_motion(SDL_MouseMotionEvent const& event);void loop() {  // ...  SDL_Event e;  while(SDL_PollEvent(&e)) {    switch(e.type) {      //      case SDL_MOUSEMOTION:        handle_mouse_motion(e.motion);        break;      default:        break;    }    // ...  }}

Quote:However, the way I do it with opengl button is that a check if the x and y position of the cursor is it is over a button… when you have 100s of buttons it could be expensive… especially when you use justification, left, right, top and/or bottom of the screen… anyways, im not sure how it could be made otherwise… the trouble I find with this technique is that you can only work with rectangular buttons… it is still a mystery how web browser can support custom rollover shapes and run so fast.

They likely just test against rectangles first, and only do pixel-per-pixel checks if the mouse cursor is within the bounds of a shape's bounding box. It's even possible than each bounding box is divided in smaller sub-rectangles. You'd then be able to discard most of the pixels and check only those in the sub-rectangle of interest.

The same logic can be applied to widgets: with a few exceptions (widgets that "unroll" like combobox, menus, etc), widgets are usually contained in their parent's bounding box. If the mouse cursor isn't in the parent's bounds, then there's no need to check its children.

Quote:way to go is to double click the .sln and press build… how hard is that… if you want some options, knock yourself out but at least provide a quick startup.

It's provided: ./configure && make && make install. Free software developers use free software toolchains most of the time. Most VS users don't provide configure scripts for the GNU toolchain either. Because that project is free software and apparently originates from the UN*X world, it makes sense to support free toolchains that work on UN*X-like systems, as opposed to proprietary toolchains that work only on Windows. [smile]

If you would like to make your GUI faster, you can make the restriction that all sub-components of a widget must be inside of the widget. So, if a dialog box has a button, that button must be inside of the dialog box.

Then, to do collision, you can instantly remove quite a bit of widgets from the test. If you recursively-compose the widgets, you can test for the hand being in the parent window. If and only if the mouse is over the parent widget will you check to see if it's over children widgets. Chances are, it's only over a couple of the highest-level widgets, which let's you ignore quite a few other widgets.

Of course, doing a point to axis-aligned rectangle is a very fast collision detection, consisting of only one if, two '<', two '>', possibly some addition, and three 'and's. If that's a bottleneck, you probably have a very fast program.

All interesting comments!

Im getting closer, I think im going to use wxWidgets and use os widgets… it makes more sense to me so far… hopefully sdl will support multiple windows anytime soon.

it may be all in my head but I feel like opengl is getting old and falling behind… so im slowly getting open-minded to directx 10.

Quote:Original post by golgoth13
Im getting closer, I think im going to use wxWidgets and use os widgets… it makes more sense to me so far… hopefully sdl will support multiple windows anytime soon.

That's AFAIK planned for SDL 1.3. I don't know when it's due to be released though, but you can already get the development version from the Subversion repository, so it isn't vapourware at the very least.

Quote:it may be all in my head but I feel like opengl is getting old and falling behind… so im slowly getting open-minded to directx 10.

In that case you won't need SDL, wxWidgets, etc. They're meant to be crossplatform, and Direct3D will make sure that doesn't happen, unless you abstract it away (which is, IMHO, a lot of work for very little gain). You'd probably be better off with WinForms and a .NET language too.

OpenGL is IMHO progressing nicely, although I can't claim to have followed all the recent changes related to game development in either OpenGL or Direct3D.

If your goal is to write an application or a game, then use a 3D engine/framework that abstracts OpenGL and/or Direct3D, otherwise you'll never get to actually work on said application/game. If what you're interested in is engine programming, then obviously you'll have to learn OpenGL and/or Direct3D.