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?
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.
Better solution.
Make a GTK+ widget which a SDL buffer can render into. Thus we avoid the need to
port GTK to SDL, and rather, we port SDL to GTK. This would be much easier than the
former, and doesn’t require anything other than creation of a simple widget. You
would be able to build your UI around the SDL buffer widget.
Anyone who wants to use widgets within the SDL window is nuts. Most of the modern
GUI toolkits aren’t really suited to the sort of graphical interface you’d expect
in a game (eg. how does say the Descent/Doom/Quake/you name it menu interface
compare to a conventional gui? Which toolkit would you use to achieve the same
effect in your applications? Wherever it is, I want it! Such a toolkit would be
insane… Imagine applications looking like the Quake menu interface…
Peter
Networking support is right on the border of whether it should be part of the
main SDL library or not, IMHO…
That’s why I advocate splitting it into a seperate library. It is an entirely
independant non-interlinked component of the SDL, so we should treat it as thus.
Peter> On Thu, Oct 29, 1998 at 09:01:47PM -0700, kwalker at aros.net wrote:
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.
Actually, the way Sam has been doing the demo library, it would be very
easy to only include the parts you need. Most of it isn’t even really
a library, more like object code that can be linked into your code.
Plus, (under GCC at least) when you link against a library, you only
get the code you ask for, not everything in the library file.
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.
Well, as long as the code is LGPL, you could. LGPL can be included
(compiled in or linked) into non-free code, provided that the source
for the LGPL objects is available under GPL rules.On 30 Oct, Peter Hawkins wrote:
Anyone who wants to use widgets within the SDL window is nuts. Most of the modern
GUI toolkits aren’t really suited to the sort of graphical interface you’d expect
in a game (eg. how does say the Descent/Doom/Quake/you name it menu interface
compare to a conventional gui? Which toolkit would you use to achieve the same
effect in your applications? Wherever it is, I want it! Such a toolkit would be
insane… Imagine applications looking like the Quake menu interface…
Peter
Networking support is right on the border of whether it should be part of the
main SDL library or not, IMHO…
That’s why I advocate splitting it into a seperate library. It is an entirely
independant non-interlinked component of the SDL, so we should treat it as thus.
how about it??On Fri, 30 Oct 1998, Peter Hawkins 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)
Well, like Sam, Michael, and I’ve mentioned before, SDL is already
split into the core, and the demo “libraries” (Demo libraries aren’t
really libraries, just linkable or compilable code) which can be
compiled in and linked in on an ass-needed basis, rather than
all-or-nothing.
Well, honestly now, how often are you going to use libSDLinput without
libSDLgraphics? Or the other way around? libSDLnetwork is going to be
a demo library, unless I’m COMPLETELY missing Sam’s inferrences. The
sound code right now is very simple wave-playing (Which doesn’t take
up more than a few K) or MikMOD (Which can be compiled in if needed).
libSDLmidi will have to wait, if we want Sam to do it, but if someone
else wants to tackle it themselves, I would be more than happy to
contribute all I can. Personally, I think using MikMOD will be smarter
on non-wavetable soundcards, but I can see the allure of MIDI to a lot
of programmers.
how about it??
Just so you (And the rest of the list) know I’m not trying to harp on
you or say your idea isn’t a good one. It IS a good idea, however SDL
already does most of what you’ve outlined (within reason).
Well, like Sam, Michael, and I’ve mentioned before, SDL is already
split into the core, and the demo “libraries” (Demo libraries aren’t
really libraries, just linkable or compilable code) which can be
compiled in and linked in on an ass-needed basis, rather than
all-or-nothing.
Well, honestly now, how often are you going to use libSDLinput without
libSDLgraphics? Or the other way around? libSDLnetwork is going to be
a demo library, unless I’m COMPLETELY missing Sam’s inferrences. The
sound code right now is very simple wave-playing (Which doesn’t take
up more than a few K) or MikMOD (Which can be compiled in if needed).
libSDLmidi will have to wait, if we want Sam to do it, but if someone
else wants to tackle it themselves, I would be more than happy to
contribute all I can. Personally, I think using MikMOD will be smarter
on non-wavetable soundcards, but I can see the allure of MIDI to a lot
of programmers.
I’ve heard that timidity might be a good midi solution as a library, but
I’m not sure, I’ll have to check.On Fri, 30 Oct 1998 kwalker at aros.net wrote:
On 30 Oct, Scott Stone 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)
I’m very happy to see so much people speacking about one subject. That was
exactly the purprose I expected while posting the mail
After all thoses discussion, I htink
I agree GTK is too heavy for games.
I think Sam has better to do (networking… ) than widget.
So I propose that :
We continue to give ideas.
We begin to create a simple SDL_widget.h
All the programmer who wants widget wil have to do is an include
"SDL_widget.h"
The first things I propose is a pixmap based font engine.
The user will have a .fnt file, and can do a SDL_WG_FontLoad(something.fnt);
After that, I don’t really knwo at which level the Widget should be.
Just discuss a bit more about that
For the font, I propse an complete implementation of the ASCII code.
I propose the following format :===
Format definition for .fnt (version 1)
font width [1 byte]
font height [1 byte]
font bpp [1 byte]
font data [255widthheight*bpp/8]
Thankls for all thoses good ideas guys,
Just go on
Bets regards,
–
Stephane Magnenat
stephane.magnenat at urbanet.ch
The first things I propose is a pixmap based font engine.
The user will have a .fnt file, and can do a SDL_WG_FontLoad(something.fnt);
After that, I don’t really knwo at which level the Widget should be.
Just discuss a bit more about that
For the font, I propse an complete implementation of the ASCII code.
I propose the following format :
Format definition for .fnt (version 1)
font width [1 byte]
font height [1 byte]
font bpp [1 byte]
font data [255widthheight*bpp/8]
There is a True Type Font library floating around. As long as we’re
using fonts, it might as well be the best. You just need the library
to render the fonts once, then generate the glyphs (sprites) and off
you go.
As for the buttons I think that ImLib could generate very descent
buttons easilly.
The above solutions have one drawback, they are slow. But have no
fear, I have a solution. (well sort of since I won’t actually be doing
it ;). Have a two-pass program.
First pass, a program reads your GUI needs and renders everything you
will need. Second pass, your program uses the resulting graphics.
The above is static, but as long as you can’t resize your widgets, it
should be all you need.
Thoughs on why this would be bad ?
Phil ‘Nothing is impossible to the man who doesn’t have to do it himself.’
The first things I propose is a pixmap based font engine.
The user will have a .fnt file, and can do a SDL_WG_FontLoad(something.fnt);
After that, I don’t really knwo at which level the Widget should be.
Just discuss a bit more about that
For the font, I propse an complete implementation of the ASCII code.
I propose the following format :
Format definition for .fnt (version 1)
font width [1 byte]
font height [1 byte]
font bpp [1 byte]
font data [255widthheight*bpp/8]
There is a True Type Font library floating around. As long as we’re
using fonts, it might as well be the best. You just need the library
to render the fonts once, then generate the glyphs (sprites) and off
you go.
As for the buttons I think that ImLib could generate very descent
buttons easilly.
The above solutions have one drawback, they are slow. But have no
fear, I have a solution. (well sort of since I won’t actually be doing
it ;). Have a two-pass program.
First pass, a program reads your GUI needs and renders everything you
will need. Second pass, your program uses the resulting graphics.
The above is static, but as long as you can’t resize your widgets, it
should be all you need.
Thoughs on why this would be bad ?
aside from being a pain, no. It’s too much work - if you’re going to load
premade images anyway, just make them with The Gimp or whatever yourself
and then load them as needed.On Fri, 30 Oct 1998, Lavoie Philippe 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)
Anyone who wants to use widgets within the SDL window is nuts. Most of the
modern
GUI toolkits aren’t really suited to the sort of graphical interface you’d
expect
in a game (eg. how does say the Descent/Doom/Quake/you name it menu interface
compare to a conventional gui? Which toolkit would you use to achieve the
same
effect in your applications? Wherever it is, I want it! Such a toolkit would
be
insane… Imagine applications looking like the Quake menu interface…
Umm, sorry dude, but there is more in the game world than just quake/doom
style games. Ever played Command&Conquer ?? This uses a GUI kit inside the
frame buffer and works quite well.
/devOn 30-Oct-98 Peter Hawkins wrote:
// David E. Vandewalle |Weinberg’s Law: If builders built
// vandewal at skyblue.com | buildings the way programmers wrote
// david.e.vandewalle at lmco.com | programs, then thefirst woodpecker that
// | came along would destroy civilization.
There is a True Type Font library floating around. As long as we’re
using fonts, it might as well be the best. You just need the library
to render the fonts once, then generate the glyphs (sprites) and off
you go.
This is probably what I’d do. I installed FreeType specifically so I
could use it with SDL. But I have concerns about portability. I know
Win32 has its own TrueType rendering methods, but I don’t know how to
call those from SDL yet.
As for the buttons I think that ImLib could generate very descent
buttons easilly.
Yeah, but ImLib isn’t portable. It’d be fine if all you wanted to do was
run it on Linux, but I’ve got unenlightened friends of mine (Windows
users) who I’d like to be able to use my games.
The above solutions have one drawback, they are slow. But have no
fear, I have a solution. (well sort of since I won’t actually be doing
it ;). Have a two-pass program.
No, slow is watching Diablo load off a 4x CD-ROM.
First pass, a program reads your GUI needs and renders everything you
will need. Second pass, your program uses the resulting graphics.
The above is static, but as long as you can’t resize your widgets, it
should be all you need.
Problem with that is it’ll gobble up memory. How much depends on how
many graphics your game uses.
There is a True Type Font library floating around. As long as we’re
using fonts, it might as well be the best. You just need the library
to render the fonts once, then generate the glyphs (sprites) and off
you go.
This is probably what I’d do. I installed FreeType specifically so I
could use it with SDL. But I have concerns about portability. I know
Win32 has its own TrueType rendering methods, but I don’t know how to
call those from SDL yet.
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?
I was talking about GUIs for editors etc, and outside the game. (i.e. in
paused mode or whatever), inside the game only something like N(or others
in its genre) would be appropriate(ability to control cpu load, interleave
objects with game etc).
have you ever people seen the GUI system in crack.com’s (RIP…) ABUSE?
have you seen the window dragging, the editor menu’s etc? no?
check it out. the source is available. i think the license was free
enough to allow just taking it and porting it to SDL.
www.crack.com (i don’t know if this site is still running, as
crack went out of bussiness)
the source is about 2.5M and maybe it would be good to look into
the golgotha source (~30M) which i think has some neat gui too.
have you ever people seen the GUI system in crack.com’s (RIP…) ABUSE?
have you seen the window dragging, the editor menu’s etc? no?
check it out. the source is available. i think the license was free
enough to allow just taking it and porting it to SDL.
www.crack.com (i don’t know if this site is still running, as
crack went out of bussiness)
the source is about 2.5M and maybe it would be good to look into
the golgotha source (~30M) which i think has some neat gui too.
–tomaasz
Ok, I just downloaded it and I’m compiling it, I’ll look into the source
code to see if we can get interessant things.–
Stephane Magnenat
stephane.magnenat at urbanet.ch
