Re: [Plib-devel] Mac Updates/Patches (Tux too!)

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

Darrell Walisser wrote:
> 
> 
> >> Steve, the disappearing
> >> texture problem is back. This may only be an issue for ATI Rage Pro cards
> >> (looks fine in software). I will have a Voodoo3 to test on in  a few days,
> >> maybe it will work on that ;-)
> >
> > It's been a while - about 100,000 emails ago probably!  Can you remind
> > me of the symptoms?
> >
> 
> We added some code to SGI loader so that it always used an alpha channel,
> even if the SGI file didn't contain an alpha channel. Otherwise, the texture
> doesn't display, seemingly getting skipped by the renderer. For example, in
> the opening screen of tux, there is just the water texture at the bottom,
> tux's feet, and other things that contain alpha channel.

Oh - *thats* not good.

(Although I like the ghostly tux-feet!)

Well, I think we have to be looking at an error in your OpenGL implementation,
but I can't imagine what.  Presumably some OpenGL state information isn't
being maintained correctly.

Tux runs on nearly a dozen different OpenGL's now - and the one you are using
is the only one to exhibit anything this strange...I think that has to point
to a problem in the driver.

The fact that forcing all textures to be alpha's cures the problem points
to a possible reason.  Perhaps the alpha channel of non-alpha texture is
left turned on internally to OpenGL - and is defaulting to zero instead of one.

I would suggest that you check this theory by finding all the glEnable(GL_BLEND)
calls in PLIB and change them to glDisable's.  If my theory is correct then the
opaque terrain will return - although the transparent polygons will become opaque
also.  If that works then we are certainly looking at an OpenGL bug.


> I suppose you could include it, but the way it works right now is not
> exactly good programming practice. The compiler inserts a header file I made
> into all sources, looks like this:
> 
> #include <stdio.h>
> 
> extern  FILE* mac_fopen (const char*, const char*);
> #define fopen(x,y) mac_fopen (x,y)

OK - but we could write a 'ulFOpen' that does that - and programs that
want machine-independent file opening can use it in place of fopen.

> The unix-to-mac conversion is pretty hairy because you can't do a simple
> separator replacement. For example, to go to a higher directory on MacOS,
> you append ":" to the *beginning* of the path. In unix you can add /../
> *anywhere* in the path to do the same thing.

well, xxx/yyy/../zzz in UNIX is equivelent to xxx/zzz - so you *could*
filter those intelligently and only turn ../xxx/yyy/zzz into :xxx:yyy:zzz
...but it's certainly not pretty.

> The mac-to-unix conversion would just be separator replacement though. Take
> the leading ':' and convert to '../' and then for the rest replace ':' with
> '/'

What about things like '~' in UNIX (it means "my home directory") and '~fred'
(meaning "fred's home directory) ?

> I guess it would be wise to start working on a ulFile class that takes care
> of these things for you. In that case I'd gladly add the mac-unix and
> unix-mac converter for you.
> 
> Also, of course, you'd have to enforce valid file naming (no '/', ':', '\',
> or '.')

Perhaps it would be smart to define a class that expresses a filename in
an OS-neutral manner (eg as an array of strings - so no separators are
involved - and the only ".." operators are at the top - and stuff like the
Windoze 'C:' drive name and the Linux/UNIX "~" are removed).

Then that class could have 'fromUNIX', 'fromMacOS', 'fromWin" and so on to
convert existing file names into the class - and then operations like
'fopen' that internally convert to whatever native format the OS needs
before doing their work.
 
The application could then be written in whatever native style the author
prefers - and the class would convert to whatever target OS is needed.

That way, you only have to write a 'fromXXX' and 'toXXX' convertor for
each OS in order to have every possibility covered.  Otherwise, we'll
be forever writing 'BeOS_to_Amiga', 'CP/M_to_legOS' and such like.

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