Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
This came from Siggraph 2003 as did this cloud paper from MS
http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf
Hmmm...some interesting hints in there.
Indeed, I esp like the super impostor
i.e the 'distant' clouds
Norman Vine writes:
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
This came from Siggraph 2003 as did this cloud paper from MS
http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf
Hmmm...some interesting hints in there.
Indeed, I esp like the super
Curtis L. Olson writes:
Norman Vine writes:
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
This came from Siggraph 2003 as did this cloud paper from MS
http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf
Hmmm...some interesting hints in there.
Norman Vine [EMAIL PROTECTED] said:
This came from Siggraph 2003 as did this cloud paper from MS
http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf
Hmmm...some interesting hints in there.
Best,
Jim
___
Flightgear-devel mailing list
Norman Vine wrote:
I noticed a *very* significant fps drop with the new scenry objects
in San Francisco which may be due to having many small textures
rather then having the small textures combined into one as is done
with the Panel
I use texture repetition for the buildings. Is it
Frederic BOUVIER writes:
Norman Vine wrote:
I noticed a *very* significant fps drop with the new scenry objects
in San Francisco which may be due to having many small textures
rather then having the small textures combined into one as is done
with the Panel
I use texture
Norman Vine wrote:
Frederic BOUVIER writes:
Norman Vine wrote:
I noticed a *very* significant fps drop with the new scenry objects
in San Francisco which may be due to having many small textures
rather then having the small textures combined into one as is done
with the
Norman Vine [EMAIL PROTECTED] wrote:
It's disturbing that even at take off from KSFO that the FPS drops
so dramatically when looking in the 'right' direction when these things
are so far away
In my opinion this is the only annoyance in FlightGear that really hurts
noticeably. Even when you
Martin Spott writes:
Norman Vine [EMAIL PROTECTED] wrote:
It's disturbing that even at take off from KSFO that the FPS drops
so dramatically when looking in the 'right' direction when these things
are so far away
In my opinion this is the only annoyance in FlightGear that really
Frederic BOUVIER writes:
BTW, what are the good trade-off, performance wise ?
- big texture vs small repeated texture,
- texture vs geometry
- colour vs texture
Good questions !
Rule of thumb is fewer is better but it all depends on
your GFX card and what else you are displaying :-)
Hi,
Just moved house, having all kinds of problems... but I have still get a
deep sense of curiousity about all this.
Is the scene calculated in the main loop? - Do we check these buildings
are there every cycle?
Or is the implementation more along the lines of; calculated in advance
and
Christopher S Horler writes:
Just moved house, having all kinds of problems... but I have still get a
deep sense of curiousity about all this.
Is the scene calculated in the main loop? - Do we check these buildings
are there every cycle?
Or is the implementation more along the lines
David Megginson writes:
I've noticed a substantial (50%) framerate drop with the recent
revisions to FlightGear. I'll try some profiling when I have time,
but is it possible that some of the recent changes to airport handling
have introduced some slow code into the main loop? It could
David Megginson writes:
I've noticed a substantial (50%) framerate drop with the recent
revisions to FlightGear. I'll try some profiling when I have time,
but is it possible that some of the recent changes to airport handling
have introduced some slow code into the main loop? It could also
but 2.0 is in part a 'rconciliation' of the various 'propriatary' extensions
and the inclusion of things that almost all of the manufacturers have done
to support M$oft DX#. And this driver has more of these upcoming features
then any of the previous ones.
So this driver is Nvidia's tool to
-
From: Norman Vine [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 07, 2002 10:32 AM
To: 'David Megginson'
Cc: 'Curtis Olson'
Subject: RE: [Flightgear-devel] FrameRate !!
Curt David
Something changed recently so that when the HUD
is displayed the framerate drops dramatically when the
Menu
Norman Vine writes:
This appears to be a bug in the latest NVIDIA drivers
Reverting to any of several of their earlier ones and the
problem goes away.
Just for the benefit of everyone else, Norm means the latest NVIDIA
*windows* drivers. I'm not aware of any similar problem with the
David Megginson writes:
Norman Vine writes:
This appears to be a bug in the latest NVIDIA drivers
Reverting to any of several of their earlier ones and the
problem goes away.
Just for the benefit of everyone else, Norm means the latest NVIDIA
*windows* drivers. I'm not aware of any
This driver has lots of neat new features OpenGL 2.0
Do they really implement the upcoming OpenGL-2.0 features in hardware or do
they tend to rely on fallbacks ? It's somewhat astonishing that they already
provide a driver for a still not really existent OpenGL standard. Do they
create their
Martin Spott writes:
This driver has lots of neat new features OpenGL 2.0
Do they really implement the upcoming OpenGL-2.0 features in hardware or do
they tend to rely on fallbacks ? It's somewhat astonishing that they
already
provide a driver for a still not really existent OpenGL
I think a series of demos would be a great idea. It would also be nice if
there were demos for various terrain types (stress testing). I fly around
the Seattle area simply because the mountains drastically impact frame
rate.
Not only the mountains. ATIS display has _heavy_ impact. I
On Monday 08 April 2002 07:41 am, you wrote:
I think a series of demos would be a great idea. It would also be nice
if there were demos for various terrain types (stress testing). I fly
around the Seattle area simply because the mountains drastically impact
frame rate.
Not only the
On Monday 08 April 2002 07:41 am, you wrote:
Not only the mountains. ATIS display has _heavy_ impact. I usually get
around 100 fps inside a 800x600 window (BETA Radeon DRI driver, only 40 fps
left at 1600x1024 ), at KSEA I only get 30-50 fps because of ATIS
display (with today's current
Jim Wilson wrote:
Alex Perry [EMAIL PROTECTED] said:
Gadds. I don't know...even with an almost completely idle cpu occaisonally I
seem to have these weird performance discrepencies. It isn't heat, so who
knows. Maybe its something weird about the kernel. Later without changing
Norman Vine wrote:
This profiling run might be enlightening
time seconds secondscalls us/call us/call name
4.07 2.45 0.14 657919 0.21 0.21 fgGetBool(char const
3.49 2.57 0.12 2352563 0.05 0.05 fgGetDouble(char const
3.20 2.92
Christian Mayer writes:
Norman Vine wrote:
This profiling run might be enlightening
IT's very interesting to see that fgGetBool takes a
significantly longer
time to run (3x - 10x as long).
Perhaps we can optimze the result by returning a int instead of a bool
(afaik is int supposed to be
From: Christian Mayer [EMAIL PROTECTED]
Norman Vine wrote:
This profiling run might be enlightening
time seconds secondscalls us/call us/call name
4.07 2.45 0.14 657919 0.21 0.21 fgGetBool(char
const
3.49 2.57 0.12 2352563 0.05
Norman Vine wrote:
Christian Mayer writes:
Norman Vine wrote:
This profiling run might be enlightening
IT's very interesting to see that fgGetBool takes a
significantly longer
time to run (3x - 10x as long).
Perhaps we can optimze the result by returning a int instead of a bool
Hello,
How about a reproductible way to benchmark FlightGear ? Something like
q1test or
q2test in Quake. That is : an automated sequence of flight during, say 30s
to 2mn,
along a predetermined path from KSFO with different views. This could be
presented
has a demo and at the end, a summary on
Hello,
How about a reproductible way to benchmark FlightGear ? Something like
q1test or
q2test in Quake. That is : an automated sequence of flight during, say 30s
to 2mn,
along a predetermined path from KSFO with different views. This could be
presented
has a demo and at the end, a
Christian Mayer writes:
THat's nice, but the 'problem' with fgGetBool is still existant (and
it's getting worse as we are using the property system more and more).
fgGetBool may be taking longer because it's accessing a property
that's not typed as a bool. If you have this in an init file
Jim Wilson writes:
Haven't had a chance to look through the changes, but umm...I'm seeing a
25% decrease in framerate after this mornings patches. Sorry.
(Voodoo3/P3-750mhz/100mhz MB/384mb Ram)
Ouch! Have you upgraded SimGear as well?
All the best,
David
--
David Megginson
[EMAIL
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Haven't had a chance to look through the changes, but umm...I'm seeing a
25% decrease in framerate after this mornings patches. Sorry.
(Voodoo3/P3-750mhz/100mhz MB/384mb Ram)
Ouch! Have you upgraded SimGear as well?
Gadds. I don't know...even with an almost completely idle cpu occaisonally I
seem to have these weird performance discrepencies. It isn't heat, so who
knows. Maybe its something weird about the kernel. Later without changing
anything it looked much better, aproximately a 10% improvement
Alex Perry [EMAIL PROTECTED] said:
Gadds. I don't know...even with an almost completely idle cpu occaisonally I
seem to have these weird performance discrepencies. It isn't heat, so who
knows. Maybe its something weird about the kernel. Later without changing
anything it looked much
Norman Vine writes:
all figures are for at rest no HUD or Panel Default location
at Noon Brakes on MingW32 compiled on Win2k
Geforce2 GTS No model shown ie. View[0]
March 16 ~78 fps
last week ~71 fps
today ~66 fps
this is a negative change of 15% :-(((
David Megginson writes:
Norman Vine writes:
all figures are for at rest no HUD or Panel Default location
at Noon Brakes on MingW32 compiled on Win2k
Geforce2 GTS No model shown ie. View[0]
March 16 ~78 fps
last week ~71 fps
today ~66 fps
this is a negative
Norman Vine writes:
This profiling run might be enlightening
4.07 2.45 0.14 657919 0.21 0.21 fgGetBool(char const
*, bool)
3.49 2.57 0.12 2352563 0.05 0.05 fgGetDouble(char const
*, double)
OK, this jogs my memory. I took out the old
On Sat, Apr 06, 2002 at 12:25:29PM -0500, Norman Vine wrote:
Anyone know how to count 'cache invalidations' ?
Under Linux, you can get this kind of thing from oprofile
(http://oprofile.sf.net), if you have a motherboard with an IO-APIC
interrupt controller. It's a very powerful profiling
David Megginson wwrites:
Norman Vine writes:
This profiling run might be enlightening
OK, this jogs my memory. I took out the old path-caching code before,
and didn't add a new hashtable yet. I'll try to do that early next
week.
Cool
This might be a problem too
time seconds seconds
Norman Vine writes:
This might be a problem too
time seconds secondscalls us/call us/call
5.81 2.31 0.20 3455357 0.06 0.06
FGGlobals::get_current_view(void) const
Judging by the number of times this is called
i.e 54 times per LOOP
David Megginson writes:
Norman Vine writes:
Judging by the number of times this is called
i.e 54 times per LOOP iteration
this 'might' be a 'good' candidate for inlining
It's a bad one for inlining, actually, because that forces globals.hxx
to have a dependency on viewmgr.hxx, so all
Norman Vine writes:
So ???
So it hurts development a lot. Developers have limited time to
contribute to FlightGear, and if the program takes always takes 5 or
10 minutes to rebuild (and has to be rebuilt, say, 10 times to test
and debug each change), we all suffer because a lot less code
David Megginson [EMAIL PROTECTED] said:
It's a bad one for inlining, actually, because that forces globals.hxx
to have a dependency on viewmgr.hxx, so all of FlightGear has to
rebuild whenever Jim touches the viewer code.
What we should do is find out why get_current_view is called so much
David Megginson writes:
Norman Vine writes:
So ???
So it hurts development a lot. Developers have limited time to
contribute to FlightGear, and if the program takes always takes 5 or
10 minutes to rebuild (and has to be rebuilt, say, 10 times to test
and debug each change), we all suffer
David Megginson [EMAIL PROTECTED] said:
Norman Vine writes:
So ???
So it hurts development a lot. Developers have limited time to
contribute to FlightGear, and if the program takes always takes 5 or
10 minutes to rebuild (and has to be rebuilt, say, 10 times to test
and debug each
Jim Wilson writes:
David Megginson [EMAIL PROTECTED] said:
There's an easy solution here -- remove FGGlobals::get_current_view
completely and have the callers use FGGlobals::get_view_mgr to get the
current view. The right solution, though, is to find out *why* so
many parts of the code are
Norman Vine [EMAIL PROTECTED] said:
It seems as if we are losing FrameRate rather quickly
all figures are for at rest no HUD or Panel Default location
at Noon Brakes on MingW32 compiled on Win2k
Geforce2 GTS No model shown ie. View[0]
March 16 ~78 fps
last week ~71 fps
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
It seems as if we are losing FrameRate rather quickly
all figures are for at rest no HUD or Panel Default location
at Noon Brakes on MingW32 compiled on Win2k
Geforce2 GTS No model shown ie. View[0]
March 16 ~78 fps
last
Melchior FRANZ [EMAIL PROTECTED] said:
The changes from yesterday turned my framerate at KSFO from about
10 to 1 per second. Ten is already painful enough, and that with
clouds and panel turned off. But one is a bit weak and makes fgfs
virtually unflyable. (I've only got a 266MHz processor
Melchior FRANZ writes:
The changes from yesterday turned my framerate at KSFO from about
10 to 1 per second. Ten is already painful enough, and that with
clouds and panel turned off. But one is a bit weak and makes fgfs
virtually unflyable. (I've only got a 266MHz processor and a V3
51 matches
Mail list logo
