paragui-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [paragui-users] a small quick question (for opengl support)


From: Andrew Ford
Subject: Re: [paragui-users] a small quick question (for opengl support)
Date: Wed, 5 Jun 2002 22:38:49 -0700 (PDT)

Okay, I can tell you the way it should probably go...

- OpenGL paragui allocates one or more textures (each
a power of two in each dimension) to represent the
screen surface.  These textures together will
represent the screen surface for the rest of paragui.
- User does whatever to the paragui widgets (i.e.
modifies state), gets ready to blit the gui.
- User requests a bulk-blit of paragui.
- Textures that represent the screen surface for
paragui are updated to the new state, via
glTexSubImage2D, or the in-memory buffers are updated,
then dirty (changed) regions of the textures are
re-uploaded (via glTexSubImage2D, again) to OpenGL.
- The projection matrix is pushed, cleared and an
ortho2D matrix is set.
- Textured quads are drawn, one for each
screen-texture, to blit the gui. (make sure that
glEnable( GL_TEXTURE_2D ) is enabled, or if it isn't
enable it and re-disable it afterwards, same with
lighting)
- The projection matrix is popped, the blit is
finished.
- User does whatever else, then swaps buffers.

You could probably get away with just disabling
depth-testing, lighting, and enabling texturing and
let the user deal with the state changes, but you can
always save what the original state was with a
glIsEnabled or glGet.  The punchline is that you'll
run into texture-size limitations on some cards (i.e.
256x256 on voodoo3), and you have to split the screen
"surface" into multiple textures, glSDL does not
handle this.
Paragui doesn't need to know what's going on outside
of the PG_BlitSurface (right name?) function, which
can have the same interface whether it's SDL blitting,
or blitting to an OpenGL texture region.  As far as
paragui is concerned, they can be the same.  The user
needs to know differently only insofar as he has to be
using double buffering (single buffered opengl is a
bit nasty but could be supported similarly, I wouldn't
recommend it in general).

Bit of a pain in the ass isn't it...

Andrew.

--- Teunis Peters <address@hidden> wrote:
> On Wed, 5 Jun 2002, Andrew Ford wrote:
> 
> > I don't think any changes to the api would be
> > necessary when using paragui in the double-buffer
> > style.
> 
> 'struth
> 
> > As for paragui rendering to texture, that's
> already
> > what glsdl is supposed to do.  Man, I wish I had
> my
> > computer with me so that I could look into this
> stuff
> > too...
> 
> Only prob is I've got to find some way that when
> rendering everything gets
> rendered - and glSDL doesn't really like
> SDL_Surfaces being changed often.
> Thinking of taking some ideas from gtv (OpenGL movie
> player in smpeg
> source tree)...  still exploring this.
> 
> > What 3D accelerator are you using, by the way?
> 
> Matrox G450 Dualhead
> It's not "latest'n'greatest" but I like it so far.
> although second display isn't accelerated as far as
> I can tell...
> 
> am now VERY strongly considering a
> hardware-abstraction layer of some
> kind.  which is what glSDL does, but there's
> advantages to knowing how
> code is going to use texture memory.  Could possibly
> be done hidden
> inside paragui without exposing it... maybe...  but
> it would be better
> shown *g*
> 
> G'day, eh? :)
>       - Teunis
> 
> 
> _______________________________________________
> paragui-users mailing list
> address@hidden
>
http://mail.freesoftware.fsf.org/mailman/listinfo/paragui-users


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]