paragui-users
[Top][All Lists]
Advanced

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

Re: [paragui-users] OpenGL work - next CVS update within a few days *g*


From: Teunis Peters
Subject: Re: [paragui-users] OpenGL work - next CVS update within a few days *g*
Date: Sat, 5 Oct 2002 11:21:52 -0700 (PDT)

On Fri, 4 Oct 2002, Eric Ross wrote:

> On Fri, 4 Oct 2002, Teunis Peters wrote:
>
> > New updates:
> >     Video driver management code - working on this.  Hoping to have
> >     operational today...  Uses SDL's module loader but suspect have to
> >     rewrite....  am prepared to supply code for unix/windows *g*
> >
> > Any thoughts on this?
> > Just cleaning up the core lib now - still hunting the segfault-on-exit
> > And I -will- attempt a DirectX driver soon *sillygrin*
> >
> > The driver manager allows drivers to be written in seperate libs btw -
> > which could prove to be an advantage.  I'm also thinking of child
> > applications being loaded into ParaGUI apps, especially thanks to the XML
> > stuff... *g*
>
> Cool :) All this OpenGL stuff is going very well :) Good job
>
> All this means that one can switch to the SDL or OpenGL backend in
> runtime, something like passing an flag to some init function to select
> the backend ?

actually I've rewritten (in the opengl branch) the entire graphics chain
with the idea being loadable graphics modules.  Currently the only ones
are the default (SDL), OpenGL (which needs some work), dummy (good for
debugging :), and DirectX *grin* (completely untouched yet)

The idea is that if you start up ParaGUI it starts up assuming normal SDL
(SDL will be required regardless btw) and one can boot up a different
module.

It's all working nicely actually - I've got more work to do on the
rendering chain as I've found more parts of ParaGUI that talk to the
screen directly (fonts) which is -BAD- for OpenGL

And no I'm not (anymore) using glSDL.  It's quite a useful system but
doesn't work for ParaGUI for various reasons.  I will admit at this time
most of the rendering tree I'm working with is -based- on glSDL, but the
resemblance is fading over time as I add more....

> I didnt know that SDl had a module loader.. Any difference with using
> dlopen and friends ?

1. It's not yet a public API *grr* (due for SDL 1.3) and needs to be
explicitely enabled
2. as near as I can tell, unlike dlopen and friends it works under
windows, MacOS, BeOS and possibly other systems... *grin*
3. it's almost -identical- to dlopen and friends for calling convention...

if need be I can re-implement this section in paragui if it turns out to
be a pain to work with the SDL code.  The nice thing about both projects
is they're both Library GNU copyleft which makes this kind of work easier :)

> Good job again.. what about doing a aa (ascii art) backend ? :-)

Tricky... but possible.
Haven't looked at it *wry grin*.  I'm using either fbcon or opengl most of
the time (be nice if accellerated GL worked outside of X though *sigh*)

note:
- am also considering loading of GUI 'applets' under ParaGUI
  (could simplify widgets... or open up a new can of worms :)
- am NOT interested in removing XML.  That's a core component of a
  couple of pieces I'm working on.  (it's also not my code :)
- I -will- be setting up drivers so that widgets could theoretically be
        rendered in 3D....
- am also working on a ruleset that would allow multimedia (audio/...)
  stuff slightly easier... possibly...

one of my programs involves loading sub-applications that communicate
with the host through XMLRPC - and can have graphical interfaces.  This is
the bit that uses XML.  It's nowhere near presentable at this time but
that's my next goal :)
ummm I can explain...

anyways I'm off for the weekend
G'day, eh? :)
        - Teunis





reply via email to

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