>
> Indeed the jitter is caused by Nasal's "garbageCollect" method. Simple
> test: add a printf (apply attached "patch" to simgear) and you should see
> the "stutter" is synchronized with it.
>
True! The text is printfed with every jitter.
> Well, there is a workaround! Use a faster CPU :). I s
On 25.03.2011 02 :56, Robert wrote:
Yeah you are right. After removing every script from the global Nasal
folder, the events subsystem showed it spent 0 ms.
Copying the scripts back to that folder one by one increased the time
spent.
Indeed the jitter is caused by Nasal's "garbageCollect" method
Just wanted to add that transparency is working with Alpha Exponent
(DXT5) for me.. I'm using the latest Hudson build (Win7 x64) with
fgdata cloned last night. I converted the F-16 liveries to DXT5, and
used Alpha Exponent for the markings (which are mostly transparent).
It looks ugly in the dds v
On 3/24/2011 2:18 PM, Kpykcъ wrote:
> Hi all,
>
> with no doubt, question about view capture is not rare, but what
> i've found, is that only solution which able to stream view image via
> network is screenstreamer [ http://pigeond.net/flightgear/screenstreamer/ ]
> patch and
> now its outdated, a
Nice "white-out" or rather "gray-out" when entering the rainy bit :) . (Not
recommended with a plane that has no interior :P )
As for texture sizes, I think that those that are 6-9/sheet can be "converted"
to 6-9 textures of 256x256, for the rest I think it depends on their shape,
and of course
On Thu, 24 Mar 2011 14:33:45 +0100, Robert wrote in message
:
> >
> > > > --prop:/sim/rendering/multi-sample-buffers=true
> > >
> > > ..this segfaulted on my 3 day old git, will retest with todays.
> >
>
> This maybe a problem with your graphics drivers. This option turns on
> Antialiasing. As I
On Friday 25 March 2011 14:00:20 thorsten.i.r...@jyu.fi wrote:
> > Quick and easy way out, compressed textures for the clouds as in .dds
> > textures
> >
> > :D
> >
> > (sorry about that, couldn't help myself :P)
>
> I doubt it's a general solution since I get 30% framerate reduction for
> dds t
On Friday 25 March 2011 14:00:20 thorsten.i.r...@jyu.fi wrote:
> > The most efficient way seems to have everything else maxed out, and
> > selected.
>
> Not always. Asymmetric buffering is good if you fly straight, but very bad
> if you circle - for soaring it's completely unsuitable as you'd con
> Quick and easy way out, compressed textures for the clouds as in .dds
> textures
> :D
> (sorry about that, couldn't help myself :P)
I doubt it's a general solution since I get 30% framerate reduction for
dds textures. But you can do it for yourself and see if it helps your case
- all models and
On Friday 25 March 2011 13:38:38 Emilian Huminiuc wrote:
> On Friday 25 March 2011 12:52:58 thorsten.i.r...@jyu.fi wrote:
> > > Yep things improve, noticeably. And I'm more convinced it's a lack of
> > > gpu memory issue (as in it gets filled up pretty quick with the
> > > clouds), as I caught a gl
On Friday 25 March 2011 12:52:58 thorsten.i.r...@jyu.fi wrote:
> > Yep things improve, noticeably. And I'm more convinced it's a lack of gpu
> > memory issue (as in it gets filled up pretty quick with the clouds), as I
> > caught a glimpse of scenery getting redrawn too.
>
> You may be right - I l
> Yep things improve, noticeably. And I'm more convinced it's a lack of gpu
> memory issue (as in it gets filled up pretty quick with the clouds), as I
> caught a glimpse of scenery getting redrawn too.
You may be right - I looked up the specs of my computer, and it seems I
have 512 MB VRAM, so th
On Friday 25 March 2011 11:57:38 Emilian Huminiuc wrote:
> Hmm, I'm gonna do a compile with the changed CACHE_OFF to CACHE_ALL, and
> see if that makes a difference.
Yep things improve, noticeably. And I'm more convinced it's a lack of gpu
memory issue (as in it gets filled up pretty quick with t
Hmm, I'm gonna do a compile with the changed CACHE_OFF to CACHE_ALL, and see
if that makes a difference.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security dem
Or maybe the mobile card's design is a bit different, or a bit newer and might
have better memory specs.(bandwidth, timings, size etc...)
--
Enable your software for Intel(R) Active Management Technology to meet the
growi
On Friday 25 March 2011 11:31:57 thorsten.i.r...@jyu.fi wrote:
> Hm, I'm running an nVidia GeForce 8600M GT from linux - unless the mobile
> version makes all the difference, that would argue against a graphics card
> issue (or maybe I'm missing something, I'm not a hardware specialist
> either...)
On Fri, Mar 25, 2011 at 7:44 AM, Thorsten Renk wrote:
>> The "local weather" menu option is first before the other local weather
>> options. This does open up a dialog box where you do have to create
>> clouds
>> 1-by-1. Looking at this, it appears that the intent of this is more for
>> debuggin
> This happens here as well (nVidia 8600GT (256MB VRAM) on linux). Now
> that I
> think of it it looks and behaves like graphics card memory bandwidth
> issue,
> maybe it is cured with the image cache set with CACHE_ALL? as by adding
> some
> more sistem RAM things haven't improved here.
Hm, I'm r
On Friday 25 March 2011 10:01:33 thorsten.i.r...@jyu.fi wrote:
> > The main thing that bugs me with the system is that the view frustum
> > culling
> > around the edges of the screen is visible, so you continuously see the
> > clouds being created and disappearing at the edges of the screen as you
> The main thing that bugs me with the system is that the view frustum
> culling
> around the edges of the screen is visible, so you continuously see the
> clouds being created and disappearing at the edges of the screen as you
> turn
> or change views. If it was once in a while I could live with
> The "local weather" menu option is first before the other local weather
> options. This does open up a dialog box where you do have to create
> clouds
> 1-by-1. Looking at this, it appears that the intent of this is more for
> debugging. Maybe it would make sense to move this option over to th
21 matches
Mail list logo
