Sign in to follow this  
golgoth13

SDL and UI

Recommended Posts

Hi all! I would like to make a 3d editor like application with menus, dialog boxes, etc. im currently using SLD... is there any cross platform UI solution? why not include UI features into sdl? thx [Edited by - golgoth13 on June 7, 2007 3:57:28 PM]

Share this post


Link to post
Share on other sites
Quote:
why not include UI features into sdl?


SDL is a layer that abstracts system window management, input and graphics. Given this, it wouldn't be of much sense to put effort into making an UI, instead of focusing on the really important stuff.

Share this post


Link to post
Share on other sites
not important? SDL_UI will do just fine... extend the possibilities... one library to develop application on any platform... cant you see it?!

Share this post


Link to post
Share on other sites
Quote:
Original post by golgoth13
not important? SDL_UI will do just fine... extend the possibilities... one library to develop application on any platform... cant you see it?!


There are quite a lot of GUI toolkits built on top of SDL. Guichan and ParaGUI are apparently popular.

If you want something that'll make use of a 3D API, you'll probably want to go with something like CEGUI or some engine with a toolkit (like, eg, Irrlicht). They aren't related to SDL though.

Finally, if what you want is to get SDL to render to a 3rd party toolkit's windows like you would with, say, DirectDraw and MFC, you're going to have a hard time. It's possible with the SDL_WINDOWID hack, sometimes. Such portable libraries include Qt, wxWidgets, FLTK, the FOX toolkit, Ultimate++ and Gtk+, for example.

Share this post


Link to post
Share on other sites
Oh... that is good information... I can almost see the light... must choose one lib now... I ll look at them closely... any advantage of using one lib in particular? window, mac and linux would be fine.

Quote:

If you want something that'll make use of a 3D API


im not sure what u meant there... I do have a 3d engine using opengl in a sdl framework... I don’t need any 3d ui if this is what you are saying... but all other 2d widgets are what I need...

im going to look at SDL_WINDOWID hack... interesting... but still hard to believe we have to hack such thing...

Share this post


Link to post
Share on other sites
Quote:
Original post by golgoth13
Oh... that is good information... I can almost see the light... must choose one lib now... I ll look at them closely... any advantage of using one lib in particular? window, mac and linux would be fine.


I think Guichan is the most popular of them all, but it largely depends on your needs. I don't think any of them will be able to handle CJK or RTL languages. Most of them probably don't handle Unicode either.


Quote:

Quote:

If you want something that'll make use of a 3D API


im not sure what u meant there... I do have a 3d engine using opengl in a sdl framework... I don’t need any 3d ui if this is what you are saying... but all other 2d widgets are what I need...


If you want a GUI that'll be 2D but rendered by OpenGL, then CEGUI is probably what you're looking for. If, OTOH, you want something that looks like regular Win32 controls (on Windows, anyway), then Qt, wxWidgets, etc, are what you're looking for.


Quote:
im going to look at SDL_WINDOWID hack... interesting... but still hard to believe we have to hack such thing...


I think SDL 1.3 will fix that, but it's not production-ready yet. It's a problem for many people, but then again SDL wasn't meant for tools, and I suspect it's victim of its success. [smile]

Share this post


Link to post
Share on other sites
There's one written in C that works with OpenGL under SDL or SDL native for that matter. It's AGAR and it seems to be very powerful... if you can get it to build from the source using the autoconf-based configure scripts.

Share this post


Link to post
Share on other sites
thx for your inputs guys... I really appreciate it.

then again... im a little confused... I did compile wxWidgets successfully and implement it into my project... my framework being sdl... let say I want a standard File->Open menu... can I expect it to work in or on top of my SDL window? or do I need to embed the SDL window within a wxWidgets context?

or like samuraicrow mentioned, use something like Agar being SDL native would be much easier? can anyone help me clear this up?

Share this post


Link to post
Share on other sites
I ve been looking at Agar Lib and it seams interesting indeed... the only problem is I ve been in the dark for a long time regarding the make file technique... even though I see this all over... I have no idea how it works... here is what the install note looks like:

Quote:

Build and install the Agar library:

$ ./configure [--help]
$ make depend && make
# make install
$ agar-config --version
1.0-beta
$ cat config.log | mail -s "compiles ok" report@agar.csoft.org

…SNIP

In the Agar root directory we have the files:

configure
configure.in
Makefile
Makefile.config

Have tried to execute them via cmd… didn’t do anything… there is no VS project to build... honestly, I have no clue what to do with this... seams like everyone on the planet knows how to but me... if it is not too much trouble, any help would be greatly appreciated.

thx again

Share this post


Link to post
Share on other sites
Quote:
Original post by golgoth13
let say I want a standard File->Open menu... can I expect it to work in or on top of my SDL window? or do I need to embed the SDL window within a wxWidgets context?


You'll have to tell SDL to render to a wxWidgets widget, which is exactly what the aforementioned SDL_WINDOWID hack is meant to do. I wish you good luck with it though, as it's quite tricky.


Quote:
or like samuraicrow mentioned, use something like Agar being SDL native would be much easier? can anyone help me clear this up?


I suspect it would be easier to set it up. I don't know if it'd be easier to use in a large project though (I've never used Agar). Since you're using OpenGL, I'd go with CEGUI and be done with it, although the learning curve is probably steeper. A lot of people here seem to use it, so I'm sure it has Visual Studio project files.


Quote:
Have tried to execute them via cmd… didn’t do anything… there is no VS project to build... honestly, I have no clue what to do with this... seams like everyone on the planet knows how to but me... if it is not too much trouble, any help would be greatly appreciated.


There is apparently no support for VS out of the box. I suppose it's meant to be using with MinGW or the Cygwin version of GCC in either MSYS or the Cygwin shell.

Maybe is it as simple as creating a new DLL project, adding all the source files to it and linking against SDL, SDL_image, etc. Maybe not. The only moment I use Windows is to make sure my software ports correctly, and I usually don't work with C++ (and when I do, I use the MinGW or Cygwin port of GCC), so I can't be of much help there.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

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