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 interes
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 l
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'
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
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
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 setti
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 :-)
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 th
"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
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
> >
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 textu
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 pos
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 cou
> 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
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
> 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 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
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
Li
elease !
Norman
>-Original Message-
>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 chan
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 withou
> 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
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 on
> 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 usu
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 look
> 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
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 a
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
[EMA
Norman Vine <[EMAIL PROTECTED]> said:
>
> It seems to be worthwhile trying to get fgRehape() out of the loop
> This is only necessary for determining if the Panel display has been
> toggled or switched so we should be able to get this out of the main
> loop also :-)
>
> Folks might want to upda
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
> 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,
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 fra
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 returnin
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
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 sup
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
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 t
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 de
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
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 s
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 get
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.
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 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
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 t
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 pa
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
> >
> >
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%
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
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
Norman Vine writes:
> 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
> today
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
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 proces
53 matches
Mail list logo
