paraGUI

Johannes Schmidt offered a link to ParaGUI in response to the “How to open a
dialog box” question:

http://www.paragui.org

So I just checked it out, and it looks quite good. I tried to register into
their site, but got no email password response. Reading their mailing list
archives seems to show an open source project capable of disappearing from
lack of interest.

After downloading their 1.0.1 version, I’ve very impressed. Impressed to the
point of not understanding how an apparently high quality system like this
could have a lack of interest.

Does anyone here have any experience with it? If not, do you know anyone
that I could contact that has? I’m specifically interested in OpenGL and
ParaGUI together, plus all the nice features of SDL, of course!

-Blake

I haven’t used it much under openGL yet, but in
general paragui is quite nice to work with and it has
a bunch of widgets which are all customizable. It’s
also themable which is nice if you want to give your
application a custom look. Since it’s C++, I’d prefer
to see it under a license which makes static linkage
easier, but such is life I guess :slight_smile:

Andrew.

— Blake Senftner wrote:> Johannes Schmidt offered a link to ParaGUI in

response to the “How to open a
dialog box” question:

http://www.paragui.org

So I just checked it out, and it looks quite good. I
tried to register into
their site, but got no email password response.
Reading their mailing list
archives seems to show an open source project
capable of disappearing from
lack of interest.

After downloading their 1.0.1 version, I’ve very
impressed. Impressed to the
point of not understanding how an apparently high
quality system like this
could have a lack of interest.

Does anyone here have any experience with it? If
not, do you know anyone
that I could contact that has? I’m specifically
interested in OpenGL and
ParaGUI together, plus all the nice features of SDL,
of course!

-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

Johannes Schmidt offered a link to ParaGUI in response to the “How to open a
dialog box” question:

http://www.paragui.org
[…]

Does anyone here have any experience with it? If not, do you know anyone
that I could contact that has? I’m specifically interested in OpenGL and
ParaGUI together, plus all the nice features of SDL, of course!

I’ve used it just a little bit. It works quite well and I considered
stepping forward to maintain it. Stopped by lack of time.On Thu, Apr 11, 2002 at 01:34:20PM -0700, Blake Senftner wrote:


Joseph Carter Have chainsaw will travel

Actually, I think I’ll wait for potato to be finalised before
installing debian.
That should be soon, I’m hoping. :slight_smile:
Endy: You obviously know very little about Debian.

-------------- 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/20020412/ef37794c/attachment.pgp

Andrew & Joseph,

Have you seen any information about ParaGL, the OpenGL extension for
ParaGUI? For my purposes I need to have high frame rate OpenGL rendering,
and depending upon how ParaGL handles the interaction between widgets and GL
rendering it could be fine or very slow. Thus far I’ve only seen mailing
list archive references to the existance of this ParaGL extension, but I can
locate nothing beyond that.

Also, attempts to join their mailing lists get bounced. Any idea what’s up
with that? I get this error message in my bounced mail when I try to join
any of their mailing lists:

dev-subscribe at paragui.ostdev.net
SMTP error from remote mailer after RCPT
TO::
host paragui.ostdev.net [64.125.133.60]: 553 sorry, that domain isn’t in
my list of allowed rcpthosts (#5.7.1)

Did their domain cease?

Sam, sorry to fill your mailing list with these ParaGUI messages. I’m just
trying to get an open line of communication with them.

-Blake

Just in case you haven’t already found it in the news section:
http://www.bms-austria.com/projects/paragui/modules.php?name=News&file=article&sid=14

paragui is moving to savannaOn Friday 12 April 2002 16:50, Blake Senftner wrote:

Also, attempts to join their mailing lists get bounced. Any idea what’s up
with that? I get this error message in my bounced mail when I try to join
any of their mailing lists:

dev-subscribe at paragui.ostdev.net
SMTP error from remote mailer after RCPT
TO::
host paragui.ostdev.net [64.125.133.60]: 553 sorry, that domain isn’t
in my list of allowed rcpthosts (#5.7.1)

Did their domain cease?


Johannes Schmidt

< http://libufo.sourceforge.net > Your widget set for OpenGL

Unfortunately, I haven’t used paraGL for a while. I
think you can get it in the downloads/source downloads
section on www.paragui.org. I believe there was also
some talk of making a target branch specifically for
openGL, but I don’t think much work took place on it.
The frame-rates should be decent, though, as paragui
includes a bulk-blit mechanism for blitting the entire
gui on a per-frame basis. I think it uses the SDL
openGL blit mechanism, were there still complaints
about that. One thing you might try is getting it to
work with sdlGL. You have a seperate package for
that, don’t you david (I’m thinking of the right, guy
aren’t I? Kobo deluxe is cool). As far as I know all
the blit operations in paragui use a function
PG_Draw::BlitSurface, which calls SDL_BlitSurface, in
which case perhaps that wouldn’t be too tough to
change. I’m interested in being able to use it for
OpenGL too.

Andrew.

— Blake Senftner wrote:> Andrew & Joseph,

Have you seen any information about ParaGL, the
OpenGL extension for
ParaGUI? For my purposes I need to have high frame
rate OpenGL rendering,
and depending upon how ParaGL handles the
interaction between widgets and GL
rendering it could be fine or very slow. Thus far
I’ve only seen mailing
list archive references to the existance of this
ParaGL extension, but I can
locate nothing beyond that.

Also, attempts to join their mailing lists get
bounced. Any idea what’s up
with that? I get this error message in my bounced
mail when I try to join
any of their mailing lists:

dev-subscribe at paragui.ostdev.net
SMTP error from remote mailer after RCPT
TO::
host paragui.ostdev.net [64.125.133.60]: 553
sorry, that domain isn’t in
my list of allowed rcpthosts (#5.7.1)

Did their domain cease?

Sam, sorry to fill your mailing list with these
ParaGUI messages. I’m just
trying to get an open line of communication with
them.

-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

Why do you think I wanted to take over maintenance of ParaGUI? I
specifically want that abomination known as OPENGLBLIT to die a horrible
death.

I certainly hope Sam plans to remove it in 1.3 altogether. I won’t use
ParaGUI in OpenGL until this is fixed and nobody else should either.
Since nearly everything I write is OpenGL as it is, ParaGUI is essentially
crippled because it uses the single most retarded thing to ever be added
to SDL, ever. (Sorry Sam, but it really is a Bad Thing™!)On Sat, Apr 13, 2002 at 09:55:35AM -0700, Andrew Ford wrote:

Unfortunately, I haven’t used paraGL for a while. I
think you can get it in the downloads/source downloads
section on www.paragui.org. I believe there was also
some talk of making a target branch specifically for
openGL, but I don’t think much work took place on it.
The frame-rates should be decent, though, as paragui
includes a bulk-blit mechanism for blitting the entire
gui on a per-frame basis. I think it uses the SDL
openGL blit mechanism, were there still complaints
about that.


Joseph Carter You expected a coherent reply?

  • bma is a yank
  • Knghtbrd is a Knghtbrd
  • dhd is also a yank
  • Espy is evil
  • Knghtbrd believes Espy

-------------- 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/20020413/d7a3c4fd/attachment.pgp

I certainly hope Sam plans to remove it in 1.3 altogether.

Yes, SDL_OPENGLBLIT will not be in the SDL 1.3 API.

-Sam Lantinga, Software Engineer, Blizzard Entertainment
> Why do you think I wanted to take over maintenance of ParaGUI? I > specifically want that abomination known as OPENGLBLIT to die a horrible > death. > > I certainly hope Sam plans to remove it in 1.3 altogether. I won't use > ParaGUI in OpenGL until this is fixed and nobody else should either. > Since nearly everything I write is OpenGL as it is, ParaGUI is essentially > crippled because it uses the single most retarded thing to ever be added > to SDL, ever. (Sorry Sam, but it really is a Bad Thing(TM)!)

Joseph!

You have NO right to judge that way about ParaGUI only because it has
the ability to use OPENGLBLIT.

Thats it.

AlexAm Sam, 2002-04-13 um 20.09 schrieb Joseph Carter:

Unfortunately, I haven’t used paraGL for a while. I
think you can get it in the downloads/source downloads
section on www.paragui.org. I believe there was also
some talk of making a target branch specifically for
openGL, but I don’t think much work took place on it.
The frame-rates should be decent, though, as paragui
includes a bulk-blit mechanism for blitting the entire
gui on a per-frame basis. I think it uses the SDL
openGL blit mechanism, were there still complaints
about that.

Why do you think I wanted to take over maintenance of ParaGUI? I
specifically want that abomination known as OPENGLBLIT to die a horrible
death.

Aaaah! This is exactly the type of key information that I’ve been looking
for.

So, Joseph, are you going to become the ParaGUI maintainer?

Anyone care to explain exactly how is OPENGLBLIT implemented less than
optimal? I just glanced at the logic from SDL_video.c, and it looks like a
texture object is being used rather than something awful like
glCopyPixels(). Does it just need to be updated to keep a single texture
object per SDL surface around and update via glCopyTexSubImage2D()? (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…

-Blake

Hi Alex,
I don’t think he was critisizing paragui
specifically, just openglblit. Has anyone tried using
glsdl with paragui yet? I’ve used the OpenGL modes in
kobo deluxe and it seems pretty quick. And would
somebody have to do more than re-target the PG_Draw
functions to be able to blit directly to OpenGL? On a
side note, how about adding a function in the physfs
wrapper that returns a vector< string > for the
directory entries, instead of the awfulness that is
char **? I can write that if you think that’s
reasonable.

Andrew

— Alexander Pipelka wrote:> Am Sam, 2002-04-13 um 20.09 schrieb Joseph Carter:

> Why do you think I wanted to take over maintenance of ParaGUI? I > specifically want that abomination known as OPENGLBLIT to die a horrible > death. > > I certainly hope Sam plans to remove it in 1.3 altogether. I won't use > ParaGUI in OpenGL until this is fixed and nobody else should either. > Since nearly everything I write is OpenGL as it is, ParaGUI is essentially > crippled because it uses the single most retarded thing to ever be added > to SDL, ever. (Sorry Sam, but it really is a Bad Thing(TM)!)

Joseph!

You have NO right to judge that way about ParaGUI
only because it has
the ability to use OPENGLBLIT.

Thats it.

Alex


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax

Ability? If you desire to use OpenGL with it, OPENGLBLIT IS A REQUIREMENT
which DOES NOT EVEN WORK FOR EVERYBODY.

It’s a bad feature. No OpenGL support at all is better than OPENGLBLIT
because then at least nobody will pretend that it actually works. With
OPENGLBLIT, it may or may not work and costs you something close to 40% of
your graphics card’s performance. That is unacceptable. So yes I judge
it as useless for practical applications. Moreover I judge it as a bad
implementation used as a crutch by people who can’t or won’t learn how to
use OpenGL properly.On Sat, Apr 13, 2002 at 08:29:42PM +0200, Alexander Pipelka wrote:

> Why do you think I wanted to take over maintenance of ParaGUI? I > specifically want that abomination known as OPENGLBLIT to die a horrible > death. > > I certainly hope Sam plans to remove it in 1.3 altogether. I won't use > ParaGUI in OpenGL until this is fixed and nobody else should either. > Since nearly everything I write is OpenGL as it is, ParaGUI is essentially > crippled because it uses the single most retarded thing to ever be added > to SDL, ever. (Sorry Sam, but it really is a Bad Thing(TM)!)

Joseph!

You have NO right to judge that way about ParaGUI only because it has
the ability to use OPENGLBLIT.

Thats it.


Joseph Carter glDisable (DX8_CRAP);

damn, the autonomous mouse movement starts usually after I use a
mouse button
don’t use a mouse button then :slight_smile:
yeah, right :slight_smile:

-------------- 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/20020414/fca93b11/attachment.pgp

Break out the champaigne! ;)On Sat, Apr 13, 2002 at 11:27:38AM -0700, Sam Lantinga wrote:

I certainly hope Sam plans to remove it in 1.3 altogether.

Yes, SDL_OPENGLBLIT will not be in the SDL 1.3 API.


Joseph Carter Don’t feed the sigs

  • Omnic looks at his 33.6k link and then looks at Joy
  • Mercury cuddles his cable modem… (=:]

-------------- 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/20020414/408c47cb/attachment.pgp

Likely not. I really haven’t the time it’d take to do a good job of
maintaining it. Especially given that I simply could not allow myself to
ignore the OPENGLBLIT problem. I would feel obligated to fix that on the
same day I took over maintenance. While I could do it (it really
shouldn’t be hard, though it requires abstracting how things get drawn a
bit), it’d probably take me stopping other projects for a day or two while
I pound a re-implementation into shape. Plus then because of backwards
compatibility I would have to make the OPENGLBLIT mode still work, want to
or not. There are also a couple of minor buglets I know of that’d need
fairly prompt attention if they haven’t already been fixed.

I just can’t set aside other projects that long, but I hope whoever takes
it over eventually does have that time and is hopefully hostile enough to
the compatibility problems and performance loss of OPENGLBLIT to fix it
right away.On Sat, Apr 13, 2002 at 12:34:18PM -0700, Blake Senftner wrote:

So, Joseph, are you going to become the ParaGUI maintainer?


Joseph Carter You’re entitled to my opinion

  • woot smiles serenely.
    I don’t want to seem over eager about getting into knghtbrd’s
    siglist.

-------------- 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/20020414/9ec5deff/attachment.pgp

If you found some bugs/issues to be solved why didn’t you send in a bug
report ?
I think you aren’t very familiar with the project. If you would you
would know that ParaGUI wasn’t designed for OpenGL. The OPENGLBLIT stuff
was a quick hack a guy asked for (~1 year ago).

I you need OpenGL stuff use a lib designed for OpenGL (like
http://libufo.sf.net).

I wouldn’t hand over the project to you.

Last statment on this thread. I have more productive things to do.

AlexAm Son, 2002-04-14 um 10.16 schrieb Joseph Carter:

On Sat, Apr 13, 2002 at 12:34:18PM -0700, Blake Senftner wrote:

So, Joseph, are you going to become the ParaGUI maintainer?

Likely not. I really haven’t the time it’d take to do a good job of
maintaining it. Especially given that I simply could not allow myself to
ignore the OPENGLBLIT problem. I would feel obligated to fix that on the
same day I took over maintenance. While I could do it (it really
shouldn’t be hard, though it requires abstracting how things get drawn a
bit), it’d probably take me stopping other projects for a day or two while
I pound a re-implementation into shape. Plus then because of backwards
compatibility I would have to make the OPENGLBLIT mode still work, want to
or not. There are also a couple of minor buglets I know of that’d need
fairly prompt attention if they haven’t already been fixed.

Paragui works great for me. We run Paragui in 2D
non-GL for all our game setup, multiplayer chat
screens etc… and initialize GL/GLX/SDL again for
video modes of choice when entering the game. I think
it has accomplished everything it was meant to do for
the modes it supported. In fact your could write your
own blit functions for Widgets if you like 3D
accelarted versions. It’s up to you to do. Thanks
for your great work Alex and hopefully this thread
ends here.

Alan

— Alexander Pipelka wrote:> Am Son, 2002-04-14 um 10.16 schrieb Joseph Carter:

On Sat, Apr 13, 2002 at 12:34:18PM -0700, Blake Senftner wrote:

So, Joseph, are you going to become the ParaGUI
maintainer?

Likely not. I really haven’t the time it’d take
to do a good job of
maintaining it. Especially given that I simply
could not allow myself to
ignore the OPENGLBLIT problem. I would feel
obligated to fix that on the
same day I took over maintenance. While I could
do it (it really
shouldn’t be hard, though it requires abstracting
how things get drawn a
bit), it’d probably take me stopping other
projects for a day or two while
I pound a re-implementation into shape. Plus then
because of backwards
compatibility I would have to make the OPENGLBLIT
mode still work, want to
or not. There are also a couple of minor buglets
I know of that’d need
fairly prompt attention if they haven’t already
been fixed.

If you found some bugs/issues to be solved why
didn’t you send in a bug
report ?
I think you aren’t very familiar with the project.
If you would you
would know that ParaGUI wasn’t designed for OpenGL.
The OPENGLBLIT stuff
was a quick hack a guy asked for (~1 year ago).

I you need OpenGL stuff use a lib designed for
OpenGL (like
http://libufo.sf.net).

I wouldn’t hand over the project to you.

Last statment on this thread. I have more productive
things to do.

Alex


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

* doesn't rely on surfaces with bigger area than
  the largest supported texture

* doesn't blit from or within the screen

* doesn't try to lock the screen and access it
  directly

(No major news in that area - I’ve been working on the new audio engine
most of the limited spare time I’ve had lately.)

You have a seperate package for
that, don’t you david

Not yet, unfortunately… (Naughty me! :wink:

It’s just a matter of ripping out a few files from Kobo Deluxe, and
writing a small HOWTO. (Very small, actually - there’s isn’t much you
should do, other than including glSDL.h instead of SDL.h. Use the SDL API
as usual.) I should try to do that RSN, so people can start trying out
the core code while I turn it into an SDL backend. (Well, some have been
playing with it for a while already, but maybe people in general don’t
appreciate the free bonus game that comes with it… :wink:

(I’m thinking of the right, guy
aren’t I?

Yep.

Kobo deluxe is cool).

Multiplayer will be even better! :wink:

As far as I know all
the blit operations in paragui use a function
PG_Draw::BlitSurface, which calls SDL_BlitSurface, in
which case perhaps that wouldn’t be too tough to
change. I’m interested in being able to use it for
OpenGL too.

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.
(Dealing with that is the major part of glSDL - the rest is fairly
trivial.)

//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 Saturday 13 April 2002 18:55, Andrew Ford wrote:

[…]

Anyone care to explain exactly how is OPENGLBLIT implemented less than
optimal? I just glanced at the logic from SDL_video.c, and it looks
like a texture object is being used rather than something awful like
glCopyPixels().

Problem is that it uses a texture with alpha to “simulate” actual
rendering on top of the OpenGL display, rather than just overwriting the
whole screen. Besides, it uses only a single 256x256 texture that has to
be glTexImage2D()ed and blitted in a tight loop - not exactly what your
average driver will enjoy. (Most probably, there will be no parallelism
whatsoever WRT the CPU and the GPU.)

Does it just need to be updated to keep a single
texture object per SDL surface around and update via
glCopyTexSubImage2D()?

Kind of - although it’s not exactly trivial, as there are texture size
limitations and other issues to deal with.

Either way, that’s what glSDL does, basically. In a way, glSDL could
probably be made to work like a “proper” replacement for OPENGLBLIT, but
that isn’t exactly what it’s designed for. (If you’re doing OpenGL, do it
right: use OpenGL only. glSDL is a way of getting full h/w acceleration
for normal SDL 2D applications.)

(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.)

//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 Saturday 13 April 2002 21:34, Blake Senftner 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.
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.

— 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 screen
    I don’t think there’s a backing store for the screen,
    so I don’t think this happens

  • doesn’t try to lock the screen and access it
    directly

Kobo deluxe is cool).

Multiplayer will be even better! :wink:
It’d be cooler if I could get past damn level 23 :slight_smile:

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.__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax

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? If it’s only
the 3dfx cards that you need to do this for (I guess
you could run into 1024x1024 as well), that’s
unfortunate since those drivers are going to be
getting crustier and crustier without anyone
maintaining them. What about multiple sub-blits on
one texture of maximum size when you need to blit a
large surface?

— David Olofson <david.olofson at reologica.se> wrote:> Problem is that it uses a texture with alpha to

“simulate” actual
rendering on top of the OpenGL display, rather than
just overwriting the
whole screen. Besides, it uses only a single 256x256
texture that has to
be glTexImage2D()ed and blitted in a tight loop -
not exactly what your
average driver will enjoy. (Most probably, there
will be no parallelism
whatsoever WRT the CPU and the GPU.)

Does it just need to be updated to keep a single
texture object per SDL surface around and update
via
glCopyTexSubImage2D()?

Kind of - although it’s not exactly trivial, as
there are texture size
limitations and other issues to deal with.

Either way, that’s what glSDL does, basically. In a
way, glSDL could
probably be made to work like a “proper” replacement
for OPENGLBLIT, but
that isn’t exactly what it’s designed for. (If
you’re doing OpenGL, do it
right: use OpenGL only. glSDL is a way of getting
full h/w acceleration
for normal SDL 2D applications.)

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.)

//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 -’


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax