plib-devel

Re: [Plib-devel] VRML Loader issues

[Chris P. <cj...@lo...>]

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.
I'm trying to import it into my software.
The model editor I'm using at the moment is AC3D.

-- 
Christopher John Purnell  | I thought I'd found a reason to live
http://www.lost.org.uk/   | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands

Re: [Plib-devel] PLIB developers needed.

[<Va...@t-...>]

Steve Baker wrote:
> 
> Gil Carter wrote:
> 
> >> But I doubt that we can run the famous Mont Blanc demo from SGI where
> >> you can zoom from a space view of the earth down to the Mont Blanc and
> >> fly around it. On the fair where I saw it (on an ONYX :-)) ) they told
> >> me that the textures had a resolution of 1 metre and you could see the
> >> walking tracks...
> >
> > IIRC, that application is also a pretty good demonstration of Performer's
> > ClipTextures, which allow the management of much larger textures than will
> > fit into physical texture memory.  I think ClipTextures are implemented
> > using special hardware on the Onyxes, so that demo will need some major
> > surgery to work on a PC!
> 
> It certainly does use clip-texture - that's why they wrote that particular
> demo.

Sorry, but what's the clip-texture really doing?

> However, it's a rather 'rigged' demo because you can only zoom in on
> Mont Blanc - you can't (for example) zoom in on a point 10 miles south
> of there.

But it's been still very impressive (esp. at a time where nobody would
expect 3d accelleration for consumer PCs)

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

CU,
Christian

RE: [Plib-devel] Texture and blend modes

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

I don't think that ssg would push something and not pop it or vis-versa but
there is always the chance of that. you may want to send in your code and
see if there is something wrong in it.
Sorry for the spelling in the last message, someone was asking me to hurry
up, so I was typing as fast as I could. 

Later Ben

-----Original Message-----
From: Curtis L. Olson [mailto:cu...@me...]
Sent: Monday, August 21, 2000 4:11 PM
To: pli...@li...
Subject: RE: [Plib-devel] Texture and blend modes


Ben Woodhead writes:
> One more thing, I you may now this but I thought I would say it anyway.
When
> you pop it of the stack, it purmanatly pops off. 
> A on stack
> push
> B on stack
> 
> pop // b comes off leaving just a.

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.

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

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

RE: [Plib-devel] Texture and blend modes

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

Ben Woodhead writes:
> One more thing, I you may now this but I thought I would say it anyway. When
> you pop it of the stack, it purmanatly pops off. 
> A on stack
> push
> B on stack
> 
> pop // b comes off leaving just a.

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.

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] Texture and blend modes

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

One more thing, I you may now this but I thought I would say it anyway. When
you pop it of the stack, it purmanatly pops off. 
A on stack
push
B on stack

pop // b comes off leaving just a.
Later Ben
-----Original Message-----
From: Curtis L. Olson [mailto:cu...@me...]
Sent: Monday, August 21, 2000 3:58 PM
To: pli...@li...
Subject: RE: [Plib-devel] Texture and blend modes


Ben Woodhead writes:
> 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.

Ben,

I just added glGetError() calls after each push/pop.  These always
return zero (even the very first call) and their presence makes the
rendering work ...

Now I take out the calls to glGetError() and it still works ... lovely ...
:-(

But I duplicate the code else where and it obviously isn't restoring
the depth_test ... :-(

Thrust back into opengl la-la-land ... I might be better off just
putting things back to the way that I know they work and saving myself
about 100 or so hours ...

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

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

RE: [Plib-devel] Texture and blend modes

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

Norman Vine writes:
> Maybe Try
> glPushAttrib( GL_FOG_BIT | GL_DEPTH_BUFFER_BIT );

Yes, I tried that ...

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] Texture and blend modes

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

Ben Woodhead writes:
> 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.

Ben,

I just added glGetError() calls after each push/pop.  These always
return zero (even the very first call) and their presence makes the
rendering work ...

Now I take out the calls to glGetError() and it still works ... lovely ... :-(

But I duplicate the code else where and it obviously isn't restoring
the depth_test ... :-(

Thrust back into opengl la-la-land ... I might be better off just
putting things back to the way that I know they work and saving myself
about 100 or so hours ...

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] Texture and blend modes

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

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.

Later Ben

-----Original Message-----
From: Vallevand, Mark K [mailto:Mar...@UN...]
Sent: Monday, August 21, 2000 3:40 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] Texture and blend modes


Plib uses push and pop attributes in its ssgVtxArray code.  It
seems to work, and might be a useful example.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

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

RE: [Plib-devel] Texture and blend modes

[Vallevand, M. K <Mar...@UN...>]

Plib uses push and pop attributes in its ssgVtxArray code.  It
seems to work, and might be a useful example.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

RE: [Plib-devel] Texture and blend modes

[Norman V. <nh...@ca...>]

Curtis L. Olson 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 );

Maybe Try
glPushAttrib( GL_FOG_BIT | GL_DEPTH_BUFFER_BIT );

>
>    glDisable( GL_DEPTH_TEST );
>    glDisable( GL_FOG );
>
>    return true;
>  }
>
>  static int postdraw( ssgEntity *e ) {
>    glPopAttrib();
>
>    return true;
>  }
>

RE: [Plib-devel] glPopAttrib and glPushAttrib

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

Sorry due to the characters in the link I sent, the full like is not
highlighted, if you are going to use the link highligh all the text the
paste it into your browser.

Later Ben

-----Original Message-----
From: Ben Woodhead 
Sent: Monday, August 21, 2000 3:28 PM
To: 'pli...@li...'
Subject: [Plib-devel] glPopAttrib and glPushAttrib


Hello

Here is a link to the opengl redbook, have a look at the glpop and glpush
section. That should help you out. Sorry I was wrong about the glpopattrib,
its been along time since I read this chapter.
Later Ben  
 
 
http://heron.cc.ukans.edu/ebt-bin/nph-dweb/dynaweb/SGI_Developer/OpenGL_PG/@
Generic__BookTextView/6043;cd=7;td=6;cs=fullhtml;pt=6045;nh=1?DwebQuery=glpo
pattrib#X
 <<OpenGL Programming Guide (Addison-Wesley Publishing Company).url>> 

RE: [Plib-devel] Texture and blend modes

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

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

Later Ben
ps I will read it, see if I can see any probs with your code. 


-----Original Message-----
From: Curtis L. Olson [mailto:cu...@me...]
Sent: Monday, August 21, 2000 3:25 PM
To: pli...@li...
Subject: RE: [Plib-devel] Texture and blend modes


Ben Woodhead writes:
> I think that glpopattrib(); will pop all attributes including anything you
> have changed other then the gl_depth and gl_fog. Perhaps you want to
> specific ones. 
> 
> Later Ben
> I will have a look in my book about that. Later 

From reading the man pages, my understanding is that you feed
glPushAttrib() a mask which is usually an "or'd" list of attributes
you are interested in preserving.

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?

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.

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? :-)

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

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

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

[Plib-devel] glPopAttrib and glPushAttrib

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

Hello

Here is a link to the opengl redbook, have a look at the glpop and glpush
section. That should help you out. Sorry I was wrong about the glpopattrib,
its been along time since I read this chapter.
Later Ben  
 
 
http://heron.cc.ukans.edu/ebt-bin/nph-dweb/dynaweb/SGI_Developer/OpenGL_PG/@
Generic__BookTextView/6043;cd=7;td=6;cs=fullhtml;pt=6045;nh=1?DwebQuery=glpo
pattrib#X
 <<OpenGL Programming Guide (Addison-Wesley Publishing Company).url>> 

RE: [Plib-devel] Texture and blend modes

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

Ben Woodhead writes:
> I think that glpopattrib(); will pop all attributes including anything you
> have changed other then the gl_depth and gl_fog. Perhaps you want to
> specific ones. 
> 
> Later Ben
> I will have a look in my book about that. Later 

From reading the man pages, my understanding is that you feed
glPushAttrib() a mask which is usually an "or'd" list of attributes
you are interested in preserving.

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?

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.

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? :-)

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

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] Texture and blend modes

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

I think that glpopattrib(); will pop all attributes including anything you
have changed other then the gl_depth and gl_fog. Perhaps you want to
specific ones. 

Later Ben
I will have a look in my book about that. Later 

-----Original Message-----
From: Curtis L. Olson [mailto:cu...@me...]
Sent: Monday, August 21, 2000 3:06 PM
To: pli...@li...
Subject: Re: [Plib-devel] Texture and blend modes


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? :-)

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;
  }

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

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

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

Re: [Plib-devel] Texture and blend modes

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

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? :-)

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;
  }

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

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] Re: KobayashiMaru & plib

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

Well here is the code, but this code is going to be eventually put into
plib, but right now its really messy. I have to do alot of portability code,
especially for mac os, and I am not sure it will work on windows. But the
code is started, hopefully if I don't have another day like today the code
should be cleaner and portable. 
Are you interested in actually working on the code or just using it.
Currently you have to create one socket per connection and I have not
developed it for more then one connection. I am sure there would be little
change to the interface for this to work but I have not coded for it yet. So
far I was working on just a ip to ip connection, or that kind of idea,
someone  hosts a game and the other connects to the game. 
But you are left to handle the trafic and just the tcp and upd code is there
for you.

Later Ben
the code should be attacted. Also there are alot of comments in the code for
places that need to be cleaned up. If you do any work on the code please
e-mail it back to me, Thanks

-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Monday, August 21, 2000 2:43 PM
To: pli...@li...
Subject: Re: [Plib-devel] Re: KobayashiMaru & plib



----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Monday, August 21, 2000 6:29 PM
Subject: RE: [Plib-devel] Re: KobayashiMaru & plib


> Hello
>
> I am also working on some networking code for plib, a tcp and a udp
section,
> perhaps we can work together on it. It's not portable to mac yet and there
> are definately some places that have to be worked on but hey if your
> interested let me know.

Yes, that would be good.  I'm using ACE
(http://www.cs.wustl.edu/~schmidt/ACE.html) at the moment to make my socket
and thread code
portable, but ACE is a very heavy weight library (it's the foundation for
TAO - a complete COBRA implementation).

ACE supposedly has some very powerful network functions that I've never
fully had time to look at.  Take the following example:

Do you create a new thread for each client that connects to the server?
This would be great if you never expect to have more than
about 20 clients connected, but what about 3000?  You can easily become
swamped in task switching overhead here.  But by the same
token you might not want to be single threaded.  There's an optimal balance
for clients per thread, and it can vary on different
hardware and is of course effected by the number of CPUs.

Now I'm told ACE can take a single re-enterant function and a socket that
clients will try to connect on and handle all this for
you.  If will run tests on the hardware at runtime and automatically balance
the clients per thread ratio for you.

But I fear that ACE might have to much of the ivory tower approach in it for
my purposes.  I only ever stumbled across it when I was
looking for a cross-platform socket and thread library :)

Sam



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

Re: [Plib-devel] Re: KobayashiMaru & plib

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

----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Monday, August 21, 2000 6:29 PM
Subject: RE: [Plib-devel] Re: KobayashiMaru & plib


> Hello
>
> I am also working on some networking code for plib, a tcp and a udp section,
> perhaps we can work together on it. It's not portable to mac yet and there
> are definately some places that have to be worked on but hey if your
> interested let me know.

Yes, that would be good.  I'm using ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) at the moment to make my socket and thread code
portable, but ACE is a very heavy weight library (it's the foundation for TAO - a complete COBRA implementation).

ACE supposedly has some very powerful network functions that I've never fully had time to look at.  Take the following example:

Do you create a new thread for each client that connects to the server?  This would be great if you never expect to have more than
about 20 clients connected, but what about 3000?  You can easily become swamped in task switching overhead here.  But by the same
token you might not want to be single threaded.  There's an optimal balance for clients per thread, and it can vary on different
hardware and is of course effected by the number of CPUs.

Now I'm told ACE can take a single re-enterant function and a socket that clients will try to connect on and handle all this for
you.  If will run tests on the hardware at runtime and automatically balance the clients per thread ratio for you.

But I fear that ACE might have to much of the ivory tower approach in it for my purposes.  I only ever stumbled across it when I was
looking for a cross-platform socket and thread library :)

Sam

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

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

----- Original Message -----
From: "Fay John F Contr AAC/WMG" <joh...@eg...>
To: <pli...@li...>
Sent: Monday, August 21, 2000 6:21 PM
Subject: Use of Language (was RE: [Plib-devel] Re: KobayashiMaru & plib)


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

Sam

RE: [Plib-devel] Re: KobayashiMaru & plib

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

Hello 

I am also working on some networking code for plib, a tcp and a udp section,
perhaps we can work together on it. It's not portable to mac yet and there
are definately some places that have to be worked on but hey if your
interested let me know.

Later Ben


I'm currently in the process of taking the network code from this and
rewriting it into a separate generic library (something I
should had done from the start, but hey, we live and learn).  The network
library (to my surprise), is turning out to be quite
powerful :) . From an API point of view you can just subclass new objects
from the base one provided, and effectively do:

STNetworkObj *obj = new STNetworkObj ;
obj -> SetPos ( blah ) ;

NetworkEnv::AddNewObj ( obj ) ;

( Obviously it's a bit more complex than that.  In actuallality your
subclassed objects have to specify which of their
data-variables are to be transmitted over the network, what accuracy they
require (this can be range based) etc.  Objects can also
be placed in classes and assigned relative strengths.  For example, you
might have a scanning class - into which you can place
scanners and jammers.  The network engine works out what information the
client *should* know about and transmit only that).

The network library shields all the nasty dead-reckoning, time-sync, latency
and path extropolation problems at it's highest level.

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

[Fay J. F C. AAC/W. <joh...@eg...>]

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

John F. Fay
joh...@eg...


-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Monday, August 21, 2000 10:41
To: pli...@li...
Subject: Re: [Plib-devel] Re: KobayashiMaru & plib



----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Friday, August 11, 2000 9:26 AM
Subject: Re: [Plib-devel] Re: KobayashiMaru & plib



>
> > > But do you really believe that as a beginner 3D programmer, you will
manage to
> > > write a single game that spans deep space PLUS flight sim PLUS
hand-to-hand
> > > combat and integrates all those seamlessly?  Not one single game
throughout
> > > the entire history of game making has ever been that ambitious.  Not
one.

> Utterly universal game engines don't exist because they can't exist.
> There is a galaxy of difference between a first person shooter game
> engine like Quake or Doom and a flight simulation engine like FlightGear.
> The idea that you can just change the model and program some different
> behaviours in is very naive.

Well, I wasn't going to jump in here, but in the end I thought "what the
hell"...

In terms of outdoor and indoor environments being mixed in a single game you
could cite Descent 3.  This game - supposedly (I
haven't seen any truely techy articles on it), managed to successfully mix
an outdoor engine, with an indoor portal culling engine.
At the time it was described as a "tremondous technical feat" :)

So, I don't believe that it's actually impossible - merely just incredibly
difficult.

I'm working on a similar game to KobayashiMaru myself, but I understand the
technical challenges involved and I don't expect to ever
fully complete the project.

I'm tackling it in stages, creating the neccessary technology at each stage
to complete those goals.  So to begin with I have a
straight up space-shooter (and this has taken me long enough! :).

I'm currently in the process of taking the network code from this and
rewriting it into a separate generic library (something I
should had done from the start, but hey, we live and learn).  The network
library (to my surprise), is turning out to be quite
powerful :) . From an API point of view you can just subclass new objects
from the base one provided, and effectively do:

STNetworkObj *obj = new STNetworkObj ;
obj -> SetPos ( blah ) ;

NetworkEnv::AddNewObj ( obj ) ;

( Obviously it's a bit more complex than that.  In actuallality your
subclassed objects have to specify which of their
data-variables are to be transmitted over the network, what accuracy they
require (this can be range based) etc.  Objects can also
be placed in classes and assigned relative strengths.  For example, you
might have a scanning class - into which you can place
scanners and jammers.  The network engine works out what information the
client *should* know about and transmit only that).

The network library shields all the nasty dead-reckoning, time-sync, latency
and path extropolation problems at it's highest level.

This isn't fantasy.  I have this code base working, and I'll have small
programs to demonstrate the library ready in the coming
months (starting with network Pong! and getting more complex).

Now, this is only a very tiny part of what a game like KobayashiMaru would
need to achieve - and this has taken me 18 months to get
this far. :)

When the network library is fully debugged, I plan on adding a basic trading
mechanism to SpaceThing - and the amount of spare time
I have at the moment (maybe I'll have to stay in more), this will be a
while.  After that I need to add a persistant database to the
server-side of the network library.  God knows how long that will take!

From my point of view it's a bit of fun, and I get nice side programs at
every stage - even it is shitty Pong! :)

Well, that appears to be enough of a ramble/blanant plug for my network
library.

Sam



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

Re: [Plib-devel] Re: KobayashiMaru & plib

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

----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Friday, August 11, 2000 9:26 AM
Subject: Re: [Plib-devel] Re: KobayashiMaru & plib



>
> > > But do you really believe that as a beginner 3D programmer, you will manage to
> > > write a single game that spans deep space PLUS flight sim PLUS hand-to-hand
> > > combat and integrates all those seamlessly?  Not one single game throughout
> > > the entire history of game making has ever been that ambitious.  Not one.

> Utterly universal game engines don't exist because they can't exist.
> There is a galaxy of difference between a first person shooter game
> engine like Quake or Doom and a flight simulation engine like FlightGear.
> The idea that you can just change the model and program some different
> behaviours in is very naive.

Well, I wasn't going to jump in here, but in the end I thought "what the hell"...

In terms of outdoor and indoor environments being mixed in a single game you could cite Descent 3.  This game - supposedly (I
haven't seen any truely techy articles on it), managed to successfully mix an outdoor engine, with an indoor portal culling engine.
At the time it was described as a "tremondous technical feat" :)

So, I don't believe that it's actually impossible - merely just incredibly difficult.

I'm working on a similar game to KobayashiMaru myself, but I understand the technical challenges involved and I don't expect to ever
fully complete the project.

I'm tackling it in stages, creating the neccessary technology at each stage to complete those goals.  So to begin with I have a
straight up space-shooter (and this has taken me long enough! :).

I'm currently in the process of taking the network code from this and rewriting it into a separate generic library (something I
should had done from the start, but hey, we live and learn).  The network library (to my surprise), is turning out to be quite
powerful :) . From an API point of view you can just subclass new objects from the base one provided, and effectively do:

STNetworkObj *obj = new STNetworkObj ;
obj -> SetPos ( blah ) ;

NetworkEnv::AddNewObj ( obj ) ;

( Obviously it's a bit more complex than that.  In actuallality your subclassed objects have to specify which of their
data-variables are to be transmitted over the network, what accuracy they require (this can be range based) etc.  Objects can also
be placed in classes and assigned relative strengths.  For example, you might have a scanning class - into which you can place
scanners and jammers.  The network engine works out what information the client *should* know about and transmit only that).

The network library shields all the nasty dead-reckoning, time-sync, latency and path extropolation problems at it's highest level.

This isn't fantasy.  I have this code base working, and I'll have small programs to demonstrate the library ready in the coming
months (starting with network Pong! and getting more complex).

Now, this is only a very tiny part of what a game like KobayashiMaru would need to achieve - and this has taken me 18 months to get
this far. :)

When the network library is fully debugged, I plan on adding a basic trading mechanism to SpaceThing - and the amount of spare time
I have at the moment (maybe I'll have to stay in more), this will be a while.  After that I need to add a persistant database to the
server-side of the network library.  God knows how long that will take!

From my point of view it's a bit of fun, and I get nice side programs at every stage - even it is shitty Pong! :)

Well, that appears to be enough of a ramble/blanant plug for my network library.

Sam

RE: [Plib-devel] listbox and filepicker

[Fay J. F C. AAC/W. <joh...@eg...>]

Sorry about the delay in responding to this; I missed it the first time it
came around and just found it in the TODO list.
 
I think the problem in deleting the wrong dialog box comes from the
"puPopLiveInterface ()" call in the "puInterface" destructor.  I would
tentatively fix it by removing the call from the destructor and placing it
in the "puDeleteObject" function:
 
if ( ob->getType() | PUCLASS_INTERFACE )
  puPopLiveInterface () ;
 
I don't have any applications where dialog boxes create other dialog boxes
while destroying themselves so I can't test it out, but a look at the code
makes me think it will work.  Can someone check it out for me please?  I put
it into my own application and it doesn't seem to have broken anything.  
 

John F. Fay 
joh...@eg... 

 
-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Friday, August 04, 2000 12:52
To: 'pli...@li...'
Subject: [Plib-devel] listbox and filepicker



i added a listbox and filepicker to pui 
in the pui example called complex.cxx i hooked the filepicker to the
menu/save button 

one thing i noticed in doing this is that having the callback for one dialog

create another dialog and then delete itself via puDeleteObject has problems

the reason is that pui maintains an interface *stack* in puInterface.cxx 
the creation of another dialog precedes the deferred deletion of the old
dialog 
which messes up the stack so when the puInterface destructor calls
puPopLiveInterface () ; 
it is popping the wrong dialog (ie: the new one) and the old one (which was
destructed) 
gets left on the stack.  at least this is what i think is happening.  what
is needed 
is a better way to handle this because *chaining* from one dialog to another
ala 
linked buttons is pretty common.  any suggestions? 

--Dave 

Re: [Plib-devel] Terrain optimization in ssg?

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

----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Monday, August 21, 2000 4:10 AM
Subject: Re: [Plib-devel] Terrain optimization in ssg?


> Gil Carter wrote:
> >
> > At 02:15 PM 8/20/00 -0400, you wrote:
> > >I seem to remember a while back that someone
> > >was talking about adding one of the terrain optimization
> > >algorithms (ala ROAM and others) to ssg.  Does anyone
> > >know who brought this up and if anything has been done about
> > >it?

Yeah, it was me.  And I haven't done anything about it - although I still plan to .. It's for a game I'm working on in my spare
time. I thought an extra planet based environment would make it seem like I'd achieved more, but in the end I decided that
concentrating on the network engine would be more productive. :)

If anyone's interested I was using the implementation on gamasutra as a starting point -
http://www.gamasutra.com/features/20000403/turner_01.htm

I was only ever really playing with it though, for the practice and experience.  In the end I think I'll be generating the terrain
from perlin noise (which of course already has lot's of LOD benefits), overlayed with pregenerated (but slightly randomised)
features.

But in the short term the gamasutra ROAM code seems to be an easy way to get fairly complex pre-generated landscapes into my game in
the short term.

> >  Ben Discoe's VTerrain site
> > has a good summary of these techniques, with links to their original papers
> > at http://vterrain.org/LOD/published.html
>
> There was significant discussion of ROAM and other continuous terrain LOD
> mechanisms at SigGraph.  The bottom line conclusion was that the decision
> as to whether to go with fixed levels of detail - or continuous LOD - changes
> with the prevailing graphics technology - and that currently the availability
> of cheap T&L hardware means that the pendulum is swinging back towards multiple
> fixed levels of detail - or perhaps no level of detail management at all.
>
> This definitely reduces my enthusiasm for implementing ROAM in SSG - although
> if someone did want to write it, I'd be very happy to accept such a contribution
> into the codebase.

Well, I only have a TNT2 (no T&L), so *I'm* still interested in ROAM :)

Sam

Re: [Plib-devel] Terrain optimization in ssg?

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

Gil Carter wrote:
> 
> At 02:15 PM 8/20/00 -0400, you wrote:
> >I seem to remember a while back that someone
> >was talking about adding one of the terrain optimization
> >algorithms (ala ROAM and others) to ssg.  Does anyone
> >know who brought this up and if anything has been done about
> >it?
> 
> Well, I did mention it about a fortnight ago as a possible future
> contribution, but my efforts are currently on the VRML import/export
> followed by documentation and then the ssgStatistics module.  I think that
> it will be a fair while before I get to implementing ROAM for PLIB in my
> spare time!
> 
> That said, ROAM is only one of a number of continuous level of detail
> schemes for real time rendering - albeit a fairly oft-discussed one.

..and it's generally agreed that you don't really want to implement
ALL the subtleties of ROAM because some of the final layers of optimisations
do bad things to memory locality - and are actually somewhat pessimal.

>  If you're thinking of doing some work on a CLOD system for PLIB, you might
> like to also look at some of the other methods of doing it - adaptive
> quadtrees, view independent progressive meshes and bin tri-trees, as well
> as simple distance based switching of meshes.

Distance-based mesh switching is of course already supported in SSG...although
not with alpha blending between levels.

>  Ben Discoe's VTerrain site
> has a good summary of these techniques, with links to their original papers
> at http://vterrain.org/LOD/published.html

There was significant discussion of ROAM and other continuous terrain LOD
mechanisms at SigGraph.  The bottom line conclusion was that the decision
as to whether to go with fixed levels of detail - or continuous LOD - changes
with the prevailing graphics technology - and that currently the availability
of cheap T&L hardware means that the pendulum is swinging back towards multiple
fixed levels of detail - or perhaps no level of detail management at all.

This definitely reduces my enthusiasm for implementing ROAM in SSG - although
if someone did want to write it, I'd be very happy to accept such a contribution
into the codebase.

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