glgui-dev

[Glgui-dev] Issues

[SiO2 S. <si...@ne...>]

----- Original Message -----
From: "SiO2 Software" <si...@ne...>
To: <glg...@li...>
Sent: Friday, April 07, 2000 10:23 AM
Subject: [Glgui-dev] Bonjour


> Subscribed at last! The archives are still fubar, so I haven't a clue
what's
> been discussed in my absence.
>
> Anyway, I'll have my set of mod's done over the weekend (Famous Last
Words).
> I'll post the URL to the list (binary attachments are *evil*) so you can
all
> see what I'm doing.
>
> Scott and I have been discussing a few things over the last three weeks or
> so. Here's a segment of an email I sent to Scott last week:
>
> >I have some points I'd like to discuss on the mailing list:
> >1. Use of C++ and how/if this effects portability.
> >2. Use of stl.
> >3. Usability with Direct3D. I can port glGameGUI to d3dGameGUI, but we
need
> >a common base!
>
> There's no problem with doing the Direct3D port. That will be a "piece of
> cake". But what do we call it? We can't call it "glGui"!

Does anyone have any comments on these issues? I'm just about to start work
again on glGui, so it would be nice if we had the relevant discussions
*before* I begin. [My contract work with Intel has taken prominence over the
last couple of weeks]

For those who don't know, I will be using glGui in my next game title. I
will definitely be doing a Direct3D version of glGui, but we absolutely need
to keep full OpenGL functionality. ;-)

Regards,

Keith Harrison
SiO2 Software.
ke...@ne... (personal)
si...@ne... (work)

[Glgui-dev] Issues

[Travis M. <Tra...@st...>]

Sorry Keith, I meant to just send it to the mailing list.

I suggest a fully implemented Bridge.  We can then allow any developers who
dislike our implementations of the D3D and OpenGL classes extend the
abstract base class which defines the interface easily.  Or create a simple
adapter and integrate their own versions of D3D OpenGL bridge with our own.
That would also allow a very easy extension to anything else, even (dare I
say it) a software renderer.  Then no ports will be necessary, we can just
derive from GraphicsAPI (or whatever we want to call it.)  This is what I do
in my engine, and it is one heck of a timesaver.  Admittedly it will add an
extra layer, but I think the increased flexibility would be worth it.

Also let me say here and now, I love the stl.  I know on a few systems it is
still unsupported, but it is the biggest time saver save templates
themselves.  I say we should use it to its fullest.

PS. Sorry I haven't been active, school has hit me harder than I thought it
would.  This is finals week, so hopeful If I survive I should be able to get
back into the swing of things next week. 



	-----Original Message-----
	From:	SiO2 Software [SMTP:si...@ne...]
<mailto:[SMTP:si...@ne...]> 
	Sent:	Monday, April 24, 2000 10:41 AM
	To:	glgui-dev
	Subject:	[Glgui-dev] Issues


	----- Original Message -----
	From: "SiO2 Software" <si...@ne...
<mailto:si...@ne...> >
	To: <glg...@li...
<mailto:glg...@li...> >
	Sent: Friday, April 07, 2000 10:23 AM
	Subject: [Glgui-dev] Bonjour


	> Subscribed at last! The archives are still fubar, so I haven't a
clue
	what's
	> been discussed in my absence.
	>
	> Anyway, I'll have my set of mod's done over the weekend (Famous
Last
	Words).
	> I'll post the URL to the list (binary attachments are *evil*) so
you can
	all
	> see what I'm doing.
	>
	> Scott and I have been discussing a few things over the last three
weeks or
	> so. Here's a segment of an email I sent to Scott last week:
	>
	> >I have some points I'd like to discuss on the mailing list:
	> >1. Use of C++ and how/if this effects portability.
	> >2. Use of stl.
	> >3. Usability with Direct3D. I can port glGameGUI to d3dGameGUI,
but we
	need
	> >a common base!
	>
	> There's no problem with doing the Direct3D port. That will be a
"piece of
	> cake". But what do we call it? We can't call it "glGui"!

	Does anyone have any comments on these issues? I'm just about to
start work
	again on glGui, so it would be nice if we had the relevant
discussions
	*before* I begin. [My contract work with Intel has taken prominence
over the
	last couple of weeks]

	For those who don't know, I will be using glGui in my next game
title. I
	will definitely be doing a Direct3D version of glGui, but we
absolutely need
	to keep full OpenGL functionality. ;-)

	Regards,

	Keith Harrison
	SiO2 Software.
	ke...@ne... <mailto:ke...@ne...>  (personal)
	si...@ne... <mailto:si...@ne...>  (work)



	_______________________________________________
	Glgui-dev mailing list
	Glg...@li...
<mailto:Glg...@li...> 
	http://lists.sourceforge.net/mailman/listinfo/glgui-dev
<http://lists.sourceforge.net/mailman/listinfo/glgui-dev> 

Re: [Glgui-dev] Issues

[Scott F. <sf...@gl...>]

> I suggest a fully implemented Bridge.  We can then allow any developers
who
> dislike our implementations of the D3D and OpenGL classes extend the
> abstract base class which defines the interface easily.  Or create a
simple
> adapter and integrate their own versions of D3D OpenGL bridge with our
own.
> That would also allow a very easy extension to anything else, even (dare I
> say it) a software renderer.  Then no ports will be necessary, we can just
> derive from GraphicsAPI (or whatever we want to call it.)  This is what I
do
> in my engine, and it is one heck of a timesaver.  Admittedly it will add
an
> extra layer, but I think the increased flexibility would be worth it.

This was what I was going to suggest.  As of now, there's a pretty limited
portion of the GL that needs to be abstracted.  I haven't used d3d in a long
time, and don't know how other api's implement similar functionality, so
I'll leave it to someone else to lay out the abstraction class.  But I'll
write the opengl version once the base interface is done.

> Also let me say here and now, I love the stl.  I know on a few systems it
is
> still unsupported, but it is the biggest time saver save templates
> themselves.  I say we should use it to its fullest.

I like it too, but if there are too many support problems, it may not be
worth using.

> PS. Sorry I haven't been active, school has hit me harder than I thought
it
> would.  This is finals week, so hopeful If I survive I should be able to
get
> back into the swing of things next week.

Same goes for me.  Except that I'm in my last week of classes and will be
starting finals next week.  I'm also lining up a job for the summer which
will include a good bit of time moving, etc.  I may be unable to do much
work for a few weeks still.  But I'll try to stay a part of the discussion
and can even spend a few hours here and there to do some simple design /
programming.

One of the things I'd like to work on next is a more complete shader class,
with functionality similar to that in quake3.  But the issues Keith has
made, as well as some of the others that have been mentioned (other widgets,
better text, etc) should take precedence.

Scott Franke [druid-]
   sf...@gl...
druid-'s GL Journal
   http://www.gljournal.org

Re: [Glgui-dev] Issues

[SiO2 S. <si...@ne...>]

I'll let you all know what I've come up with Real Soon(tm). ;-)

----- Original Message -----
From: "Scott Franke" <sf...@gl...>
To: <glg...@li...>
Sent: Wednesday, April 26, 2000 5:28 AM
Subject: Re: [Glgui-dev] Issues


> > I suggest a fully implemented Bridge.  We can then allow any developers
> who
> > dislike our implementations of the D3D and OpenGL classes extend the
> > abstract base class which defines the interface easily.  Or create a
> simple
> > adapter and integrate their own versions of D3D OpenGL bridge with our
> own.
> > That would also allow a very easy extension to anything else, even (dare
I
> > say it) a software renderer.  Then no ports will be necessary, we can
just
> > derive from GraphicsAPI (or whatever we want to call it.)  This is what
I
> do
> > in my engine, and it is one heck of a timesaver.  Admittedly it will add
> an
> > extra layer, but I think the increased flexibility would be worth it.
>
> This was what I was going to suggest.  As of now, there's a pretty limited
> portion of the GL that needs to be abstracted.  I haven't used d3d in a
long
> time, and don't know how other api's implement similar functionality, so
> I'll leave it to someone else to lay out the abstraction class.  But I'll
> write the opengl version once the base interface is done.
>
> > Also let me say here and now, I love the stl.  I know on a few systems
it
> is
> > still unsupported, but it is the biggest time saver save templates
> > themselves.  I say we should use it to its fullest.
>
> I like it too, but if there are too many support problems, it may not be
> worth using.
>
> > PS. Sorry I haven't been active, school has hit me harder than I thought
> it
> > would.  This is finals week, so hopeful If I survive I should be able to
> get
> > back into the swing of things next week.
>
> Same goes for me.  Except that I'm in my last week of classes and will be
> starting finals next week.  I'm also lining up a job for the summer which
> will include a good bit of time moving, etc.  I may be unable to do much
> work for a few weeks still.  But I'll try to stay a part of the discussion
> and can even spend a few hours here and there to do some simple design /
> programming.
>
> One of the things I'd like to work on next is a more complete shader
class,
> with functionality similar to that in quake3.  But the issues Keith has
> made, as well as some of the others that have been mentioned (other
widgets,
> better text, etc) should take precedence.
>
> Scott Franke [druid-]
>    sf...@gl...
> druid-'s GL Journal
>    http://www.gljournal.org
>
>
> _______________________________________________
> Glgui-dev mailing list
> Glg...@li...
> http://lists.sourceforge.net/mailman/listinfo/glgui-dev
>