Flightgear-commitlogs wrote:
The branch, next has been updated
- Log -
[...]
commit 1dfde64ac2e6ed0af91cf986cad8808c0182d408
Author: Frederic Bouvier
Date: Wed Jan 25 23:42:10 2012 +0100
Use bigger point sprites for
I think that you have to add new techniques (an XML element) to
existing effect file. You leave the current technique intact and
copy/paste it in the same file, add or change what is needed and
Modify its predicate.
Look at model-default.eff that implements 2 techniques.
Techniques can
Martin Spott wrote:
On my (my wife's) system (Linux Nvidia proprietary driver) this change
turns PAPI/VASI lights into huge, illuminated baloons. Therefore I
strongly propose to just revert this change.
The same applies to the other runway lights which are affected by the
same commit.
Anyhow
Martin wrote:
On my (my wife's) system (Linux Nvidia proprietary driver) this change
turns PAPI/VASI lights into huge, illuminated baloons. Therefore I
strongly propose to just revert this change.
Same here on Nvidia Geforce GT 540M, see screenshot at:
On Wed, 2012-03-07 at 11:54 +0100, Gijs de Rooy wrote:
Martin wrote:
On my (my wife's) system (Linux Nvidia proprietary driver) this
change
turns PAPI/VASI lights into huge, illuminated baloons. Therefore I
strongly propose to just revert this change.
Same here on Nvidia Geforce GT
De: Erik Hofman
On Wed, 2012-03-07 at 11:54 +0100, Gijs de Rooy wrote:
Martin wrote:
On my (my wife's) system (Linux Nvidia proprietary driver) this
change
turns PAPI/VASI lights into huge, illuminated baloons. Therefore
I
strongly propose to just revert this change.
Erik Hofman wrote:
I believe their size used to be distance dependent in the past.
It still is. When looking from the startup position on 07 at EDDS at
the PAPI, the light 'balloons' appear as being much taller than a
Cessna. From the centerline at PAPI position the still look like
spheres of
Frederic Bouvier wrote:
Just wanted to break the statu quo
I confirm, you've been successful :-)
Anyhow I think you've just replaced one flaw by another - and the new
one is even more inappropriate than the previous state.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just
Techniques (with their predicate) are tested in
ascending order of their index (the n attribute), so you can
create a new technique with a lower index than the one for the
current technique and add a predicate that test (for example)
/sim/rendering/lightfield.
Thanks Frederic - this seems to
De: thorsten i renk
I think that you have to add new techniques (an XML element) to
existing effect file. You leave the current technique intact and
copy/paste it in the same file, add or change what is needed and
Modify its predicate.
Look at model-default.eff that implements 2
Techniques (with their predicate) are tested in
ascending order of their index (the n attribute), so you can
create a new technique with a lower index than the one for the
current technique and add a predicate that test (for example)
/sim/rendering/lightfield.
Thanks Frederic - this
Hi all.
3. define an XML format for describing the two possible rendering pipelines
(the current and new). The format will introduce optional elements (such as
shadows, ambient occlusion, glow).
I want to point out my work on my newcameras branch:
Hi Lauri,
Hi all.
3. define an XML format for describing the two possible rendering
pipelines (the current and new). The format will introduce
optional elements (such as shadows, ambient occlusion, glow).
I want to point out my work on my newcameras branch:
Martin Spott wrote:
As far as I can tell there's still a functional gap in the current
implementation of shader control. When I start FlightGear with:
--prop:/sim/rendering/shaders/quality-level=0
(that's what is controlled by the slider, correct ?) then I still
get the full
Hi everybody,
it's a few weeks I'm dealing with a few analog to digital converters, I'm
using them to convert external analog signals and use them as inputs to
FlightGear controls.
I'm wondering which resolution is best when dealing with properties of type
double. My analog values get
Hi,
On Wednesday, March 07, 2012 11:54:39 Gijs de Rooy wrote:
Same here on Nvidia Geforce GT 540M, see screenshot at:
https://lh3.googleusercontent.com/-YGfvue1R00s/T1c-OMTX83I/CdQ/nnik0
ZI1_Wk/s1024/fgfs-screen-055.png
No screenshot here, but I also agree that the current lights are
Am 07.03.2012 18:14, schrieb Roberto Inzerillo:
Hi everybody,
it's a few weeks I'm dealing with a few analog to digital converters, I'm
using them to convert external analog signals and use them as inputs to
FlightGear controls.
I'm wondering which resolution is best when dealing with
Hi,
On Wednesday, March 07, 2012 14:58:26 Lauri Peltonen wrote:
3. define an XML format for describing the two possible rendering
pipelines (the current and new). The format will introduce optional
elements (such as shadows, ambient occlusion, glow).
I want to point out my work on my
On Wed, 7 Mar 2012, Roberto Inzerillo wrote:
I see FGFS keyboard/mouse interface uses 7/8bit resolution. I'd like to
know if someone can help me figuring out what input resolution should I
use for: /controls/flight/aileron /controls/flight/aileron-trim
/controls/flight/elevator
Hi,
I've been using 12 bit resolution. Need it since I'm also operating with a
control force loading system and autopilot. If you go to 12 bits suggest you
get some high res, multi-turn pots or some other systems (like magnetic) to
give you the precision that warrants 12 bits. If you're using
On Wed, Mar 7, 2012 at 04:54, Martin Spott martin.sp...@mgras.net wrote:
Therefore I think it would be a good idea to revert the entire commit
as a whole and to leave this place as-is until a better implementation
of airport lights comes up.
On a slightly related note, this makes me think of
Parking brake is just a on/off flag (1bit).
Well, right, but not totally. I've seen aircrafts accepting a double
value, and I'd like to make it consistent. Intermediate values make
sense here since it's a lever that moves along a path (or at least
rotates around a hinge). It's not a two
Roberto Inzerillo wrote:
Well, right, but not totally. I've seen aircrafts accepting a double
value, and I'd like to make it consistent. Intermediate values make
sense here since it's a lever that moves along a path (or at least
rotates around a hinge). It's not a two positions switch.
On Wed, 7 Mar 2012, castle...@comcast.net wrote:
Hi,
I've been using 12 bit resolution. Need it since I'm also operating with
a control force loading system and autopilot. If you go to 12 bits
suggest you get some high res, multi-turn pots or some other systems
(like magnetic) to give
Think of it this way, determine the angular travel of your control
stick; for 8bits divide by 256; for 12 bits divide by 4096. That defines
the resoluion., i.e. degrees per bit. So then you have to decide how
good is your sensor in defining the control stick location. If you can't
sense 4096
Am 07.03.2012 20:59, schrieb Roberto Inzerillo:
I'm not talking about what people are currently doing (I'd go with 24bit
on everything ... joking!), I'm asking about reasons (technical aspects,
facts) that can help me decide for high-res against low-res.
That would help me a lot in making good
I can tell you from experience with many users during our LinuxTag and
FSweekend presentations that you need
- for throttle: 1 bit (full/idle)
- for Mixture: 1 bit(full rich/cutoff)
- for RPM: allway full (constant)
:D :D :D :D :D
On Wed, Mar 7, 2012 at 2:46 PM, Torsten Dreyer tors...@t3r.de wrote:
I can tell you from experience with many users during our LinuxTag and
FSweekend presentations that you need
- for throttle: 1 bit (full/idle)
- for Mixture: 1 bit(full rich/cutoff)
- for RPM: allway full (constant)
If you plan to do any formation flight, then you need all the resolution you
can get from engine controls.
Anyway, I would try to dimension the resolution on the minimum amount of play
that can be obtained on the controls.
Just build one sensor and edit the input file so that you can map it
Hi,
Also for the breginning of the development cycle, I started working on
improoving fgviewer and cleanup scenery/model loading.
I have now checked in a change that should fix some long standing problems with
modelss that appear to have z-fighting. This change should not harm and works
so
I still have two small (weather-related) issues which I can't resolve myself:
* rain is still 'smart' i.e. de-activates above the lowest cloud layer.
Since Advanced Weather has its own precipitation region control, I'd need
a dumb version which just rains when I set the property
* for
31 matches
Mail list logo
