plib-devel

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

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

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.

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.

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

> 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] [Fwd: Model loader (fwd)]

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

There was a comment today on the OpenGL Games Developers' list.

We were talking about ASE loaders.  I wonder if this is of use
to people messing with the PLIB ASE loader.

> ---------- Forwarded message ----------
> From: Ales Mlakar <ja...@sl...>
> To: Multiple recipients of list OPENGL-GAMEDEV-L
>      <OPE...@fa...>
> Subject: Re: Model loader

> Acctually, it's not posibile to extract hierarchy from an ASE file becouse
> of the lack of Pivot info. You will be able to, for example if all your
> models rotate around 0,0,0 local space, else you'll have to write a new
> exporter.
-----------------------------------------------------------------------


-- 
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: R: [Plib-devel] 3DS loader bug? [Fwd: Porting loaders to SGL]

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

Paolo Leoncini wrote:
> 
> > Scott McMillan wrote:
> >
> > > 2) I may have found a bug.  Not knowing the 3ds format at all, I
> > > cannot be sure.  It involves the parsing texture scale and offset
> > > parameters starting at line 343 (of PLIB version 1.2.0).  Shouldn't
> > > parse_uscale() stick the value into element 0 of the texture_scale?

<snip>

> I modified Per Liedman's 3DS loader in this way since 3DS files exported by
> 3DStudio Max (3.0) present such u-v scale swap (coming from the
> repetition/tiling param). Have you tried with any datafile?

(I forwarded this bug report message from Scott - I don't know if he's subscribed here)

-- 
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] 3DS loader bug? [Fwd: Porting loaders to SGL]

[Scott M. <mcm...@ca...>]

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.

Paolo Leoncini wrote:
> 
> > Scott McMillan wrote:
> >
> > > 2) I may have found a bug.  Not knowing the 3ds format at all, I
> > > cannot be sure.  It involves the parsing texture scale and offset
> > > parameters starting at line 343 (of PLIB version 1.2.0).  Shouldn't
> > > parse_uscale() stick the value into element 0 of the texture_scale?
> > >
> > > static int parse_uscale( char **p, unsigned int length )
> > > {
> > >   texture_scale[ num_materials - 1 ][1] = get((float*)*p);
> > > //                                  ^^^
> > > //                                   0?
> > >   return PARSE_OK;
> > > }
> > >
> > > static int parse_vscale( char **p, unsigned int length )
> > > {
> > >   texture_scale[ num_materials - 1 ][0] = get((float*)*p);
> > > //                                  ^^^
> > > //                                   1?
> > >   return PARSE_OK;
> > > }
> > >
> > > 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;
> > > }
> 
> I modified Per Liedman's 3DS loader in this way since 3DS files exported by
> 3DStudio Max (3.0) present such u-v scale swap (coming from the
> repetition/tiling param). Have you tried with any datafile? I did it with
> textured 3DS'es produced by Max, Sim Rational Reducer (very good!), and
> Rhino3D - it seems to work. But I can't exclude exceptions to this
> experimental rule.

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

RE: [Plib-devel] RE: Model Formats

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

Good.  I couldn't believe that it wouldn't work, but couldn't
see how it was done.

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

> 
> "Vallevand, Mark K" wrote:
> > 
> > I was looking at the SSG code for save and load.  It looks 
> like object
> > that are in the scene graph more than once are written more 
> that once.
> > So, when the load is done, one object becomes many.
> 
> I don't think so.
> 
> Check out line 309 or so of plib/src/ssg/ssgBranch.cxx,
> it uses the 'spare' field of the database node (which is
> re-used for all sorts of short-term tree-walking kinds of
> things).  As a node is written out, we set the spare field
> to a consecutively incrementing non-zero value.  When we
> try to write it out the second time, the ssgBranch code
> notices that the spare field is non-zero and instead
> writes out a special 'BACKWARDS REFERENCE' node that
> contains the 'spare' value.
> 
> When the model is reloaded, we build an ssgList of all
> the entities that are loaded - if we see a 'BACKWARDS REFERENCE'
> node - then we just link to the entry in the table pointed
> to by that 'spare' field.
> 
> This same mechanism is used to save writing out the same
> ssgState many times...and possibly other node types also.
> 
> > Is this correct, or am I dropping bits in my memory?
> 
> I *hope* you are incorrect - I went to some trouble to
> ensure that things wouldn't be written out more than once.
> 
> If this isn't working for you, please send me a concrete
> example of it failing.
> 
> -- 
> 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] TuxKart on Win32 works fine

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

> 
> "Vallevand, Mark K" wrote:
> > 
> > I ported TuxKart to Win32 last night.  It was pretty easy.  It
> > is very runable at 640x480 with accelerated OpenGL on a P2-333.
> > 
> > I found a bunch of typical unix-isms and window-isms in the code.
> > This is a common one that doesn't work in windows:
> > 
> > for ( int i = 0; i < foo; i++ ) blah();
> > for ( int i = 0; i < foo; i++ ) moreblah();
> 
> Well, it *does* work in Windoze - it just doesn't work with MSVC++.
> CygWin has no problems with it.

Correct.  I made a series of MSVC++ changes.  Not just Win32.

> 
> If you'd care to post your fixes to a web site somewhere - I'll
> merge them into the current stuff.  Alternatively, if you'd like
> CVS access - let me know what your sourceforge userid is and I'll
> "make it so".
> 
> > The GLUT game mode doesn't work as advertised on my system, so I
> > hacked it to run in a window like non-win32 systems.  I want to
> > investigate this more.  It *should* work.
> 
> Yes - I'm not too sure about that code - it doesn't work
> well on all Linux systems either.

I made a simple change that works will for me.  I don't supply
the game mode string and just let the game mode code use its
defaults.

> 
> > Also, the joystick code misbehaves if you have a broken joystick
> > driver.  My WinNT joystick driver stopped reporting buttons.  All
> > buttons are set.  It might be the port HW.  I tried other sticks.
> > Anyway, after unplugging the joystick, everything works fine.
> 
> That's strange - the joystick code is just PLIB - and that's
> reported to work OK for FGFS and Tux_AQFH under Windoze.
> 
> Does the PLIB joystick test program exhibit the same symptoms?

I haven't tried it, but I have tried the NT joystick setup, and,
yes, it fails, too.  It looks like either all buttons are lit.

>  
> > I'll clean up my changes and put them, a DevStudio workspace and
> > project, and an executable Win32 Tuxkart on a website later.  Maybe
> > tonight or this weekend.
> 
> OK.
> 

http://vallevand.homepage.com/tuxkart/tuxcart.exe
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.

> -- 
> Steve Baker


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

RE: [Plib-devel] MS VC6 changes for Tuxkart

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

Try these urls...

http://vallevand.homepage.com/tuxkart/tuxcart.exe
http://vallevand.homepage.com/tuxkart/tuxkart-0.0.3-msvc.tar.gz

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: Vallevand, Mark K [mailto:Mar...@un...]
> Sent: Monday, July 10, 2000 11:59 AM
> To: 'pli...@li...'
> Subject: [Plib-devel] MS VC6 changes for Tuxkart
> 
> 
> http://vallevand.homepage.com/tuxkart
> 
> There is a gzip'd tar file with the changes and an
> executable of tuxkart.
> 
> Homepage seems to be down for maintenance, but the
> url *should* work.
> 
> 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
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

R: [Plib-devel] 3DS loader bug? [Fwd: Porting loaders to SGL]

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

> Scott McMillan wrote:
>
> > 2) I may have found a bug.  Not knowing the 3ds format at all, I
> > cannot be sure.  It involves the parsing texture scale and offset
> > parameters starting at line 343 (of PLIB version 1.2.0).  Shouldn't
> > parse_uscale() stick the value into element 0 of the texture_scale?
> >
> > static int parse_uscale( char **p, unsigned int length )
> > {
> >   texture_scale[ num_materials - 1 ][1] = get((float*)*p);
> > //                                  ^^^
> > //                                   0?
> >   return PARSE_OK;
> > }
> >
> > static int parse_vscale( char **p, unsigned int length )
> > {
> >   texture_scale[ num_materials - 1 ][0] = get((float*)*p);
> > //                                  ^^^
> > //                                   1?
> >   return PARSE_OK;
> > }
> >
> > 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;
> > }

I modified Per Liedman's 3DS loader in this way since 3DS files exported by
3DStudio Max (3.0) present such u-v scale swap (coming from the
repetition/tiling param). Have you tried with any datafile? I did it with
textured 3DS'es produced by Max, Sim Rational Reducer (very good!), and
Rhino3D - it seems to work. But I can't exclude exceptions to this
experimental rule.

Greetings -

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

[Plib-devel] 3DS loader bug? [Fwd: Porting loaders to SGL]

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

Scott McMillan wrote:

> 2) I may have found a bug.  Not knowing the 3ds format at all, I
> cannot be sure.  It involves the parsing texture scale and offset
> parameters starting at line 343 (of PLIB version 1.2.0).  Shouldn't
> parse_uscale() stick the value into element 0 of the texture_scale?
> 
> static int parse_uscale( char **p, unsigned int length )
> {
>   texture_scale[ num_materials - 1 ][1] = get((float*)*p);
> //                                  ^^^
> //                                   0?
>   return PARSE_OK;
> }
> 
> static int parse_vscale( char **p, unsigned int length )
> {
>   texture_scale[ num_materials - 1 ][0] = get((float*)*p);
> //                                  ^^^
> //                                   1?
>   return PARSE_OK;
> }
> 
> 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;
> }

-- 
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:
> 
> I ported TuxKart to Win32 last night.  It was pretty easy.  It
> is very runable at 640x480 with accelerated OpenGL on a P2-333.
> 
> I found a bunch of typical unix-isms and window-isms in the code.
> This is a common one that doesn't work in windows:
> 
> for ( int i = 0; i < foo; i++ ) blah();
> for ( int i = 0; i < foo; i++ ) moreblah();

Well, it *does* work in Windoze - it just doesn't work with MSVC++.
CygWin has no problems with it.

If you'd care to post your fixes to a web site somewhere - I'll
merge them into the current stuff.  Alternatively, if you'd like
CVS access - let me know what your sourceforge userid is and I'll
"make it so".

> The GLUT game mode doesn't work as advertised on my system, so I
> hacked it to run in a window like non-win32 systems.  I want to
> investigate this more.  It *should* work.

Yes - I'm not too sure about that code - it doesn't work
well on all Linux systems either.

> Also, the joystick code misbehaves if you have a broken joystick
> driver.  My WinNT joystick driver stopped reporting buttons.  All
> buttons are set.  It might be the port HW.  I tried other sticks.
> Anyway, after unplugging the joystick, everything works fine.

That's strange - the joystick code is just PLIB - and that's
reported to work OK for FGFS and Tux_AQFH under Windoze.

Does the PLIB joystick test program exhibit the same symptoms?
 
> I'll clean up my changes and put them, a DevStudio workspace and
> project, and an executable Win32 Tuxkart on a website later.  Maybe
> tonight or this weekend.

OK.

-- 
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] RE: Model Formats

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

"Vallevand, Mark K" wrote:
> 
> I was looking at the SSG code for save and load.  It looks like object
> that are in the scene graph more than once are written more that once.
> So, when the load is done, one object becomes many.

I don't think so.

Check out line 309 or so of plib/src/ssg/ssgBranch.cxx,
it uses the 'spare' field of the database node (which is
re-used for all sorts of short-term tree-walking kinds of
things).  As a node is written out, we set the spare field
to a consecutively incrementing non-zero value.  When we
try to write it out the second time, the ssgBranch code
notices that the spare field is non-zero and instead
writes out a special 'BACKWARDS REFERENCE' node that
contains the 'spare' value.

When the model is reloaded, we build an ssgList of all
the entities that are loaded - if we see a 'BACKWARDS REFERENCE'
node - then we just link to the entry in the table pointed
to by that 'spare' field.

This same mechanism is used to save writing out the same
ssgState many times...and possibly other node types also.

> Is this correct, or am I dropping bits in my memory?

I *hope* you are incorrect - I went to some trouble to
ensure that things wouldn't be written out more than once.

If this isn't working for you, please send me a concrete
example of it failing.

-- 
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] SGSky class

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

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/

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. :-)
In the process of writing the docs I cleaned quite a few things up,
but ran out of steam and left a few things as is.  So, the result
isn't 100% satisfying and there is a ton of room for improvement, but
this is what I have so far.

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

The most current code should be fetched via anonymous cvs (directions
are at the web site.)

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

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

[Plib-devel] MS VC6 changes for Tuxkart

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

http://vallevand.homepage.com/tuxkart

There is a gzip'd tar file with the changes and an
executable of tuxkart.

Homepage seems to be down for maintenance, but the
url *should* work.

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

RE: [Plib-devel] Model Formats

[Per L. <li...@ho...>]

On Wed, 05 Jul 2000, Dave McClurg wrote:
> The 3ds loader was created by Per Liedman.  It is a very important
> *binary* format.  AFAIK, it works correctly and supports textures.
> Per?

The last time I checked, which was some time ago, the loader worked, but it
didn't seem to hard to find strange models that would cause somewhat awkward
results...which is kind of disappointing, I must confess. I and Paolo Leoncini
are discussing some changes to improve the performance. I also think Paolo has a
more up to date opinion of how well the loader actually works.

> Another *big* todo item is to add ssgIndexArray to the _ssgCreateFunc
> so it can support Mark's ssgVertexArray.cxx module.  That would
> make large ASE models load and render faster since they are
> naturally in indexed array form.

I must have a look at this stuff, since it definitely sounds like something the
3ds-loader could use...

Regards,
Per Liedman

-- 
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

[Plib-devel] Confusion with sign of pitch

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

I have a trivial question:

If I am in a slightly ascending aeroplane, is my pitch positive?
Looking at

void sgHPRfromVec3 ( sgVec3 hpr, const sgVec3 src )

at the line

  hpr[1] = -(SGfloat) atan2 ( tmp [ 2 ], sqrt ( sgSquare ( tmp [ 0 ] )
+ sgSquare ( tmp [ 1 ] ) ) ) *
SG_RADIANS_TO_DEGREES ;

it seems to be negative, is that correct?

Bye bye,
Wolfram Kuss.

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

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

> -----Original Message-----
> From: Norman Vine [mailto:nh...@ca...]
> Sent: Thursday, July 06, 2000 10:44 AM
> To: pli...@li...
> Subject: RE: [Plib-devel] TuxKart on Win32 works fine
> 
> 
> Mark Vallevand writes:
> 
> >The GLUT game mode doesn't work as advertised on my system, so I
> >hacked it to run in a window like non-win32 systems.  I want to
> >investigate this more.  It *should* work.
> 
> Hmm...  This code is identical to what we use in FGFS
> try changing the gamemode string to
>   sprintf( game_mode_str, "width=640 height=480 bpp=32" );
>     experiment with the bpp=%d
> This should really be a command line option

I'll play with this.  I'd also like to change it to switch to game mode
in the current resolution.  Switching to 640x480 full screen does
funky stuff to my system.  And, yes, it should be an option somehow.
> 
> >
> >Also, the joystick code misbehaves if you have a broken joystick
> >driver.  My WinNT joystick driver stopped reporting buttons.  All
> >buttons are set.  It might be the port HW.  I tried other sticks.
> >Anyway, after unplugging the joystick, everything works fine.
> 
> Hmm..
> Works fine on Cygwin
>  which is using the same code as you are..

I'm reasonably sure that its busted HW or SW on my system.  I just
need to dig some more.

> 
> Cheers
> 
> Norman

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

> 

RE: [Plib-devel] RE: Model Formats

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

Besides AC3D, the only one I'm comfortable with is using "3d studio max" to
export ASE files.
Wavefront OBJ is a pretty common format but not sure which modelers export
it well.
I'm also working on writing a "VRML 1.0 ascii" loader for use with "blender"

--Dave

> Hello 
> 
> Thanks for your help Dave and Steve. You are right I did know 
> about ssg and
> ac3d, and I was looking to find if any of the new types where 
> implemented.
> Know I can find a modeler for these formats.
> One think is there any other modelers around that support ssg 
> format other
> then pretty poly.
> 
> Thanks Ben

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

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

Mark Vallevand writes:
>
>I ported TuxKart to Win32 last night.  It was pretty easy.  It
>is very runable at 640x480 with accelerated OpenGL on a P2-333.

Cool !
 
FWIW it only took a couple of hours to get Cygwin supported

>The GLUT game mode doesn't work as advertised on my system, so I
>hacked it to run in a window like non-win32 systems.  I want to
>investigate this more.  It *should* work.

Hmm...  This code is identical to what we use in FGFS
try changing the gamemode string to
  sprintf( game_mode_str, "width=640 height=480 bpp=32" );
    experiment with the bpp=%d
This should really be a command line option

>
>Also, the joystick code misbehaves if you have a broken joystick
>driver.  My WinNT joystick driver stopped reporting buttons.  All
>buttons are set.  It might be the port HW.  I tried other sticks.
>Anyway, after unplugging the joystick, everything works fine.

Hmm..
Works fine on Cygwin
 which is using the same code as you are..

Cheers

Norman

[Plib-devel] TuxKart on Win32 works fine

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

I ported TuxKart to Win32 last night.  It was pretty easy.  It
is very runable at 640x480 with accelerated OpenGL on a P2-333.

I found a bunch of typical unix-isms and window-isms in the code.
This is a common one that doesn't work in windows:

for ( int i = 0; i < foo; i++ ) blah();
for ( int i = 0; i < foo; i++ ) moreblah();

There were some header file adjustments, and some system functions
that have different names, eg access() and chdir().

The GLUT game mode doesn't work as advertised on my system, so I
hacked it to run in a window like non-win32 systems.  I want to
investigate this more.  It *should* work.

Also, the joystick code misbehaves if you have a broken joystick
driver.  My WinNT joystick driver stopped reporting buttons.  All
buttons are set.  It might be the port HW.  I tried other sticks.
Anyway, after unplugging the joystick, everything works fine.

I'll clean up my changes and put them, a DevStudio workspace and
project, and an executable Win32 Tuxkart on a website later.  Maybe
tonight or this weekend.

Thanks Steve and Oliver.  I have some neat ideas for TuxKart.

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
 

RE: [Plib-devel] RE: Model Formats

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

I was looking at the SSG code for save and load.  It looks like object
that are in the scene graph more than once are written more that once.
So, when the load is done, one object becomes many.

Is this correct, or am I dropping bits in my memory?

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


> No - nothing else will support '.ssg' format - that is 
> something that is
> unique to PLIB's SSG module.  PrettyPoly supports it only because it
> happens to use SSG - so it was easy.
> -- 
> Steve Baker  

Re: [Plib-devel] [Fwd: [TuxKart-users] I have a compilation problem]

[Bernie B. <bb...@bi...>]

Steve Baker wrote:
> 
> Norman Vine wrote:
> >
> > Steve Baker writes:
> > >>
> > >
> > >> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use
> > >this function)
> > >
> > >...
[snip]
> >
> > Steve,
> >
> > I went through this torment of not seeing  float.h when I first started
> > using gcc.  Then one day I noticed that a program was complaining
> > about conflicting with <float.h>  after much searching I finally found
> > it hiding in
> >
> > / lib / gcc-lib / i686-pc-cygwin / 2.95.2 / include
> >
[snip]
> 
> Yep - that make sense - so the compiler should know where the
> magic include directory is.  In your case it knows to look
> in i686-pc-cygwin/2.95.2 - and in my case, it knows about
> 
> /usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h
> 
> ...but how does it know that this is a SuSE Linux machine?
> 
> Our friend over on TuxKart-users (who is unfortunately
> not a programmer) is getting complaints that you and I
> don't see.
> 
> Perhaps this is a screwup in the Mandrake distro?
> 
> I hope not.
> 
> Are there any Mandrake users listening who could
> check this out?

Under my Mandrake 7.1 installation <float.h> is
/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/include/float.h.  Just
updated my CVS source and it compiles fine.

Bernie

RE: [Plib-devel] [Fwd: [TuxKart-users] I have a compilation problem]

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

Steve Baker writes:
>
>Norman Vine wrote:
>>  >
>> >> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use
>> >this function)
>> >

<snip>

>> 
>> I believe the rationale behind this is that float.h is very
>> compiler and machine specific and by doing it this way
>> gcc can support cross-compiling and native-compiling
>> on the same host :-)
>
>Yep - that make sense - so the compiler should know where the
>magic include directory is.  In your case it knows to look
>in i686-pc-cygwin/2.95.2 - and in my case, it knows about
>
>/usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h
>
>...but how does it know that this is a SuSE Linux machine?

The machine type and version of the compiler is hardwired wired
in at compile time.  

strings /bin/gcc.exe > jnk
head -n 2 jnk    // Not sure if these are always the first two strings
2.95.2
i686-pc-cygwin

and gcc uses these to find the actual compiler tools
and libc ect based on their path

>Our friend over on TuxKart-users (who is unfortunately
>not a programmer) is getting complaints that you and I
>don't see.

Isn't this problem solved if we just add  to <sg.h>
#include <float.h>

ANSII guarantees that the compiler will be able to find <float.h>

Cheers

Norman

Re: [Plib-devel] [Fwd: [TuxKart-users] I have a compilation problem]

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

Norman Vine wrote:
> 
> Steve Baker writes:
> >>
> >
> >> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use
> >this function)
> >
> >...
> >
> >This seems to be related to the problem with FLT_EPSILON being
> >undefined in some places and <float.h> being "missing" sometimes.
> >
> >Dunno if anyone can shed any light on this - but indeed, the
> >classic C header
> >"/usr/include/float.h" is not present under my SuSE 6.4
> >system...and none of
> >the other headers in /usr/include or and of it's
> >subdirectories seem to have
> >a definition for FLT_MAX.
> >
> 
> Steve,
> 
> I went through this torment of not seeing  float.h when I first started
> using gcc.  Then one day I noticed that a program was complaining
> about conflicting with <float.h>  after much searching I finally found
> it hiding in
> 
> / lib / gcc-lib / i686-pc-cygwin / 2.95.2 / include
> 
> I think that this is standard for gcc
> ( substitute your machine type for i686-pc-cygwin
>   and 2.95.2 for your version of gcc in the above )
> and that you can just include <float.h> and it will be
> automagically picked up.
> 
> I believe the rationale behind this is that float.h is very
> compiler and machine specific and by doing it this way
> gcc can support cross-compiling and native-compiling
> on the same host :-)

Yep - that make sense - so the compiler should know where the
magic include directory is.  In your case it knows to look
in i686-pc-cygwin/2.95.2 - and in my case, it knows about

/usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h

...but how does it know that this is a SuSE Linux machine?

Our friend over on TuxKart-users (who is unfortunately
not a programmer) is getting complaints that you and I
don't see.

Perhaps this is a screwup in the Mandrake distro?

I hope not.

Are there any Mandrake users listening who could
check this out?

-- 
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] [Fwd: [TuxKart-users] I have a compilation problem]

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

Steve Baker writes:
>> 
>
>> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use 
>this function)
>
>...
>
>This seems to be related to the problem with FLT_EPSILON being 
>undefined in some places and <float.h> being "missing" sometimes.
>
>Dunno if anyone can shed any light on this - but indeed, the 
>classic C header 
>"/usr/include/float.h" is not present under my SuSE 6.4 
>system...and none of
>the other headers in /usr/include or and of it's 
>subdirectories seem to have
>a definition for FLT_MAX.
>

Steve,

I went through this torment of not seeing  float.h when I first started
using gcc.  Then one day I noticed that a program was complaining
about conflicting with <float.h>  after much searching I finally found
it hiding in 

/ lib / gcc-lib / i686-pc-cygwin / 2.95.2 / include

I think that this is standard for gcc 
( substitute your machine type for i686-pc-cygwin
  and 2.95.2 for your version of gcc in the above )
and that you can just include <float.h> and it will be
automagically picked up.

I believe the rationale behind this is that float.h is very
compiler and machine specific and by doing it this way
gcc can support cross-compiling and native-compiling
on the same host :-)

Cheers

Norman