plib-devel

RE: [Plib-devel] Networking Code

[Dave M. <Dav...@dy...>]

Hi Ben,

In adding networking code to plib, I recommend keeping it simple like the
code you showed me from tuxkart.  We just need a portable way to setup a
connection.  The application code should be responsible for the rest.

A turn based game doesn't need dead-reckoning so setPos() probably doesn't
belong in plib proper.  Things like real-time state management or
match-making systems for finding opponents could be placed in an auxillary
library.

-- Dave

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

>> Thanks, I have that, and I am trying to read through it, but I am new to
c
>> and c++ so you can amagine how fun it is. Luckly, I have some of steves
>> code, that uses structures in c++ so I have been able to get passed some
of
>> the problems but its not fun.
>> Thanks for the site.
>
>ACE is built upon on single core class ACE_OS, which provides a single
Unix/POSIX like >interface to all the standard thread and
>socket calls.
>
>This is mostly done in ACE_OS.h as a large bunch of #ifdef's.  I haven't
really studied it >that much, but it might be worthwhile
>having a look.
>
>(One gottcha I should point out is that almost all the higher level ACE
applications use >
>recv and send - not read and write (these
>calls are supposed to be identical), with the result that ACE_OS::read and
ACE_OS::write >
>appear to be broken under Win2000 with ACE
>(This might actually be problems with WinSock under Win2K I haven't
investigated)).

I did not realise that you could use recv and send and not read and write
with TCP, I think I  read somewhere that for the TCP section I should use
read and write, I really don't know if there is a difference but I will have
a look at it. 
As well I have not had much of a chance to look at winsocks so I am not
really sure what is the best way to deal with windows but I will be looking
at that. 

Thanks Ben
ps Can you send me a link to where I can find ace. I don't think I ran
across that yet.




_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] Networking Code

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 3:15 PM
Subject: RE: [Plib-devel] Networking Code


> Thanks, I have that, and I am trying to read through it, but I am new to c
> and c++ so you can amagine how fun it is. Luckly, I have some of steves
> code, that uses structures in c++ so I have been able to get passed some of
> the problems but its not fun.
> Thanks for the site.

ACE is built upon on single core class ACE_OS, which provides a single Unix/POSIX like interface to all the standard thread and
socket calls.

This is mostly done in ACE_OS.h as a large bunch of #ifdef's.  I haven't really studied it that much, but it might be worthwhile
having a look.

(One gottcha I should point out is that almost all the higher level ACE applications use recv and send - not read and write (these
calls are supposed to be identical), with the result that ACE_OS::read and ACE_OS::write appear to be broken under Win2000 with ACE
(This might actually be problems with WinSock under Win2K I haven't investigated)).

You could always strip ACE_OS out of ACE (shouldn't be *that* hard), and then you have a bunch of platform independant OS calls for
sockets and threads - and ACE supports a *lot* of platforms.

Sam

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks, I have that, and I am trying to read through it, but I am new to c
and c++ so you can amagine how fun it is. Luckly, I have some of steves
code, that uses structures in c++ so I have been able to get passed some of
the problems but its not fun. 
Thanks for the site.
Ben

-----Original Message-----
From: Darrell Walisser [mailto:dwa...@pu...]
Sent: Tuesday, August 22, 2000 11:11 AM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code


Hi. Below I have some network code that was used to implement the SDL_Net
library for MacOS, using OpenTransport. I didn't write the code, but I think
it will help you a lot.

    http://icdweb.cc.purdue.edu/~walisser/sdl/SDL_net.sit


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] Networking Code

[Darrell W. <dwa...@pu...>]

Hi. Below I have some network code that was used to implement the SDL_Net
library for MacOS, using OpenTransport. I didn't write the code, but I think
it will help you a lot.

    http://icdweb.cc.purdue.edu/~walisser/sdl/SDL_net.sit

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Hey Sam

If you write a few little test programs for it, can you send them back to
me, I would like to add them in for testing. 

Thanks Ben

-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Tuesday, August 22, 2000 10:49 AM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code



----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 1:58 PM
Subject: [Plib-devel] Networking Code


> Hello
>
> I have started to do some work on the portability of the networking code,
> but I don't have a mac, windows or a network for that matter, I was
> wondering if someone would like to help me with this code.
>
> Some of the things I don't know? (Yes I am aware of all the comments that
> could come with that statement)
>
> I have no idea if it runs in windows
> I do know it does not run on a mac (but I am working on the code)
> I don't know how well it works on linux or bsd

I can test the windows and Linux versions - and perhaps Irix as well.

Do you have any test programs to check the code?  If not I can knock a quick
couple of programs that attempt to pass data back and
forth between them and check the validity of it.

Sam



_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks Sam

I don't have any test programs wrote yet, I am trying to get some mac code
in there but I am lost. Also there are some places in the code that need to
be cleaned up, but it should work for you (I hope). 

Here is the code.
Thanks Ben

-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Tuesday, August 22, 2000 10:49 AM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code



----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 1:58 PM
Subject: [Plib-devel] Networking Code


> Hello
>
> I have started to do some work on the portability of the networking code,
> but I don't have a mac, windows or a network for that matter, I was
> wondering if someone would like to help me with this code.
>
> Some of the things I don't know? (Yes I am aware of all the comments that
> could come with that statement)
>
> I have no idea if it runs in windows
> I do know it does not run on a mac (but I am working on the code)
> I don't know how well it works on linux or bsd

I can test the windows and Linux versions - and perhaps Irix as well.

Do you have any test programs to check the code?  If not I can knock a quick
couple of programs that attempt to pass data back and
forth between them and check the validity of it.

Sam



_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] Networking Code

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 1:58 PM
Subject: [Plib-devel] Networking Code


> Hello
>
> I have started to do some work on the portability of the networking code,
> but I don't have a mac, windows or a network for that matter, I was
> wondering if someone would like to help me with this code.
>
> Some of the things I don't know? (Yes I am aware of all the comments that
> could come with that statement)
>
> I have no idea if it runs in windows
> I do know it does not run on a mac (but I am working on the code)
> I don't know how well it works on linux or bsd

I can test the windows and Linux versions - and perhaps Irix as well.

Do you have any test programs to check the code?  If not I can knock a quick couple of programs that attempt to pass data back and
forth between them and check the validity of it.

Sam

[Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Hello 

I have started to do some work on the portability of the networking code,
but I don't have a mac, windows or a network for that matter, I was
wondering if someone would like to help me with this code. 

Some of the things I don't know? (Yes I am aware of all the comments that
could come with that statement)

I have no idea if it runs in windows
I do know it does not run on a mac (but I am working on the code)
I don't know how well it works on linux or bsd

Thanks Ben

RE: Use of Language (was RE: [Plib-devel] Re: KobayashiMaru & pli b)

[Ben W. <be...@bg...>]

HEHEHE, you just had to make sure you repeated them all. Ahh well, if they
are paying close appention they would have seen these by now. Hope hes not
in to much shit. 

Later Ben
ps Good try, but I really don't think your message helped any. Infact it
just had all the word repeated over and over with all the replies. Sorry

-----Original Message-----
From: Alexander Rawass [mailto:a_r...@in...]
Sent: Tuesday, August 22, 2000 2:59 AM
To: pli...@li...
Subject: Re: Use of Language (was RE: [Plib-devel] Re: KobayashiMaru &
plib)


Hi,

I know very well that what I will do now will very probably get me
flamed or
being in put in the killfile of many/some in this list.
But this was something I couldn't stand.

Fay John F Contr AAC/WMG wrote:
> 
> Folks,
>         While I hesitate to do this as a relative newcomer to the list, I
> feel that I need to put in a plug for decent language.  Four-letter
> Anglo-Saxon words are not only offensive (at least to me, personally), but

Love. Hell. Sexy. Fuck. Bomb. Iraq. Nuke. Sperm. Dick. XMas.

Which one do you mean?

> they are also unprofessional.  I also have a job-related interest in the
> matter:  I have a ".mil" address, and every byte that comes in or goes out

If you are afraid of loosing your job or getting into trouble, you
should better receive this mailing-list at our private mail account,
not at your job account.

If you receive it at your private account, no one will monitor you and
you are completely free to do what _you_ want.

AND you don't waste the time and money of your employers by reading
private mail in working time.

OR - even better - you should quit your job at once.

> is monitored.  I don't want to have to explain to the computer security
> people why I am subscribed to this sort of a mailing list.

So, do you have the Gestapo on your back?


Alex from good old Germany, just got his Deja Vu

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: Use of Language (was RE: [Plib-devel] Re: KobayashiMaru & plib)

[Alexander R. <a_r...@in...>]

Hi,

I know very well that what I will do now will very probably get me
flamed or
being in put in the killfile of many/some in this list.
But this was something I couldn't stand.

Fay John F Contr AAC/WMG wrote:
> 
> Folks,
>         While I hesitate to do this as a relative newcomer to the list, I
> feel that I need to put in a plug for decent language.  Four-letter
> Anglo-Saxon words are not only offensive (at least to me, personally), but

Love. Hell. Sexy. Fuck. Bomb. Iraq. Nuke. Sperm. Dick. XMas.

Which one do you mean?

> they are also unprofessional.  I also have a job-related interest in the
> matter:  I have a ".mil" address, and every byte that comes in or goes out

If you are afraid of loosing your job or getting into trouble, you
should better receive this mailing-list at our private mail account,
not at your job account.

If you receive it at your private account, no one will monitor you and
you are completely free to do what _you_ want.

AND you don't waste the time and money of your employers by reading
private mail in working time.

OR - even better - you should quit your job at once.

> is monitored.  I don't want to have to explain to the computer security
> people why I am subscribed to this sort of a mailing list.

So, do you have the Gestapo on your back?


Alex from good old Germany, just got his Deja Vu

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-devel] Texture and blend modes

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> Let's see if I understand ...
> 
> I am (by definition) not tweaking any states that ssg normally would
> manage.

Indeed.

>  But, since these states are grouped, and doing a
> glPushAttribute() saves a whole slew of states, I may unwittingly
> alter a state that ssg *does* manage as a side effect of my
> glPopAttribute()

Yes - by accidentally restoring it to the state BEFORE the most
recent state->apply.
 
> I'll give it a try in my sky code ...
> 
> Here's what I get now:
> 
> no matching function for call to `ssgEntity::hasState ()'
> no matching function for call to `ssgEntity::getState ()'

Doh!  These are only members of ssgLeaf - general purpose entities
don't have states unless they happen to be leaf nodes.
 
> A check of ssg.h indicates that these are indeed not members of
> ssgEntity.

Yep.
 
> But, the compiler lets me get away with this ... sound reasonable?
> 
>     ssgLeaf *f = (ssgLeaf *)e;
>     if ( f -> hasState () ) f->getState()->apply() ;

Yep - so long as you only attach this callback to a leaf node.

If you were playing it super-safe you could do an 'isAKindOf' test to
check before you did the cast.
 
> I'll play around with this some more.  I'm still having a touch of bad
> luck with GL_DEPTH_TEST, but I'm forcing this in other places in my
> code too.  Could be that I'm entering the code with it off and since
> the sky code is actually preserving the state rather than turning it
> [back] on when it is done, I could be exiting they sky rendering
> section with the state set different now.

Urrrggggg ... brainnn ... can't ... quite .... reach ...

Hold on - it's coming <rumble> - yes - comprehension is dawning <creak>
<rattle> <rattle> *POP* 

      Yes.

By doing this "right" you could actually be cancelling out one
half of an elegant matched pair of antique Colonial bugs...which
erm...greatly reduces their value.

Hmmm - so this might mean that my explanation is not the right one (although
it's still "TRUE" and must still be attended to).

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Texture and blend modes

[Curtis L. O. <cu...@in...>]

Steve Baker writes:
> > So you are saying I could do something like the following:
> >
> >   static int predraw( ssgEntity *e ) {
> >
> >     glPushAttrib( GL_ENABLE_BIT | GL_DEPTH_BUFFER_BIT );
> >
> >     glDisable( GL_DEPTH_TEST );
> >     glDisable( GL_FOG );
> >
> >     return true;
> >   }
> >
> >   static int postdraw( ssgEntity *e ) {
> >     glPopAttrib();
> >
> >     return true;
> >   }
>
> Yes - exactly...although pushing and popping ALL the enable bits is
> perhaps a tad drastic...
>
> There is a 'gotcha' here.  Since the pre-draw callback is called BEFORE
> ssgState::apply() is called, your 'pop' will also have undone any glEnable
> or glDisable's that ssgSimpleState may have done.  Since ssgSimpleState
> doesn't know that you did that, it'll assume that whatever it enabled
> or disabled is *STILL* that way when the next state is applied - and since
> it's lazy - it won't re-enable anything that it *thinks* is already
> enabled.

Let's see if I understand ...

I am (by definition) not tweaking any states that ssg normally would
manage.  But, since these states are grouped, and doing a
glPushAttribute() saves a whole slew of states, I may unwittingly
alter a state that ssg *does* manage as a side effect of my
glPopAttribute()

> So you need to either be rather surgical and save only exactly the
> things that need saving (and I'm not sure if the granularity of the
> attribute stack allows you to be that precise)...OR you could do an
>
>     if ( e -> hasState () ) e->getState()->force() ;
>
> ...just AFTER your glPopAttrib - or (more obscurely - but more
> efficiently) an
>
>    if ( e -> hasState () ) e->getState()->apply() ;
>
> ...just BEFORE your glPushAttrib.
>
> Either of these *should* fix up any problems you might have in a
> clean manner.

Urrrggggg ... brainnn ... can't ... quite .... reach ...

Hold on, let me find a stool.

Ok, that's better ...

I'll give it a try in my sky code ...

Here's what I get now:

no matching function for call to `ssgEntity::hasState ()'
no matching function for call to `ssgEntity::getState ()'

A check of ssg.h indicates that these are indeed not members of
ssgEntity.

But, the compiler lets me get away with this ... sound reasonable?

    ssgLeaf *f = (ssgLeaf *)e;
    if ( f -> hasState () ) f->getState()->apply() ;

I'll play around with this some more.  I'm still having a touch of bad
luck with GL_DEPTH_TEST, but I'm forcing this in other places in my
code too.  Could be that I'm entering the code with it off and since
the sky code is actually preserving the state rather than turning it
[back] on when it is done, I could be exiting they sky rendering
section with the state set different now.

Curt.
--
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] VRML Loader issues

[Gil C. <g.c...@ca...>]

At 07:32 PM 8/21/00 -0500, you wrote:
>Gil Carter wrote:
>
> > I know of AC3D, but I've not used it - what type of VRML import does it
> > support?  Does it also do VRML export?
>
>It claims VRML 1.0 import and VRML 1.0, VRML 2.0 (and 'VRML 2.0 proto') 
>export.
>
>I strongly suspect that the quality of these is minimal...but I confess I
>have not worked with them very much.

Any chance you could try exporting a couple of TAQFH models out of AC3d in 
VRML format to give me some more fodder for the parser?

>
> > If you're interested to give it a try, see if AC3D will load this file:
> >
> > http://www.powerup.com.au/~gcarter/plib/VRML/VRML1/AllNodes.wrl
>
>I'll try....
>
><time passes>
>
>It crashed!
>
>I'm not suprised.

Nor am I - that file is a little nasty in terms of having empty nodes or 
nodes with default values.  If AC3D is expecting valid contents for VRML 
nodes in its loader, I'm not surprised it had trouble.  That test file came 
from the original VRML1.0 parser/loader produced by SGI back in 1995, and I 
suspect that it was only really intended to show that parser could 
recognise all of the nodes.

I'll be producing a full set of new VRML1 test files for the parser, so 
hopefully they should provide a fairer test once they're done.  Since these 
won't really form part of the PLIB distribution but would be useful to have 
around, where should I put them?  Is there a convenient place in the CVS 
tree for them, or would they be better just on my local web site?

Rgds,

Gil

[Plib-devel] Clip Texture (Was: PLIB developers needed.)

[Steve B. <sjb...@ai...>]

Gil Carter wrote:

> To get it from SGI themselves:
> 
> "IRIS Performer on InfiniteReality® allows you to create textures that are
> much bigger than will fit in texture memory and even in system memory, so
> that you can fit your entire world in a single texture. IRIS Performer will
> also manage all of the texture loading for you from disk to system memory
> and then to texture memory, based on your current position in the database.
> IRIS Performer provides for virtual memory for very large Mip-mapped
> textures by only storing potentially visible texels in system and texture
> memory. Efficient management of texture memory is made possible by special
> capabilities of the InfiniteReality texturing hardware. This general
> technique is called clipmapping and is the subject of the rest of this paper"
> 
> The paper which they're referring to is at
> http://www.sgi.com/software/performer/presentations/clipmap_intro.pdf

This is about how Performer *uses* Clipmapping - the underlying OpenGL
extension doesn't do file I/O and such like - that's purely a Performer
thing.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] VRML Loader issues

[Steve B. <sjb...@ai...>]

Gil Carter wrote:

> I know of AC3D, but I've not used it - what type of VRML import does it
> support?  Does it also do VRML export?

It claims VRML 1.0 import and VRML 1.0, VRML 2.0 (and 'VRML 2.0 proto') export.

I strongly suspect that the quality of these is minimal...but I confess I
have not worked with them very much.
 
> If you're interested to give it a try, see if AC3D will load this file:
> 
> http://www.powerup.com.au/~gcarter/plib/VRML/VRML1/AllNodes.wrl

I'll try....

<time passes>

It crashed!

I'm not suprised.
 
> If AC3D can load this
> without complaining, it either fully supports VRML1 or it supports a subset
> and fails silently on unsupported nodes...

Hmmm - well - it didn't actually *complain*.
Does core dumping count as "failing silently" ?   :-)

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] PLIB developers needed.

[Gil C. <g.c...@ca...>]

At 06:35 PM 8/21/00 -0500, you wrote:
>Christian Mayer wrote:
>
> > > It certainly does use clip-texture - that's why they wrote that 
> particular
> > > demo.
> >
> > Sorry, but what's the clip-texture really doing?
>
>Clip texture is lots of things - but essentially it allows you to have
>a 'virtual' texture map that is *MASSIVE* - perhaps 1,000,000 x 1,000,000
>texels.  Since that's impossibly large, you are allowed to write into just
>some sections at the highest MIPmap level - and others at lower levels -
>and where there are gaps it can fill in.
>
>Urgh - that's a terrible explanation - but essentially, it allows you
>much more freedom in paging texture from disk efficiently.

To get it from SGI themselves:

"IRIS Performer on InfiniteReality® allows you to create textures that are 
much bigger than will fit in texture memory and even in system memory, so 
that you can fit your entire world in a single texture. IRIS Performer will 
also manage all of the texture loading for you from disk to system memory 
and then to texture memory, based on your current position in the database. 
IRIS Performer provides for virtual memory for very large Mip-mapped 
textures by only storing potentially visible texels in system and texture 
memory. Efficient management of texture memory is made possible by special 
capabilities of the InfiniteReality texturing hardware. This general 
technique is called clipmapping and is the subject of the rest of this paper"

The paper which they're referring to is at 
http://www.sgi.com/software/performer/presentations/clipmap_intro.pdf

Rgds,

Gil

Re: [Plib-devel] VRML Loader issues

[Gil C. <g.c...@ca...>]

At 08:21 PM 8/21/00 +0000, you wrote:
>On Fri, Aug 18, 2000 at 08:26:01AM +1000, Gil Carter wrote:
>
> > >However I've yet to find anything that'll convert a VRML2 file into
> > >something I can import into anything.
>
> > Can you be a little more specific?  What packages do you want to import
> > VRML into and what packages are producing the original VRML?
>
> > Most of the big "name brand" 3D modelling packages will do pretty good
> > VRML97 import and export - 3D Studio Max is the one we use here, and it
> > reads and writes VRML97 very competently.
>
>The VRML is some stuff that I've downloaded off the web.

Got any URL's?  I'm trying to assemble a collection of models which people 
would like to use with PLIB so that I can test with them, and it will make 
my life easier if I can test against what you're looking at.

>I'm trying to import it into my software.
>The model editor I'm using at the moment is AC3D.

I know of AC3D, but I've not used it - what type of VRML import does it 
support?  Does it also do VRML export?

If you're interested to give it a try, see if AC3D will load this file:

http://www.powerup.com.au/~gcarter/plib/VRML/VRML1/AllNodes.wrl

This file contains all of the valid VRML1 nodes, although the end result 
after loading looks awful - there are no textures or materials assigned, 
and all of the objects are located at the origin.  If AC3D can load this 
without complaining, it either fully supports VRML1 or it supports a subset 
and fails silently on unsupported nodes...

Rgds,

Gil

Re: [Plib-devel] PLIB developers needed.

[Steve B. <sjb...@ai...>]

Christian Mayer wrote:

> > It certainly does use clip-texture - that's why they wrote that particular
> > demo.
> 
> Sorry, but what's the clip-texture really doing?

Clip texture is lots of things - but essentially it allows you to have
a 'virtual' texture map that is *MASSIVE* - perhaps 1,000,000 x 1,000,000
texels.  Since that's impossibly large, you are allowed to write into just
some sections at the highest MIPmap level - and others at lower levels -
and where there are gaps it can fill in.

Urgh - that's a terrible explanation - but essentially, it allows you
much more freedom in paging texture from disk efficiently.

The only 'gotcha' is that only hideously expensive ONYX'en have the
hardware to make it truly work.
 
> But it's been still very impressive (esp. at a time where nobody would
> expect 3d accelleration for consumer PCs)

It doesn't run on PC's (AFAIK) - or at least if it does, they found a way
to cram it all in without cliptexture (which is certainly possible).

> > They had a version where you zoomed in past the mountain and onto a
> > Nintendo-64 (which was developed by SGI) - through the case and down
> > into the 'Reality Chip'.
> 
> Yup, that's the demo I saw. SGI also had a Nintendo-64 prototype at
> their booth running SuperMario 64.

Exactly.  They actually offered me a job on the N64 design team - it
would have been a blast - but their pay scales (whilst MUCH better than
I was earning at the time in actual $$$) didn't come close to what I
was earning when you considered the cost of living in Silicon Valley
versus Texas.
              :-(

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Texture and blend modes

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> Yup, so if I do these in matched pairs the "right" thing should
> happen.  Unless ssg is somehow interleaving things weirdly behind my
> back, but I can't imagine that would be happening.

No - it's not.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Texture and blend modes

[Steve B. <sjb...@ai...>]

Ben Woodhead wrote:
> 
> The code looks fine according to the redbook, but one thing I was wondering
> did you test to see how big the stack is and how many are being used. If
> plib is also using stacks you may have reached your limit.

SSG doesn't use the attribute stack - although PUI does.  PUI should
only be consuming stack entries while it's actually being called.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Texture and blend modes

[Steve B. <sjb...@ai...>]

Ben Woodhead wrote:
> 
> There is also a glclientpushattrib() and glclientpopattrib(), the read the
> redbook that should tell you what you need to know.

Yes - but unless you are in a remote-rendering GLX kind of a situation you won't
care.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Texture and blend modes

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> Question ... in the man page GL_DEPTH_TEST and GL_FOG are both listed
> under multiple "bits".  Does this mean I can pick one or the other?
> Do I need all of them?

One or the other.

They are supposedly grouped into 'helpful' subsets of the full OpenGL state
because there is generally some cost to doing a push/pop for some of the
attributes - so it's best to deal with the MINIMUM set.
 
> The prototype for glPopAttrib() is "void glPopAttrib( void )".  My
> understanding is that it just takes the top thing off the stack and
> restores which ever states had been previously pushed there.

Yes.
 
> My code doesn't work though ... this could be due to:
> 
> a) my misunderstanding of how these things really work.
> 
> b) $#@$#@ mesa bugs
>    ^^^^^^ -> is this ok for the .mil filter? :-)

Yes - so long as you don't say things like "President Assassination
Bomb Threat Terrorism Iraq" because that sets off their autodetection
circuits and forces some hapless individual to have to *read* the mail
personally.

<wave> Hi! </wave>

   :-)
 
> But, I haven't seen mesa break this badly before so perhaps (a) is
> more likely?

Well, as I explained in my last email - although you have basically
the right idea - the devil is in the details - but I do know for sure
that Mesa *has* had problems with some combinations of glPush/PopAttrib.

Try the extra getState()->apply() - and if *that* doesn't fix it then
you are probably looking at a Mesa error.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Texture and blend modes

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:
> 
> Steve Baker writes:
> > glPushAttrib/glPopAttrib ?
> >
> > Call one in pre-draw and the other in post-draw.
> 
> Those are nifty little calls, when did they get added? :-)

 Erm - was there an OpenGL before 1.0 ?  :-)

> So you are saying I could do something like the following:
> 
>   static int predraw( ssgEntity *e ) {
> 
>     glPushAttrib( GL_ENABLE_BIT | GL_DEPTH_BUFFER_BIT );
> 
>     glDisable( GL_DEPTH_TEST );
>     glDisable( GL_FOG );
> 
>     return true;
>   }
> 
>   static int postdraw( ssgEntity *e ) {
>     glPopAttrib();
> 
>     return true;
>   }

Yes - exactly...although pushing and popping ALL the enable bits is
perhaps a tad drastic...

There is a 'gotcha' here.  Since the pre-draw callback is called BEFORE
ssgState::apply() is called, your 'pop' will also have undone any glEnable
or glDisable's that ssgSimpleState may have done.  Since ssgSimpleState
doesn't know that you did that, it'll assume that whatever it enabled
or disabled is *STILL* that way when the next state is applied - and since
it's lazy - it won't re-enable anything that it *thinks* is already
enabled.

So you need to either be rather surgical and save only exactly the
things that need saving (and I'm not sure if the granularity of the
attribute stack allows you to be that precise)...OR you could do an

    if ( e -> hasState () ) e->getState()->force() ;

...just AFTER your glPopAttrib - or (more obscurely - but more
efficiently) an

   if ( e -> hasState () ) e->getState()->apply() ;

...just BEFORE your glPushAttrib.

Either of these *should* fix up any problems you might have in a
clean manner.

> This unfortunately yields rendering problems ... can you see anything
> obvious that I am doing wrong or misunderstanding here?

Well, apart from the slight subtlety I explain above, as I mentioned
before - Mesa has bugs in glPush/Pop attrib (or at least *had* - past
tense - I havn't played with recent versions).

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: Use of Language (was RE: [Plib-devel] Re: KobayashiMaru & plib)

[Steve B. <sjb...@ai...>]

Sam Stickland wrote:

> > While I hesitate to do this as a relative newcomer to the list, I
> > feel that I need to put in a plug for decent language.  Four-letter
> > Anglo-Saxon words are not only offensive (at least to me, personally), but
> > they are also unprofessional.  I also have a job-related interest in the
> > matter:  I have a ".mil" address, and every byte that comes in or goes out
> > is monitored.  I don't want to have to explain to the computer security
> > people why I am subscribed to this sort of a mailing list.
> 
> Sorry, it won't happen again.  I tend to work in a fairly causal atmosphere, and my ..ah.. background probably doesn't make me
> assign the sort of severity to these words that other people might.

In the end this is an unmoderated list with open membership - to expect there
to never be the odd expletif creeping in is unrealistic.

I don't think anything *too* unacceptable is going on here.

I also work in a military (contractor admittedly) environment and every
byte is also theoretically monitored - but I don't think they'd really
bat an eyelid about other people's language.  Of course if it was me
who was cursing up a storm - that would be a different matter.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net