plib-devel

Re: [Plib-devel] ssg animation

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

> Dave McClurg wrote:
> 
> Proposed changes:
> 
> ssgSelector would allow more than 32 frames by adding a max_kids param to the constructor
> 
>   ssgSelector ( int max_kids = 32 ) ;
> 
> the derived classed ssgRangeSelector and ssgTimedSelector would also take this param.

What about the current ability (which I use quite a bit) to pass an integer mask
with one bit per child object to enable you to select multiple child objects at
once?

> also, i would like to move this
> 
>   _ssgFrameCounter++ ;
> 
> from the top of ssgCullAndDraw() to the bottom of ssgCullAndDraw() because i want
> the animation rate to be based on logic frames and not render frames.

Yes - that's becoming important.

I was planning on making a new member function in ssgTimedSelector to allow you
to ask for either 'realtime' of 'frame-locked' animation.

There are cases when each is useful - and I'd like to mix them in the same
application sometimes.

> I'll just call ssgSetFrameCounter(fc) before calling ssgCullAndDraw().

That'll work in the short term.

> My logic frames are scheduled with a timer so that I always have 60 logic frames
> per second regardless of my render frame rate.  My animation plays correctly
> on slow machines and fast ones.  I prefer this over non-determistic simulations
> where the number of logic frames varies and uses floating point time intervals.

Yes - but there are times when frame-locked synchronisation is *CRITICAL*.

One example is in a weather simulation model we have at work that does
lightning bolts.  You need the lightning bolt to appear as briefly as
possible - yet never NOT happen because the previous frame took too long
to render.  To make the lightning look brighter, we do the visual trick
of pre-rendering a black lightning bolt, then doing the white one and
then another black one.  Its CRUCIAL that each of those three things
lasts just one frame - irrespective of the elapsed wall-clock time.

Anyway - doing this per-object rather than for the entire program
seems crucial to me.
 
> Please tell me your thoughts

Wibble, wibble, wibble.

  -- You did ask.  :-)


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

[Plib-devel] PUI 1.3.0 in Multiple Windows

[<fa...@tc...>]

ssg animationThe following source code changes will allow the PUI in PLIB
1.3.0 to operate in multiple windows.  I developed this using MSVC 6 on a
Windows 98 computer, but it isn't very exotic and should be easily portable.

(1) pu.h, line 461:  add a variable "int window ;" to the definition of a
"puObject".  This variable will contain the GLUT window containing the PUI
widget.

(2) pu.h, line 469:  add the test "&& window == glutGetWindow()" to the
"isHit" function.  This way a widget will be hit only if it is in the active
window.

(3) pu.h, lines 612-623:  add the methods "getWindow()" and "setWindow(int
w)" to the definition of a "puObject".  The contents of the methods should
be self-explanatory.  I haven't actually used the methods, but I think they
should be there in case someone wants them.

(4) (optional)
     pu.h, line 309:  prototype the function "void puDisplay ( int
window_number ) ;"
     pu.cxx, line 216:  add the function "void puDisplay ( int
window_number )":

void  puDisplay ( int window_number )  /* Redraw only the current window */
{
  puSetOpenGLState () ;
  puInterface *base_interface = puGetUltimateLiveInterface () ;
  puObject *ob = base_interface -> getFirstChild () ;
  while ( ob )
  {
    if ( ob -> getWindow () == window_number )
    {
      ob -> draw ( 0, 0 ) ;
      break ;
    }

    ob = ob -> getNextObject () ;
  }

  int h = puGetWindowHeight () ;

  if ( _puCursor_enable )
    puDrawCursor ( _puCursor_x,
                   h - _puCursor_y ) ;

  puRestoreOpenGLState () ;
}

This function assumes that all the widgets in the given window are listed
under a "puGroup" widget in that window which is listed directly under the
ultimate live interface.  I added this function to try to speed up execution
some, figuring that the program shouldn't have to redraw the widgets in an
inactive window.  It is not necessary for the multiple window capability.

(5)  (multiple places):  At the start of each "draw" function (except
"puGroup" and "puInterface"), add the following test:
  if ( window != glutGetWindow () ) return ;  /* check for the correct
window */

(6)  (multiple places):  At the start of each "checkKey" function (except
"puGroup" and "puInterface"), add the following test:
  if ( window != glutGetWindow () ) return FALSE ;  /* Check for the correct
window */

The exceptions in (5) and (6) (not testing the window in "puGroup" and
"puInterface") allow the user to put widgets in windows in any order at all.
This is more general than the arrangement supported by (4).  I'm not sure
which is better, the general case or the more restricted case.

I generated these changes as an upgrade from my previous version of PUI,
which I customized to use multiple windows.  I've checked the changes out
somewhat, but only on my system and only with a small modification to the
"complex.cxx" program.  (Anybody who wants a copy of the modified
"complex.cxx" can e-mail me and I will send it to him.)  There is one
problem that I found, which is that a PUI-defined cursor is drawn in every
window all the time.  If someone knows why this would happen and how to fix
it I would greatly appreciate hearing about it.
John F. Fay
joh...@eg...

[Plib-devel] ssg animation

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

Proposed changes:

ssgSelector would allow more than 32 frames by adding a max_kids param to
the constructor

  ssgSelector ( int max_kids = 32 ) ;

the derived classed ssgRangeSelector and ssgTimedSelector would also take
this param.

also, i would like to move this

  _ssgFrameCounter++ ;

from the top of ssgCullAndDraw() to the bottom of ssgCullAndDraw() because i
want
the animation rate to be based on logic frames and not render frames.   I'll
just
call ssgSetFrameCounter(fc) before calling ssgCullAndDraw().

My logic frames are scheduled with a timer so that I always have 60 logic
frames
per second regardless of my render frame rate.  My animation plays correctly
on slow machines and fast ones.  I prefer this over non-determistic
simulations
where the number of logic frames varies and uses floating point time
intervals.

Please tell me your thoughts

--Dave

Re: [Plib-devel] src/util includes

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

Norman Vine wrote:
> 
> Steve Baker writes:
> >
> >You need PLIB's CVS version.
> >
> >The UL library is a new feature that I added (at the request
> >of this group),
> >and it hasn't made it into a released version yet.
> >
> 
> unix newbie question
> 
> Is it possible to use symlinks instead of hard links
> in the /usr tree for the .h and .a files

Yes.

> If so how does one do this ?
> 
> I would like to be able to switch back and forth easily
> between using the released and CVS versions of several
> projects that use PLib

Presuming you have:

/usr/include/plib-1.2.0

and

/usr/include/plib-1.3.1

and also:

/usr/lib/libplibssg.so.1.2.0
/usr/lib/libplibssg.so.1.3.1

then you could write a shell script:

plib-1.2:

  rm /usr/include/plib
  rm /usr/lib/libplib*.so
  ln -s /usr/include/plib-1.2.0 /usr/include/plib
  ln -s /usr/lib/plibssg.so /usr/lib/plibssg.so.1.2.0

and another:

plib-1.3:

  rm /usr/include/plib
  rm /usr/lib/libplib*.so
  ln -s /usr/include/plib-1.3.1 /usr/include/plib
  ln -s /usr/lib/plibssg.so /usr/lib/plibssg.so.1.3.1

(In reality, you'd have to link each of the plib*.so libraries - I only did
one - for brevity).

So far, every PLIB application that works with 1.2 has worked with
1.3.1 provided the 'configure.in' file was modified by adding:

   AC_CHECK_LIB(plibul,ulInit,,,)

...so you shouldn't have to resort to symlinks, etc.

-- 
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] src/util includes

[Dave M. <dp...@ef...>]

Bram Stolk wrote:
> I'm probably doing something wrong here, but I got myself
> the latest cvs tree, and did aclocal,autoconf,automake, and
> configure.
> 
> This resulted in this error during build:
> 
snip
> ../../src/sg/sg.h:5: ul.h: No such file or directory 
> 
> Adding this to Makefile.am in src/pui, src/sg, src/fnt helps:
> 
> INCLUDES += -I$(top_srcdir)/src/util
> 
>     Bram

Thanks. My fault. I commited the change.

--Dave

RE: [Plib-devel] src/util includes

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

Steve Baker writes:
>
>You need PLIB's CVS version.
>
>The UL library is a new feature that I added (at the request 
>of this group),
>and it hasn't made it into a released version yet.
>

unix newbie question

Is it possible to use symlinks instead of hard links 
in the /usr tree for the .h and .a files

If so how does one do this ?

I would like to be able to switch back and forth easily
between using the released and CVS versions of several
projects that use PLib

Norman

Re: [Plib-devel] src/util includes

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

Bram Stolk wrote:
> 
> Hello plibbers,
> 
> I'm probably doing something wrong here, but I got myself
> the latest cvs tree, and did aclocal,autoconf,automake, and
> configure.

You need PLIB's CVS version.

The UL library is a new feature that I added (at the request of this group),
and it hasn't made it into a released version yet.

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

[Plib-devel] src/util includes

[Bram S. <br...@ch...>]

Hello plibbers,


I'm probably doing something wrong here, but I got myself
the latest cvs tree, and did aclocal,autoconf,automake, and
configure.

This resulted in this error during build:

Making all in pui
make[2]: Entering directory `/usr/local/src/plib/src/pui'
c++ -DPACKAGE=\"plib\" -DVERSION=\"1.3.1\" -DHAVE_LIBDL=1 -DHAVE_LIBGL=1
-DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DSTDC_HEADERS=1 -DHAVE_GL_GL_H=1
-DHAVE_GL_GLU_H=1 -DLINUX_JOYSTICK_IS_PRESENT=1 -DGLUT_IS_PRESENT=1  -I. -I. 
-I../../src/sg -I../../src/fnt    -g -O2 -O6 -Wall -c pu.cxx
In file included from pu.h:4,
                 from puLocal.h:2,
                 from pu.cxx:2:
../../src/sg/sg.h:5: ul.h: No such file or directory


Adding this to Makefile.am in src/pui, src/sg, src/fnt helps:

INCLUDES += -I$(top_srcdir)/src/util

    Bram

PS: the majik example doesnt compile for me:
make[3]: Entering directory `/usr/local/src/plib/examples/src/ssg/majik'
c++ -DPACKAGE=\"plib_examples\" -DVERSION=\"1.1.8\" -DHAVE_LIBPLIBUL=1
-DHAVE_LIBGL=1 -DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DSTDC_HEADERS=1
-DHAVE_GL_GL_H=1 -DHAVE_GL_GLUT_H=1 -DHAVE_PLIB_SG_H=1 -DHAVE_PLIB_SL_H=1
-DHAVE_PLIB_SSG_H=1 -DHAVE_PLIB_FNT_H=1 -DHAVE_PLIB_PU_H=1 -DHAVE_PLIB_JS_H=1
-DLINUX_JOYSTICK_IS_PRESENT=1  -I. -I.      -g -O2 -O6 -Wall -c majik_demo.cxx
majik_demo.cxx:29: syntax error before `*'
majik_demo.cxx:30: syntax error before `*'


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Bram Stolk               "Linux - Why use windows, if there is a door?"
  work: br...@sa...
  priv: br...@ch...

Re: [Plib-devel] bend example

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

> Dave McClurg wrote:
> 
> FWIW, i placed an example of mesh animation in plib/examples/src/tux/bend.cxx.  if you run this program it will load the bend.ase model and play its animation using an ssgTimedSelector.
> 
> it's handy for doing Spyro stuff like those flowers that bend in the breeze and flags and any other animations that have no more than 32 frames.  of course, you will need 3dsmax to create mesh animations in ASE format.

Cool!

We need to do something about that 32 step limit sometime.

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

[Plib-devel] bend example

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

FWIW, i placed an example of mesh animation in
plib/examples/src/tux/bend.cxx.  if you run this program it will load the
bend.ase model and play its animation using an ssgTimedSelector.

it's handy for doing Spyro stuff like those flowers that bend in the breeze
and flags and any other animations that have no more than 32 frames.  of
course, you will need 3dsmax to create mesh animations in ASE format.

--Dave

Re: [Plib-devel] TuxKart on Win32 works fine

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

"Vallevand, Mark K" wrote:
> 
> Great.  I'll post sample workspace and project files, too.
> They should go a long ways toward getting any MSVC6 programmer
> up and compiling.  I've got some ideas to play with myself...
> I've got some automatic terrain and road generation code lying
> around from some SimCity-clone test beds.  And some neat
> underwater effects.

I think we are on the wrong mailing list...this belongs on
TuxKart-devel.

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

[Plib-devel] plib_examples

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

Steve checked in the plib docs and examples!  Steve wrote:

> I decided to put the examples in a subdirectory of the plib area - and
> the documents into the plib doc area.  However, the 'configure.in' in
> the main directory won't build the examples or mess with the documents.
> 
> There is a separate configure.in in the examples area.
> 
> This will allow us to do a single commit for examples, documents and
> the libraries themselves - yet do separate releases for the various
> parts.
> 
> Your next checkout will be S-L-O-W because of all those image files
> in the examples area - but since they never change, it'll be a one-time
> thing.

I updated the win32 project files, README.win32, and added a batch
file to install PLIB on your system called INSTALL_win32.bat

> I created some MSVC++ 6.0 project files for PLIB and the examples.
>
> All you need to do is open the workspace "plib.dsw" in MSVC++,
> select the "plib" project (using Set Active Project in the Project
> menu), and build it (using "Rebuild All" in the Build menu).
>
> To "install" PLIB to your system so that the examples and your
> own projects can use them, run "INSTALL_win32.bat".  It copies
> the includes into /usr/include/plib and the libraries into /usr/lib.
>
> In the examples folder, open the workspace "plib_examples.dsw".
> Each example has a seperate project in the workspace.  Select
> the one you want and build it.  Then you should be able to hit
> the Go icon on the toolbar and try it out.

--Dave McClurg

RE: [Plib-devel] TuxKart on Win32 works fine

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

Great.  I'll post sample workspace and project files, too.
They should go a long ways toward getting any MSVC6 programmer
up and compiling.  I've got some ideas to play with myself...
I've got some automatic terrain and road generation code lying
around from some SimCity-clone test beds.  And some neat
underwater effects.

Time.  I need time.

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho


> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Wednesday, July 12, 2000 8:49 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] TuxKart on Win32 works fine
> 
> 
> "Vallevand, Mark K" wrote:
> 
> > Posted.  Try again...  It should work now.  (I had to use real
> > ftp.  Some web-based uploader was putting extra characters at
> > the end of the file.)
> 
> Thanks - I have it.  I need to make some changes so it'll
> compile with either PLIB 1.2 or 1.3 - then I'll commit your
> changes.
> 
> -- 
> 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
> 
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] Prepare for PLIB 1.3/1.4

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

IMPORTANT NOTICE:
~~~~~~~~~~~~~~~~~

From PLIB 1.3.1 onwards, there will be a new library 'libplibul.a' with some common
utility functions that other PLIB libraries may need.

If you use 'autoconf/automake' to build your application, you can easily cope
with this change by adding:

    AC_CHECK_LIB(plibul, ulInit,,,)

...with that in your 'configure.in', you should be able to build against either
PLIB 1.3.0 and earlier or PLIB 1.3.1 and later.

If you intend to actually call any UL functions in your application, then you'll
need to call ulInit() before you do so - and #include <plib/ul.h>

If you don't intend to call UL functions, you still need to link to UL - but you
don't have to call ulInit.

-- 
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] TuxKart on Win32 works fine

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

"Vallevand, Mark K" wrote:

> Posted.  Try again...  It should work now.  (I had to use real
> ftp.  Some web-based uploader was putting extra characters at
> the end of the file.)

Thanks - I have it.  I need to make some changes so it'll
compile with either PLIB 1.2 or 1.3 - then I'll commit your
changes.

-- 
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] New CVS of PLIB pre-1.3.1

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

"Curtis L. Olson" wrote:

> Is there any way that you can engineer things on the plib end to
> generate some sort of helpful error when a current application that is
> expecting plib-1.2.x (and doesn't remember to call ulInit() for
> instance) suddenly is compiled against plib-1.3.x.

Well, apart from anything else, a PLIB 1.2 application is going to
fail to link against 1.3.1 (or 1.4 more importantly) because SSG
needs UL and a 1.2 application won't be linking to libplibul.a

>  My fear is that 6
> months down the line when plib-1.3.x transitions to the stable tree,
> I'll have completely forgotten this message and will end up wasting a
> lot of time.  :-)

Right now, ulInit() is an empty function - but I can certainly put some
'traps' into the code to check that it was called before any future
hypothetical function that might need it.
 
> Is there a good function in libplibul.a that we can test for?

  ulInit()

   :-P

> Autoconf has the AC_CHECK_LIB( lib, function) macro that will test for
> a library and add it to the link line if it exists.

Right - and I'm putting that into all my application's configure.in's
as we speak.
 
You'll also need:

#if WE_DETECTED_A_VALID_ulInit_IN_THE_CONFIGURE_SCRIPT

  ulInit () ;

#endif

...uck!  Messy!

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

[Plib-devel] various updates to PLIB CVS

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

I made some updates to PLIB CVS

- BMP images are upside down.  i noticed the problem when i started using
PNG files.
  I fixed ssgImageLoader to vertically *flip* the BMP images and modified
the
  ssgLoadASE to set the V texture coordinate properly.

- I updated the ASE loader to create a parent heirarchy.  ASE has a
*NODE_PARENT tag
  which lets you do this.  the parent heirarchy should allow more
sophisticated
  control of the model transforms.  you'll have to do skeletal animation
manually.
  i've given up on transform animation with ASE because of incomplete info
in the
  file format.

- I added MESH_ANIMATION support to the ASE loader.  If it sees
*MESH_ANIMATION then it
  builds a ssgTimedSelector entity to the scene graph.  I tested this with a
shark model
  I have that bends back and forth.  It works great.  Of course, you can do
this with
  multiple models yourself but the ASE format has mesh animation built into
it.  If I can
  find some models that I can opensource, I will.

- I added the ssgIndexArray to the ssgCreateData structure.  This is the
first step
  toward allowing the loaders to use Mark's vertex array class.

still working on the Blender VRML loader.  It's going well.  Just taking a
little
longer than I hoped. :)

-- Dave McClurg
mailto:dav...@dy...         http://www.dynamix.com
mailto:da...@po... (home)            http://www.pond.net/~davem 

Re: [Plib-devel] New CVS of PLIB pre-1.3.1

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

Steve,

Is there any way that you can engineer things on the plib end to
generate some sort of helpful error when a current application that is
expecting plib-1.2.x (and doesn't remember to call ulInit() for
instance) suddenly is compiled against plib-1.3.x.  My fear is that 6
months down the line when plib-1.3.x transitions to the stable tree,
I'll have completely forgotten this message and will end up wasting a
lot of time.  :-)

Steve Baker writes:
> I've committed code into the PLIB 1.3 CVS tree that turns the 'UL'
> (Utility Library) from a somewhat invisible header file into something
> that the application code has to be aware of.
> 
> Previously, SSG used the src/util/ul.h header with a rather nasty
> trick to get the non-inlined functions compiled into the SSG library.
> 
> That was necessary for backwards compatibility of application's
> Makefiles.
> 
> Well, it's time to make libplibul.a and plib/ul.h into a 'real'
> utility library.
> 
> So, from the current CVS (which will soon be PLIB 1.3.1) onwards,
> applications must (at the very least) add '-lplibul' to their
> link lines (after all the other plib libraries is best).
> 
> This library will grow to include a number of functions that are
> traditionally Operating System functions - but which wouldn't be
> portable if you called the OS directly.  Other similar utility
> stuff that doesn't obviously belong anywhere else in PLIB will
> end up in libutil.
> 
> So far, there is a simple error handler (which is already in
> use within SSG's file loaders) and a fast, portable realtime
> timer class.
> 
> [ PPE is currently using 'guClock' from the TuxKart sources,
> this class exists in UL - but it's called 'ulClock', it includes
> member functions to set and get the maximum clock delta and has
> Windoze code to cater for systems that don't support the Performance
> Counter - it falls back to using the multimedia timer. ]
> 
> Right now, no PLIB applications will work with this new CVS version.
> 
> That's not a suprise - this is version 1.3.xx and it's expected to
> be unstable, etc.  If you need stability, use PLIB 1.2.0.
> 
> Ideally, one should add code into your configure.in to detect the
> presence of /usr/lib/libplibul.a and to add it to the link line
> if it exists.

Is there a good function in libplibul.a that we can test for?
Autoconf has the AC_CHECK_LIB( lib, function) macro that will test for
a library and add it to the link line if it exists.

> Programs that don't use SSG don't need libplibul - but that will
> certainly change as I use UL's error handler throughout PLIB.
> 
> If you want to call UL functions your code, you should:
> 
> 1)  #include <plib/ul.h>
> 
> 2)  Call 'ulInit()' before any other UL function.
> 
> 3)  Link with -lplibul.a
> 
> I hate non-reverse-compatible changes - but this one was unavoidable.
> We may possible add another PLIB library - for SSG utilities - but
> that will be truly optional.  UL is not because PLIB itself needs
> to use it.
> 
> Windoze users: Please don't get confused and look in the 'src/UL'
> directory for UL source code - that was a mistake that CVS isn't
> capable of fixing.  The correct place for UL code is src/util
> 
> If anyone out there could test ulClock under Windoze - and especially
> on a Windoze machine that *doesn't* have a Performance counter - that
> would be most welcome...I don't know whether the code even compiles
> right 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] TuxKart on Win32 works fine

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

I used a non-standard gzipper.  I've never had it fail before.
However, it does unzip and has the correct files in it.  At
least it works for me using WinZip on WinNT at work.  WinZip
reports the problem as trailing garbage.  Anyway, I'll follow
up and post a better version.

Posted.  Try again...  It should work now.  (I had to use real
ftp.  Some web-based uploader was putting extra characters at
the end of the file.)

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho


> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Tuesday, July 11, 2000 8:38 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] TuxKart on Win32 works fine
> 
> 
> "Vallevand, Mark K" wrote:
> 
> > http://vallevand.homepage.com/tuxkart/tuxkart-0.0.3-msvc.tar.gz
> > 
> > But, I forgot to include the workspace and project files.  But you
> > can see the code.
> 
> That link delivers a ~16kb file - but the GNU unzipper claims that
> it's prematurely truncated.
> 
> Any ideas?
> 
> -- 
> 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
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] SGSky class

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

Steve Baker writes:
> This looks *great*! 

Cool, I was fearing a violent reaction. :-) :-) :-)

> So do you want it to remain a part of SimGear - or should I slurp it
> up into an SSG-UT (utility toolkit) library?

For my purposes and goals right now it makes sense to keep this code
as a part of SimGear (www.simgear.org).  But, I have no problem with
keeping a parallel copy in ssg.  I think I've seen that performer has
some instant sky capabilities too, so putting this inside ssg is not
without precedent.

It may be that down the road if I'm pleased with how it all was merged
in with ssg I would just remove the sky code from SimGear and let the
official copy reside with ssg.

I imagine you would need to make some changes to integrate with ssg.
It might even make sense to change naming conventions and such.

> I can see how incorporating the things that FGFS needs (like
> SGEphemeris) would be hard if it were a part of SSG-UT - but if it
> would certainly be quite a bit more useful to non-simulation users
> if it were inside PLIB (one less dependancy!).

I tried to design the sky code in such a way that you can hardcode
your own object position values and not depend on real/current object
positions, etc.

However, it would be nice to keep things structure so you can continue
to easily plug in real world values so that the sky can always match
reality if that is what you want.

> (Of course, it doesn't have to be either/or - it could be in both -
> separately maintained).
> 
> Until I get time to play with it, it's hard to say.  The API looks
> pretty good though.

Ok, when you get a chance to play, let me know what you think.  I have
some additional things that might make sense to add to the api, and as
we look closer at things it might make sense to shuffle some of the
parameters around, but hopefully this is a good starting point.

Regards,

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

R: [Plib-devel] 3DS loader bug?

[Paolo L. <p.l...@ci...>]

Scott McMillan wrote:
>
> I am not sure what you are saying.  Are you saying the scale is
> swapped but the offset is not? In other words, is the code as
> written in version 1.2.0 correct:
>
>     parse_uscale goes to element [1]
> but parse_uoffst goes to element [0]
>
> etc....?  I personally don't have the capability of generating
> 3ds models to test this aspect.
>

Premise:
Max (like, perhaps, the older 3DStudio) conceptually separates UVW Mapping
(per object) and transformations on the texture image (per material). The
former implicitly modifies object texture coordinates, while the latter goes
as explicit uv scale and offset values among the material params - these are
the values we are talking about. In particular, scale is the Tiling value
within the Max Material Editor user interface (the default 1.0 value is not
written in the 3DS file, so the need of an initialization at the end of the
file!).

Back to our problem, I *never* had occasion to apply an offset to a
(material) texture, yet normally put offset to objects' UVW mapping.

Just now I did a test on texture uv-offset and experienced that the right
Max -> SSG mapping can be obtained by negating the u-offset, i.e. in the
source

static int parse_uoffst( char **p, unsigned int length )
{
  texture_offst[ num_materials - 1 ][0] = -get((float*)*p);   <<== !
  return PARSE_OK;
}

static int parse_voffst( char **p, unsigned int length )
{
  texture_offst[ num_materials - 1 ][1] = get((float*)*p);
  return PARSE_OK;
}

so, for answering to your question, as to my datasets:
- u-scale goes to index 1
- u-offset goes to index 0, but with the opposite sign.
Scale/offset on object UV-mapping does correctly work since is directly
managed by Max.

I'll do some further tests on this, but I would like to hear some other
experience on this. Per and I should then converge to a new version of the
3DS loader.

----------------------------------------------------------------------------
-
Paolo Leoncini						phone:  +39 (0823) 623134
Scientific Visualization Group			fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches	p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy		www.cira.it/research/vis

Re: [Plib-devel] New CVS of PLIB pre-1.3.1

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

Steve Baker wrote:
> 
> Wolfram Kuss wrote:
> >
> > Steve Baker wrote:
> >
> > >[ PPE is currently using 'guClock' from the TuxKart sources,
> > >this class exists in UL - but it's called 'ulClock', it includes
> > >member functions to set and get the maximum clock delta and has
> > >Windoze code to cater for systems that don't support the Performance
> > >Counter - it falls back to using the multimedia timer. ]
> >
> > Great, thanks!
> >
> > BTW, why is there an
> > void ulInit ( void )
> > in both ul.cxx and ulError.cxx? Should one not use ul.cxx?
> 
> Oops!  I didn't notice the on in ulError - I'll fix it now.

OK - that's committed - sorry!

-- 
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] New CVS of PLIB pre-1.3.1

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

Wolfram Kuss wrote:
> 
> Steve Baker wrote:
> 
> >[ PPE is currently using 'guClock' from the TuxKart sources,
> >this class exists in UL - but it's called 'ulClock', it includes
> >member functions to set and get the maximum clock delta and has
> >Windoze code to cater for systems that don't support the Performance
> >Counter - it falls back to using the multimedia timer. ]
> 
> Great, thanks!
> 
> BTW, why is there an
> void ulInit ( void )
> in both ul.cxx and ulError.cxx? Should one not use ul.cxx?

Oops!  I didn't notice the on in ulError - I'll fix it now.

-- 
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] New CVS of PLIB pre-1.3.1

[Wolfram K. <w_...@rz...>]

Steve Baker wrote:

>[ PPE is currently using 'guClock' from the TuxKart sources,
>this class exists in UL - but it's called 'ulClock', it includes
>member functions to set and get the maximum clock delta and has
>Windoze code to cater for systems that don't support the Performance
>Counter - it falls back to using the multimedia timer. ]

Great, thanks!

BTW, why is there an 
void ulInit ( void )
in both ul.cxx and ulError.cxx? Should one not use ul.cxx?

Bye bye,
Wolfram Kuss.

Re: [Plib-devel] SGSky class

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

"Curtis L. Olson" wrote:
> 
> I've been working on adapting the FlightGear sky code to be a "drop
> in" sky class for use in any plib/ssg based programs.
> 
> For those that are interested, here is the initial documentation for
> my SGSky class:
> 
>     http://www.simgear.org/Docs/SGSky/

This looks *great*! 

> As I've found quite often before, sitting down and documenting
> something makes me ask why in the heck did I impliment it that way and
> exposes lots of little inconsistancies and organizational issues. :-)

None of those are really obvious.

> This is part of my larger "SimGear" package:  www.simgear.org

So do you want it to remain a part of SimGear - or should I slurp it
up into an SSG-UT (utility toolkit) library?

I can see how incorporating the things that FGFS needs (like SGEphemeris)
would be hard if it were a part of SSG-UT - but if it would certainly
be quite a bit more useful to non-simulation users if it were inside
PLIB (one less dependancy!).

(Of course, it doesn't have to be either/or - it could be in both -
separately maintained).

> I'm happy to entertain comments, feedback, questions, etc.

Until I get time to play with it, it's hard to say.  The API looks
pretty good though.

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