Thread: [Plib-devel] Mac Updates/Patches (Tux too!)
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Darrell W. <wal...@ho...> - 2000-08-03 21:21:28
Attachments:
js.h.gz
|
New CodeWarrior projects are available. There is also a MacCVS Pro config file to help with setting up CVS access. http://icdweb.cc.purdue.edu/~walisser/plib/plib.cw5.sit I have also implemented experimental JS support using InputSprocket. I wish I could test it more, but I don't have a joystick yet ( I plan on getting one real soon). The new js.h file is attached. Mostly just to test my unix-to-mac path converter, I did a quick and dirty build of tux (with 1 minor modification to source). 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 ;-) At any rate, here is my project setup for tux (brief README included): http://icdweb.cc.purdue.edu/~walisser/plib/tux.cw5.sit 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" ) ) ; Well thats it! See ya! Darrell ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com |
|
From: Steve B. <sjb...@ai...> - 2000-08-04 00:54:00
|
Darrell Walisser wrote: > > New CodeWarrior projects are available. There is also a MacCVS Pro config > file to help with setting up CVS access. > > http://icdweb.cc.purdue.edu/~walisser/plib/plib.cw5.sit Thanks - I'll try to get them online soon. > I have also implemented experimental JS support using InputSprocket. I wish > I could test it more, but I don't have a joystick yet ( I plan on getting > one real soon). The new js.h file is attached. Excellent! > Mostly just to test my unix-to-mac path converter, I did a quick and dirty > build of tux (with 1 minor modification to source). Good. > 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? > At any rate, here is my project setup for tux (brief README included): > > http://icdweb.cc.purdue.edu/~walisser/plib/tux.cw5.sit OK. > 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. > Well thats it! Great! It's always good to hear from MacOS people. Now, where did the BeOS dudes vanish to? -- 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 |
|
From: Darrell W. <dwa...@pu...> - 2000-08-04 01:54:42
|
>> 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 '.') |
|
From: Steve B. <sjb...@ai...> - 2000-08-04 03:29:35
|
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
|
|
From: Curtis L. O. <cu...@me...> - 2000-08-04 03:44:49
|
Steve Baker writes: > > 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 belive '~' expansion is called "globbing" in unix and is typically done at the shell level (i.e. is expanded by the shell.) The unix libc doesn't have any "glob" functionality built in and programs that "glob" usually fake it and quite often don't do nearly as nice of a job as the shell. Try writing a simple C program that opens "~sjbaker/junk" (the string being hardcoded and not passed in from the shell) and see what happens. > 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. I will lobby for KISS here. If you make something that is too all encompassing and can handle just about every possible situation the most deviant OS designer could come up with there is a good chance you will end up with a library that is complex and unwieldy and is a hassle to use ... in which case people often won't. I like the flight gear FGPath class myself. It can't handle every case you could dream up, but it is pretty simple and easy to use (and easy to convert hardcoded paths to use FGPath.) With a little thought on the part of the app writer to avoid degenerate situations, the FGPath class can be made to work very well ... 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 |
|
From: Steve B. <sjb...@ai...> - 2000-08-04 04:06:01
|
"Curtis L. Olson" wrote:
> > What about things like '~' in UNIX (it means "my home directory") and '~fred'
> > (meaning "fred's home directory) ?
>
> I belive '~' expansion is called "globbing" in unix and is typically
> done at the shell level (i.e. is expanded by the shell.) The unix
> libc doesn't have any "glob" functionality built in and programs that
> "glob" usually fake it and quite often don't do nearly as nice of a
> job as the shell. Try writing a simple C program that opens
> "~sjbaker/junk" (the string being hardcoded and not passed in from the
> shell) and see what happens.
Doh! Of course! I knew that... :-)
> > 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.
>
> I will lobby for KISS here. If you make something that is too all
> encompassing and can handle just about every possible situation the
> most deviant OS designer could come up with there is a good chance you
> will end up with a library that is complex and unwieldy and is a
> hassle to use ... in which case people often won't.
Well, I don't think this would be hard to use:
ulFilename fname ( "/home/steve/tux/models/tux.ac", UL_UNIX ) ;
...or...
ulFilename fname ( "C:\HOME\STEVE\TUX\MODELS\TUX.AC", UL_WINDOZE ) ;
...or...
ulFilename fname ( "home:steve:tux:models:tux.ac", UL_MACOS ) ;
...(any of those would work on any of those operating systems)...and then:
FILE *fd = fname -> fopen ( "r" ) ;
...and that's *it*.
We could go on to add frills like:
fname . getFileName () ;
...which returns "tux.ac"...or whatever is appropriate for the OS type
the ulFileName was created in.
Internally, converting to and out of a standard internal form wouldn't be that
hard.
> I like the flight gear FGPath class myself. It can't handle every
> case you could dream up, but it is pretty simple and easy to use (and
> easy to convert hardcoded paths to use FGPath.) With a little thought
> on the part of the app writer to avoid degenerate situations, the
> FGPath class can be made to work very well ...
I think that with FGFS, you have a slightly easier task. You have only
one set of users on one (admittedly large) project. For something like
PLIB, where we don't know where it'll ultimately end up, I think we have
to be more robust.
--
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
|
|
From: Wolfram K. <w_...@rz...> - 2000-08-05 16:19:31
|
Curtis wrote: >I like the flight gear FGPath class myself. While speaking about portable file- and path-functions: I would like a function to add two paths. Two examples in Windo$ speak: ".\subdir1" plus "subdir2\file.ext" gives ".\subdir1\subdir2\file.ext". ".\subdir1" plus "c:\file.ext" gives "c:\file.ext" . Is there such a beast in the flightGear code? It would be nice if we had something like this in the coming plib-functions. >Curt. |
|
From: Curtis L. O. <cu...@me...> - 2000-08-07 14:08:00
|
Wolfram Kuss writes: > While speaking about portable file- and path-functions: > I would like a function to add two paths. > Two examples in Windo$ speak: > > ".\subdir1" plus "subdir2\file.ext" gives > ".\subdir1\subdir2\file.ext". > > ".\subdir1" plus "c:\file.ext" gives "c:\file.ext" . > > Is there such a beast in the flightGear code? > It would be nice if we had something like this in > the coming plib-functions. Yikes, from a unix perspective this is un-grokable. :-) 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X