Erik Hofman wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/threads
> In directory baron:/tmp/cvs-serv22758
>
> Modified Files:
> SGThread.hxx
> Log Message:
> Back out the shared mutex code [...]
This is great - because it works for me :-)
Martin.
--
Unix _IS_ user fri
Erik Hofman wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/model
> In directory baron:/tmp/cvs-serv31442
> Modified Files:
> shadanim.cxx
> Log Message:
> Harald JOHNSEN:
>
> I have corrected a few bugs with the owner draw gauge, weather radar
> code and heat-haze effect.
T
On Sonntag 11 September 2005 19:07, Ampere K. Hardraade wrote:
> On September 11, 2005 12:19 pm, Mathias Fröhlich wrote:
> > I would prefere everything open sourced over everything closed, but in
> > this case, try the ati binary driver ...
> > This one should do ...
>
> That's not an option for me
On September 11, 2005 12:19 pm, Mathias Fröhlich wrote:
> I would prefere everything open sourced over everything closed, but in this
> case, try the ati binary driver ...
> This one should do ...
That's not an option for me. ATI's binary drivers don't support PCI card, and
my graphic card is a
Hi,
On Samstag 10 September 2005 18:14, Ampere K. Hardraade wrote:
> Unfortunately, 3D clouds is still not working over here. I am still
> getting the "RenderTexture Error: Couldn't find a suitable pixel format"
> message everytime I start FlightGear.
>
> I am using ATI Radeon 9200 SE PCI versio
On September 6, 2005 02:33 pm, Mathias Fröhlich wrote:
> > Yay! This brought back 3D-clouds which I've been missing for a long time
> > (using XFree86 4.3 + ATI's proprietary driver for Mobility Radeon
> > 9600) :-)
>
> Good to hear ...
>
> Thanks
>
>Mathias
Unfortunately, 3D clouds is st
On Montag 05 September 2005 23:29, Ralf Gerlich wrote:
> > Then the render texture again ...
> >
> > glxQueryVersion turns out to return the minimum of the client libraries
> > glx version and the servers glx version. *All* Xorg servers return 1.2
> > here. So we never get the glxPBuffer functions
Hi,
Erik Hofman schrieb:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen
In directory baron:/tmp/cvs-serv2961
Modified Files:
RenderTexture.cpp extensions.cxx
Log Message:
Mathias Fröhlich:
[SNIP]
Then the render texture again ...
glxQueryVersion turns out to return the minimum of
Martin Spott wrote:
Any objections against the following patch ? 'sqrtf' doesn't exist on
Solaris:
This should not cause any problems.
Erik
--- SimGear/simgear/scene/sky/newcloud.cxx~ 2005-05-05 16:18:14.319996000
+0200
+++ SimGear/simgear/scene/sky/newcloud.cxx 2005-05-05 16:18:13.347644050
Erik Hofman wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky
> In directory baron:/tmp/cvs-serv10162/scene/sky
>
> Modified Files:
> Makefile.am cloud.cxx cloud.hxx
> Added Files:
> bbcache.cxx bbcache.hxx cloudfield.cxx cloudfield.hxx
> newcloud.cxx newcloud.h
Martin Spott wrote:
Hello Erik,
Erik Hofman wrote:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen
In directory baron:/tmp/cvs-serv13251
Modified Files:
texture.cxx
Log Message:
Use the double precission pow() function to get Solaris compiling.
Thanks for the quick fix !
You're welcome.
Er
Hello Erik,
Erik Hofman wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen
> In directory baron:/tmp/cvs-serv13251
>
> Modified Files:
> texture.cxx
> Log Message:
> Use the double precission pow() function to get Solaris compiling.
Thanks for the quick fix !
Martin.
--
Uni
Erik Hofman wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky/clouds3d
> In directory baron:/tmp/cvs-serv18531
>
> Modified Files:
> glut_shapes.c
> Log Message:
> Solaris fix.
Very attentive - thanks,
Martin.
--
Unix _IS_ user friendly - it's just selective about
[EMAIL PROTECTED] wrote:
> I have a problem installing the newest (0.3.8-pre1) simgear sources on my
> FreeBSD 5.3 system.
> ./configure cannot find the openal libs, but the openal freebsd package
> (version 20040816) is installed. The libs are in /usr/local/lib.
Last time I checked (23rd Decembe
Erik Hofman wrote:
> Update of /var/cvs/SimGear-0.3/SimGear
> In directory baron:/tmp/cvs-serv12391
> Modified Files:
> configure.ac
> Log Message:
> This was too quick, now pthreads isn't detected on IRIX (and other
> platforms?) anymore. This needs some more thought.
> Index: configu
TED]>, "J.
> Couch" <[EMAIL PROTECTED]>
> Subject: Re: [Flightgear-devel] Re: [Simgear-cvslogs]
>
> Hi Martin,
>
> Ok, this sounds reasonable. I assume this means that the isnan()
> problems are fixed in newer versions of FreeBSD?
>
> Thanks,
>
"Curtis L. Olson" wrote:
> Ok, this sounds reasonable. I assume this means that the isnan()
> problems are fixed in newer versions of FreeBSD?
To be honest: I don't know if the current handling in FreeBSD-5.3 is
_correct_, I just can state that the clause you introduced at this
place annoyed th
Hi Martin,
Ok, this sounds reasonable. I assume this means that the isnan()
problems are fixed in newer versions of FreeBSD?
Thanks,
Curt.
Martin Spott wrote:
Hello Curt,
could you please revert this change and remove the whole FreeBSD
clause - it just makes life harder on the cuurrent FreeBSD R
Hello Curt,
could you please revert this change and remove the whole FreeBSD
clause - it just makes life harder on the cuurrent FreeBSD RELEASE - or
change it. See below.
"Curtis L. Olson" wrote:
> Update of /var/cvs/SimGear-0.3/source/simgear/sound
> In directory baron:/tmp/cvs-serv27687/sound
>
"Norman Vine" wrote:
> according to this
> http://www.delorie.com/gnu/docs/glibc/libc_404.html
>
> isnan() is only defined for BSD for ISO C99
Might this be related to using different compilers? Curt uses GCC-3.3.3
and I have 3.4.2,
Martin.
--
Unix _IS_ user friendly - it's just selective abo
Martin Spott writes:
>
> "I don't understand why FreeBSD doesn't see isnan() after including math.h
> but it doesn't. Trying the apple approach to fixing isnan results in an
> infinite loop (making me wonder what happens on OSX?) This is an alternative
> approach to checking isnan() on freebsd .
Martin Spott wrote:
You're absolutely right. I was juggling with several patches and as a
result of my confusion I finally hit the wrong posting. Actually this
one would have been correct:
"I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple a
Erik Hofman wrote:
> This has nothing to do with _this_ patch, you must be referring to
> another one.
You're absolutely right. I was juggling with several patches and as a
result of my confusion I finally hit the wrong posting. Actually this
one would have been correct:
"I don't understand why
Erik Hofman wrote:
> This has nothing to do with _this_ patch, you must be referring to
> another one.
Hmmm, yes, it actually looked a bit strange to me, too, but I copied
the patch from the posting and applied it to my copy of the tree.
Maybe I picked the wrong file for patching confusion
Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/sound
In directory baron:/tmp/cvs-serv16290
Modified Files:
soundmgr_openal.cxx xmlsound.cxx
Log Message:
Melchior FRANZ:
At last I've found the reason why fgfs crashed routinely for me. When I still
use
Erik Hofman wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/sound
> In directory baron:/tmp/cvs-serv16290
> Modified Files:
> soundmgr_openal.cxx xmlsound.cxx
> Log Message:
> Melchior FRANZ:
>
> At last I've found the reason why fgfs crashed routinely for me. When I still
> used
"Curtis L. Olson" wrote:
> Jim Couch set up a freebsd machine and gave me an account on it. I
> don't know what release he installed, but it was running gcc-3.3.3 if
> that says anything to you.
The current RELEASE has 3.4.2 as their default compiler, so yours is
older. You can't do distinct d
On Sonntag 21 November 2004 22:46, Curtis L. Olson wrote:
> Christian Mayer wrote:
> >> + #if defined (__FreeBSD__)
> >> + inline int isnan(double r) { return !(r < 0 || r > 0); }
> >> + #endif
> >
> > This test will break if r == 0
According to IEEE, NaN is the only fp value that is not equal to
Martin Spott wrote:
"Curtis L. Olson" wrote:
I don't think my first attempt at an isnan() fix worked ... I ended up
in an infinite loop. I've tried a less elegant/brute force approach and
that seems to work. We actually got FG up and running on a FreeBSD
machine tonight (woohoo!)
Yeah
Christian Mayer wrote:
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r < 0 || r > 0); }
+ #endif
This test will break if r == 0
Oops, duhhh! Thanks!
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Pr
"Curtis L. Olson" wrote:
> I don't think my first attempt at an isnan() fix worked ... I ended up
> in an infinite loop. I've tried a less elegant/brute force approach and
> that seems to work. We actually got FG up and running on a FreeBSD
> machine tonight (woohoo!)
Yeah ! Welcome to a won
Curtis L. Olson schrieb:
Log Message:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an alternative
approach to checking isnan() on free
Martin Spott wrote:
"Curtis L. Olson" wrote:
Update of /var/cvs/SimGear-0.3/source/simgear/screen
In directory baron:/tmp/cvs-serv29601
Modified Files:
extensions.cxx
Log Message:
FreeBSD fix.
Thank you!
Would anyone mind to comment on the two proposed changes to SimGear and
"Curtis L. Olson" wrote:
> Update of /var/cvs/SimGear-0.3/source/simgear/screen
> In directory baron:/tmp/cvs-serv29601
> Modified Files:
> extensions.cxx
> Log Message:
> FreeBSD fix.
Thank you!
Would anyone mind to comment on the two proposed changes to SimGear and
FlightGear that I po
In the tarball, the directory is there with a Makefile.am with zero length
and a Makefile.in. I didn't try to generate from the tarball.
-Fred
Curtis L. Olson wrote:
> Shoot, that is junk that probalby shouldn't be there. I don't think it
> actually causes a problem though.
>
> Curt.
>
>
> Fred
Shoot, that is junk that probalby shouldn't be there. I don't think it
actually causes a problem though.
Curt.
Frederic Bouvier wrote:
Curtis L. Olson wrote:
Update of /var/cvs/SimGear-0.3/source/simgear/scene
In directory baron:/tmp/cvs-serv10533/simgear/scene
Modified Files:
Makefil
Curtis L. Olson wrote:
> Update of /var/cvs/SimGear-0.3/source/simgear/scene
> In directory baron:/tmp/cvs-serv10533/simgear/scene
>
> Modified Files:
> Makefile.am
> Log Message:
> Final 0.3.7 changes.
>
>
> Index: Makefile.am
> ==
Frederic Bouvier wrote:
> Erik Hofman wrote:
>
> > Erik Hofman wrote:
> > > Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb
> > > In directory baron:/tmp/cvs-serv8740/tgdb
> > >
> > > Modified Files:
> > > obj.cxx
> > > Log Message:
> > > Frederic Bouvier:
> > >
> > > put all leaf is a
Erik Hofman wrote:
> Erik Hofman wrote:
> > Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb
> > In directory baron:/tmp/cvs-serv8740/tgdb
> >
> > Modified Files:
> > obj.cxx
> > Log Message:
> > Frederic Bouvier:
> >
> > put all leaf is a seperated branch so that it is
> > possible
Erik Hofman wrote:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb
In directory baron:/tmp/cvs-serv8740/tgdb
Modified Files:
obj.cxx
Log Message:
Frederic Bouvier:
put all leaf is a seperated branch so that it is
possible to use a pretrav callback to cull out
terrain without culling
>On Mar 16, 2004, at 9:38 AM, Erik Hofman wrote:
>
>> Innis Cunningham wrote:
>>> Hi Guys
>>> I don't know if this helps in any way but I did
>>>a complete rebuild(plib,simgear,flightgear) about
>>>7 days ago under Cygwin on windows 98 and did
>>>not have any problem so unless the above area
>>> ha
On Mar 16, 2004, at 9:38 AM, Erik Hofman wrote:
Innis Cunningham wrote:
Hi Guys
I don't know if this helps in any way but I did
a complete rebuild(plib,simgear,flightgear) about
7 days ago under Cygwin on windows 98 and did
not have any problem so unless the above area
has been changed in the last
Hi John
You sure seem to have had your fair share of trouble doing
the build.I assume you have a running version of FG from
the binaries.
You say you are a software engineer maybe this is part of the
problem(I mean this in the nicest way).
I have and had very little knowledge of building FG so I ha
i uninstalled X11 but still can't run configure.
john
- Original Message -
From: "Erik Hofman" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Tuesday, March 16, 2004 10:38 AM
Subject: Re: [Flightgear-devel]Re:
Innis Cunningham wrote:
Hi Guys
I don't know if this helps in any way but I did
a complete rebuild(plib,simgear,flightgear) about
7 days ago under Cygwin on windows 98 and did
not have any problem so unless the above area
has been changed in the last 7 days it is not
simgear or cygwin that is to bl
Hi Guys
I don't know if this helps in any way but I did
a complete rebuild(plib,simgear,flightgear) about
7 days ago under Cygwin on windows 98 and did
not have any problem so unless the above area
has been changed in the last 7 days it is not
simgear or cygwin that is to blame.
Cheers
Innis
__
Norman Vine wrote:
I still submit that what I proposed is a 'proper' solution and don't
understand what you have against it as it only affects MingW and
Cygwin users.
I'm not against it. I just want to know why this was needed because
obviously the extensions code needs the same update then.
Eri
Erik Hofman writes:
>
> Norman Vine wrote:
>
> > If it works then it is getting WIN32 predefined from someplace other
> > then the compiler itself which will break a Cygwin compilation for
> > GLX < X windows OpenGL > which is a separate issue
> >
> > AFAIK the *only* Windows compiler that does
Norman Vine wrote:
If it works then it is getting WIN32 predefined from someplace other
then the compiler itself which will break a Cygwin compilation for
GLX < X windows OpenGL > which is a separate issue
AFAIK the *only* Windows compiler that does not #define WIN32 is Cygwin.
This is in orde
Erik Hofman writes:
>
> Norman Vine wrote:
>
> > This is still wrong needs to be included *before*
> > inorder for the the WINDOWS GL extensions and not the GLX extensions
> > to be recognized
>
> How do you explain that the extensions code does work this way.
If it works then it is getting W
Norman Vine wrote:
This is still wrong needs to be included *before*
inorder for the the WINDOWS GL extensions and not the GLX extensions
to be recognized
How do you explain that the extensions code does work this way.
Did you read the code or just the CVS log message?
Erik
Norman Vine wrote:
>
> so something like
>
> #if defined(__CYGWIN__) # && !defined(USING_X)
> #define WIN32
> #endif
>
> #if defined(WIN32) # MINGW and MSC predefine WIN32
> # include
> #endif
>
> HTH
Arrgh ... of course I meant something like
#if defined(__CYGWIN__) /* && !defined(USING_X
Erik Hofman writes:
>
> Frederic BOUVIER wrote:
> > Erik Hofman wrote:
> >
> >>Modified Files:
> >>glut_shapes.c glut_shapes.h
> >>Log Message:
> >>Further refinement of the Cygwin problem as suggested by Frederic.
> >
> >
> > Well, I had the impression that the code was originally good but th
Frederic BOUVIER wrote:
Erik Hofman wrote:
Modified Files:
glut_shapes.c glut_shapes.h
Log Message:
Further refinement of the Cygwin problem as suggested by Frederic.
Well, I had the impression that the code was originally good but the
configure step was failing to detect and set HAVE_WINDOWS_
Erik Hofman wrote:
>
> Modified Files:
> glut_shapes.c glut_shapes.h
> Log Message:
> Further refinement of the Cygwin problem as suggested by Frederic.
Well, I had the impression that the code was originally good but the
configure step was failing to detect and set HAVE_WINDOWS_H
That's why
Erik Hofman wrote:
> A : [EMAIL PROTECTED]
> Copie à :
> Objet : [Simgear-cvslogs] CVS: SimGear/simgear/scene/sky/clouds3d glut_shapes.h,
> 1.1, 1.2
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky/clouds3d
> In directory baron:/tmp/cvs-serv14020
>
> Modified Files:
> glut_shapes.h
>
David Megginson wrote:
Erik Hofman wrote:
Silently ignore texture files that are not present.
How about putting out a warning at a very low priority level, so that
people can debug problems if they need to?
That would be an option ...
The thing is, we now can have more than one specification f
Erik Hofman wrote:
Silently ignore texture files that are not present.
How about putting out a warning at a very low priority level, so that people
can debug problems if they need to?
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTE
Frederic BOUVIER wrote:
> Martin Spott wrote:
>> "proxy-username" ?
> When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD
> and the format is 'username:passwd'. You should try that syntax with FG.
Sorry, this does not work, I get a TCP_DENIED on my squid - but I'm
Martin Spott wrote:
Frederic BOUVIER wrote:
Martin Spott wrote:
"proxy-username" ?
When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD
and the format is 'username:passwd'. You should try that syntax with FG.
Sorry, this does not work, I get a TCP_DENIED on my
* Erik Hofman -- Thursday 26 February 2004 13:06:
> * Martin Spott wrote:
> > * Frederic BOUVIER wrote:
> > > When I use libcurl to do that, there is a single field called
> > > CURLOPT_PROXYUSERPWD
> > > and the format is 'username:passwd'. You should try that syntax with FG.
> >
> > Sorry, thi
Melchior FRANZ wrote :
> * Erik Hofman -- Thursday 26 February 2004 13:06:
> > * Martin Spott wrote:
> > > * Frederic BOUVIER wrote:
> > > > When I use libcurl to do that, there is a single field called
> > > > CURLOPT_PROXYUSERPWD
> > > > and the format is 'username:passwd'. You should try that
Frederic BOUVIER wrote:
> Melchior FRANZ wrote :
>
> > * Erik Hofman -- Thursday 26 February 2004 13:06:
> > > * Martin Spott wrote:
> > > > * Frederic BOUVIER wrote:
> > > > > When I use libcurl to do that, there is a single field called
> > > > > CURLOPT_PROXYUSERPWD
> > > > > and the format
* Frederic BOUVIER -- Thursday 26 February 2004 16:03:
> Pretty obvious : user and password seperated by colon ':', then base64
> encoded and then prepended with 'Basic '. I read reports saying that 'basic '
> (lower case), while permitted by the rfc, is rejected by some servers.
Thanks for the
* Frederic BOUVIER -- Thursday 26 February 2004 12:15:
> When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD
> and the format is 'username:passwd'. You should try that syntax with FG.
Ahh. That sounds reasonable. It's possibly up to the proxy to decide
how the autho
Melchior FRANZ wrote:
> * Martin Spott -- Thursday 26 February 2004 11:38:
> > BTW, after reading the patch I didn't figure _where_ to place the
> > information for proxy use
>
> Erik added the missing parts today. You can now set proxy information
> in /sim/presets/proxy/{host,port,authenticati
* Martin Spott -- Thursday 26 February 2004 11:38:
> BTW, after reading the patch I didn't figure _where_ to place the
> information for proxy use
Erik added the missing parts today. You can now set proxy information
in /sim/presets/proxy/{host,port,authentication}
/sim/presets/proxy/host = lo
Martin Spott wrote:
> Erik Hofman wrote:
>
> > Index: metar.cxx
> > ===
> > RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/environment/metar.cxx,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -C2 -r1.2 -r1.3
> > **
Erik Hofman wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/environment
> In directory baron:/tmp/cvs-serv28945
> Modified Files:
> metar.cxx metar.hxx
> Log Message:
> Melchior FRANZ:
>
> Add proxy support to the metar class. Authorization is untested, but
> everything else works.
Melchior FRANZ wrote:
> * Curtis L. Olson -- Friday 15 August 2003 19:56:
> > I haven't looked into this issue very closely. I have an nvidia card
> > and wasn't seeing anything odd, but perhaps I wasn't looking closely
> > enough.
>
> Same for me: nvidia without having seen anything strange.
He
* Curtis L. Olson -- Friday 15 August 2003 19:56:
> I haven't looked into this issue very closely. I have an nvidia card
> and wasn't seeing anything odd, but perhaps I wasn't looking closely
> enough.
Same for me: nvidia without having seen anything strange.
m.
Curtis L. Olson wrote:
> Erik Hofman writes:
> > Curtis L. Olson wrote:
> > > Erik,
> > >
> > > Using glGet() is considered a no-no in real time applications. That
> > > stalls out the pipeline and forces all pending operations to flush
> > > before the card can return with the correct answer. We
Erik Hofman writes:
> Curtis L. Olson wrote:
> > Erik,
> >
> > Using glGet() is considered a no-no in real time applications. That
> > stalls out the pipeline and forces all pending operations to flush
> > before the card can return with the correct answer. We might be able
> > to get away with
Frederic Bouvier wrote:
Erik Hofman wrote:
Curtis L. Olson wrote:
Erik,
Using glGet() is considered a no-no in real time applications. That
stalls out the pipeline and forces all pending operations to flush
before the card can return with the correct answer. We might be able
to get away with i
Erik Hofman wrote:
> Curtis L. Olson wrote:
> > Erik,
> >
> > Using glGet() is considered a no-no in real time applications. That
> > stalls out the pipeline and forces all pending operations to flush
> > before the card can return with the correct answer. We might be able
> > to get away with i
Curtis L. Olson wrote:
Erik,
Using glGet() is considered a no-no in real time applications. That
stalls out the pipeline and forces all pending operations to flush
before the card can return with the correct answer. We might be able
to get away with it in limited quantities, but this can *quickl
Erik,
Using glGet() is considered a no-no in real time applications. That
stalls out the pipeline and forces all pending operations to flush
before the card can return with the correct answer. We might be able
to get away with it in limited quantities, but this can *quickly* turn
into a performa
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen
> In directory baron:/tmp/cvs-serv22511
> Modified Files:
> texture.cxx texture.hxx
> Log Message:
> Attempt to get these files back to a compilable state.
Thanks,
Martin.
--
Unix
* Martin Spott -- Friday 11 July 2003 13:42:
> Unfortunately this still does not fix it. [...]
> texture.cxx: In member function `void SGTexture::set_pixel(unsigned int,
>unsigned int, float (&)[3])':
> texture.cxx: In member function `float (* SGTexture::get_pixel(unsigned int,
>unsigne
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen
> In directory baron:/tmp/cvs-serv16734
> Modified Files:
> texture.cxx
> Log Message:
> Don't use floats where ints are more appropriate
Unfortunately this still does not fix it. The output almo
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen
> In directory baron:/tmp/cvs-serv16338/simgear/screen
> Modified Files:
> texture.cxx texture.hxx
> Log Message:
> Allow removing of the texture data after it is sent to OpenGL
make[3]: Entering
Martin Spott wrote:
This does not serve as a complete fix:
quickstep: 16:54:30 /usr/local/src/SimGear> grep SGTHREAD simgear/Makefile
#SGTHREAD_DIR = threads
SGTHREAD_DIR =
$(SGTHREAD_DIR) \
I don't feel too smart right now.
Should be fixed.
Erik
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/SimGear-0.3/SimGear
> In directory baron:/tmp/cvs-serv13077
> Modified Files:
> configure.ac
> Log Message:
> Back out a patch that never went in CVS ...
This does not serve as a complete fix:
quickstep: 16:54:30 /usr/local/src/S
Michael Basler writes:
> I know it would come. I recall the (justified) discussion on options to
> disable certains FDMs in the build which would result in these FDMs soon
> beeing out of sync and forgotten. I fear this will be the fate of the 3D
> clouds (which I enjoyed very much), now.
The FDM'
Curt,
> Remove 3d clouds from the default build. These can still be
> built manually
I know it would come. I recall the (justified) discussion on options to
disable certains FDMs in the build which would result in these FDMs soon
beeing out of sync and forgotten. I fear this will be the fate of
Ok, sounds like a good idea.
Curt.
Bernie Bright writes:
> On Wed, 26 Feb 2003 13:50:17 -0600
> "Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
>
> > Update of /var/cvs/SimGear-0.3/SimGear/simgear/misc
> > In directory seneca:/tmp/cvs-serv25218/simgear/misc
> >
> > Modified Files:
> > sg_path
On Wed, 26 Feb 2003 13:50:17 -0600
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/misc
> In directory seneca:/tmp/cvs-serv25218/simgear/misc
>
> Modified Files:
> sg_path.cxx sg_path.hxx
> Log Message:
> Add some convenience functions to the S
On Mon, 30 Dec 2002 15:32:53 -0600
David Megginson <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/SimGear-0.3/SimGear/simgear/compatibility
> In directory seneca:/tmp/cvs-serv31511/simgear/compatibility
>
> Log Message:
> Directory /var/cvs/SimGear-0.3/SimGear/simgear/compatibility added to the
88 matches
Mail list logo
