plib-devel

[Plib-devel] New release (Was: puAuxList.cxx)

[Erik H. <er...@eh...>]

Bram Stolk wrote:

> What's the status on this?

I't not yet committed.

> Wasn't there an issue that someone forget to check in, and is now
> having cvs troubles?

Yep, if you would want to do this for me.

After that, wouldn't it be time for the new release to happen, that way 
you might not miss the next release of FlightGear.

Erik

[Plib-devel] Debug messages with 1.8.3 / ATI problems on Mac

[Jan R. <slo...@gm...>]

Hello!

I'm currently rewriting the graphics engine of the CRRCsim model airplane
flight simulator to use SSG (and some other parts of PLIB). Right now
we're running a mixture of "old" OpenGL code and "new" SSG code. The
sky dome and the airplane models are drawn by SSG but the scenery and some
parts of the 2D screen overlay are still using plain OpenGL.

Until now the conversion was quite easy and problem-free, but right now
we're facing three strange problems. I don't know if they are really
caused by PLIB, but maybe they are related to it and therefore I hope
that maybe someone on this list has an idea what goes wrong.

First problem: one developer reports strange debugging messages
when linking with plib-1.8.3 (from the Debian repository) on
Debian Sarge GNU/Linux:

[_ae_loopback_array_elt,759] aa->offset = 57
[_ae_loopback_array_elt,759] aa->offset = 137

This problem only arises when a special AC3D model is loaded into the
scenegraph. With other models the message does not appear. When
linking against plib-1.8.4 (this time built from source) the
messages are also gone. But grep-ing through the 1.8.3 source code did 
not reveal a line that could produce a message like this.

Any idea where this messages could come from?


Second problem, on the same computer: All untextured AC3D models
look plain white. This problem hasn't shown up on any other
computer yet. Textured models look o.k., and the problem only
arises with 1.8.4. With 1.8.3 (and after removing any "crease"
entries from the .ac files) all models look right.


Next problem: Some MacOSX-users are reporting a missing texture on
the sky dome. The dome (not using the ssgaSky class) simply
consists of some vertex arrays which form a half sphere. The vertices
don't have a color value but are assigned texture coordinates from one
256x256 pixel RGB texture. This looks alright on Linux machines
and on an iMac, but two users with ATI-powered-Macs reported a plain
white sky sphere.

I don't think that this problem is related to PLIB at all, but maybe 
other PLIB applications have this problem as well and maybe even
could provide a solution. Some details on one of the machines from
the CRRCsim log file:

Using the following rendering mode:
  Renderer:    ATi Rage 128 Pro OpenGL Engine
  Vendor:      ATI Technologies Inc.
  GL version:  1.1 ATI-1.4.4
  RGBA bpp:    8/8/8/8
  Depth bpp:   24
  Stencil bpp: 0

BTW, the OpenGL window is initialized using SDL. Don't know if this
could be related to any of these problems.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

[Plib-devel] [PATCH] DirectX file loader bugfix

[Jan R. <slo...@gm...>]

Hello,

attached to this mail you find an enhanced patch for ssgLoadX.cpp and
ssgLoaderWriterStuff.cpp. I've already posted this patch before, but
this time I've included an additional fix for loading .x files that
don't fully comply with the .x spec.

Could someone please add this patch to the CVS?

List of all changes:

1.) When loading an .x file, all materials will be stored in
a globalMaterialList, but the materials are never added to the
LoaderWriterMesh. I've added a fix to ssgLoadX.cxx that adds the
created SimpleStates to the mesh.

2.) Second bugfix is for the mesh handler itself. There's a global
variable currentDiffuse that holds the most recent diffuse colour
found by the ASCII parser. Now when composing the final SSG branch,
all leafs not containing a colour array will be set to this
variable's value. This is, in fact, the colour that was defined last
in whatever file we were parsing. But this is wrong, the right
diffuse colour is located in the SimpleState that is used to draw
the leaf. Therefore we have to create the colour array with that
value. To understand the effect of this bug, here's what I experienced
while bug-hunting: I used a .x airplane model which contained 5 materials.
All materials but the last one were opaque, only the last (used to draw
the propeller disc) was 80% translucent. This caused the whole model
to look 80% translucent because the model did not contain any per-vertex
or per-face colour values, only the colours defined by the materials
(and the GL_COLOR_MATERIAL mode).

3.) I've encountered a lot of .x files that feature a texture
coordinate array which is formatted

...
u1;v1;
u2;v2;
...

instead of

...
u1;v1;,
u2;v2;,
...

The current parser won't work without the commas. My fix removes the
comma-check and makes the parser simply search for the next float
value.

I've tested all fixes with my own application and with the pview example.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

[Plib-devel] puAuxList.cxx

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

Frederic Bouvier wrote:
>>>A shame about missing the FG release though :-(
>>
>>There will be other releases.  :-)
> 
> 
> Perhaps in the meantime, puAuxList.cxx would find its way to the CVS repository
> ?


What's the status on this?
Wasn't there an issue that someone forget to check in, and is now
having cvs troubles?

  Bram

> 
> -Fred
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[steve <sjb...@ai...>]

Bram Stolk wrote:
> steve wrote:
> 
> 
>>So I'm left wondering why someone thought this fixed a bug -
>>and I'm guessing that whatever they did wasn't necessarily
>>correct and that we should look more carefully and inquire
>>as to what was intended to be fixed.
> 
> 
> Ok, I'll be more careful next time, but a crash of flightgear
> was reported on this list, in this posting:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_id=9160195&forum_id=4479
> 
> Can you live with the current "r" mode, or do you want "ra" back
> in?

Oh - no - I'm sure that just 'r' is fine.

I'm just suprised that this fixed anything.

> As you said, the 'a' was probably a mistake by a PDP-7 programmer
> who retired in the 90s :-)

Hey - be careful... I programmed a PDP-7 once.

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Mathias <Mat...@gm...>]

Whoow,

What a huge thread for that. The fact that I read my private mail only at h=
ome=20
and not during the daytime takes me totally off such discussions ...

On Mittwoch 07 Dezember 2005 10:50, Melchior FRANZ wrote:
> * Bram Stolk -- Wednesday 07 December 2005 10:42:
> > > You have to deal with both \r and \n. But IIRC I submitted a fix for
> > > exactly this problem (r1.31, r1.32),
> >
> > So, what do you suggest now? Revert it back to "ra" ?
>
> No, on the contrary. Mathias has apparently found out that "ra" leads
> to crashes. It isn't standard, and that ssgLoadAC.cxx wouldn't work
> without the "a" is (a) unproofed, and (b) unlikely (because the \r&\n
> issue *has* been dealt with already). Looks like the next release isn't
> urgent, as FlightGear 0.9.9 has been released without waiting for it,
> so I think we can wait until someone reports a problem.
Almost exactly true, except that credits should be forwarded to my chief Ol=
af=20
=46lebbe who appears to be infected by the flightgear virus by me :)

He just forwarded that to me and I was searching for a plausible explanatio=
n=20
in between breakfast and traveling to work ...

So sorry for the false explanation by me and many thanks for applying!

    Greetings

          Mathias

=2D-=20
Mathias Fr=F6hlich, email: Mat...@gm...

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Andy R. <an...@pl...>]

steve wrote:
> Mainly though, the commit comment "Avoid append flag" shows a
> misunderstanding of what "ra" means.  It DOES NOT MEAN
> 'Append'.

It does, actually.  Or at least so say SUSv2 and MSDN:

http://www.opengroup.org/onlinepubs/007908799/xsh/fopen.html

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_fopen.2c_._wfopen.asp

The issue I think you're trying to explain is that it's not a
modifier -- you specify *either* "r" or "a" (or "w"), not both.
Neither spec defines a meaning for a second "a", and both are
silent as to what the meaning of extra undefined characters.
What was the purpose behind "ra" in the first place?

Andy

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Frederic B. <fre...@fr...>]

Quoting Bram Stolk <br...@sa...>:

> steve wrote:
>
> > So I'm left wondering why someone thought this fixed a bug -
> > and I'm guessing that whatever they did wasn't necessarily
> > correct and that we should look more carefully and inquire
> > as to what was intended to be fixed.
>
> Ok, I'll be more careful next time, but a crash of flightgear
> was reported on this list, in this posting:

The crash is real. It is Visual C++ 2005 that throws exceptions on invali=
d
options.

There are other strangeness that might appears logical at the seconf thou=
ght.
For example, strchr returns a 'const char *' in VC2005 although standard =
C says
that strchr should returns a char *. So loaders that do ( from memory ) :

const char *filename;
char *pt =3D strchr( filename, "/" );
*pt =3D '\0';

must be rewritten to add a const_cast statement.

-Fred

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

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

steve wrote:

> So I'm left wondering why someone thought this fixed a bug -
> and I'm guessing that whatever they did wasn't necessarily
> correct and that we should look more carefully and inquire
> as to what was intended to be fixed.

Ok, I'll be more careful next time, but a crash of flightgear
was reported on this list, in this posting:

http://sourceforge.net/mailarchive/forum.php?thread_id=9160195&forum_id=4479

Can you live with the current "r" mode, or do you want "ra" back
in? As you said, the 'a' was probably a mistake by a PDP-7 programmer
who retired in the 90s :-)

  Bram


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Frederic B. <fre...@fr...>]

Quoting steve :

> Bram Stolk wrote:
> > steve wrote:
> >
> >>Bram Stolk wrote:
> >>
> >>
> >>>Update of /cvsroot/plib/plib/src/ssg
> >>>In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8823
> >>>
> >>>Modified Files:
> >>>    ssgLoadAC.cxx Log Message:
> >>>Avoid append flag. Fix by Mathias
> >>
> >>
> >>-  loader_fd =3D fopen ( filename, "ra" ) ;
> >>+  loader_fd =3D fopen ( filename, "r" ) ;
> >>
> >>
> >>Wooaaahhhhhh.
> >>
> >>That's not right!
> >>
> >>The 'a' flag only means 'append' if it's the first character
> >>in the mode string.  In the second position, it should be
> >>ignored.  On some systems, an 'a' in the second position
> >>means "ASCII" (as opposed to 'b' for binary).
> >>
> >>I'm sceptical about this patch.
> >
> >
> > Well... I'll be happy to reverse it, but I tried to find
> > information about this "ra" mode.
>
> Well, exactly - not many OS's use it.  What I'm sceptical
> about is how (if at all) it fixes anything.  Mainly though,
> the commit comment "Avoid append flag" shows a misunderstanding
> of what "ra" means.  It DOES NOT MEAN 'Append'.  That would be
> "a" by itself.

Visual C++ 2005 Express generate an exception when meeting the "a" at the=
 second
position, as it consider it as an invalid option.

Reading the fopen man page from Tru64 Unix, it is stated that "+" should =
be used
for updating.
So the right way to open an ascii file in update mode is "r+" not "ra".

>
> So if this patch was intended to fix something - then the
> person doing the fixing didn't understand what they were
> doing - and we should be sceptical about whether this is
> indeed the correct patch.

-Fred

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[steve <sjb...@ai...>]

Bram Stolk wrote:
> steve wrote:
> 
>>Bram Stolk wrote:
>>
>>
>>>Update of /cvsroot/plib/plib/src/ssg
>>>In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8823
>>>
>>>Modified Files:
>>>    ssgLoadAC.cxx Log Message:
>>>Avoid append flag. Fix by Mathias
>>
>>
>>-  loader_fd = fopen ( filename, "ra" ) ;
>>+  loader_fd = fopen ( filename, "r" ) ;
>>
>>
>>Wooaaahhhhhh.
>>
>>That's not right!
>>
>>The 'a' flag only means 'append' if it's the first character
>>in the mode string.  In the second position, it should be
>>ignored.  On some systems, an 'a' in the second position
>>means "ASCII" (as opposed to 'b' for binary).
>>
>>I'm sceptical about this patch.
> 
> 
> Well... I'll be happy to reverse it, but I tried to find
> information about this "ra" mode.

Well, exactly - not many OS's use it.  What I'm sceptical
about is how (if at all) it fixes anything.  Mainly though,
the commit comment "Avoid append flag" shows a misunderstanding
of what "ra" means.  It DOES NOT MEAN 'Append'.  That would be
"a" by itself.

So if this patch was intended to fix something - then the
person doing the fixing didn't understand what they were
doing - and we should be sceptical about whether this is
indeed the correct patch.

> I can't find it on the
> net, nor on linux ia32, linux ia64, irix, freebsd manpages.

"ra" is something I've seen in very ancient IBM systems where
the underlying computer used EBCIDIC instead of ASCII and this
flag was used to convert ASCII to EBCIDIC behind the scenes.

But nobody runs PLIB on those machines (if indeed any of them
still exist)!

So I guess that the 'a' at the end of the string was a mistaken
attempt to be the opposite of a 'b' at the end - and so this
probably *is* an error - but one that should be 100% benign.

So I'm left wondering why someone thought this fixed a bug -
and I'm guessing that whatever they did wasn't necessarily
correct and that we should look more carefully and inquire
as to what was intended to be fixed.

> Also, I assume ac is an ascii file

Yes, it is.

> and if on those "some
> systems" it is read as binary, surely there is no harm in
> that? What happens if you read a file as binary, when in
> fact it's ascii?

* Under Linux/UNIX/BSD - nothing bad happens.  A file is
   just a file.  There are no 'ASCII files' and 'Binary files'.

* Under Windows - any \r\n pairs come through unchanged
   instead of being turned into simple \n as you'd expect
   when reading ASCII.  However, programs that run portably
   ought to be prepared for the occasional spurious '\r'
   because files written under Windows but read under
   Linux/UNIX would have any \r's that got stuffed into
   the file by Windows come out literally just as they
   would under Windows if you accidentally opened an ASCII
   file as binary.  Hence well-written, portable programs
   shouldn't care whether a file opened for reading is
   accidentally opened as binary incorrectly.  The reverse
   is not the case however - if you open as ASCII when it's
   really a binary file then 'Very Bad Things' happen.

* Under MacOS-9 - I believe that any \r's in the file get
   read as \r instead of being turned into \n's.   That
   *might* be a bad thing - even for well-written portable
   programs because they are expecting '\n' to terminate a
   line and they'll never see a '\n' because the underlying
   file has a '\r' in it and without the ASCII translation
   mode turned on those '\r's come out as written.

* Under MaxOSX - I'm not sure...probably the same as MacOS-9
   and earlier.

Very ikky for portable programming.

Moral of the story:  UNIX had it right.  Abandon all other
OS's immediately!

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Frederic B. <fre...@fr...>]

> > A shame about missing the FG release though :-(
>
> There will be other releases.  :-)

Perhaps in the meantime, puAuxList.cxx would find its way to the CVS repo=
sitory
?

-Fred

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Martin S. <Mar...@mg...>]

Melchior FRANZ wrote:
> * Bram Stolk -- Wednesday 07 December 2005 10:59:

>> A shame about missing the FG release though :-(
> 
> There will be other releases.  :-)

Well, for PLIB this still has to be proven ....

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

[Plib-devel] BSD analog joystick fixes

[Jean-Yves L. <jyl...@Fr...>]

Hi,

I've attached BSD analog joystick fixes:

  - support joysticks having only one axis
  - filter out bogus values when reading
  - warn if the calibration file cannot be opened
  - provide a calibration utility for creating ~/.joy?rc

Regards,
Jean-Yves Lefort

-- 
Jean-Yves Lefort

jyl...@Fr...
http://lefort.be.eu.org/

[Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Melchior F. <mf...@us...>]

* Bram Stolk -- Wednesday 07 December 2005 10:59:
> Ok, thanks for explaining.

I had missed that "steve" in this thread is *the* Steve. I would have
been more hesitant with my comments otherwise. Anyway:


* Steve Baker -- Thursday 03 July 2003 05:36:
| '.ac' files don't have DOS line endings - even the ones written
| by the Windoze version of AC3D.

This was in thread "[PATCH] ssg/ssgLoadAC.cxx: fix potential crash;
accept DOS line endings", which for some reason isn't in the sf
archive. The patch was applied nevertheless. There are probably
Windows people subscribed here who can easily test the current
version and report any problems.



> A shame about missing the FG release though :-(

There will be other releases.  :-)

m.

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

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

Melchior FRANZ wrote:
> * Bram Stolk -- Wednesday 07 December 2005 10:42:
> 
>>>You have to deal with both \r and \n. But IIRC I submitted a fix for
>>>exactly this problem (r1.31, r1.32),
> 
> 
>>So, what do you suggest now? Revert it back to "ra" ?
> 
> 
> No, on the contrary. Mathias has apparently found out that "ra" leads
> to crashes. It isn't standard, and that ssgLoadAC.cxx wouldn't work
> without the "a" is (a) unproofed, and (b) unlikely (because the \r&\n
> issue *has* been dealt with already). Looks like the next release isn't
> urgent, as FlightGear 0.9.9 has been released without waiting for it,
> so I think we can wait until someone reports a problem.

Ok, thanks for explaining.
A shame about missing the FG release though :-(

  Bram

-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

[Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Melchior F. <mf...@us...>]

* Bram Stolk -- Wednesday 07 December 2005 10:42:
> > You have to deal with both \r and \n. But IIRC I submitted a fix for
> > exactly this problem (r1.31, r1.32),

> So, what do you suggest now? Revert it back to "ra" ?

No, on the contrary. Mathias has apparently found out that "ra" leads
to crashes. It isn't standard, and that ssgLoadAC.cxx wouldn't work
without the "a" is (a) unproofed, and (b) unlikely (because the \r&\n
issue *has* been dealt with already). Looks like the next release isn't
urgent, as FlightGear 0.9.9 has been released without waiting for it,
so I think we can wait until someone reports a problem.

m.

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

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

Melchior FRANZ wrote:
> * Bram Stolk -- Wednesday 07 December 2005 10:24
> 
>>What happens if you read a file as binary, when in fact it's ascii?
> 
> 
> You have to deal with both \r and \n. But IIRC I submitted a fix for
> exactly this problem (r1.31, r1.32), and that although some plib
> developer claimed that this wouldn't be necessary because the ac3d
> spec *demands* that line ends are Unix-style. So there should really
> be no problem.

Ah, ok...
This issue has a history, I see.
It looked like a no-brainer, but it is not.
I'm sorry about that.

So, what do you suggest now? Revert it back to "ra" ?

  Bram


> 
> m.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

[Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[Melchior F. <mf...@us...>]

* Bram Stolk -- Wednesday 07 December 2005 10:24
> What happens if you read a file as binary, when in fact it's ascii?

You have to deal with both \r and \n. But IIRC I submitted a fix for
exactly this problem (r1.31, r1.32), and that although some plib
developer claimed that this wouldn't be necessary because the ac3d
spec *demands* that line ends are Unix-style. So there should really
be no problem.

m.

Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

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

steve wrote:
> Bram Stolk wrote:
> 
>> Update of /cvsroot/plib/plib/src/ssg
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8823
>>
>> Modified Files:
>>     ssgLoadAC.cxx Log Message:
>> Avoid append flag. Fix by Mathias
> 
> 
> -  loader_fd = fopen ( filename, "ra" ) ;
> +  loader_fd = fopen ( filename, "r" ) ;
> 
> 
> Wooaaahhhhhh.
> 
> That's not right!
> 
> The 'a' flag only means 'append' if it's the first character
> in the mode string.  In the second position, it should be
> ignored.  On some systems, an 'a' in the second position
> means "ASCII" (as opposed to 'b' for binary).
> 
> I'm sceptical about this patch.

Well... I'll be happy to reverse it, but I tried to find
information about this "ra" mode. I can't find it on the
net, nor on linux ia32, linux ia64, irix, freebsd manpages.
They only speak of the 'b' suffix, which is normally ignored.

Also, I assume ac is an ascii file, and if on those "some
systems" it is read as binary, surely there is no harm in
that? What happens if you read a file as binary, when in
fact it's ascii?

  Bam

> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

[Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[steve <sjb...@ai...>]

Bram Stolk wrote:
> Update of /cvsroot/plib/plib/src/ssg
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8823
> 
> Modified Files:
> 	ssgLoadAC.cxx 
> Log Message:
> Avoid append flag. Fix by Mathias

-  loader_fd = fopen ( filename, "ra" ) ;
+  loader_fd = fopen ( filename, "r" ) ;


Wooaaahhhhhh.

That's not right!

The 'a' flag only means 'append' if it's the first character
in the mode string.  In the second position, it should be
ignored.  On some systems, an 'a' in the second position
means "ASCII" (as opposed to 'b' for binary).

I'm sceptical about this patch.

Re: [Plib-devel] Crash fix for msvc-8 and external memory problem

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

Mathias Fr=F6hlich wrote:
> Hi,
>=20
> Attached is a fix to plib/ssg which causes flightgear (and likely other=
 users=20
> of plib) to crash on startup.
> It avoids the 'append' fopen flag when opening a file for 'read'.
>=20
> The other patch makes ssgSimpleList only delete memory region if it is =
owned=20
> by it.
>=20
> Please apply to cvs!
>=20
>   Thanks in advance
>=20
>              Mathias Fr=F6hlich

Ok, I committed these fixes to CVS.


  Bram

>=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> Index: ssgLoadAC.cxx
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/plib/plib/src/ssg/ssgLoadAC.cxx,v
> retrieving revision 1.36
> diff -c -r1.36 ssgLoadAC.cxx
> *** ssgLoadAC.cxx	15 Jan 2005 20:36:46 -0000	1.36
> --- ssgLoadAC.cxx	5 Dec 2005 22:33:30 -0000
> ***************
> *** 895,901 ****
>     sgSetVec2 ( texrep, 1.0, 1.0 ) ;
>     sgSetVec2 ( texoff, 0.0, 0.0 ) ;
>  =20
> !   loader_fd =3D fopen ( filename, "ra" ) ;
>  =20
>     if ( loader_fd =3D=3D NULL )
>     {
> --- 895,901 ----
>     sgSetVec2 ( texrep, 1.0, 1.0 ) ;
>     sgSetVec2 ( texoff, 0.0, 0.0 ) ;
>  =20
> !   loader_fd =3D fopen ( filename, "r" ) ;
>  =20
>     if ( loader_fd =3D=3D NULL )
>     {
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> Index: src/ssg/ssgSimpleList.cxx
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/plib/plib/src/ssg/ssgSimpleList.cxx,v
> retrieving revision 1.14
> diff -u -r1.14 ssgSimpleList.cxx
> --- src/ssg/ssgSimpleList.cxx	25 Jan 2004 16:50:04 -0000	1.14
> +++ src/ssg/ssgSimpleList.cxx	6 Dec 2005 06:33:23 -0000
> @@ -28,11 +28,13 @@
>  {
>    ssgBase::copy_from ( src, clone_flags ) ;
> =20
> -  delete [] list ;
> +  if (own_mem)
> +    delete [] list ;
>    size_of =3D src -> getSizeOf () ;
>    total   =3D src -> getNum () ;
>    limit   =3D total ;
>    list    =3D new char [ limit * size_of ] ;
> +  own_mem =3D true ;
>    memcpy ( list, src->raw_get ( 0 ), limit * size_of ) ;
>  }
> =20
> Index: src/ssg/ssg.h
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/plib/plib/src/ssg/ssg.h,v
> retrieving revision 1.176
> diff -u -r1.176 ssg.h
> --- src/ssg/ssg.h	29 Dec 2004 07:19:40 -0000	1.176
> +++ src/ssg/ssg.h	6 Dec 2005 06:33:24 -0000
> @@ -444,7 +444,8 @@
> =20
>    void removeAll ()
>    {
> -    delete [] list ;
> +    if (own_mem)
> +      delete [] list ;
>      list =3D NULL ;
>      limit =3D total =3D 0 ;
>    }


--=20
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

[Plib-devel] [PATCH] make enabled/disabled state of menu entries/titles more obvious

[Melchior F. <mf...@us...>]

Currently, disabled menu entries are only grayed out, but they are
still drawn shaded and with beveled frame when hovering the mouse
over it. This implies that the entry is still functional. It doesn't
make clear enough that the entry is disabled and not available.
The attached patch makes disabled entries 'plain' and frameless.

m.

[Plib-devel] Crash fix for msvc-8 and external memory problem

[Mathias <Mat...@gm...>]

Hi,

Attached is a fix to plib/ssg which causes flightgear (and likely other use=
rs=20
of plib) to crash on startup.
It avoids the 'append' fopen flag when opening a file for 'read'.

The other patch makes ssgSimpleList only delete memory region if it is owne=
d=20
by it.

Please apply to cvs!

  Thanks in advance

             Mathias Fr=C3=B6hlich

=2D-=20
Mathias Fr=C3=B6hlich, email: Mat...@gm...

[Plib-devel] plib doesn't handle > 32 button joystick

[Plib M. l. <pl...@he...>]

I have a Saitek X52 joystick system.  It has 11 axes and 34 buttons.
You can see the beast here: http://www.saitekusa.com/usa/prod/x52.htm

The topmost numbered buttons won't work.  Or actually, what happens is
that they end up "wrapping around" to the lower bits, so they end up
acting like buttons 0, 1 etc.

The relevant function signature is jsJoystick.read(int* buttons, float* axes).
For the axes, it treats it like an array of floats, which works
correctly for 11 axes (and presumably far more).

But for the buttons, it apparently just treats it as a pointer to int.
Hence the limit of 32 buttons.

Why not treat it like an array, as with the axes?  Then, for 34 buttons
you'd just pass in "int buttons[2]".  And when Saitek releases a
90-button joystick later, "int buttons[3]" etc.

PS: I hacked plib to do just that about a month ago and have
been using it that way with Flightgear without any problems.
I only did the Linux implementation part; presumably the
other platforms won't be a big deal.  I can send diffs if there
is interest.

PPS: It might be worthwhile to use a new method for this behaviour,
for backwards compatibility reasons.  Otherwise, existing code that
passes in a single int will cause buffer overruns when I use
those top buttons...