On Mon, 2011-04-11 at 05:39 +0200, Pascal J. Bourguignon wrote:
> I just checked out the next branches in simgear and flightgear and
> pulled them, and when compiling with:
I think you either need to configure simgear using --with-jpeg-factory
or need to doe a 'make uninstall' for simgear before r
I just checked out the next branches in simgear and flightgear and
pulled them, and when compiling with:
#!/bin/bash
base=/data/src/simulation/fg/
prefix=/opt/fgfs
rsynch="rsync -HSWacvxz --progress --force --delete --delete
and another : why couldn't we maintain our own apt.dat /airport database ?
On Sun, Apr 10, 2011 at 7:39 PM, George Patterson
wrote:
> On Mon, Apr 11, 2011 at 10:10 AM, J. Holden wrote:
>> A number of Pacific Northwest airports have changed their identification.
>>
>> For instance Ranger Creek, W
Just another thought , but I'm on a laptop with mouse ... no joystick
to test is property aliasing ?
the multipayer options give me the idea but i'm no expert on this myself...
This is an example is a property transmitted over MP.
Mind you , you'd hav
Arnt,
Per your suggest, I re-ran the tests with --enable-fullscreen and
--geometry=1024x768. This improves performance noticeably on the master build,
and on the next build with material shaders off, but I don't see any
differences with material shaders on. So it actually opens the performanc
On Mon, Apr 11, 2011 at 10:10 AM, J. Holden wrote:
> A number of Pacific Northwest airports have changed their identification.
>
> For instance Ranger Creek, WA (near Mt. Rainier) is now K21W (from 6WA8?).
>
> Pierce Co. Thun is now KPLU, from 1S0.
>
> Tillamook is now KTMK, from S47.
>
> How do w
A number of Pacific Northwest airports have changed their identification.
For instance Ranger Creek, WA (near Mt. Rainier) is now K21W (from 6WA8?).
Pierce Co. Thun is now KPLU, from 1S0.
Tillamook is now KTMK, from S47.
How do we make these changes?
Cheers
John
-
On Sun, Apr 10, 2011 at 10:23 PM, Arnt Karlsen wrote:
> Hi,
>
> ..now, running it...
> loading scenario 'nimitz_demo'
> ALSA lib pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
> ALSA lib pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM
> cards.pcm.center_lfe ALSA lib pcm.c:2190:(snd_p
On Sun, Apr 10, 2011 at 11:15 PM, Arnt Karlsen wrote:
> Hi,
>
> ..first build failed on missing separators???, the next on:
> fgcom.cpp: In function ‘int main(int, char**)’:
> fgcom.cpp:374:53: error: ‘SPECIAL_FREQUENCIES_FILE’ was not declared in
> this scope
> fgcom.cpp:378:31: error: ‘DEFAULT_P
Hi,
..first build failed on missing separators???, the next on:
fgcom.cpp: In function ‘int main(int, char**)’:
fgcom.cpp:374:53: error: ‘SPECIAL_FREQUENCIES_FILE’ was not declared in
this scope
fgcom.cpp:378:31: error: ‘DEFAULT_POSITIONS_FILE’ was not declared in
this scope
fgcom.cpp:226:7: warni
On Sun, 10 Apr 2011 13:40:47 -0700, Alex wrote in message
<87pqotq1ps@sycorax.lbl.gov>:
> Arnt Karlsen writes:
>
> > and OSG-svn does not build on neither g++-4.6 nor g++-4.5, which
> > compiler version is used on the Hudson server?
>
> what are you talking about? osg svn head builds just
Arnt Karlsen writes:
> and OSG-svn does not build on neither g++-4.6 nor g++-4.5, which
> compiler version is used on the Hudson server?
what are you talking about? osg svn head builds just fine for me on
debian unstable with g++ 4.5.2 and everything just works.
--alex--
--
| I believe the m
Sid wrote: "Maybe you already looked into this , but to me it would make more
sense to bind the joystick buttons to activate the properties in the
actual autopilot.xml files rather than modifying the author's specialized
scripts.Or write a generic nasal file to handle the variety of different
On Sun, 10 Apr 2011 15:03:47 -0500, Curtis wrote in message
:
> Just for the record, I would be pretty strongly opposed to adding a
> thread for no particular benefit. In fact I think the threshold of
> gained benefit needs to be pretty high to add another thread to the
> code. Threads might se
On Sun, 10 Apr 2011 13:21:43 -0700 (PDT), Catherine wrote in message
<310496.9512...@web83912.mail.sp1.yahoo.com>:
> I'm noticing some very significant performance differences running
> the master build vs. the next build on my old, slow machine. Here's
> a quick table of fps rates, taken while
Hi,
..now, running it...
arnt@celsius:~/FG-git$ ./run_fgfs.sh --geometry=1920x1200 --httpd=
--jpg-httpd=9876 --prop:controls/gear/brake-parking=1
--prop:sim/frame-rate=true --fov=90 --enable-fullscreen
--timeofday=noon --aircraft=ju52 & [1] 14345 arnt@celsius:~/FG-git$
Processing command line
I'm noticing some very significant performance differences running the master
build vs. the next build on my old, slow machine. Here's a quick table of fps
rates, taken while sitting on the default runway at SFO in the 172, using no
command-line startup options:
master: no material shaders
Just for the record, I would be pretty strongly opposed to adding a thread
for no particular benefit. In fact I think the threshold of gained benefit
needs to be pretty high to add another thread to the code. Threads might
seem simple at first, but they can hide nasty bugs that are almost
impossi
On Sun, 10 Apr 2011, Curtis Olson wrote:
> I'm not an expert in nasal garbage collection, but I think the problem is
> that garbage collection is not something we can divide up into chunks (which
> is essentially what threading would do.) In addition, threading adds a lot
> of potential order dep
Heiko Schulz wrote:
> In Theory you could use Blender and manipulate the terrain:
> http://users.tkk.fi/~lapelto2/fgfs/import_btg_v7.py
> http://users.tkk.fi/~lapelto2/fgfs/export_btg.py
Sure, this approach is tempting, because you're getting nice return
pretty soon. But on the other hand it carr
On Sun, Apr 10, 2011 at 1:43 PM, Robert wrote:
> As discussed in "Stuttering at 1 Hz rate" we now know that regular and
> unpleasant stuttering is caused by Nasals garbage collector.
> So I thought about possibilities to improve it.
> What if we could decouple the following function as a separate
As discussed in "Stuttering at 1 Hz rate" we now know that regular and
unpleasant stuttering is caused by Nasals garbage collector.
So I thought about possibilities to improve it.
What if we could decouple the following function as a separate thread, so
that it runs *asynchronously* from the main t
On Sun, 10 Apr 2011 13:30:57 +0200, Csaba wrote in message
:
> On Sun, Apr 10, 2011 at 12:24 PM, Arnt Karlsen wrote:
> > Hi,
> >
> > ..simgear(?) link error output, compile log link below:
> > in function vtable for
> > simgear::SGPagedLOD:SGPagedLOD.cxx(.rodata._ZTVN7simgear10SGPagedLODE+0x110)
On Sun, 2011-04-10 at 19:24 +0200, Arnt Karlsen wrote:
> ... OSG-svn does not build on neither g++-4.6 nor g++-4.5,
> which compiler version is used on the Hudson server?
Nor with my OLD g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) ;=))
Geoff.
-
On Sun, 10 Apr 2011 14:34:35 +0200, ThorstenB wrote in message
<4da1a3db.8000...@gmail.com>:
> On 10.04.2011 13:29, Geoff McLane wrote:
>
> > As far as I am aware we can _NOT_ presently use
> > later that OSG-2.9.9 ;=((
> Yes, we can. But 2.8.3 + 2.9.9 are used by the automatic "download &
> co
On 10.04.2011 15:02, Geoff McLane wrote:
> On Sun, 2011-04-10 at 14:34 +0200, ThorstenB wrote:
>>> As far as I am aware we can _NOT_ presently use
>>> later that OSG-2.9.9 ;=((
>> Yes, we can.
> Huh? Then WHY does Arnt have a LINK problem with OSG-2.9.11?
I don't know. The error Arndt is seeing is
On Sun, 2011-04-10 at 14:34 +0200, ThorstenB wrote:
> > As far as I am aware we can _NOT_ presently use
> > later that OSG-2.9.9 ;=((
> Yes, we can.
Huh? Then WHY does Arnt have a LINK problem with OSG-2.9.11?
> It always takes some days to adapt sg/fg to OSG changes, but right
> now,
> it compi
On 10.04.2011 13:29, Geoff McLane wrote:
> As far as I am aware we can _NOT_ presently use
> later that OSG-2.9.9 ;=((
Yes, we can. But 2.8.3 + 2.9.9 are used by the automatic "download &
compile" script, since these versions are known to work fine. And as we
noticed, we have a lot of people run
On Sun, Apr 10, 2011 at 12:24 PM, Arnt Karlsen wrote:
> Hi,
>
> ..simgear(?) link error output, compile log link below:
> in function vtable for
> simgear::SGPagedLOD:SGPagedLOD.cxx(.rodata._ZTVN7simgear10SGPagedLODE+0x110):
> error: undefined reference to
> 'osg::PagedLOD::removeExpiredChildren(d
On Sun, 2011-04-10 at 12:24 +0200, Arnt Karlsen wrote:
> [snip]
> error: undefined reference to
> 'osg::PagedLOD::removeExpiredChildren(double, int,
> [snip]
Hi Arnt,
>From your compile log, note the entry -
*..we use system's OSG-2.9.11-1. ;o) ***
and from your 'dpkg' display that is what you ar
Hi,
..simgear(?) link error output, compile log link below:
make[3]: Leaving directory
`/home/arnt/FG-git/fgfs/flightgear/src/Traffic' make[2]: Leaving
directory `/home/arnt/FG-git/fgfs/flightgear/src/Traffic' Making
install in Main make[2]: Entering directory
`/home/arnt/FG-git/fgfs/flightgear/sr
On Sun, 10 Apr 2011 03:29:52 +0200, Csaba wrote in message
:
> On Sun, Apr 10, 2011 at 2:52 AM, Arnt Karlsen wrote:
> >
> > ..was my last successful OSG-build, OSG-2.9.9 and OSG-2.9.11
> > now also fails to build with c++-4.5.2-8, I'm using:
> > http://www.gitorious.org/fg/fgmeta/blobs/raw/maste
Catherine,
Not quite the answer you seek, but following to Sids comments. My advice is
keep any thing you want generic to your setup away from aircraft model nasal
if possible.
If it helps,
I used xml for controlling "some" auto pilot functions via Joy stick control
to avoid fooling around in na
On Sun, 10 Apr 2011 04:02:28 +0200, Arnt wrote in message
<20110410040228.676314d3@celsius.local>:
> On Sun, 10 Apr 2011 02:52:34 +0200, Arnt wrote in message
> <20110410025234.74393785@celsius.local>:
>
> > ..both plib and SimGear builds ok on c++-4.6.0-2 and my last
> > OSG, and on system OS
34 matches
Mail list logo
