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

[Darrell W. <dwa...@pu...>]

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

To better illustrate, here is a screen:

http://icdweb.cc.purdue.edu/~walisser/plib/tux.jpg

>> Also a slight mod in slModFile.cxx to use fopen() instead of open(). I need
>> to use fopen because my unix-to-mac path converter only intercepts fopen()
>> calls.
>> 
>> Looks like this:
>> 
>> slModFile.cxx  560:
>> 
>> int fd = fileno ( fopen ( fname, "rb" ) ) ;
> 
> OK - can we put your UNIX-to-MAC path convertor into PLIB/UTIL somewhere?
> We really need UNIX-to-Windoze, Windoze-to-UNIX, Windoze-to-Mac and
> Mac-to-Windoze
> convertors too.  I've been putting off doing those for a while because there
> was nowhere sensible in PLIB to put them...but now that Dave is off creating
> things like directory searching inside the 'UL' space, we should start to
> address
> the thorny issues of file/path names and (ugh) file line-termination in a
> portable
> manner.

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)

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.

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

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 '.')