Possible GUI Solution

SDL Development
1

GLUI, a UI library for OpenGL currently uses GLUT for event handling. I
plan on porting to SDL, if poeple are intersted in helping/getting a
copy of it when I’m done, tell me.

emblem

2

Hi there…

emblem wrote:

GLUI, a UI library for OpenGL currently uses GLUT for event handling. I
plan on porting to SDL, if poeple are intersted in helping/getting a
copy of it when I’m done, tell me.

Where can GLUI be found?

:slight_smile:
Peter

3

Peter Hawkins wrote:

Hi there…

emblem wrote:

GLUI, a UI library for OpenGL currently uses GLUT for event handling. I
plan on porting to SDL, if poeple are intersted in helping/getting a
copy of it when I’m done, tell me.

Where can GLUI be found?

:slight_smile:
Peter

Hello,

All thoses solutions for The GUI seems interesant. What I propose is that
before everyone developpe
his own toolkit, is that all people concert to know which is best.
GTK seems good, so porting it seems a good idea.
What I propose as Key feature for the GUI widget toolkit :

  • Easy implementation
  • Good documentation
  • Fast
  • Nice
  • Programmable either in C or C++
  • can be placed over a picture with pseudo-transparence ( for example :
    button will let us see the
    image that is under it )
    So, to conclude, I think it is important to speak and to take a decision
    before beginning to program anything

Best regards–
Stephane Magnenat
stephane.magnenat at urbanet.ch

4

St\iphane Magnenat writes:

All thoses solutions for The GUI seems interesant. What I propose is that
before everyone developpe
his own toolkit, is that all people concert to know which is best.
GTK seems good, so porting it seems a good idea.

I think you only need to port Glib, as it’s the interface to X11 that
Gtk+ uses.

That would be nice though, themable games :slight_smile:

Phil

5

What I propose as Key feature for the GUI widget toolkit :

  • Easy implementation
  • Good documentation
  • Fast
  • Nice
  • Programmable either in C or C++
  • can be placed over a picture with pseudo-transparence ( for example :
    button will let us see the image that is under it )
    So, to conclude, I think it is important to speak and to take a decision
    before beginning to program anything

I’d like to add " - Extendable" to the list. :slight_smile:
C++ is very good for making extendable widgets.

It doesn’t do a whole lot of good to have a button, if you can’t say, put
an image on it, or link it to a text input, or …

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

6

What I propose as Key feature for the GUI widget toolkit :

  • Easy implementation
  • Good documentation
  • Fast
  • Nice
  • Programmable either in C or C++
  • can be placed over a picture with pseudo-transparence ( for example :
    I’d like to add " - Extendable" to the list. :slight_smile:

I was hoping for something really small and simple, only used for ugly
internal tools, not for the final game. I have spend much of the last 1 1/2
years for developing inhouse tools using a toolkit with the following
attributes:

  • runs well on double/triple - buffered screens
  • fast enough for update each frame (allthough it does redraw
    optimisations)
  • very limited and poorly extendabe, therefore small and easy to understand
  • quite ugly. well we can do about that.
  • only good for one simple style of application
  • simple to use

I assume that the interface of a game has to be recoded everytime. The
first thing the user sees is the menu, therefore a lot of design has to go
there, and creating a widget set which is versatile enough to cope with the
creativity of our designers is a really big job (the game I am working on
now has a menu with a slightly diagonal style, really cool but hard to
implement efficient…).

What I need a gui for are the tools. Almost any game needs an editor, and
the quality of the editor is an important factor for the quality of the
final game. It is a good idea to have an editor that uses the same engine
as the game, and therefore the editor should run in the same environment as
the game. I still hope to find a widget set that is simple enougth to be
ported to SDL, but I would prefer a highly limited application framework
that lets you concentrate on the real work while the interface comes from
itself. I assume I could do it in 64-80 KByte source+header, by porting or
adapting what I have done for my current game project.

By the way, If you live in Germany, you might have a look at the "YARG"
article in the magazine “Next Level 11/98”. It contains some screenshots of
the editor I did and even a photograph of me…

Dierk Ohlerich
@Dierk_Ohlerich> From: Sam Lantinga

To: sdl at surfnetcity.com.au
Subject: Re: [SDL] Possible GUI Solution.
Date: Donnerstag, 29. Oktober 1998 18:54

7

Lavoie Philippe wrote:

St\iphane Magnenat writes:

All thoses solutions for The GUI seems interesant. What I propose is that
before everyone developpe
his own toolkit, is that all people concert to know which is best.
GTK seems good, so porting it seems a good idea.

I think you only need to port Glib, as it’s the interface to X11 that
Gtk+ uses.

That would be nice though, themable games :slight_smile:

Actually, glib is a library of generic routines for list and string
manipulation, etc. It is very portable. What you mean is gdk, the
wrapper that gtk+ uses to interface with the gui system. The original
gdk runs under X, while the win32 port is almost useable. There is even
talk of porting it to embedded RISC processors as an alternative to
WinCE. Imaging GNOME on your palmtop. :slight_smile:

Porting gdk to SDL should be pretty painless. After that, you get most
of gtk+ for free. I say most because some of the newer / more complex
widgets are naughty and use X directly instead of going through gdk.

I would like to see this done, and a MacOS port of SDL. Then I could run
the GIMP on Mac!

Max Watson

8

Max Watson wrote:

Porting gdk to SDL should be pretty painless. After that, you get most
I disagree, gdk uses a windowing system, you would have to create a very complex
interface layer between gdk and the SDL buffer.> Max Watson

9

All thoses solutions for The GUI seems interesant. What I propose is that
before everyone developpe
his own toolkit, is that all people concert to know which is best.
GTK seems good, so porting it seems a good idea.

Well I think the reason we’re all on this list is because we don’t want
to develop our own toolkit. We all want to use SDL (Which I still think
is a DAMN fine toolkit for full-screen or one-window applications).

I don’t think GTK is all that good for game programming. GTK is an
event-based UI, which isn’t going to work well for games that need to be
real-time. And they’re already working on porting it to non-X environments.

What I propose as Key feature for the GUI widget toolkit :

  • Easy implementation

To be quite honest, SDL is one of the easiest toolkits I’ve ever seen.
And I’ve been looking since I started learning to program X.

  • Good documentation

Again, score for SDL. It’s got some of the most extensive documentation
I’ve seen. I’ve looked into the GTK+ documentation, and as of yesterday
their tutorials are STILL missing a LOT of information.

  • Fast
  • Nice

Take your pick. If you want it fast, you’re going to have to do a lot of
the work yourself. Sam can’t anticipate the particular needs of your
game, and if he even tried, it would be completely detremental to SDL.
If you want nice, you’ll have to define that better. Do you mean nice as
in “it does all the hard work for me”, or nice as in “I’m not losing all
my hair trying to master this beast”? And for what it’s worth, SDL is
easier for me to understand then GTK+ is (I’ve tried to write two
programs in GTK+ and failed miserably both times).

  • Programmable either in C or C++

SDL is already programmable in either of those. That’s the advantage of
using C as a base, rather than C++ (Like Prometheus). If you know C++
then it should be fairly trivial to write extensible wrappers around most
SDL functions.

  • can be placed over a picture with pseudo-transparence ( for example :
    button will let us see the image that is under it )

That is simply a matter of refresh order. If you refresh the button
first, then the image, it’ll work fine. Or if you just refresh the edges
of the button, it’ll do the same thing (But the image won’t move, which
might take away from the believability of it).

So, to conclude, I think it is important to speak and to take a decision
before beginning to program anything

I agree. A good design phase is always a good idea if you don’t have
tons of extra time to re-write huge parts of your code. However, I still
think that SDL is great for its designed purpose. I think GTK+ is great
if you’re making applications that spend most of their time waiting on
either the user, the network, or some other external trigger, but for the
minute control you need for your game, you’re going to need the control
you have with SDL.

But if I might add a couple things to this wishlist…

-small size (both memory footprint and executable size)
-excessive control over game execution

The reason I bring these up is because not everyone has the latest and
greatest Pentium 2 with 3D card. We all know how much we hate slow
games, so we should also dedicate ourselves to writing the smallest,
fastest games we can.

-Knight Walker

10

I was hoping for something really small and simple, only used for ugly
internal tools, not for the final game. I have spend much of the last 1 1/2
years for developing inhouse tools using a toolkit with the following
attributes:

Well, Small and Simple are two major goals for Simple Directmedia Layer.
I personally think SDL is useful for more than just the ugly internal
tools. In fact, I think it’s quite elegant. I’ve played both the demos
that were coded in it, as well as D1X and SDLDoom and they both look
great. But I can see why you wouldn’t want to scrap the 1 1/2 years
you’ve put into your toolkit.

  • runs well on double/triple - buffered screens

That is something Sam might be interested in. I know he’s working on
double-buffering for SDL 9.

  • fast enough for update each frame (allthough it does redraw
    optimisations)

The assembler sections of SDL may be that fast. I know Sam has published
benchmarks between SDL and Prometheus, and SDL has out-run Prometheus
nearly every time.

  • very limited and poorly extendabe, therefore small and easy to understand

Well that could be a problem. Small and easy are definite plusses, but I
know that I don’t want to have to re-write tons of SDL code just to make
a GPL’d game.

  • quite ugly. well we can do about that.

No comment on that one.

  • only good for one simple style of application

Ditto.

  • simple to use

I can only speak for myself, but I find SDL to be extremely easy to use.
When Sam asked me to compile all the SDL demos and projects using SDL for
SDL 8, I was able to update most of them from SDL 7 with little trouble.

I assume that the interface of a game has to be recoded everytime. The
first thing the user sees is the menu, therefore a lot of design has to go
there, and creating a widget set which is versatile enough to cope with the
creativity of our designers is a really big job (the game I am working on
now has a menu with a slightly diagonal style, really cool but hard to
implement efficient…).

Well, if I think about all the games I’ve seen lately, a menu-type
interface would be good, but it should be flexable enough that you
could put text, images, or a combination of both. The buttons should
also be flexable enough that you can change their color, size, shape, and
even animated properties. Also good would be a movie-playing method (SDL
has FLI/FLC, but I haven’t been able to test it).

What I need a gui for are the tools. Almost any game needs an editor, and
the quality of the editor is an important factor for the quality of the
final game. It is a good idea to have an editor that uses the same engine
as the game, and therefore the editor should run in the same environment as
the game. I still hope to find a widget set that is simple enougth to be
ported to SDL, but I would prefer a highly limited application framework
that lets you concentrate on the real work while the interface comes from
itself. I assume I could do it in 64-80 KByte source+header, by porting or
adapting what I have done for my current game project.

You’re right. The quality of the editor does have a large impact on the
quality of the game. However, I don’t know that it’s necessary for the
editor and the game to have the same engine–look at the editors for
WarCraft2, StarCraft, and TotalAnnihilation. Those editors have no
"engine" to them, yet they allow you to do hundreds of things to the
game, add/remove units, buildings, walls, and so on. And the editors for
Quake, DOOM, and Descent that I’ve seen are almost like 3D CAD programs.

But you’re right, the editor should run in the same environment as the
game (And by that, I mean if the game runs in X, the editor should too,
and if the game runs in Win32, the editor should too.

As for the simple-to-use widget set for SDL, download and look at the
sdl-demo archive. That adds almost a whole new level of usefullness to SDL.

By the way, If you live in Germany, you might have a look at the "YARG"
article in the magazine “Next Level 11/98”. It contains some screenshots of
the editor I did and even a photograph of me…

Is there any way you could scan those and post 'em on the net anywhere?

-Knight Walker

11

My 0,02 DM on this :slight_smile:

  1. Dierk is right. If you’re not writing a simulation game like SC2000, you
    don’t need a real gui, you have to do a menu which has, as pointed out,
    to be done manually anyway and some message boxes which should
    unique (nice word!) so the people don’t say what’s that? Hereos of Might
    and Magic 3 or what? We need a gui in the level editor. I first wrote a
    level editor manually which worked until a certain point. Making a dialog
    to select a file yourself takes a week or two and even then it has got
    its
    problems. I finally ended up using Delphi which is wonderful.
  2. The problem with GTK is that it’s simply too heavy. All those toolkits
    were made to do complex guis and they’re not intended to render into
    a frame buffer but to be used by a real window manager. I think, what
    we would need more would be something very simple and light-weight
    with function calls like: DrawInputDialog( “Save filename”, “Enter the
    filename”,
    save_filename, 60, CLRED, CLBLUE, DOUBLE_FRAME );
    or DrawFrameWindow(10,10,80,80);
    and let the app do the mouse handling and such things theirselves. That
    would simplfy everything a lot and it would be still much to do
    (really!).
    Just think a second about fonts!
    Maybe even some simple text put routines (not with C++ classes, that’s
    rubbish) and box routines would help us…
  3. Maybe you’re right - integrate GTK, OpenGL, Corba and Java into SDL
    and it would immediately turn into SUPER-SDL!

Paulus Esterhazy

12

To be quite honest, SDL is one of the easiest toolkits I’ve ever seen.
And I’ve been looking since I started learning to program X.

Thanks for the comments Knight, it’s great to get positive feedback. :slight_smile:

Take your pick. If you want it fast, you’re going to have to do a lot of
the work yourself. Sam can’t anticipate the particular needs of your
game, and if he even tried, it would be completely detremental to SDL.

I’ve been mostly quiet on the widgets issue for two reasons.

  1. I think that they are a great idea, and should be a layer above SDL,
    as in a demo library.
  2. I’m very interested in what you come up with. :slight_smile:

SDL is already programmable in either of those. That’s the advantage of
using C as a base, rather than C++ (Like Prometheus). If you know C++
then it should be fairly trivial to write extensible wrappers around most
SDL functions.

You can even emulate the Prometheus API using SDL. :slight_smile: Check out the PTC
subdirectory in the demos archive.

  • can be placed over a picture with pseudo-transparence ( for example :
    button will let us see the image that is under it )

That is simply a matter of refresh order. If you refresh the button
first, then the image, it’ll work fine. Or if you just refresh the edges
of the button, it’ll do the same thing (But the image won’t move, which
might take away from the believability of it).

I think he means translucent buttons. This can be achieved using alpha
blending. Check out the “testalpha” test program. Note that this looks
really bad in palettized mode. You need to run in at least 16-bit color
for it to work properly, without carefully managing your palette.

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

13
  • runs well on double/triple - buffered screens

That is something Sam might be interested in. I know he’s working on
double-buffering for SDL 9.

Double-buffering is completely supported as of SDL 0.9.6
Check out the new “testsprite” test program for an example of how to use it.

The assembler sections of SDL may be that fast. I know Sam has published
benchmarks between SDL and Prometheus, and SDL has out-run Prometheus
nearly every time.

brn and I have worked very closely to improve both SDL’s and PTC’s
blitting. In fact, SDL now uses some of the same assembly blitters
that PTC uses. The speed of PTC and SDL are now nearly comparable,
with SDL having a slight edge because it uses C rather than C++.
Some of the newer blitters in PTC may be faster than SDL in select cases,
since I haven’t optimized some of the ones PTC has.
BTW, optimizing a blitter is trivial, it just adds size to the library,
so if you need a particular case to work really fast, let me know.

As for the simple-to-use widget set for SDL, download and look at the
sdl-demo archive. That adds almost a whole new level of usefullness to SDL.

What people are asking for, menus, buttons, text widgets, etc., don’t come
pre-built with the tools in the demo archives. You can build them with the
demo libraries, in fact that’s what Maelstrom does, but there is definitely
a lack of good widgets available for use with SDL.
It’s true though, there’s a lot of other good stuff in the demos archive.
grin

I’m probably going to come up with a scrolling text box widget, just to get
debug output working nicely in some of the fullscreen evironments. This is
at least three weeks out though. I want to get networking and some other
things working first.

I want to give a big thanks to Dan Kegel of Activision for some excellent
advice on the networking code, BTW. :slight_smile: It is going to rock! :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

14

All thoses solutions for The GUI seems interesant. What I propose is that
before everyone developpe
his own toolkit, is that all people concert to know which is best.
GTK seems good, so porting it seems a good idea.
What I propose as Key feature for the GUI widget toolkit :

  • Easy implementation
  • Good documentation
  • Fast
  • Nice
  • Programmable either in C or C++
  • can be placed over a picture with pseudo-transparence ( for example :
    button will let us see the
    image that is under it )
    So, to conclude, I think it is important to speak and to take a decision
    before beginning to program anything

I think Gtk Would be the best solution for GUIs, but a game really needs a
more optimised gui if it is to work directly with animations etc. Sam and
I have discussed N, and either me or pfh will eventually find what went
wrong since we last used it. It does all the things mentioned above.

njhOn Thu, 29 Oct 1998, St?phane Magnenat wrote:

15

Double-buffering is completely supported as of SDL 0.9.6
Check out the new “testsprite” test program for an example of how to use it.

Now I just need a video card that can exploit the double-buffering…

brn and I have worked very closely to improve both SDL’s and PTC’s
blitting. In fact, SDL now uses some of the same assembly blitters
that PTC uses. The speed of PTC and SDL are now nearly comparable,
with SDL having a slight edge because it uses C rather than C++.
Some of the newer blitters in PTC may be faster than SDL in select cases,
since I haven’t optimized some of the ones PTC has.
BTW, optimizing a blitter is trivial, it just adds size to the library,
so if you need a particular case to work really fast, let me know.

I noticed, when you posted the benchmarks. Personally, I think it’s
great. Competition in the Linux world is something I’ll alway support.
But I do believe C is faster than C++, which is why I prefer
programming in C.

What people are asking for, menus, buttons, text widgets, etc., don’t come
pre-built with the tools in the demo archives. You can build them with the
demo libraries, in fact that’s what Maelstrom does, but there is definitely
a lack of good widgets available for use with SDL.

Well, it’s been my experience that you almost need the demo archive to
do anything useful without bogging yourself down in the lower levels of
SDL. But that was the idea, right? :slight_smile:

It’s true though, there’s a lot of other good stuff in the demos archive.
grin

I’ll say. Now I just need an FLI/FLC so I can test the player out.
I’d really like to see how it works, so I can try swindling a graphic
artist I know into writing the cut scenes for me. :slight_smile:

I’m probably going to come up with a scrolling text box widget, just to get
debug output working nicely in some of the fullscreen evironments. This is
at least three weeks out though. I want to get networking and some other
things working first.

And then we can hack it into an in-game chat feature. :slight_smile:

I want to give a big thanks to Dan Kegel of Activision for some excellent
advice on the networking code, BTW. :slight_smile: It is going to rock! :slight_smile:

So now we’ve got professional game programmers giving advice? We’re
unstopable. :)On 29 Oct, Sam Lantinga wrote:

–

| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

16

All thoses solutions for The GUI seems interesant. What I propose is that
before everyone developpe
his own toolkit, is that all people concert to know which is best.
GTK seems good, so porting it seems a good idea.
What I propose as Key feature for the GUI widget toolkit :

  • Easy implementation
  • Good documentation
  • Fast
  • Nice
  • Programmable either in C or C++
  • can be placed over a picture with pseudo-transparence ( for example :
    button will let us see the
    image that is under it )
    So, to conclude, I think it is important to speak and to take a decision
    before beginning to program anything

I think Gtk Would be the best solution for GUIs, but a game really needs a
more optimised gui if it is to work directly with animations etc. Sam and
I have discussed N, and either me or pfh will eventually find what went
wrong since we last used it. It does all the things mentioned above.

how would one integrate SDL and GTK into the same app, anyway? gtk wants
its gtk_main() run, and I assume SDL doesn’t have a toplevel event handler
like that at all, but if it does, it’s different, right?On Fri, 30 Oct 1998, Nathan Hurst wrote:

On Thu, 29 Oct 1998, St?hane Magnenat wrote:

Scott M. Stone <sstone at pht.com, sstone at pht.co.jp>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)

17

What people are asking for, menus, buttons, text widgets, etc., don’t come
pre-built with the tools in the demo archives. You can build them with the
demo libraries, in fact that’s what Maelstrom does, but there is definitely
a lack of good widgets available for use with SDL.

Well, it’s been my experience that you almost need the demo archive to
do anything useful without bogging yourself down in the lower levels of
SDL. But that was the idea, right? :slight_smile:

I think that widgets are perfectly suited to the demo collection. SDL stands
for “Simple Direct Media Layer”. I see nothing simple or direct media about
a widget set.

Of course, there is nothing wrong with making an LGPL demo library of a widget
set that goes on top of SDL, as was done with screenlib.

Networking support is right on the border of whether it should be part of the
main SDL library or not, IMHO…On Thu, Oct 29, 1998 at 09:01:47PM -0700, kwalker at aros.net wrote:

–
– Michael Samuel

18

Well, it’s been my experience that you almost need the demo archive to
do anything useful without bogging yourself down in the lower levels of
SDL. But that was the idea, right? :slight_smile:

Yep. :slight_smile:

I’m probably going to come up with a scrolling text box widget, just to get
debug output working nicely in some of the fullscreen evironments. This is
at least three weeks out though. I want to get networking and some other
things working first.

And then we can hack it into an in-game chat feature. :slight_smile:

Hey, why not? :slight_smile:

So now we’ve got professional game programmers giving advice? We’re
unstopable. :slight_smile:

grin

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

19

Networking support is right on the border of whether it should be part of the
main SDL library or not, IMHO…

It will depend on how useful and how simple the networking support is.
We’ll see. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

20

Hi there…

Sam Lantinga wrote:

  • runs well on double/triple - buffered screens

That is something Sam might be interested in. I know he’s working on
double-buffering for SDL 9.

Double-buffering is completely supported as of SDL 0.9.6
Check out the new “testsprite” test program for an example of how to use it.

The assembler sections of SDL may be that fast. I know Sam has published
benchmarks between SDL and Prometheus, and SDL has out-run Prometheus
nearly every time.

brn and I have worked very closely to improve both SDL’s and PTC’s
blitting. In fact, SDL now uses some of the same assembly blitters
that PTC uses. The speed of PTC and SDL are now nearly comparable,
with SDL having a slight edge because it uses C rather than C++.
Some of the newer blitters in PTC may be faster than SDL in select cases,
since I haven’t optimized some of the ones PTC has.
BTW, optimizing a blitter is trivial, it just adds size to the library,
so if you need a particular case to work really fast, let me know.

As for the simple-to-use widget set for SDL, download and look at the
sdl-demo archive. That adds almost a whole new level of usefullness to SDL.

What people are asking for, menus, buttons, text widgets, etc., don’t come
pre-built with the tools in the demo archives. You can build them with the
demo libraries, in fact that’s what Maelstrom does, but there is definitely
a lack of good widgets available for use with SDL.
It’s true though, there’s a lot of other good stuff in the demos archive.
grin

I’m probably going to come up with a scrolling text box widget, just to get
debug output working nicely in some of the fullscreen evironments. This is
at least three weeks out though. I want to get networking and some other
things working first.

I want to give a big thanks to Dan Kegel of Activision for some excellent
advice on the networking code, BTW. :slight_smile: It is going to rock! :slight_smile:

Can I just make a request at this point that you split up the SDL into seperate
libraries? I know you only get for example what you request from SDL_Init(), but
I’d feel a lot more comfortable that when I write an application which only uses
the networking support, I get only the networking support, not a bunch of
other stuff hanging round unwanted in memory.

It’d also mean that you’d only have to distribute the relevant components with
your application (remember static linking isn’t an option for non GPLed code) - as
opposed to the whole library.

:slight_smile:
Peter>

See ya!
-Sam Lantinga (slouken at devolution.com)

–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/