[…]
about that. One thing you might try is getting it to
work with sdlGL.Should work with current versions of glSDL as long as it
Where do you get glSDL exactly anyway? I’ve done web searches, and looked
around the SDL webpages, but hadn’t seen any sign of it. Someone’s sure
hidden it well!-Jason
----- Original Message -----
From: david.olofson@reologica.se (David Olofson)
To:
Sent: Monday, April 15, 2002 11:13 AM
Subject: Re: [SDL] paraGUI
On Saturday 13 April 2002 18:55, Andrew Ford wrote:
How do you handle packing surfaces that aren’t powers
of two in each dimension? Widgets can potentially
have their own surfaces of the widget’s sizes.
You must have a fakie surface for the screen, I guess.
Nope, that would most probably suck, performance wise. (Well, it might
work for an application that’s specifically designed for it, but that’s
about the opposite of what glSDL is meant for. 
glSDL assumes nothing about texture size or format, but rather just tiles
them as needed to fit them into a texture. (There’s one TODO: Currently,
only one texture can be used for one surface, which puts a restriction on
surface “area”.)
For example, the fonts in Kobo Deluxe are normal SFont format fonts,
stored as wide images. glSDL splits them up into multiple rows, and then
puts the pieces back together as needed when “blitting” from the texture.
Either way, if the paragui blit-surface is retargeted
in a new backend to use glSDL, that can be handled by
detecting the pointer to the screen surface.
There is no retargeting involved when using glSDL. glSDL is an
implementation of the SDL API.
— David Olofson <david.olofson at reologica.se> wrote:
Should work with current versions of glSDL as long
as it* doesn't rely on surfaces with bigger area than the largest supported texture * doesn't blit from or within the screenI don’t think there’s a backing store for the screen,
so I don’t think this happens
Good - no problem with that then. (It would have been a performance
problem on many targets anyway.)
* doesn't try to lock the screen and access it directlyKobo deluxe is cool).
Multiplayer will be even better!
It’d be cooler if I could get past damn level 23
Well, the third round is where it starts to get real hard! I’ve been
stuck at stage 145 for a good while.
Anyway, it might be that the levels aren’t in the best order. OTOH, the
game is well balanced enough that it’s going to take some thinking and
thourough testing to change anything without making things worse. So far,
I haven’t touched the actual game, and I don’t intend to make any
significant changes, at least not to the single player mode.
Sounds to me that depending on what kind of images
used, it might
actually be pretty easy to add “native” OpenGL
support. Anything that is
wider and/or taller than 256 pixels is asking for
trouble, though.Only on certain, ahem, sucky 3D cards.
Well, yeah, but the limit can be 512 or 1024 as well - unless you’re
designing specifically for OpenGL, you will run into problems unless
you implement some form of tiling, or just stick to max 256x256 images.
(Especially if you’re trying to fool code that doesn’t even know what
OpenGL is, like glSDL is doing.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 15 April 2002 17:41, Andrew Ford wrote:
If you’re only dealing with actual textures when you
upload before a blit, isn’t it mostly a matter of
keeping a sheet of 258x258 (when necessary) textures
and setting the necessary border values?
No borders needed unless you’re doing filtered stretching.
Anyway, yeah, OPENGLBLIT could possibly be made faster that way, but only
marginally so.
The real problem is that any “blitting to the screen” has to be done by
s/w blitting into an RGBA shadow buffer, which is then (fully or
partially) downloaded to the video card, and finally rendered, with alpha
blending enabled, over the screen.
The weakest link there is the downloading, as that will frequently have
to be done without busmaster DMA, and thus, you have the same bottleneck
as with pure software rendering, PLUS the overhead of involving OpenGL,
and of course, actually using the GPU to transfer the data yet another
time.
The proper solution is to store all data on the video card, and have
OpenGL render everything as normal textures. Any hybrid that isn’t
specifically designed to operate as “procedural textures” is bound to be
dog slow, more or less.
If it’s only
the 3dfx cards that you need to do this for (I guess
you could run into 1024x1024 as well),
Right; this is a real restriction on practically any card, so the tiling
is always needed. Try running Kobo Deluxe in 1280x1024 on a card that can
do only 1024x1024 (like the G400 on Linux - although it does support
2048x2048 in h/w…). Oops, where did the framework go?
that’s
unfortunate since those drivers are going to be
getting crustier and crustier without anyone
maintaining them.
Well, if the drivers die, so does the h/w… Nothing to do with glSDL or
OPENGLBLIT or anything specifically.
What about multiple sub-blits on
one texture of maximum size when you need to blit a
large surface?
Not sure how you mean exactly, but it sounds a whole lot like what glSDL
is doing. 
It handles anything that can be chopped up and squeezed into one texture
(and it will select the smallest possible texture size), but the “tiling
across multiple textures” feature is still missing. (I’ve been hacking
other stuff lately.)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 15 April 2002 17:54, Andrew Ford wrote:
— David Olofson <david.olofson at reologica.se> wrote:
Nope, that would most probably suck, performance
wise. (Well, it might
work for an application that’s specifically designed
for it, but that’s
about the opposite of what glSDL is meant for.
I was talking about internally in your SDL_BlitSurface
replacement.
glSDL assumes nothing about texture size or format,
but rather just tiles
them as needed to fit them into a texture. (There’s
one TODO: Currently,
only one texture can be used for one surface, which
puts a restriction on
surface “area”.)
Does that mean that each “surface” is kept in a
texture, or do you copy to a scratch-texture during
each blit operation.
Either way, if the paragui blit-surface is
retargeted
in a new backend to use glSDL, that can be handled
by
detecting the pointer to the screen surface.
There is no retargeting involved when using glSDL.
glSDL is an
implementation of the SDL API.
I’m pretty sure that Alex doesn’t want OpenGL
interfering with the rest of paragui. Right now
openGL support is a separate part of the library.
Basically, I think this would mean that the glSDL
header wouldn’t get included except on the separate
paragl portions. Perhaps if someone wanted a quickie
port to opengl they could just change all the #include
“SDL.h” to #include “glSDL.h”.
Kobo deluxe is cool).
Multiplayer will be even better!
It’d be cooler if I could get past damn level 23
Well, the third round is where it starts to get
real hard! I’ve been
stuck at stage 145 for a good while.Anyway, it might be that the levels aren’t in the
best order. OTOH, the
game is well balanced enough that it’s going to take
some thinking and
thourough testing to change anything without making
things worse. So far,
I haven’t touched the actual game, and I don’t
intend to make any
significant changes, at least not to the single
player mode.
The only really difficult things I’ve run into are
those balls that explode into an arc of regular-shots.
Since they can’t be shot, you can’t do anything about
them, and there are fifty-billion of them on the
screen at a time when you assault the bases. Thirty
or fourty tries later… still no luck 
Well, yeah, but the limit can be 512 or 1024 as well
- unless you’re
designing specifically for OpenGL, you will run
into problems unless
you implement some form of tiling, or just stick to
max 256x256 images.
(Especially if you’re trying to fool code that
doesn’t even know what
OpenGL is, like glSDL is doing.
So what exactly is the trouble with tiling (other than
requiring you to have several textures and quads or a
single texture which you have to re-upload and paste
over several quads? You won’t run into any artifacts
if you set the borders correctly, will you?
(I know it’s all a pain in the ass, so I don’t blame
you for not wanting to implement it)
Andrew.> On Monday 15 April 2002 17:41, Andrew Ford wrote:
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
Okay, I get you now
Andrew.
— David Olofson <david.olofson at reologica.se> wrote:> Not sure how you mean exactly, but it sounds a whole
lot like what glSDL
is doing.It handles anything that can be chopped up and
squeezed into one texture
(and it will select the smallest possible texture
size), but the “tiling
across multiple textures” feature is still missing.
(I’ve been hacking
other stuff lately.)
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
That’s not the right function to use, but glTexSubImage2D is pretty widely
supported. Note though that the subimage has to be linear - ie, no gaps
in the memory of the source.On Mon, Apr 15, 2002 at 05:24:00PM +0200, David Olofson wrote:
(I hope I have the SDL terms correct, I’m only a
week into SDL…) For what it’s worth, I hear that the render to
texture methods are not yet as fast as glCopyTexSubImage2D(). Nvidia
says that their next driver should fix the speed issues with render to
texture and pBuffers… I don’t keep track of the status of ATI driver
quality…I’m not even sure that feature is widely available in OpenGL
implementations yet… Either way, glSDL uses SDL’s 2D blitters for
surface->surface blits; only blits to the screen are accelerated. (That
might change though, if possible and feasible.)
–
Joseph Carter No conceit in my family
Alter.net seems to have replaced one of its router with a zucchini.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020415/e6cb00ba/attachment.pgp
To sum what I was trying to get from this thread, it looks like ParaGUI (and
any other GUI toolkit for that matter) is not a good choice for an SDL &
OpenGL application where I need complex 3D rendering, (game quality) high
frame rates and a GUI that sits above the 3D display.
It looks like I’ll have to make the GUI within my application. I expected
that after all, but for a few fleeting days it looked like I found an
alternative…
-Blake
For now, perhaps. I think paragui will be able to do
it if a rendering back-end for openGL is made. I know
for a fact that paragui can be made to sit above the
rest of the application (that’s what I’m doing, except
in 2D), and I think the frame-rates should be fine if
you use bulk-blitting from the gui to the screen
(which is supported).
Andrew.
— Blake Senftner wrote:> To sum what I was trying to get from this thread, it
looks like ParaGUI (and
any other GUI toolkit for that matter) is not a good
choice for an SDL &
OpenGL application where I need complex 3D
rendering, (game quality) high
frame rates and a GUI that sits above the 3D
display.It looks like I’ll have to make the GUI within my
application. I expected
that after all, but for a few fleeting days it
looked like I found an
alternative…-Blake
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
[…]
about that. One thing you might try is getting it to
work with sdlGL.Should work with current versions of glSDL as long as it
Where do you get glSDL exactly anyway? I’ve done web searches, and
looked around the SDL webpages, but hadn’t seen any sign of it.
Someone’s sure hidden it well!
Yes indeed; deep inside the later versions of Kobo Deluxe.
I’ll try and rip it out into a separate package tonight. (Haven’t got the
lastest tree here, and I’d like to grab it from there, just ta make sure
I get the latest version.)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 15 April 2002 18:14, Jason Hoffoss wrote:
----- Original Message -----
From: “David Olofson” <david.olofson at reologica.se>
To:
Sent: Monday, April 15, 2002 11:13 AM
Subject: Re: [SDL] paraGUIOn Saturday 13 April 2002 18:55, Andrew Ford wrote:
— David Olofson <david.olofson at reologica.se> wrote:
Nope, that would most probably suck, performance
wise. (Well, it might
work for an application that’s specifically designed
for it, but that’s
about the opposite of what glSDL is meant for.I was talking about internally in your SDL_BlitSurface
replacement.
Ok… Well, it keeps the software surfaces, but only in case you should
lock and modify them. (The textures are updated automatically if you do.)
Tiling style and tile size is determined when a surface is created, and
then stored in the “TexInfo”, to avoid having that code in the main path
when you’re doing “procedural surfaces”. (As I probably will in Kobo
Deluxe eventually, BTW - the current implementation of the scrolling
radar sucks, with or without glSDL.)
glSDL assumes nothing about texture size or format,
but rather just tiles
them as needed to fit them into a texture. (There’s
one TODO: Currently,
only one texture can be used for one surface, which
puts a restriction on
surface “area”.)Does that mean that each “surface” is kept in a
texture, or do you copy to a scratch-texture during
each blit operation.
Each surface gets it’s own texture. The “TexInfo” struct keeps track of
that, as well as some other things. (In the “real” version, that stuff
should be hooked up to ‘hwdata’, I think.)
Either way, if the paragui blit-surface is
retargeted
in a new backend to use glSDL, that can be handled
by
detecting the pointer to the screen surface.
There is no retargeting involved when using glSDL.
glSDL is an
implementation of the SDL API.I’m pretty sure that Alex doesn’t want OpenGL
interfering with the rest of paragui. Right now
openGL support is a separate part of the library.
Basically, I think this would mean that the glSDL
header wouldn’t get included except on the separate
paragl portions. Perhaps if someone wanted a quickie
port to opengl they could just change all the #include
"SDL.h" to #include “glSDL.h”.
Well, that’s what the current glSDL is anyway; it’s an ugly quick hack.
It should be turned into an SDL backend, so that applications can use it
even without being recompiled. Applications in general shouldn’t even be
aware of the existence of glSDL.
Kobo deluxe is cool).
Multiplayer will be even better!
It’d be cooler if I could get past damn level 23
Well, the third round is where it starts to get
real hard! I’ve been
stuck at stage 145 for a good while.Anyway, it might be that the levels aren’t in the
best order. OTOH, the
game is well balanced enough that it’s going to take
some thinking and
thourough testing to change anything without making
things worse. So far,
I haven’t touched the actual game, and I don’t
intend to make any
significant changes, at least not to the single
player mode.The only really difficult things I’ve run into are
those balls that explode into an arc of regular-shots.
Yeah, those are problably the hardest enemies around.
Since they can’t be shot,
They can be shot; you just have to figure out how to get in range
without triggering them…
you can’t do anything about
them, and there are fifty-billion of them on the
screen at a time when you assault the bases. Thirty
or fourty tries later… still no luck
Hint: Diagonals!
Well, yeah, but the limit can be 512 or 1024 as well
- unless you’re
designing specifically for OpenGL, you will run
into problems unless
you implement some form of tiling, or just stick to
max 256x256 images.
(Especially if you’re trying to fool code that
doesn’t even know what
OpenGL is, like glSDL is doing.So what exactly is the trouble with tiling (other than
requiring you to have several textures and quads or a
single texture which you have to re-upload and paste
over several quads? You won’t run into any artifacts
if you set the borders correctly, will you?
There is no problem, really; I just haven’t implemented it yet.
And you don’t need to set the borders at all, unless you’re using texture
filtering… (Which cannot be used anyway, as it simply doesn’t work
correctly for anything but sprites.)
BTW, note that Kobo Deluxe on glSDL does not use texture filtering. The
reason why it might look like it is the image scaling plugins that scale
all graphics to the right resolution at load time. (Works just like in
normal SDL 2D mode.)
(I know it’s all a pain in the ass, so I don’t blame
you for not wanting to implement it)
Well, it’s a bit hairy, but that doesn’t mean I don’t want to implement
it… It will be done eventually, just as the transforming into a real
backend, blitting from/within the screen and other stuff.
I just have too many things going on… heh
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 15 April 2002 18:41, Andrew Ford wrote:
On Monday 15 April 2002 17:41, Andrew Ford wrote:
Interesting. I’ll have to look at the source and give
it a try when I get a chance.
Andrew.
— David Olofson <david.olofson at reologica.se> wrote:> On Monday 15 April 2002 18:41, Andrew Ford wrote:
— David Olofson <david.olofson at reologica.se>
wrote:On Monday 15 April 2002 17:41, Andrew Ford wrote:
Nope, that would most probably suck, performance
wise. (Well, it might
work for an application that’s specifically
designedfor it, but that’s
about the opposite of what glSDL is meant for.
I was talking about internally in your
SDL_BlitSurface
replacement.Ok… Well, it keeps the software surfaces, but only
in case you should
lock and modify them. (The textures are updated
automatically if you do.)Tiling style and tile size is determined when a
surface is created, and
then stored in the “TexInfo”, to avoid having that
code in the main path
when you’re doing “procedural surfaces”. (As I
probably will in Kobo
Deluxe eventually, BTW - the current implementation
of the scrolling
radar sucks, with or without glSDL.)glSDL assumes nothing about texture size or
format,but rather just tiles
them as needed to fit them into a texture.
(There’sone TODO: Currently,
only one texture can be used for one surface,
whichputs a restriction on
surface “area”.)Does that mean that each “surface” is kept in a
texture, or do you copy to a scratch-texture
during
each blit operation.Each surface gets it’s own texture. The “TexInfo”
struct keeps track of
that, as well as some other things. (In the “real”
version, that stuff
should be hooked up to ‘hwdata’, I think.)Either way, if the paragui blit-surface is
retargeted
in a new backend to use glSDL, that can be
handledby
detecting the pointer to the screen surface.
There is no retargeting involved when using
glSDL.glSDL is an
implementation of the SDL API.I’m pretty sure that Alex doesn’t want OpenGL
interfering with the rest of paragui. Right now
openGL support is a separate part of the library.
Basically, I think this would mean that the glSDL
header wouldn’t get included except on the
separate
paragl portions. Perhaps if someone wanted a
quickie
port to opengl they could just change all the
#include
“SDL.h” to #include “glSDL.h”.Well, that’s what the current glSDL is anyway; it’s
an ugly quick hack.It should be turned into an SDL backend, so that
applications can use it
even without being recompiled. Applications in
general shouldn’t even be
aware of the existence of glSDL.Kobo deluxe is cool).
Multiplayer will be even better!
It’d be cooler if I could get past damn level
23
Well, the third round is where it starts to
getreal hard! I’ve been
stuck at stage 145 for a good while.Anyway, it might be that the levels aren’t in
thebest order. OTOH, the
game is well balanced enough that it’s going to
takesome thinking and
thourough testing to change anything without
makingthings worse. So far,
I haven’t touched the actual game, and I don’t
intend to make any
significant changes, at least not to the single
player mode.The only really difficult things I’ve run into are
those balls that explode into an arc of
regular-shots.Yeah, those are problably the hardest enemies
around.Since they can’t be shot,
They can be shot; you just have to figure out how
to get in range
without triggering them…you can’t do anything about
them, and there are fifty-billion of them on the
screen at a time when you assault the bases.
Thirty
or fourty tries later… still no luckHint: Diagonals!
Well, yeah, but the limit can be 512 or 1024 as
well
- unless you’re
designing specifically for OpenGL, you will
runinto problems unless
you implement some form of tiling, or just stick
tomax 256x256 images.
(Especially if you’re trying to fool code that
doesn’t even know what
OpenGL is, like glSDL is doing.So what exactly is the trouble with tiling (other
than
requiring you to have several textures and quads
or a
single texture which you have to re-upload and
paste
over several quads? You won’t run into any
artifacts
if you set the borders correctly, will you?There is no problem, really; I just haven’t
implemented it yet.And you don’t need to set the borders at all, unless
you’re using texture
filtering… (Which cannot be used anyway, as it
simply doesn’t work
correctly for anything but sprites.)BTW, note that Kobo Deluxe on glSDL does not use
texture filtering. The
reason why it might look like it is the image
scaling plugins that scale
all graphics to the right resolution at load time.
(Works just like in
normal SDL 2D mode.)(I know it’s all a pain in the ass, so I don’t
blame
you for not wanting to implement it)Well, it’s a bit hairy, but that doesn’t mean I
don’t want to implement
it… It will be done eventually, just as the
transforming into a real
backend, blitting from/within the screen and other
stuff.I just have too many things going on… heh
=== message truncated ===
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
Well, glSDL uses glTexSubImage2D() - I was thinking about blitting into
textures using the GPU. (H/w accelerated procedural textures, that is.)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 16 April 2002 07:11, Joseph Carter wrote:
On Mon, Apr 15, 2002 at 05:24:00PM +0200, David Olofson wrote:
(I hope I have the SDL terms correct, I’m only a
week into SDL…) For what it’s worth, I hear that the render to
texture methods are not yet as fast as glCopyTexSubImage2D().
Nvidia says that their next driver should fix the speed issues with
render to texture and pBuffers… I don’t keep track of the status
of ATI driver quality…I’m not even sure that feature is widely available in OpenGL
implementations yet… Either way, glSDL uses SDL’s 2D blitters for
surface->surface blits; only blits to the screen are accelerated.
(That might change though, if possible and feasible.)That’s not the right function to use, but glTexSubImage2D is pretty
widely supported. Note though that the subimage has to be linear - ie,
no gaps in the memory of the source.
yes I know this is old reply but I’ve been getting active in some devel
with paragui+opengl so I figured I’d respond
There’s a couple q’s in here for folks who understand glSDL well g
on glSDL-0.3:
SDL_Surface *SDL_GetVideoSurface(void);
change to:
SDL_Surface *glSDL_GetVideoSurface(void);
on glSDL + paragui:
Display doesn’t render properly but it compiles properly. Runs
fine too with some boggles I’m still chasing down. Just doesn’t render
properly. Does glSDL have problem with surfaces that undergo changes?
OPENGLBLIT may be an ugly hack but it was useful… but there should be a
better way to do things (and it seems gone now
There’s a real shortage of useable OpenGL-supporting GUIs and I don’t know
of any that work under SDL and are usable…
G’day, eh?
- Teunis
Teunis Peters wrote:
There’s a real shortage of useable OpenGL-supporting GUIs and I don’t know
of any that work under SDL and are usable…G’day, eh?
- Teunis
I’m working on an SDL GUI library that will transparently run with or without openGL…
I’ll announce it when it’s ready for general consumption (within a month at most).–
-==-
Jon Atkins
http://jcatki.2y.net/
Perhaps you should give libUFO a try.
It is (better: should be) platform independent and has a SDL backend.On Thursday 06 June 2002 04:29, Teunis Peters wrote:
There’s a real shortage of useable OpenGL-supporting GUIs and I don’t know
of any that work under SDL and are usable…
–
Johannes Schmidt
< http://libufo.sourceforge.net > Your widget set for OpenGL
I haven’t seen anything that matches paragui for
features and usability (although I haven’t looked too
hard on the usability front), and there’s been a lot
of development effort put into paragui, so I don’t
expect I will for a while. Paragui also continues to
get better and the next major version should be pretty
cool. I’m confident we can successfully port paragui
to an OpenGL rendering backend.
Andrew.
— Johannes Schmidt wrote:> On Thursday 06 June 2002 04:29, Teunis Peters wrote:
There’s a real shortage of useable
OpenGL-supporting GUIs and I don’t know
of any that work under SDL and are usable…Perhaps you should give libUFO a try.
It is (better: should be) platform independent and
has a SDL backend.–
Johannes Schmidt< http://libufo.sourceforge.net > Your widget set
for OpenGL
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
There’s a real shortage of useable OpenGL-supporting GUIs and I don’t know
of any that work under SDL and are usable…Perhaps you should give libUFO a try.
It is (better: should be) platform independent and has a SDL backend.
2 things:
- paragui nice g. I like it’s design anyways…
and 2: libufo breaks nicely on my computer. (or usdl does. There aren’t
any libufo examples in the kit so I have no idea if it works or not)
Any idea what this message means?
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegate
UWidget[0,0;640x480,invalid] has no ui delegate
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegate
UWidget[0,0;640x480,invalid] has no ui delegate
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegate
Doesn’t make any sense to me other than it fills up scrollback buffer.
Umm hope this helps, but I probably won’t check out libufo any further as
it doesn’t really suit what I’m building… (yes actually paragui does -
kind of. Bits do anyways
G’day, eh?
- TeunisOn Thu, 6 Jun 2002, Johannes Schmidt wrote:
On Thursday 06 June 2002 04:29, Teunis Peters wrote:
Perhaps you should give libUFO a try.
It is (better: should be) platform independent and has a SDL backend.2 things:
- paragui nice g. I like it’s design anyways…
The libUFO design is sympathized with Java/Swing™.
If you don’t like it, don’t use it.
and 2: libufo breaks nicely on my computer.
Sorry, I do not get much feedback and I can only say that it works perfectly
here.
(or usdl does. There aren’t
any libufo examples in the kit so I have no idea if it works or not)
There are some (very old) test files in the usdl/test directory and 8
downloadable tutorials at:
http://libufo.sourceforge.net/tutorial/
Any idea what this message means?
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegate
UWidget[0,0;640x480,invalid] has no ui delegate
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegate
UWidget[0,0;640x480,invalid] has no ui delegate
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegate
Every widget has a UI class which is responsible for drawing (and some event
processing).
These error messages indicate that either the UI classes weren’t registered
at the UI manager or the widgets weren’t correctly validated.
Perhaps you could send me some system informations (compiler, OS, …) and
your ufo/usdl version numbers (privately, as there is enough other spam on
this list).
Thanks.On Thursday 06 June 2002 11:40, Teunis Peters wrote:
On Thu, 6 Jun 2002, Johannes Schmidt wrote:
–
Johannes Schmidt
< http://libufo.sourceforge.net > Your widget set for OpenGL
Hehe. Ok, I found the bug.
There were broken links at the usdl download page.
You have downloaded usdl-0.4.1.
Thanks for your testing :)> On Thursday 06 June 2002 11:40, Teunis Peters wrote:
and 2: libufo breaks nicely on my computer.
(or usdl does. There aren’t
any libufo examples in the kit so I have no idea if it works or not)
–
Johannes Schmidt
< http://libufo.sourceforge.net > Your widget set for OpenGL
This may be a bit off, but does anyone know of a decent GUI kit
for SDL (or OpenGL) purely written in C?
I understand it is very natural to select C++ as the language
for GUI kits, but I’d prefer something along the line in
the spirit of SDL, and C makes foreign language interfacing
much easier.
Regards,
.paul.On Thu, Jun 06, 2002 at 11:58:46AM +0200, Johannes Schmidt wrote:
On Thursday 06 June 2002 11:40, Teunis Peters wrote:
On Thu, 6 Jun 2002, Johannes Schmidt wrote:
Perhaps you should give libUFO a try.
It is (better: should be) platform independent and has a SDL backend.2 things:
- paragui nice g. I like it’s design anyways…
The libUFO design is sympathized with Java/Swing™.
If you don’t like it, don’t use it.and 2: libufo breaks nicely on my computer.
Sorry, I do not get much feedback and I can only say that it works perfectly
here.(or usdl does. There aren’t
any libufo examples in the kit so I have no idea if it works or not)
There are some (very old) test files in the usdl/test directory and 8
downloadable tutorials at:
http://libufo.sourceforge.net/tutorial/Any idea what this message means?
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegate
UWidget[0,0;640x480,invalid] has no ui delegate
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegate
UWidget[0,0;640x480,invalid] has no ui delegate
UButton[4,0;0x0,invalid] has no ui delegate
ULabel[“label 1” 0,0;0x0,invalid] has no ui delegateEvery widget has a UI class which is responsible for drawing (and some event
processing).These error messages indicate that either the UI classes weren’t registered
at the UI manager or the widgets weren’t correctly validated.Perhaps you could send me some system informations (compiler, OS, …) and
your ufo/usdl version numbers (privately, as there is enough other spam on
this list).Thanks.
Johannes Schmidt
< http://libufo.sourceforge.net > Your widget set for OpenGL
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl