Yon Uriarte wrote:
Hi,
On Sun, Dec 14, 2008 at 6:12 PM, Heiko Schulz aeitsch...@yahoo.de
mailto:aeitsch...@yahoo.de wrote:
My last cloudset has fewer but larger sprites. I did this because I
noticed that it saves a lot of fps. On the forum Gijs noticed the
same with my
Martin Spott wrote:
Not meaning to complain or trying to urge anyone, I just wanted to
report back that setting:
--prop:/environment/weather-scenario=METAR
either on the command line or in the ~/-fgfsrc file still does neither
set the Weather source to METAR in the Weather Scenario
Hi to all the developers,
Just want to let you know how much I appreciate your good work. FG has
come a long way and the latest CVS I am now running is a superb piece of
work. Thank you all for your diligence and hard work we appreciate it
greatly.
Now I just have one little glitch that seems to
I have sent the wrong file last time. Sorry for this new mistake.
Please send me some returns about this file. Let me know if there is
something I must change in order to put it in the repository.
Laurent
Le 9 décembre 2008 14:43, Laurent Vromman laur...@vromman.org a écrit :
Sorry, the
Hi,
On Mon, Dec 15, 2008 at 10:20 AM, Tim Moore timo...@redhat.com wrote:
Yon Uriarte wrote:
Hi,
On Sun, Dec 14, 2008 at 6:12 PM, Heiko Schulz aeitsch...@yahoo.de
mailto:aeitsch...@yahoo.de wrote:
My last cloudset has fewer but larger sprites. I did this because I
On lundi 15 décembre 2008, Yon Uriarte wrote:
Hi,
On Mon, Dec 15, 2008 at 10:20 AM, Tim Moore timo...@redhat.com wrote:
Yon Uriarte wrote:
SNIP
Yeah, at least not here (3870, 10x overkill for FG).
I maximize the window from default (800x600?) to aprox
1600x1200 and the frame rate
No, the cost of blending is proportional to the area
blended on the screen,
so a
few large sprites vs. many small sprites should cost
about the same. It is
true
that it takes longer to sort a large number of
sprites, but I'm not worried
about the sorting cost at this point.
Theory
On Monday 15 December 2008 19:43:25 Melchior Franz wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/747-400/Models/Liveries
In directory baron.flightgear.org:/tmp/cvs-serv29180/Models/Liveries
Modified Files:
KLM.xml
Log Message:
fix broken xml syntax
Ah, thanks for catching
* Durk Talsma -- Monday 15 December 2008:
Ah, thanks for catching these.
./scripts/tools/fg-check did this for me. (It also found
other problems.)
m. :-)
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las
Hi,
On Mon, Dec 15, 2008 at 6:00 PM, Heiko Schulz aeitsch...@yahoo.de wrote:
Theory vs praxis ;-) I just tested it- no, more sprites = less fps
Are you testing with drawing off? Where do I change the number of sprites?
heh, so many .xmls
What is your CPU?
If you feel so inclined, try
Theory vs praxis ;-) I just tested it- no, more
sprites = less fps
Are you testing with drawing off? Where do I change the
number of sprites?
heh, so many .xmls
What is your CPU?
cloudlayers.xml -clouds - num-sprites10/num-sprites
I use a Dualcore 2,6 Ghz
If you feel so inclined,
Hi,
or one could even more trivially do:
Index:
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
===
---
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
(revision
96)
+++
Hi,
decided to test it - more weirdness, it's not the attributes, with this
patch (still using attributes) it runs at 150+fps.
Index:
F:/c/flightgear-svn-performance/SimGear/simgear/scene/tgdb/ShaderGeometry.hxx
===
---
Hi,
ok, last tree-rendering patch spam. Using attached patch (with no
attributes) and
coverage /= 10.0 in obj.cxx:
Result: ufo, v=0, 160fps:
http://img266.imageshack.us/my.php?image=treessimpledlpatchbt7.jpg
click on the image to zoom it.
RAM usage seems to be under control. Go overheat your
Hi Tat,
- Tatsuhiro Nishioka a écrit :
Update of /var/cvs/FlightGear-0.9/data/Aircraft/A6M2
In directory baron.flightgear.org:/tmp/cvs-serv3209
Modified Files:
a6m2-sound.xml
Log Message:
Modified: to use p51d sounds in /Sounds for file sharing.
Do you plan to add p51d sound
I have taken a bit of time to test the CVS Cessna 172P, and have made a
few observations. The observations were made flying v1.0.0 on Windows
XP, but with last week's CVS aircraft. I do not have FG compiled on
Windows, and my Linux machine doesn't have nearly the performance as my
Windows
Hi,
On Dec 16, 2008, at 6:05 AM, Frederic Bouvier fredfgf...@free.fr
wrote:
Hi Tat,
- Tatsuhiro Nishioka a écrit :
Update of /var/cvs/FlightGear-0.9/data/Aircraft/A6M2
In directory baron.flightgear.org:/tmp/cvs-serv3209
Modified Files:
a6m2-sound.xml
Log Message:
Modified: to
3) I find that either the torque or P-factor (or both) modeling for
this emulation is unrealistic. When climbing at 75 knots with the Turn
Coordinator (TC) ball centered, the aircraft must be banked to the right
in order to maintain heading. This is unrealistic, and I recall that I
had
On 12/15/2008 04:31 PM, Tom Betka wrote a long note making
a number of good points.
Thanks!
Let me join the discussion here:
HP = [(2pi)*(Torque)*(RPM)] / 33000 [1]
Right. That's the formula I've been using when quoting
shaft horsepower numbers.
...one can easily see that the only
On 12/12/2008 09:36 AM, Durk Talsma wrote:
If all goes well, I would like to prepare the final release version next
Friday.
Wow.
Until that time please hold back on committing anything risky, and
give these prereleases a decent workout. Let's try to make this the best
FlightGear
On 12/15/2008 11:43 PM, Ron Jensen wrote:
As mentioned above, the MAP readings are not a bug
Well, then we need to find another word for it.
Perhaps we can call it a counterintuitive, unrealistic,
and undocumented feature.
In effect it is a highly nonlinear governor feature.
The real O-320,
21 matches
Mail list logo
