plib-users

Re: [Plib-users] Does anyone use .ssg files?

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

Steve wrote:

>Wolfram Kuss wrote:
>>=20
>> Does anyone use files in plib's own ".ssg"-format?
>
>Yes - but not for long-term model storage.

Keeping .SSG reading and writing compatible would have bloated the
code too much, so we made a break and trying to read .SSG file format
version zero leads to an error. For more see plib-devel or the docs
(in non_class.html).

Bye bye,
Wolfram.

Re: [Plib-users] height over terrain testing with a 3ds-file as map

[<cal...@ya...>]

--- Robin Laerm <Rob...@gm...> wrote: > Hello
everybody,
> 
> I have a map realized with 3d Studio Max. If I load
> the *.3ds - file with the PLIBs Load3ds - function,
> it is doing very well. But how can I realize I
> height over terrain testing with this *.3ds - file?
> 
> 

you can use ssgHOT function for this purpose.
There is a nice example for ssgHOT in example
programs.
( link is "Example programs and Documentation for
PLIB-1.3.1 or later." in plib home page )
I think it was majik_demo in ssg directory.

download it and search for string "ssgHOT". I copied
and pasted those lines in my program and they worked
well :) ( i used a 3ds file as terrain as you intend )

NOTE : check traversal masks in your scene graph.I
think SSGTRAV_HOT is on by default and this my create
performence problems if you do not disable it for
non-terrain geometry.


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

[Plib-users] height over terrain testing with a 3ds-file as map

[Robin L. <Rob...@gm...>]

Hello everybody,

I have a map realized with 3d Studio Max. If I load the *.3ds - file =
with the PLIBs Load3ds - function, it is doing very well. But how can I =
realize I height over terrain testing with this *.3ds - file?

Re: [Plib-users] Does anyone use .ssg files?

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

Wolfram Kuss wrote:
> 
> Does anyone use files in plib's own ".ssg"-format?

Yes - but not for long-term model storage.

I've always regarded it as a convenient format that'll load
quickly and contain all possible features you might need - thus
keeping the game code 'clean'.

I re-convert my models from AC3D to SSG using an offline tool whenever
I need to.

Hence, I don't (personally) care about changes and incompatibilities
between SSG versions.

That's not to say that we shouldn't strive to keep the format stable -
but remember that when I wrote the SSG file format, there were no
modellers that supported SSG.  That meant that you'd *ALWAYS* have
to convert some other file format into SSG.

With the advent of PPE and the ability to model natively in SSG, that
situation has to change.

> The reason I ask is that we are slowly nearing us to the 1.4.0 release
> and that we have to decide what to do about compatibility regarding
> these files.
> 
> One possibility is:
> Have a new file version. 1.4 would be able to read 1.2 and 1.4 files,
> 1.2 could only read its own. Files written with other versions (for
> example, 1.3.x or versions from cvs) would be invalid.
> Like I said, this is only one possibility.

Yes - but it seems reasonable.

-- 
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-users] Does anyone use .ssg files?

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

Does anyone use files in plib's own ".ssg"-format?
If yes, with what plib version do you read and write the files?

The reason I ask is that we are slowly nearing us to the 1.4.0 release
and that we have to decide what to do about compatibility regarding
these files.

One possibility is:
Have a new file version. 1.4 would be able to read 1.2 and 1.4 files,
1.2 could only read its own. Files written with other versions (for
example, 1.3.x or versions from cvs) would be invalid.
Like I said, this is only one possibility.

Bye bye,
WOlfram.

Re: [Plib-users] Question

[lafont02 <laf...@cn...>]

Thanks Norman,  that did the trick perfectly.

Don.
  ----- Original Message -----=20
  From: Norman Vine=20
  To: pli...@li...=20
  Sent: Tuesday, January 02, 2001 4:04 AM
  Subject: RE: [Plib-users] Question


   lafont02  writes:=20
    Steve,  would it be possible to get an equivalent of getBBox() for =
fntRenderer?=20
    =20
    Why not just -)=20
    =20
    float    left ;
    float    right ;
    float    bot ;
    float    top ;
    char buf[256]
    =20
    // Set this to a valid fntRenderer=20
    external fntRenderer *MyText;
    =20
    fntFont *font      =3D myText->getFont();
    float    pointsize =3D myText->getPointSize();
    float    italic    =3D myText->getSlant();
    font->getBBox ( buf, pointsize, italic,
            &left, &right, &bot, &top ) ;
    =20
    Cheers
    =20
    Norman

RE: [Plib-users] Question

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

 lafont02  writes:
  Steve,  would it be possible to get an equivalent of getBBox() for
fntRenderer?

  Why not just -)

  float    left ;
  float    right ;
  float    bot ;
  float    top ;
  char buf[256]

  // Set this to a valid fntRenderer
  external fntRenderer *MyText;

  fntFont *font      = myText->getFont();
  float    pointsize = myText->getPointSize();
  float    italic    = myText->getSlant();
  font->getBBox ( buf, pointsize, italic,
          &left, &right, &bot, &top ) ;

  Cheers

  Norman

[Plib-users] Question

[lafont02 <laf...@cn...>]

Hi,  Happy New Year to all!

Steve,  would it be possible to get an equivalent of getBBox() for =
fntRenderer?

I have a need for lots of right justified text,  and this would help out =
immensly.  If not,  any suggestions on how to go about this "sanely"?

Don.

Re: [Plib-users] problem with fnt and release mode

[Scott S. <sjs...@um...>]

> The service packs also would be interesting (6.0 goes up to SP3 IIRC)

4.0 actually.

To fix the problem, try turning the optimization settings to "assume
aliasing across functions."

This should be under project settings......tab called c++...drop-down
optimizations, customize, check the box labeled "assume aliasing across
function calls."

This may fix your problem.

------------------
Scott Shumaker
sjs...@um...

----- Original Message -----
From: "Christian Mayer" <Va...@t-...>
To: <pli...@li...>
Sent: Thursday, December 21, 2000 5:37 AM
Subject: Re: [Plib-users] problem with fnt and release mode


> Steve Baker wrote:
> >
> > Just out of interest, what version of MSVC++ is everyone who sees this
> > bug using?   I recollect someone telling me that the optimisations that
> > V6 makes are *far* more dangerous than the ones in V7.
>
> There are only versions up to 6.0. IIRC V5.0 is supposed to create buggy
> code (some people say that 6.0 is only a bug fixed 5.0)
>
> The service packs also would be interesting (6.0 goes up to SP3 IIRC)
>
> CU,
> Christian
>
>
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

Re: [Plib-users] problem with fnt and release mode

[Eero P. <epa...@ko...>]

Don Lafontaine wrote:
> 
> Has anyone come up with the precise options we should avoid to fix this
> problem?  I've tried a few but no go.  Still no fonts.
> 
> Don.


I have not found reasonably recent MS VC++ 
(for example VC++ 5.0 with SP3 and VC++ 6.0 with SP4)
guilty to f...ing up my code, with typical options.

For typical release build options I mean (in IDE)
Optimizations: Maximize Speed
Inline function: Any Suitable

I am aware of the recent discussions  regarding problems 
with template classes and VC++, on sweng-gamedev list. 
Still for the problem you describe, I would suspect that
the it is caused by something else than the compiler. 
Especially if you are not compiling your driver yourself,
but relying on the vendor provided driver. 

Btw. 1: I use Multithreaded DLL for libraries
Bt.w 2: I have seen some problems with dependecies,
so when I am in doubt I do the "Rebuild All" operation.


		Eero

Re: [Plib-users] problem with fnt and release mode

[Don L. <laf...@cn...>]

Has anyone come up with the precise options we should avoid to fix this
problem?  I've tried a few but no go.  Still no fonts.

Don.

Scott Shumaker wrote:

> Yeah, it can be.  I don't fault the optimizer, though, if you turn on "full
> optimizations" you should be prepared to face the consequences.  There is
> certainly an option called "assume aliasing across functions."  Although I
> do question MS's decision to not make this the default optimization choice.
>
> As for only affecting the G200/G400/Radeon, my guess is that NVidia drivers
> are more robust when it comes to error-handling.
>
> ------------------
> Scott Shumaker
> sjs...@um...
>
> ----- Original Message -----
> From: "Steve Baker" <sjb...@ai...>
> To: <pli...@li...>
> Sent: Thursday, December 21, 2000 1:07 AM
> Subject: Re: [Plib-users] problem with fnt and release mode
>
> > Scott Shumaker wrote:
> >
> > > Well, it only causes problems across functions, i.e.:
> > <snip>
> >
> > Yes - that seems *incredibly* dangerous to me.  I can imagine a TON of
> > places in PLIB where that would break.
> >
> > I wonder why it only affects G200/G400 and Radion?
> >
> > The OpenGL driver is a DLL - so the compiler doesn't know what driver
> > you are using...it's hard to imagine a pointer alias that would trip
> > up the optimiser with one driver and not the other.
> >
> > Just out of interest, what version of MSVC++ is everyone who sees this
> > bug using?   I recollect someone telling me that the optimisations that
> > V6 makes are *far* more dangerous than the ones in V7.
> >
> > --
> > 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-users mailing list
> > pli...@li...
> > http://lists.sourceforge.net/mailman/listinfo/plib-users
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

RE: [Plib-users] problem with fnt and release mode

[Paul B. <pbl...@di...>]

We use VC++ 6.0 with Service Pack 4 and the Processor Pack (which 
adds Athlon and P4 optimizations and code generation).

The optimizer has been "refined" (not necessarily fixed) with
each service pack.  The processor pack actually introduces a few
new problems (dealing mostly with the floating point optimizations).

The optimizer in VC is very aggressive, unfortunately it is wrong
quite often as a result.

Paul


> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Thursday, December 21, 2000 12:07 AM
> To: pli...@li...
> Subject: Re: [Plib-users] problem with fnt and release mode
> 
> 
> Scott Shumaker wrote:
>  
> > Well, it only causes problems across functions, i.e.:
> <snip>
> 
> Yes - that seems *incredibly* dangerous to me.  I can imagine a TON of
> places in PLIB where that would break.
> 
> I wonder why it only affects G200/G400 and Radion?
> 
> The OpenGL driver is a DLL - so the compiler doesn't know what driver
> you are using...it's hard to imagine a pointer alias that would trip
> up the optimiser with one driver and not the other.
> 
> Just out of interest, what version of MSVC++ is everyone who sees this
> bug using?   I recollect someone telling me that the 
> optimisations that
> V6 makes are *far* more dangerous than the ones in V7.
> 
> -- 
> 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-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
> 

Re: [Plib-users] problem with fnt and release mode

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

Steve Baker wrote:
> 
> Just out of interest, what version of MSVC++ is everyone who sees this
> bug using?   I recollect someone telling me that the optimisations that
> V6 makes are *far* more dangerous than the ones in V7.

There are only versions up to 6.0. IIRC V5.0 is supposed to create buggy
code (some people say that 6.0 is only a bug fixed 5.0)

The service packs also would be interesting (6.0 goes up to SP3 IIRC)

CU,
Christian

Re: [Plib-users] problem with fnt and release mode

[Scott S. <sjs...@um...>]

Yeah, it can be.  I don't fault the optimizer, though, if you turn on "full
optimizations" you should be prepared to face the consequences.  There is
certainly an option called "assume aliasing across functions."  Although I
do question MS's decision to not make this the default optimization choice.

As for only affecting the G200/G400/Radeon, my guess is that NVidia drivers
are more robust when it comes to error-handling.

------------------
Scott Shumaker
sjs...@um...


----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Thursday, December 21, 2000 1:07 AM
Subject: Re: [Plib-users] problem with fnt and release mode


> Scott Shumaker wrote:
>
> > Well, it only causes problems across functions, i.e.:
> <snip>
>
> Yes - that seems *incredibly* dangerous to me.  I can imagine a TON of
> places in PLIB where that would break.
>
> I wonder why it only affects G200/G400 and Radion?
>
> The OpenGL driver is a DLL - so the compiler doesn't know what driver
> you are using...it's hard to imagine a pointer alias that would trip
> up the optimiser with one driver and not the other.
>
> Just out of interest, what version of MSVC++ is everyone who sees this
> bug using?   I recollect someone telling me that the optimisations that
> V6 makes are *far* more dangerous than the ones in V7.
>
> --
> 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-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

Re: [Plib-users] problem with fnt and release mode

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

Scott Shumaker wrote:
 
> Well, it only causes problems across functions, i.e.:
<snip>

Yes - that seems *incredibly* dangerous to me.  I can imagine a TON of
places in PLIB where that would break.

I wonder why it only affects G200/G400 and Radion?

The OpenGL driver is a DLL - so the compiler doesn't know what driver
you are using...it's hard to imagine a pointer alias that would trip
up the optimiser with one driver and not the other.

Just out of interest, what version of MSVC++ is everyone who sees this
bug using?   I recollect someone telling me that the optimisations that
V6 makes are *far* more dangerous than the ones in V7.

-- 
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-users] problem with fnt and release mode

[Scott S. <sjs...@um...>]

Well, it only causes problems across functions, i.e.:


int* g_pTheInt; // global variable.

void foo()
{
  *g_pTheInt = *g_pTheInt + 1;
}


and later...


int* a;

*a = 10;

g_pTheInt = a;

foo();

printf("%d", *a); // a should now be 11, but this may not be the case

You can turn set the VC++ compiler optimization to "assume aliasing across
function calls", which will fix the problem (effectively reloading the
registers from memory, I assume).


------------------
Scott Shumaker
sjs...@um...



----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Wednesday, December 20, 2000 9:02 PM
Subject: Re: [Plib-users] problem with fnt and release mode


> Paul Bleisch wrote:
> >
> > More than likely it is either "global optimizations" or "assume
> > no aliasing".  These two cause the most problems.
>
> Yikes!
>
> Does "assume no aliasing" mean "assume no pointer aliasing" ??
>
> If so, then you'll want to turn off that sucker - bury it *DEEP*!
>
> int x = 6 ;
> int y ;
>
> int *a ;
> int *b ;
>
>   a = & x ;
>   b = & x ;
>
> ...then later on...
>
>   *a = 1234 ;
>   *b = 0 ;
>   y = *a ;
>   printf ( "%d\n", y ) ;
>
> ...will probably print 1234 with a compiler that assumes there
> is no pointer aliasing.
>
> It's hard to imagine any piece of software of any complexity
> surviving that kind of punishment.
>
> --
> 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-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

Re: [Plib-users] problem with fnt and release mode

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

Paul Bleisch wrote:
> 
> More than likely it is either "global optimizations" or "assume
> no aliasing".  These two cause the most problems.

Yikes!

Does "assume no aliasing" mean "assume no pointer aliasing" ??

If so, then you'll want to turn off that sucker - bury it *DEEP*!

int x = 6 ;
int y ;

int *a ;
int *b ;

  a = & x ;
  b = & x ;

...then later on...

  *a = 1234 ;
  *b = 0 ;
  y = *a ;
  printf ( "%d\n", y ) ;

...will probably print 1234 with a compiler that assumes there
is no pointer aliasing.

It's hard to imagine any piece of software of any complexity
surviving that kind of punishment.
  
-- 
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-users] problem with fnt and release mode

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

Paolo Leoncini writes:

>My configuration for plib is:
>- Work: NT4-SP4, Matrox Millennium G200 latest drivers (OGL ICD), 
> Cygnus B20.2 gcc 2.95.2

Hey Paolo

Do yourself a favor and upgrade your Cygnus enviroment
It has come a long ways since B20.x   :-)))

Ciao

Norman

RE: [Plib-users] problem with fnt and release mode

[Paul B. <pbl...@di...>]

More than likely it is either "global optimizations" or "assume
no aliasing".  These two cause the most problems.  

Paul


> -----Original Message-----
> From: Eric Desrosiers [mailto:sre...@ho...]
> Sent: Wednesday, December 20, 2000 11:28 AM
> To: pli...@li...
> Subject: Re: [Plib-users] problem with fnt and release mode
> 
> 
> Sam,
> 
> you were right on the money. I had my optimisation set to 
> Maximum Speed. I
> turned that off and now everything is fine!! I haven't been 
> able to exactly
> pin point which optimisations, but when you use custom 
> optimisations, you
> can still set favor fast code and everything will work fine. But the
> difference between optimised and non optimised is too subtle 
> to bother.
> 
> thank you,
> 
> Eric
> ----- Original Message -----
> From: "Stephen J Baker" <sj...@li...>
> To: <pli...@li...>
> Sent: Wednesday, December 20, 2000 12:11 PM
> Subject: Re: [Plib-users] problem with fnt and release mode
> 
> 
> >
> > The screenshots I've seen of this look VERY similar to a problem
> > that was common under Linux *ONLY* on the G200 and G400 cards.
> >
> > The symptoms were exactly the same as the ones you guys are
> > reporting - the top half of the font texture map being garbage.
> > In the case of the Linux drivers, the bottom half of the map
> > was the bottom half of the texture map - whilst in the Windoze
> > case, it appears to be two copies of a half-resolution version.
> >
> > But those symptoms are just too similar for that to be a
> > coincidence.
> >
> > I *thought* that the bug under Linux was caused by Mesa - and
> > had subsequently been fixed...but I don't have a G400 card -
> > and my G200 isn't currently installed in any of my machines
> > so it's a pain to go back and test it.
> >
> > The issue of it failing in RELEASE mode versus DEBUG mode is
> > also symptomatic of problems I've heard of before.  MSVC does
> > some VERY bad things when you are in DEBUG mode:
> >
> >   1) It makes sure that all uninitialised variables are
> >      zeroed (Those guys at M$ are COMPLETE IDIOTS!)...so
> >      if you have an uninitialised variable, it works just
> >      fine in debug mode and crashes horribly in release mode!
> >
> >   2) It turns off some of the compiler optimisations.  Since
> >      some versions of MSVC very buggy optimisations, that
> >      can conceal the effect of compiler bugs.  Trying RELEASE
> >      mode compilation with all of the optimisations turned
> >      off would be an interesting experiment.
> >
> >   3) I don't use M$ software any more - but didn't I hear somewhere
> >      that when you compile in debug mode, the debugger 
> loads different
> >      versions of the library DLL's?   If that's the case, maybe you
> >      are getting a different Matrox driver when in debug mode.
> >
> > Whilst I don't completely rule out a FNT library bug, it is a
> > fact that this problem NEVER shows up on non-Matrox hardware
> > - and when it does show up, it does so both under Linux and
> > Windoze with similar symptoms - despite there being a totally
> > different set of drivers in each case.
> >
> > That's *very* suspicious.
> >
> > You might ask "if it's a hardware problem - how come I don't
> > see it in other programs?"   If I had to guess, I'd say it
> > was because FNT uses MIPmapped luminance+alpha textures -
> > which are VERY rarely seen in other applications.
> >
> > Not only that - but look closely at those bogus screen shots.
> >
> > The bottom-left corner of the FNT test screen should be
> > one copy of the entire texture map.  What you see is the
> > top half of the image being garbage (in one case it's
> > clearly garbage left over from some other program) -
> > and the bottom half is TWO copies of a half-resolution
> > version of the texture.
> >
> > If I had to guess what that means, I'd say that we are
> > seeing the luminance and alpha data (which look identical)
> > of the lower level MIPmap.  This points to a memory allocation
> > error inside the device driver.  Perhaps it's packing the
> > data into memory as if it was an RGBA texture or something
> > and mis-computing the addresses.
> >
> > At any rate - if the data in the top half of the map was
> > just total garbage - then I'd concede that it *could* somehow
> > be an error in 'FNT' that sends garbage down to the G200/G400
> > card.  HOWEVER, in one of those screen shots, there is a perfect
> > picture of the front of a building in the upper half of the
> > texture map.  What are the odds of garbage from the main memory
> > of your CPU being a perfect picture of a building?  Pretty
> > small I'd say.  OTOH, what are the odds of garbage in the
> > TEXTURE MEMORY of the card being a perfect picture left
> > over from some previous application?  Almost certain!
> >
> > So, it's 99.999% certain that the garbage ISN'T being
> > transmitted to the hardware from main memory - it's
> > texture data that's never being written to down in the
> > Matrox hardware.
> >
> > There is no way to do that in OpenGL.  There is absolutely
> > no sequence of API instructions that can make it do that.
> >
> > *IF* I was using the 'glTexSubImage' or 'glCopyTexSubImage'
> > commands - then *maybe* we could attribute this to poor
> > error checking in the drivers (and in the drivers of every
> > other card that FNT runs on - which are MANY)...but I
> > don't ever do that.  The only way I write to texture
> > memory is using glTexImage2D - and that API only permits
> > you to write to a whole map.  You can't even try to draw
> > an image using a map that you havn't downloaded...the
> > API prevents that too.
> >
> > Hence, we may deduce that the G200/G400 has some kind of
> > a hardware problem - or some kind of driver bug that
> > was somehow propagated into Mesa by virtue of bad information
> > passed to the OpenSource driver developers by the G200/G400
> > developers at Matrox.
> >
> > So, right now - using the facts you guys have given me - I'm
> > entirely unconvinced that this is a FNT bug...although
> > anything's possible the odds are HEAVILY against it.
> >
> > I think that the next step should be to extract the font
> > loader code from FNT, boil it down to a SIMPLE OpenGL/GLUT
> > program that exhibits the problems - and (presuming that
> > we don't thereby discover a FNT library bug) ship that
> > off to Matrox as a bug report.
> >
> > ----
> > Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> > L3Com/Link Simulation & Training (817)619-2466 (Fax)
> > Work: sj...@li...           http://www.link.com
> > Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
> >
> >
> > _______________________________________________
> > plib-users mailing list
> > pli...@li...
> > http://lists.sourceforge.net/mailman/listinfo/plib-users
> >
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
> 

Re: [Plib-users] problem with fnt and release mode

[Eric D. <sre...@ho...>]

I have an Ati Radeon. I have also tested it on an Ati rage 128 and my trash
doesn't look like the others.

When I ask to draw a string say in the middle of the screen, the first
letter is in the right position, but all the others all left-aligned and are
written one over the other. But like I said in a previous message, it was
because of some optimisations and now it is working perfectly.

Eric

Re: [Plib-users] problem with fnt and release mode

[Don L. <laf...@cn...>]

All very good points Stephen,  I have one user in particular that does
some frequent testing.   I'll tinker with the optimizations to try and
figure out which one causes the problem.    Thanks for the tip.

Don.

Stephen J Baker wrote:

> The screenshots I've seen of this look VERY similar to a problem
> that was common under Linux *ONLY* on the G200 and G400 cards.
>
> The symptoms were exactly the same as the ones you guys are
> reporting - the top half of the font texture map being garbage.
> In the case of the Linux drivers, the bottom half of the map
> was the bottom half of the texture map - whilst in the Windoze
> case, it appears to be two copies of a half-resolution version.
>
> But those symptoms are just too similar for that to be a
> coincidence.
>
> I *thought* that the bug under Linux was caused by Mesa - and
> had subsequently been fixed...but I don't have a G400 card -
> and my G200 isn't currently installed in any of my machines
> so it's a pain to go back and test it.
>
> The issue of it failing in RELEASE mode versus DEBUG mode is
> also symptomatic of problems I've heard of before.  MSVC does
> some VERY bad things when you are in DEBUG mode:
>
>   1) It makes sure that all uninitialised variables are
>      zeroed (Those guys at M$ are COMPLETE IDIOTS!)...so
>      if you have an uninitialised variable, it works just
>      fine in debug mode and crashes horribly in release mode!
>
>   2) It turns off some of the compiler optimisations.  Since
>      some versions of MSVC very buggy optimisations, that
>      can conceal the effect of compiler bugs.  Trying RELEASE
>      mode compilation with all of the optimisations turned
>      off would be an interesting experiment.
>
>   3) I don't use M$ software any more - but didn't I hear somewhere
>      that when you compile in debug mode, the debugger loads different
>      versions of the library DLL's?   If that's the case, maybe you
>      are getting a different Matrox driver when in debug mode.
>
> Whilst I don't completely rule out a FNT library bug, it is a
> fact that this problem NEVER shows up on non-Matrox hardware
> - and when it does show up, it does so both under Linux and
> Windoze with similar symptoms - despite there being a totally
> different set of drivers in each case.
>
> That's *very* suspicious.
>
> You might ask "if it's a hardware problem - how come I don't
> see it in other programs?"   If I had to guess, I'd say it
> was because FNT uses MIPmapped luminance+alpha textures -
> which are VERY rarely seen in other applications.
>
> Not only that - but look closely at those bogus screen shots.
>
> The bottom-left corner of the FNT test screen should be
> one copy of the entire texture map.  What you see is the
> top half of the image being garbage (in one case it's
> clearly garbage left over from some other program) -
> and the bottom half is TWO copies of a half-resolution
> version of the texture.
>
> If I had to guess what that means, I'd say that we are
> seeing the luminance and alpha data (which look identical)
> of the lower level MIPmap.  This points to a memory allocation
> error inside the device driver.  Perhaps it's packing the
> data into memory as if it was an RGBA texture or something
> and mis-computing the addresses.
>
> At any rate - if the data in the top half of the map was
> just total garbage - then I'd concede that it *could* somehow
> be an error in 'FNT' that sends garbage down to the G200/G400
> card.  HOWEVER, in one of those screen shots, there is a perfect
> picture of the front of a building in the upper half of the
> texture map.  What are the odds of garbage from the main memory
> of your CPU being a perfect picture of a building?  Pretty
> small I'd say.  OTOH, what are the odds of garbage in the
> TEXTURE MEMORY of the card being a perfect picture left
> over from some previous application?  Almost certain!
>
> So, it's 99.999% certain that the garbage ISN'T being
> transmitted to the hardware from main memory - it's
> texture data that's never being written to down in the
> Matrox hardware.
>
> There is no way to do that in OpenGL.  There is absolutely
> no sequence of API instructions that can make it do that.
>
> *IF* I was using the 'glTexSubImage' or 'glCopyTexSubImage'
> commands - then *maybe* we could attribute this to poor
> error checking in the drivers (and in the drivers of every
> other card that FNT runs on - which are MANY)...but I
> don't ever do that.  The only way I write to texture
> memory is using glTexImage2D - and that API only permits
> you to write to a whole map.  You can't even try to draw
> an image using a map that you havn't downloaded...the
> API prevents that too.
>
> Hence, we may deduce that the G200/G400 has some kind of
> a hardware problem - or some kind of driver bug that
> was somehow propagated into Mesa by virtue of bad information
> passed to the OpenSource driver developers by the G200/G400
> developers at Matrox.
>
> So, right now - using the facts you guys have given me - I'm
> entirely unconvinced that this is a FNT bug...although
> anything's possible the odds are HEAVILY against it.
>
> I think that the next step should be to extract the font
> loader code from FNT, boil it down to a SIMPLE OpenGL/GLUT
> program that exhibits the problems - and (presuming that
> we don't thereby discover a FNT library bug) ship that
> off to Matrox as a bug report.
>
> ----
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

Re: [Plib-users] problem with fnt and release mode

[Eric D. <sre...@ho...>]

Sam,

you were right on the money. I had my optimisation set to Maximum Speed. I
turned that off and now everything is fine!! I haven't been able to exactly
pin point which optimisations, but when you use custom optimisations, you
can still set favor fast code and everything will work fine. But the
difference between optimised and non optimised is too subtle to bother.

thank you,

Eric
----- Original Message -----
From: "Stephen J Baker" <sj...@li...>
To: <pli...@li...>
Sent: Wednesday, December 20, 2000 12:11 PM
Subject: Re: [Plib-users] problem with fnt and release mode


>
> The screenshots I've seen of this look VERY similar to a problem
> that was common under Linux *ONLY* on the G200 and G400 cards.
>
> The symptoms were exactly the same as the ones you guys are
> reporting - the top half of the font texture map being garbage.
> In the case of the Linux drivers, the bottom half of the map
> was the bottom half of the texture map - whilst in the Windoze
> case, it appears to be two copies of a half-resolution version.
>
> But those symptoms are just too similar for that to be a
> coincidence.
>
> I *thought* that the bug under Linux was caused by Mesa - and
> had subsequently been fixed...but I don't have a G400 card -
> and my G200 isn't currently installed in any of my machines
> so it's a pain to go back and test it.
>
> The issue of it failing in RELEASE mode versus DEBUG mode is
> also symptomatic of problems I've heard of before.  MSVC does
> some VERY bad things when you are in DEBUG mode:
>
>   1) It makes sure that all uninitialised variables are
>      zeroed (Those guys at M$ are COMPLETE IDIOTS!)...so
>      if you have an uninitialised variable, it works just
>      fine in debug mode and crashes horribly in release mode!
>
>   2) It turns off some of the compiler optimisations.  Since
>      some versions of MSVC very buggy optimisations, that
>      can conceal the effect of compiler bugs.  Trying RELEASE
>      mode compilation with all of the optimisations turned
>      off would be an interesting experiment.
>
>   3) I don't use M$ software any more - but didn't I hear somewhere
>      that when you compile in debug mode, the debugger loads different
>      versions of the library DLL's?   If that's the case, maybe you
>      are getting a different Matrox driver when in debug mode.
>
> Whilst I don't completely rule out a FNT library bug, it is a
> fact that this problem NEVER shows up on non-Matrox hardware
> - and when it does show up, it does so both under Linux and
> Windoze with similar symptoms - despite there being a totally
> different set of drivers in each case.
>
> That's *very* suspicious.
>
> You might ask "if it's a hardware problem - how come I don't
> see it in other programs?"   If I had to guess, I'd say it
> was because FNT uses MIPmapped luminance+alpha textures -
> which are VERY rarely seen in other applications.
>
> Not only that - but look closely at those bogus screen shots.
>
> The bottom-left corner of the FNT test screen should be
> one copy of the entire texture map.  What you see is the
> top half of the image being garbage (in one case it's
> clearly garbage left over from some other program) -
> and the bottom half is TWO copies of a half-resolution
> version of the texture.
>
> If I had to guess what that means, I'd say that we are
> seeing the luminance and alpha data (which look identical)
> of the lower level MIPmap.  This points to a memory allocation
> error inside the device driver.  Perhaps it's packing the
> data into memory as if it was an RGBA texture or something
> and mis-computing the addresses.
>
> At any rate - if the data in the top half of the map was
> just total garbage - then I'd concede that it *could* somehow
> be an error in 'FNT' that sends garbage down to the G200/G400
> card.  HOWEVER, in one of those screen shots, there is a perfect
> picture of the front of a building in the upper half of the
> texture map.  What are the odds of garbage from the main memory
> of your CPU being a perfect picture of a building?  Pretty
> small I'd say.  OTOH, what are the odds of garbage in the
> TEXTURE MEMORY of the card being a perfect picture left
> over from some previous application?  Almost certain!
>
> So, it's 99.999% certain that the garbage ISN'T being
> transmitted to the hardware from main memory - it's
> texture data that's never being written to down in the
> Matrox hardware.
>
> There is no way to do that in OpenGL.  There is absolutely
> no sequence of API instructions that can make it do that.
>
> *IF* I was using the 'glTexSubImage' or 'glCopyTexSubImage'
> commands - then *maybe* we could attribute this to poor
> error checking in the drivers (and in the drivers of every
> other card that FNT runs on - which are MANY)...but I
> don't ever do that.  The only way I write to texture
> memory is using glTexImage2D - and that API only permits
> you to write to a whole map.  You can't even try to draw
> an image using a map that you havn't downloaded...the
> API prevents that too.
>
> Hence, we may deduce that the G200/G400 has some kind of
> a hardware problem - or some kind of driver bug that
> was somehow propagated into Mesa by virtue of bad information
> passed to the OpenSource driver developers by the G200/G400
> developers at Matrox.
>
> So, right now - using the facts you guys have given me - I'm
> entirely unconvinced that this is a FNT bug...although
> anything's possible the odds are HEAVILY against it.
>
> I think that the next step should be to extract the font
> loader code from FNT, boil it down to a SIMPLE OpenGL/GLUT
> program that exhibits the problems - and (presuming that
> we don't thereby discover a FNT library bug) ship that
> off to Matrox as a bug report.
>
> ----
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
>
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>

Re: [Plib-users] problem with fnt and release mode

[Stephen J B. <sj...@li...>]

The screenshots I've seen of this look VERY similar to a problem
that was common under Linux *ONLY* on the G200 and G400 cards.

The symptoms were exactly the same as the ones you guys are
reporting - the top half of the font texture map being garbage.
In the case of the Linux drivers, the bottom half of the map
was the bottom half of the texture map - whilst in the Windoze
case, it appears to be two copies of a half-resolution version.

But those symptoms are just too similar for that to be a
coincidence.

I *thought* that the bug under Linux was caused by Mesa - and
had subsequently been fixed...but I don't have a G400 card -
and my G200 isn't currently installed in any of my machines
so it's a pain to go back and test it.

The issue of it failing in RELEASE mode versus DEBUG mode is
also symptomatic of problems I've heard of before.  MSVC does
some VERY bad things when you are in DEBUG mode:

  1) It makes sure that all uninitialised variables are
     zeroed (Those guys at M$ are COMPLETE IDIOTS!)...so
     if you have an uninitialised variable, it works just
     fine in debug mode and crashes horribly in release mode!

  2) It turns off some of the compiler optimisations.  Since
     some versions of MSVC very buggy optimisations, that
     can conceal the effect of compiler bugs.  Trying RELEASE
     mode compilation with all of the optimisations turned
     off would be an interesting experiment.

  3) I don't use M$ software any more - but didn't I hear somewhere
     that when you compile in debug mode, the debugger loads different
     versions of the library DLL's?   If that's the case, maybe you
     are getting a different Matrox driver when in debug mode.

Whilst I don't completely rule out a FNT library bug, it is a
fact that this problem NEVER shows up on non-Matrox hardware
- and when it does show up, it does so both under Linux and
Windoze with similar symptoms - despite there being a totally
different set of drivers in each case.

That's *very* suspicious.

You might ask "if it's a hardware problem - how come I don't
see it in other programs?"   If I had to guess, I'd say it
was because FNT uses MIPmapped luminance+alpha textures -
which are VERY rarely seen in other applications.

Not only that - but look closely at those bogus screen shots.

The bottom-left corner of the FNT test screen should be
one copy of the entire texture map.  What you see is the
top half of the image being garbage (in one case it's
clearly garbage left over from some other program) -
and the bottom half is TWO copies of a half-resolution
version of the texture.

If I had to guess what that means, I'd say that we are
seeing the luminance and alpha data (which look identical)
of the lower level MIPmap.  This points to a memory allocation
error inside the device driver.  Perhaps it's packing the
data into memory as if it was an RGBA texture or something
and mis-computing the addresses.

At any rate - if the data in the top half of the map was
just total garbage - then I'd concede that it *could* somehow
be an error in 'FNT' that sends garbage down to the G200/G400
card.  HOWEVER, in one of those screen shots, there is a perfect
picture of the front of a building in the upper half of the
texture map.  What are the odds of garbage from the main memory
of your CPU being a perfect picture of a building?  Pretty
small I'd say.  OTOH, what are the odds of garbage in the
TEXTURE MEMORY of the card being a perfect picture left
over from some previous application?  Almost certain!

So, it's 99.999% certain that the garbage ISN'T being
transmitted to the hardware from main memory - it's
texture data that's never being written to down in the
Matrox hardware.

There is no way to do that in OpenGL.  There is absolutely
no sequence of API instructions that can make it do that.

*IF* I was using the 'glTexSubImage' or 'glCopyTexSubImage'
commands - then *maybe* we could attribute this to poor
error checking in the drivers (and in the drivers of every
other card that FNT runs on - which are MANY)...but I
don't ever do that.  The only way I write to texture
memory is using glTexImage2D - and that API only permits
you to write to a whole map.  You can't even try to draw
an image using a map that you havn't downloaded...the
API prevents that too.

Hence, we may deduce that the G200/G400 has some kind of
a hardware problem - or some kind of driver bug that
was somehow propagated into Mesa by virtue of bad information
passed to the OpenSource driver developers by the G200/G400
developers at Matrox.

So, right now - using the facts you guys have given me - I'm
entirely unconvinced that this is a FNT bug...although
anything's possible the odds are HEAVILY against it.

I think that the next step should be to extract the font
loader code from FNT, boil it down to a SIMPLE OpenGL/GLUT
program that exhibits the problems - and (presuming that
we don't thereby discover a FNT library bug) ship that
off to Matrox as a bug report.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Plib-users] problem with fnt and release mode

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

Well I can suggest a few things that could be the cause of this problem.  Try turning off all the optimisations for your release
build and see if that has an affect.

If that doesn't then the only thing I can think of is VC++'s stupid variable initialisation. In debug mode VC++ zero's or NULLs all
values, but in release mode they just just get set to random crap.  Very stupid I know (surely you really want the random values
when you are *debugging*?), but that could be hiding an obscure bug in this instance.

Sam

----- Original Message -----
From: "Eric Desrosiers" <sre...@ho...>
To: <pli...@li...>
Sent: Wednesday, December 20, 2000 7:28 AM
Subject: [Plib-users] problem with fnt and release mode


Hello,

I am compiling the font library using MSVC++ 5.0. When I compile in debug mode, everything is working fine, but when I compile the
library in release mode, the output text is trashy. Only the first letter is right.

Does anyone ever had that problem?

Eric

Re: R: [Plib-users] problem with fnt and release mode

[Don L. <laf...@mu...>]

I can confirm that too.  My matrox users have no fonts displaying at all.

And I use LOTS of text.  http://www.avsim.com/hangar/utils/freefd

Don Lafontaine

On Wed, 20 Dec 2000, Paolo Leoncini wrote:

> Me too, anyone interested can look at images in
> ftp://ftp.cira.it/paolo/plib/fnt/ (plib 1.3.1, examples 1.1.8, fnt_test a=
nd
> PUI's complex, same in 1.2.0 and earlier). Everything else in plib is ok.
> My configuration for plib is:
> - Work: NT4-SP4, Matrox Millennium G200 latest drivers (OGL ICD), Cygnus
> B20.2 gcc 2.95.2
> - Home: Windows98, Matrox Marvel G200 latest drivers, same dev env
>=20
> Greetings -
>=20
> -------------------------------------------------------------------------=
---
> -
> Paolo Leoncini                              phone:  +39 (0823) 623134
> Scientific Visualization & Virtual Reality      fax:    +39 (0823) 623126
> CIRA - Italian Center for Aerospace Researches  mailto:p.l...@ci...
> Via Maiorise - 81043 Capua (CE) Italy
> http://www.cira.it/research/vis
>=20
> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...]Per conto di Eric Desrosie=
rs
> Inviato: mercoled=EC 20 dicembre 2000 8.29
> A: pli...@li...
> Oggetto: [Plib-users] problem with fnt and release mode
>=20
>=20
> Hello,
>=20
> I am compiling the font library using MSVC++ 5.0. When I compile in debug
> mode, everything is working fine, but when I compile the library in relea=
se
> mode, the output text is trashy. Only the first letter is right.
>=20
> Does anyone ever had that problem?
>=20
> Eric
>=20
>=20
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>=20