On Fri, Sep 30, 2011 at 4:22 PM, wrote:
> Am Fri, 30 Sep 2011 16:10:39 -0500
> schrieb Curtis Olson :
>
> > The downside is that this index is used so much in the scenery files
> > that going to a larger int size will have an immediate corresponding
> > proportional impact on the btg sizes of all
Am Fri, 30 Sep 2011 16:10:39 -0500
schrieb Curtis Olson :
> The downside is that this index is used so much in the scenery files
> that going to a larger int size will have an immediate corresponding
> proportional impact on the btg sizes of all the files.
Ten years ago 16 Bit hurt much more than
All that weird stuff is quite easy to explain. The binary .btg scenery
format uses 16 bit integers as indices for the vertex, normal, texture
coordinate lists. At one point we were using signed 16 bit integers, but
I'm pretty sure we sneakily changed the flightgear btg loader to use
unsigned 16 b
On Mon, Sep 12, 2011 at 3:55 PM, Thorsten Renk wrote:
>>> 3) Antishading
>
>> If you can provide the parameters of a cloud that is exhibiting the
>> problem, that would be most useful.
>
> Okay, I've decided over the weekend that I'll make my current code
> available this week, because there's so m
On 30 Sep 2011, at 11:56, Martin Spott wrote:
> Hah, I managed to find the web page I've been searching
> for weeks, Bruce did a pretty nice writeup of the problem:
>
> http://www.cullam.com/flightgear.htm
A very useful description, yes!
James
Hi,
Thanks for your replies with regards to this subject.
It is all starting to make some sense now. If I understand correctly then, the
C++ module generates an in-memory texture that the xml files reference for
displaying within the OSG tree. This texture is being continually re-generated
"J. Holden" wrote:
> PS - I only get around 3-6 FPS on this brand new laptop(!), and I'm
> finding with 2.4 simply launching "fgfs --airport=KMSP
> --aircraft=ufo" loads up local weather/real-time weather, which is
> terrible for a simple scenery flyover test on a poorly performing
> computer
Yup
"J. Holden" wrote:
> I apologize in advance considering I'm in a very complaining mood at
> the moment.
>From my perspective that's ok. We've been doing experiments with
detailed land cover data and (OSM-) roads for about five years now -
the first sample was built for LinuxTax 2006 - and I know
Durk, I only saw now the lszh ai. How should I create such for other airports?
Martin, I've no problem releasing all on GPL but I won't go asking all
authors for permission nor be responsibly for any violations.Anyone having all
permissions, feel free to integrate my Suisse04 airports in fgfs.
--
Michael Sgier wrote:
> Martin ur a jerk.
I know :-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
Martin ur a jerk. I've told to have submitted to 850 airports maintained by
Robin.
Pls read before rant about things you have no clue of.
Durk, sure I can also add AI if you can give me an example groundnetwork.For
now, I took lszh as pattern.
--- On Fri, 9/30/11, Martin Spott wrote:
From: Ma
Durk Talsma wrote:
> If you have committed apt.dat files, to robin peel [...]
That's quite interesting. As far as I understood from Michael's various
rants, he doesn't license his work under the GPL - please correct me if
I'm wrong. On the other hand, you automagically license under the GPL
by t
12 matches
Mail list logo
