Re: [Flightgear-devel] FlightGear 1.9.1 for Mac OS X

2009-02-01 Thread Durk Talsma
Hey Tat

On Sunday 01 February 2009 20:32:31 Tatsuhiro Nishioka wrote:
 Hi there,

 I've released FlightGear 1.9.1 for Mac OS X.



Thanks a lot!

D.

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-31 Thread Frederic Bouvier
Csaba Halász a écrit :
 Hi!

 I thought one of the reasons for keeping the data package unchanged
 was to have a small upgrade download available, with only the
 executables inside.
 I don't see it on the web page, has this idea been abandoned?
 Not that I am personally interested in it, of course.
   

ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun+fgfs-osg-win32-1.9.1b.zip

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/   Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-30 Thread Csaba Halász
Hi!

I thought one of the reasons for keeping the data package unchanged
was to have a small upgrade download available, with only the
executables inside.
I don't see it on the web page, has this idea been abandoned?
Not that I am personally interested in it, of course.

-- 
Csaba/Jester

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-27 Thread Vivian Meazza
Csaba Halász

 
 On Tue, Jan 27, 2009 at 3:44 AM, Ron Jensen w...@jentronics.com wrote:
 
  A simple onespeed supercharger example is shown below:
   numboostspeeds 1   /numboostspeeds
   ratedboost18.15/ratedboost1 !-- 46.5 inHg --
   ratedpower1 1900   /ratedpower1 !-- Horsepower --
   ratedrpm1   2600   /ratedrpm1
   ratedaltitude1 0 /ratedaltitude1
 
 From an xml standpoint, all those 1s look horrible (I mean
 ratedboost1, ratedpower1, etc).
 Is it too late to do away with them?
 I would suggest something like:
 
 supercharger
 stage
 boost8.15/boost
 power1900/power
 rpm2600/rpm
 altitude0/altitude
 /stage
 stage
 !-- stage #2 here --
 /stage
 /supercharger
 
 I am saying this without any knowledge of the existing conventions and
 compatibility issues, so feel free to ignore it :)
 

You are conflating 2 issues here: a 2 speed supercharger is _not_ the same
thing as a 2 stage supercharger. 2 speeds means that there is a gear change
mechanism with makes the supercharger spin at different speeds relative to
the engine rpm. 2 stage means that there are 2 compressors (stages) in
series - the output of the first is the input of the second. A supercharger
can be any combination of stages and speeds, and not limited to just 2: 3
stages/speeds were built.

Vivian



--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-26 Thread Tim Moore
Durk Talsma wrote:
 On Saturday 24 January 2009 00:10:16 Frederic Bouvier wrote:
 Would you mind adding this commit to the VC7.1 directory :
 Fri Jan 16 07:31:01 2009 UTC : Update MSVC 7.1 project

 Otherwise I managed to get it with git and build it. I am just waiting
 instructions ;-)

 
 Just to keep everybody in the loop, I have just build the source packages for 
 what is likely going to be FlightGear 1.9.1 and put them on my website. I 
 have 
 informed have informed the people involved in building the windows and mac 
 versions, as well as those in charge of pushing the source on the mirrors 
 about the exact location, so if no unexpected problems arise, a 1.9.1. bugfix 
 release should be available soon. 
I've just committed two more of Csaba's division by zero and initialization 
patches to cvs and maint. They were submitted a while ago and should go into 
1.9.1. I promise I'll stop now :) and can tag the current maint head as 1.9.1 
in 
git if you'd like.

 
 Notice that this bugfix release is based on a subset of commits (bugfixes 
 only) that have gone into our main CVS repository, and which were kept in a 
 separate git repository set up by Tim Moore. 
 
To recap, since the 1.9 release these commits are in maint:
simgear:
git log --date=short --pretty=format:%ad %ae %s SIMGEAR_1_9_0..maint
2009-01-19 timo...@redhat.com Protect against division by zero in QuadTreeBuilde
r
2009-01-14 timo...@redhat.com Remove OptionsPusher and manipulation of osgDB dat
aFilePathList.
2009-01-14 timo...@redhat.com SGPropertyNode must increment / decrement the refe
rence counter in an aliased
2009-01-13 fredb Csaba/Jester : fix the material animation and display night tex
tures
2009-01-10 fredb fix end of file
2009-01-10 fredb ignore generated files
2008-12-26 jmt Fix test-program linkage now sgmath depends on sgstructure.
2008-12-26 jmt Fix a potential crash when OSG is misconfigured, and an appropria
te image
2008-12-22 mfranz compilation fix: cstring for strcmp()
2008-12-21 mfranz - shininess is in the rage 0..128

flightgear:
git-log --date=short --pretty=format:%ad %ae %s FLIGHTGEAR_1_9_0..maint

2009-01-26 timo...@redhat.com _kollsman member not initialized
2009-01-26 timo...@redhat.com division-by-zero fix from Csaba Halasz
2009-01-25 fredb Packaging for the 1.9.1 release
2009-01-19 timo...@redhat.com Fix regression in Vivian's last patch.
2009-01-18 timoore Division by zero fixes from Vivian Meazza.
2009-01-17 fredb Csaba/Jester :  initialize all per-engine and per-tank attribut
es ( follow-up )
2009-01-17 fredb Csaba/Jester :  initialize all per-engine and per-tank attribut
es
2009-01-16 fredb Update MSVC 7.1 project
2009-01-15 timo...@redhat.com Pad T_PositionMsg to a multiple of 8 bytes, and ch
eck for messages that aren't.
2009-01-15 timo...@redhat.com FGMultiplayMgr: use binary search to find a proper
ty by id
2009-01-14 jmt Apply Ron Jensen's fix for Csaba's atan2() fix. Also remove some
dead code,
2009-01-14 timo...@redhat.com FGClouds: initialize clouds_3d_enabled in construc
tor.
2009-01-14 timo...@redhat.com HUD::Ladder::draw was capturing the value of a fre
ed temporary
2009-01-14 timo...@redhat.com FGEnvironment: fix broken copy constructor.
2009-01-10 timo...@redhat.com Change the near plane value back to .1
2009-01-08 timoore Divide-by-zero fixes from Csaba Halász
2009-01-06 jmt Prevent exceptions in getRunwayByIdent when a malformed rwyuse.xm
l means
2009-01-03 timoore Protect against divide-by-zero in setCameraParameters
2009-01-02 jmt NaN fix by Csaba/Jester - prefer atan2(x,y) to atan(a/y).
2009-01-01 fredb Temporary hack to avoid NaN problems when _mp is negative (?).
Discovered by Csaba
2008-12-30 fredb Csaba/Alexis : fix a NAN problem when wind is unspecified in a
metar
2008-12-30 fredb Win32 fixes
2008-12-30 durk Prevent CVS from complaining about unknown files in ATCDCL.
2009-01-04 timo...@redhat.com Merge branch 'tbm/graphics-bug' into maint2
2008-12-27 fredb Win32 fixes
2008-12-27 fredb Remove warnings
2009-01-01 timoore Set far camera reference frame to ABSOLUTE_RF
2008-12-30 timoore Set BACKGROUND_BIT as camera node mask.
2008-12-30 timoore Change the order of the main cameras from NESTED_RENDER to PO
ST_RENDER
2008-12-30 timoore Don't clone far camera; create a new one and initialize it fr
om the near camera
2008-12-27 timoore Expose the CameraGroup near, far, and near/far boundry as pro
perties
2008-12-21 mfranz Stuart BUCHANAN: fix METAR cloud interpolation
2008-12-21 fredb Don't try to fetch tiles when lat or lon are invalid
2008-12-20 mfranz revert to using a cached list of aircraft -- scanning the Airc
raft/

For reference, these commits are *not* in the maint branch:
simgear:
git-log --date=short --pretty=format:%ad %ae %s --no-merges maint..next
2009-01-23 timo...@redhat.com QuadTreeBuilder: create leaves on demand
2009-01-21 timo...@redhat.com Rewrite ShaderGeometry to use display lists and OS
G primitives.
2009-01-23 timo...@redhat.com Optimize empty groups from .ac 

Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-26 Thread Csaba Halász
On Tue, Jan 27, 2009 at 3:44 AM, Ron Jensen w...@jentronics.com wrote:

 A simple onespeed supercharger example is shown below:
  numboostspeeds 1   /numboostspeeds
  ratedboost18.15/ratedboost1 !-- 46.5 inHg --
  ratedpower1 1900   /ratedpower1 !-- Horsepower --
  ratedrpm1   2600   /ratedrpm1
  ratedaltitude1 0 /ratedaltitude1

From an xml standpoint, all those 1s look horrible (I mean
ratedboost1, ratedpower1, etc).
Is it too late to do away with them?
I would suggest something like:

supercharger
stage
boost8.15/boost
power1900/power
rpm2600/rpm
altitude0/altitude
/stage
stage
!-- stage #2 here --
/stage
/supercharger

I am saying this without any knowledge of the existing conventions and
compatibility issues, so feel free to ignore it :)

-- 
Csaba/Jester

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-26 Thread Ron Jensen
On Tue, 2009-01-27 at 04:07 +0100, Csaba Halász wrote:
 On Tue, Jan 27, 2009 at 3:44 AM, Ron Jensen w...@jentronics.com wrote:
 
  A simple onespeed supercharger example is shown below:
   numboostspeeds 1   /numboostspeeds
   ratedboost18.15/ratedboost1 !-- 46.5 inHg --
   ratedpower1 1900   /ratedpower1 !-- Horsepower --
   ratedrpm1   2600   /ratedrpm1
   ratedaltitude1 0 /ratedaltitude1
 
 From an xml standpoint, all those 1s look horrible (I mean
 ratedboost1, ratedpower1, etc).
 Is it too late to do away with them?
 I would suggest something like:
 
 supercharger
 stage
 boost8.15/boost
 power1900/power
 rpm2600/rpm
 altitude0/altitude
 /stage
 stage
 !-- stage #2 here --
 /stage
 /supercharger
 
 I am saying this without any knowledge of the existing conventions and
 compatibility issues, so feel free to ignore it :)

It probably is too late to do away with them, this is a legacy
definition.  Its also rather clumsy to use, which is why I posted a
functional sample.  But if Jon B is good with changing it, I'd be happy
to. 

Ron



--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-26 Thread Martin Spott
Hi Erik,

Erik Hofman wrote:

 Alright, I've updated JSBSim now, including a number of engine files. 
 The following files might need some attention though, since they are not 
 in JSBSim CVS:

Mmmmh, did you make a plan to take care for those models whose authors
don't regularly read this list ?

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-25 Thread Durk Talsma
On Saturday 24 January 2009 00:10:16 Frederic Bouvier wrote:

 Would you mind adding this commit to the VC7.1 directory :
 Fri Jan 16 07:31:01 2009 UTC : Update MSVC 7.1 project

 Otherwise I managed to get it with git and build it. I am just waiting
 instructions ;-)


Just to keep everybody in the loop, I have just build the source packages for 
what is likely going to be FlightGear 1.9.1 and put them on my website. I have 
informed have informed the people involved in building the windows and mac 
versions, as well as those in charge of pushing the source on the mirrors 
about the exact location, so if no unexpected problems arise, a 1.9.1. bugfix 
release should be available soon. 

Notice that this bugfix release is based on a subset of commits (bugfixes 
only) that have gone into our main CVS repository, and which were kept in a 
separate git repository set up by Tim Moore. 

Given that we are taking this route now, FlightGear CVS is, I guess, cleared 
again for major and somewhat more risky commits (JSBSim sync, etc etc). 

Cheers,
Durk



--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-25 Thread Jon S. Berndt
 Given that we are taking this route now, FlightGear CVS is, I guess,
cleared
 again for major and somewhat more risky commits (JSBSim sync, etc etc).
 
 Cheers,
 Durk

I would hope that synching JSBSim would be seamless by now. Of course, it
doesn't usually work like that. :-)

Jon



--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-25 Thread Melchior FRANZ
* Durk Talsma -- Sunday 25 January 2009:
 Notice that this bugfix release is based on a subset of commits
 (bugfixes only) 

Note that there's still the very annoying Warning:: Picked up
error in TriangleIntersect bug. Unfortunately, I can't offer
a fix.  :-/

m.

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-25 Thread Durk Talsma
On Sunday 25 January 2009 21:49:21 Jon S. Berndt wrote:

 I would hope that synching JSBSim would be seamless by now. Of course, it
 doesn't usually work like that. :-)


The part we considered risky was that possibly quite a few aircraft needed 
an update to their configuration files, in order to make use and/or function 
correctly with the latest JSBSim features. This would probably require more 
time than we'd like. At least that is my understanding. 

I don't think that anybody would consider a new JSBSim version risky in terms 
of crashing FlightGear or inducing compiler errors. :-)

Cheers,
Durk

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-25 Thread Frederic Bouvier
Hi Durk,

- Durk Talsma a écrit :
 Just to keep everybody in the loop, I have just build the source
 packages for what is likely going to be FlightGear 1.9.1 and put 
 them on my website. I have informed have informed the people 
 involved in building the windows and mac versions, as well as 
 those in charge of pushing the source on the mirrors about the 
 exact location, so if no unexpected problems arise, a 1.9.1. 
 bugfix release should be available soon. 

FWIW, I didn't receive a message from you today.

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/  Photo gallery - album photo
http://fgsd.sourceforge.net/   FlightGear Scenery Designer


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-25 Thread gerard robin
On dimanche 25 janvier 2009, Durk Talsma wrote:
 On Sunday 25 January 2009 21:49:21 Jon S. Berndt wrote:
  I would hope that synching JSBSim would be seamless by now. Of course, it
  doesn't usually work like that. :-)

 The part we considered risky was that possibly quite a few aircraft
 needed an update to their configuration files, in order to make use and/or
 function correctly with the latest JSBSim features. This would probably
 require more time than we'd like. At least that is my understanding.

 I don't think that anybody would consider a new JSBSim version risky in
 terms of crashing FlightGear or inducing compiler errors. :-)

 Cheers,
 Durk



In case of the quality  is our target.

http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-January/021991.html


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-24 Thread Tim Moore
Durk Talsma wrote:
 Hi Tim,
 
 On Friday 23 January 2009 23:40:47 Timothy Moore wrote:
 Durk Talsma wrote:
 
 How is this going? I've checked in a couple of fixes to the flightgear and
 simgear maint branches since 18 January.

 Tim

 
 I think we're pretty much ready. I built a binary from the git repositories, 
 and they work well with the original 1.9.0 base package. I'm still fooling 
 around with git a little bit, and it looks like I'm having some trouble 
 fetching the latest updates. From within the flightgear/simgear directories, 
 I 
 ran 
 
 git fetch
 
 which did seem to do some updating, but then running git log gives me
 
 commit 5567eb1fff2e5335d77f495779da55f8bb9e09f9
 Author: Tim Moore timo...@redhat.com
 Date:   Thu Jan 15 16:03:34 2009 +0100
 
 as the latest commit for flightgear
 
 and
 
 commit b5840650706bd21a44c0bcdad4621adafa8b2bc6
 Author: Tim Moore timo...@redhat.com
 Date:   Wed Jan 14 22:13:12 2009 +0100
 
 as the latest commit for simgear.
 
As John says, it's very important that you have the maint branch checked out. 
There's a master branch in the repos in order to keep the git clone command 
happy, but all the action is on the maint and next branches, and maint is 
what I'm proposing for 1.9.1.

Also, git fetch by itself only updates your copies of remote branches, not 
your local copies. You need to follow git fetch by git merge, or git 
rebase 
origin; the latter is recommended if you're doing work that you intend to 
check 
back into CVS. Also, git pull may be a simpler alternative for you, which 
does 
git fetch + git merge.
 Also, to test whether this was just me, I did a new clone of the entire 
 directory, which also gave me these commits as the latest ones. 
 
Again, make sure you git checkout maint.
Tim

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-24 Thread Tim Moore
Frederic Bouvier wrote:
 Hi Tim,
 

 Would you mind adding this commit to the VC7.1 directory :
 Fri Jan 16 07:31:01 2009 UTC : Update MSVC 7.1 project
 
 Otherwise I managed to get it with git and build it. I am just waiting 
 instructions ;-)
 
 -Fred
 

It's already there. Remember, master, which is checked out by default by git 
clone and shown in the weblog, is not the maint branch from which we want to 
do the 1.9.1 release. This may seem arbitrary, but I'm saving master for 
something else.

Tim

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-24 Thread Frederic Bouvier
Tim Moore a écrit :
 Frederic Bouvier wrote:
   
 Hi Tim,

 

   
 Would you mind adding this commit to the VC7.1 directory :
 Fri Jan 16 07:31:01 2009 UTC : Update MSVC 7.1 project

 Otherwise I managed to get it with git and build it. I am just waiting 
 instructions ;-)

 -Fred

 

 It's already there. Remember, master, which is checked out by default by 
 git 
 clone and shown in the weblog, is not the maint branch from which we want 
 to 
 do the 1.9.1 release. This may seem arbitrary, but I'm saving master for 
 something else.

   

Yes, you're right. I was looking at the wrong log.

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/   Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-23 Thread Tim Moore
Durk Talsma wrote:
 Hi Tim,
 
 On Sunday 11 January 2009 21:07:25 Tim Moore wrote:
 I propose that the 1.9.1 release be made from these maint branches. This
 would let progress continue in CVS while hopefully achieving some stability
 in a maintenance release. If current committers would like write access to
 these repos, let me know privately.

 
 Didn't have a chance to respond to your proposal yet, however, this sounds 
 good to me. I just got a clone of the maint branch, and will try to see if it 
 will build into a nice 1.9.1 binary, and hope that it will still work with 
 the 
 1.9.0 base package.
 
How is this going? I've checked in a couple of fixes to the flightgear and
simgear maint branches since 18 January.

Tim


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-23 Thread Frederic Bouvier
Hi Tim,

- Tim Moore a écrit :

 Durk Talsma wrote:
  Hi Tim,
  
  On Sunday 11 January 2009 21:07:25 Tim Moore wrote:
  I propose that the 1.9.1 release be made from these maint
 branches. This
  would let progress continue in CVS while hopefully achieving some
 stability
  in a maintenance release. If current committers would like write
 access to
  these repos, let me know privately.
 
  
  Didn't have a chance to respond to your proposal yet, however, this
 sounds 
  good to me. I just got a clone of the maint branch, and will try to
 see if it 
  will build into a nice 1.9.1 binary, and hope that it will still
 work with the 
  1.9.0 base package.
  
 How is this going? I've checked in a couple of fixes to the flightgear
 and
 simgear maint branches since 18 January.

Would you mind adding this commit to the VC7.1 directory :
Fri Jan 16 07:31:01 2009 UTC : Update MSVC 7.1 project

Otherwise I managed to get it with git and build it. I am just waiting 
instructions ;-)

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/  Photo gallery - album photo
http://fgsd.sourceforge.net/   FlightGear Scenery Designer


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-23 Thread Timothy Moore
Durk Talsma wrote:
 Hi Tim,
 
 On Sunday 11 January 2009 21:07:25 Tim Moore wrote:
 I propose that the 1.9.1 release be made from these maint branches. This
 would let progress continue in CVS while hopefully achieving some stability
 in a maintenance release. If current committers would like write access to
 these repos, let me know privately.

 
 Didn't have a chance to respond to your proposal yet, however, this sounds 
 good to me. I just got a clone of the maint branch, and will try to see if it 
 will build into a nice 1.9.1 binary, and hope that it will still work with 
 the 
 1.9.0 base package.
 
How is this going? I've checked in a couple of fixes to the flightgear and 
simgear maint branches since 18 January.

Tim

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-23 Thread Durk Talsma
Hi Tim,

On Friday 23 January 2009 23:40:47 Timothy Moore wrote:
 Durk Talsma wrote:

 How is this going? I've checked in a couple of fixes to the flightgear and
 simgear maint branches since 18 January.

 Tim


I think we're pretty much ready. I built a binary from the git repositories, 
and they work well with the original 1.9.0 base package. I'm still fooling 
around with git a little bit, and it looks like I'm having some trouble 
fetching the latest updates. From within the flightgear/simgear directories, I 
ran 

git fetch

which did seem to do some updating, but then running git log gives me

commit 5567eb1fff2e5335d77f495779da55f8bb9e09f9
Author: Tim Moore timo...@redhat.com
Date:   Thu Jan 15 16:03:34 2009 +0100

as the latest commit for flightgear

and

commit b5840650706bd21a44c0bcdad4621adafa8b2bc6
Author: Tim Moore timo...@redhat.com
Date:   Wed Jan 14 22:13:12 2009 +0100

as the latest commit for simgear.

Also, to test whether this was just me, I did a new clone of the entire 
directory, which also gave me these commits as the latest ones. 

Cheers,
Durk

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-23 Thread Durk Talsma
On Saturday 24 January 2009 07:03:33 Durk Talsma wrote:

 commit b5840650706bd21a44c0bcdad4621adafa8b2bc6
 Author: Tim Moore ...@xx.
 Date:   Wed Jan 14 22:13:12 2009 +0100



Oh, I;d been planning to obfuscate you email addresses. Too early / not enough 
coffee yet... Sorry about that.

D.

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-23 Thread John Denker
On 01/23/2009 11:03 PM, Durk Talsma wrote:

 Date:   Wed Jan 14 22:13:12 2009 +0100
 
 as the latest commit for simgear.

In which branch?  I see that as the latest commit on the master branch,
but there is newer stuff on the maint branch.

 Also, to test whether this was just me, I did a new clone of the entire 
 directory, which also gave me these commits as the latest ones.

You can save a lot of time and effort by looking at what gitweb has to say:
  http://repo.or.cz/w/simgear.git
  http://repo.or.cz/w/simgear.git?a=shortlog;h=refs/heads/maint
  http://repo.or.cz/w/simgear.git?a=shortlog;h=refs/heads/master

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-17 Thread Durk Talsma
Hi Tim,

On Sunday 11 January 2009 21:07:25 Tim Moore wrote:

 I propose that the 1.9.1 release be made from these maint branches. This
 would let progress continue in CVS while hopefully achieving some stability
 in a maintenance release. If current committers would like write access to
 these repos, let me know privately.


Didn't have a chance to respond to your proposal yet, however, this sounds 
good to me. I just got a clone of the maint branch, and will try to see if it 
will build into a nice 1.9.1 binary, and hope that it will still work with the 
1.9.0 base package.

Cheers,
Durk

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-12 Thread Alexis Bory - xiii
Vivian Meazza wrote:

  I'm seeing segfaults from time to time with Windows and CVS/Head
  trying to start when mp is running. Csaba Halász reports the same.
  It's most frustrating to try to track this one down, because it is
  not reliably repeatable. Assuming that we are not the only ones
  seeing this, it would seem like a bit of a show stopper to me.

I'm seeing those segfaults from time to time. Sometime  with MP
enabled, some time with --enable-real-weather-fetch.  Some other time
this segfault happens without any network based feature enabled,
then re-enabling the network features makes the segfault disappear.

I have 3 GB ram, no swap, no other apps running excepted Gnome
Desktop. Rebooting Linux always makes the segfault disapear for a
while. :-(

Also, using gdb prevents this segfault to appear. It looks like having
a timming issue in the different processes.

I really don't know from where to begin to help trace this one. Any
guidance to help this bug hunt would be appreciated as this one is
very annoying.

Alexis




--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-12 Thread Yon Uriarte
Hi Fred,
 saw your message asking for some testing. I decided to post a new thread
asking
for more user testing:
http://flightgear.org/forums/viewtopic.php?f=2t=2812


grep -r getenv OpenSceneGraph, possibly relevant env vars, some of them are
changed in my patches:

  F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(356):if( (ptr =
getenv(OSG_SERIALIZE_DRAW_DISPATCH)) != 0)
  F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(369):if( (ptr =
getenv(OSG_NUM_DATABASE_THREADS)) != 0)
1 by default, 2 may help a little bit on multi-cores. set to #cores
  F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(374):if( (ptr =
getenv(OSG_NUM_HTTP_DATABASE_THREADS)) != 0)
1 by default, fgfs uses none. set to 0
  F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(805):const char*
str = getenv(OSG_DATABASE_PAGER_PRIORITY);
neutral by default: set to LOW
  F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(842):str =
getenv(OSG_DATABASE_PAGER_GEOMETRY);
  F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(843):if (!str) str
= getenv(OSG_DATABASE_PAGER_DRAWABLE);
  F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(872):if( (ptr =
getenv(OSG_DELETE_IN_DATABASE_THREAD)) != 0)
  F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(929):if( (ptr =
getenv(OSG_DO_PRE_COMPILE)) != 0)
recently changed from default ON to OFF. set to ON
  F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(938):if( (ptr =
getenv(OSG_MINIMUM_COMPILE_TIME_PER_FRAME)) != 0)
  F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(943):if( (ptr =
getenv(OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME)) != 0)
  F:\c\OSG\OpenSceneGraph\src\osgUtil\Optimizer.cpp(61):const char* env
= getenv(OSG_OPTIMIZER);
is this applied to all objects? maybe i look into this.
  F:\c\OSG\OpenSceneGraph\src\osgUtil\RenderBin.cpp(108):const char*
str = getenv(OSG_DEFAULT_BIN_SORT_MODE);
may be relevant on some weird hw mixes.
  F:\c\OSG\OpenSceneGraph\src\osgViewer\ViewerBase.cpp(78):const char*
str = getenv(OSG_THREADING);
default SingleThreaded. set to CullThreadPerCameraDrawThreadPerContext

regards,
 yon

On Sun, Jan 11, 2009 at 11:55 PM, Frederic Bouvier fredfgf...@free.frwrote:


 - James Turner a écrit :

  On 11 Jan 2009, at 17:18, Frederic Bouvier wrote:
 
   My findings on that is that the pager thread needs to compile
  display
   list in the main loop, and this process is framerate dependent. At
 
   that
   time of the initialisation, there is only the splashscreen on
  screen,
   but its refresh rate slow down the loading process. For instance, I
   mesured it takes more than 1000 frames to display to correctly load
  a
   terrain tile. Maybe there are parameters to tweak, like the number
  of
   maximum display lists to compile each frames, and we could use more
   aggressive values until the scenery is displayed. Just a thought.
 
  Yon Uriarte has proposed a patch that limits the frame-rate to 60hz
  during the splash screen. Would that fix the issue, by freeing up
  cycles?
 
  The patch has been around since November and I ran it locally for many
 
  weeks without seeing any problems.

 As I understand it, if you limit the framerate, you limit the slots the
 pager has to compile objects, as compilation is done in the draw thread,
 between two frames. I tried to give more time and allow the compilation of
 more objects between two frames by calling
 setMinimumTimeAvailableForGLCompileAndDeletePerFrame and
 setMaximumNumOfObjectsToCompilePerFrame on the pager and on the renderer but
 for me it makes no difference (there is no problem for me, even in the Paris
 area ). That's why I built a Windows binary to allow people with the problem
 to test the possible solution.

 The binary is here :

 ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun+fgfs-osg-win32-20090111.zip

 -Fred



--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-12 Thread Stefan Seifert
On Monday, 12. January 2009, Alexis Bory - xiii wrote:

 Also, using gdb prevents this segfault to appear. It looks like having
 a timming issue in the different processes.

When it's not reproducible with gdb, you can enable core dumps with ulimit -c 
unlimited before running FG. If it crashes it should leave a core dump (can 
be serveral GB! So it may take a while...) which can be debugged with gdb.

Stefan

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-12 Thread Vivian Meazza
Alexis wrote

9.1
 
 Vivian Meazza wrote:
 
   I'm seeing segfaults from time to time with Windows and CVS/Head
   trying to start when mp is running. Csaba Halász reports the same.
   It's most frustrating to try to track this one down, because it is
   not reliably repeatable. Assuming that we are not the only ones
   seeing this, it would seem like a bit of a show stopper to me.
 
 I'm seeing those segfaults from time to time. Sometime  with MP
 enabled, some time with --enable-real-weather-fetch.  Some other time
 this segfault happens without any network based feature enabled,
 then re-enabling the network features makes the segfault disappear.
 
 I have 3 GB ram, no swap, no other apps running excepted Gnome
 Desktop. Rebooting Linux always makes the segfault disapear for a
 while. :-(
 
 Also, using gdb prevents this segfault to appear. It looks like having
 a timming issue in the different processes.
 
 I really don't know from where to begin to help trace this one. Any
 guidance to help this bug hunt would be appreciated as this one is
 very annoying.
 


Thanks for this info. It rather blows Csaba's and my theory out of the water
- we are looking for a bug in the input data when a mp client joins. We
thought at one time it was in mp-nimitz, but that's been discounted. Like
you, I find running in debug makes it disappear!

Csaba might have trapped the bug last night - we await more info.

Of course, it's not happening right now.

Vivian



--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-12 Thread Frederic Bouvier
Hi Yon,

I saw that but also saw that the osgViewer::Renderer has its own minimum time 
that is not settable by environment variable, and the resulting time is the 
minimum of the two values, one from the pager and the other from the Renderer ( 
both initially set to 0.001 ).

In my test build I set large values until the scenery is loaded, then restore 
the default values.

It also seems that large framerate ( more than 200 fps during splashscreen 
display, I even saw 600 at FSFO ) make the scenery load a bit longer. Curiouly, 
I see better loading time under Linux with an AMD Athlon XP 2400 and a NV 
FX5850, than under Windows with a Quad core i9450 and a GTX200. I am 
defragmenting my disk just in case.

-Fred


- Yon Uriarte yon.uria...@gmail.com a écrit :

 Hi Fred,
 
 
 saw your message asking for some testing. I decided to post a new
 thread asking
 for more user testing:
 http://flightgear.org/forums/viewtopic.php?f=2t=2812
 
 
 
 
 grep -r getenv OpenSceneGraph, possibly relevant env vars, some of
 them are changed in my patches:
 
 
 
 F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(356): if( (ptr =
 getenv(OSG_SERIALIZE_DRAW_DISPATCH)) != 0)
 
 F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(369): if( (ptr =
 getenv(OSG_NUM_DATABASE_THREADS)) != 0)
 1 by default, 2 may help a little bit on multi-cores. set to #cores
 F:\c\OSG\OpenSceneGraph\src\osg\DisplaySettings.cpp(374): if( (ptr =
 getenv(OSG_NUM_HTTP_DATABASE_THREADS)) != 0)
 1 by default, fgfs uses none. set to 0
 F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(805): const char*
 str = getenv(OSG_DATABASE_PAGER_PRIORITY);
 
 neutral by default: set to LOW
 F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(842): str =
 getenv(OSG_DATABASE_PAGER_GEOMETRY);
 F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(843): if (!str)
 str = getenv(OSG_DATABASE_PAGER_DRAWABLE);
 
 F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(872): if( (ptr =
 getenv(OSG_DELETE_IN_DATABASE_THREAD)) != 0)
 F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(929): if( (ptr =
 getenv(OSG_DO_PRE_COMPILE)) != 0)
 
 recently changed from default ON to OFF. set to ON
 F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(938): if( (ptr =
 getenv(OSG_MINIMUM_COMPILE_TIME_PER_FRAME)) != 0)
 F:\c\OSG\OpenSceneGraph\src\osgDB\DatabasePager.cpp(943): if( (ptr =
 getenv(OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME)) != 0)
 F:\c\OSG\OpenSceneGraph\src\osgUtil\Optimizer.cpp(61): const char* env
 = getenv(OSG_OPTIMIZER);
 is this applied to all objects? maybe i look into this.
 F:\c\OSG\OpenSceneGraph\src\osgUtil\RenderBin.cpp(108): const char*
 str = getenv(OSG_DEFAULT_BIN_SORT_MODE);
 may be relevant on some weird hw mixes.
 F:\c\OSG\OpenSceneGraph\src\osgViewer\ViewerBase.cpp(78): const char*
 str = getenv(OSG_THREADING);
 
 default SingleThreaded. set to
 CullThreadPerCameraDrawThreadPerContext
 
 
 regards,
 yon
 
 
 On Sun, Jan 11, 2009 at 11:55 PM, Frederic Bouvier 
 fredfgf...@free.fr  wrote:
 
 
 
 - James Turner a écrit :
 
 
  On 11 Jan 2009, at 17:18, Frederic Bouvier wrote:
 
   My findings on that is that the pager thread needs to compile
  display
   list in the main loop, and this process is framerate dependent. At
 
   that
   time of the initialisation, there is only the splashscreen on
  screen,
   but its refresh rate slow down the loading process. For instance,
 I
   mesured it takes more than 1000 frames to display to correctly
 load
  a
   terrain tile. Maybe there are parameters to tweak, like the number
  of
   maximum display lists to compile each frames, and we could use
 more
   aggressive values until the scenery is displayed. Just a thought.
 
  Yon Uriarte has proposed a patch that limits the frame-rate to 60hz
  during the splash screen. Would that fix the issue, by freeing up
  cycles?
 
  The patch has been around since November and I ran it locally for
 many
 
  weeks without seeing any problems.
 
 As I understand it, if you limit the framerate, you limit the slots
 the pager has to compile objects, as compilation is done in the draw
 thread, between two frames. I tried to give more time and allow the
 compilation of more objects between two frames by calling
 setMinimumTimeAvailableForGLCompileAndDeletePerFrame and
 setMaximumNumOfObjectsToCompilePerFrame on the pager and on the
 renderer but for me it makes no difference (there is no problem for
 me, even in the Paris area ). That's why I built a Windows binary to
 allow people with the problem to test the possible solution.
 
 The binary is here :
 ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun+fgfs-osg-win32-20090111.zip
 
 -Fred
 
 
 
 --
 Check out the new SourceForge.net Marketplace.
 It is the best place to buy or sell services for
 just about anything Open Source.
 http://p.sf.net/sfu/Xq1LFB
 ___
 Flightgear-devel mailing list
 

Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-12 Thread James Turner

On 12 Jan 2009, at 11:19, Frederic Bouvier wrote:

 It also seems that large framerate ( more than 200 fps during  
 splashscreen display, I even saw 600 at FSFO ) make the scenery load  
 a bit longer. Curiouly, I see better loading time under Linux with  
 an AMD Athlon XP 2400 and a NV FX5850, than under Windows with a  
 Quad core i9450 and a GTX200. I am defragmenting my disk just in case.

I'm pretty sure that Yon's limiter patch is a good idea regardless,  
since the slow dlist compile behaviour should not be 'fixed' by  
requiring some ludicrous frame-rate - that could potentially work for  
FG by sheer chance, but clearly would be impossible for many other  
applications that might do similar periods of intense data loading and  
associated compiles.

Has anyone raised the issue on the OSG list?

James


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-12 Thread James Turner

On 11 Jan 2009, at 20:07, Tim Moore wrote:

 I propose that the 1.9.1 release be made from these maint  
 branches. This would
 let progress continue in CVS while hopefully achieving some  
 stability in a
 maintenance release. If current committers would like write access  
 to these
 repos, let me know privately.

This sounds like an excellent idea to me, since I could then get  
assorted patches (especially the various threading / atomic changes to  
Simgear) onto CVS trunk for wider testing.

James


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-12 Thread Yon Uriarte
Hi,

On Mon, Jan 12, 2009 at 12:19 PM, Frederic Bouvier fredfgf...@free.frwrote:

 Hi Yon,

 I saw that but also saw that the osgViewer::Renderer has its own minimum
 time that is not settable by environment variable, and the resulting time is
 the minimum of the two values, one from the pager and the other from the
 Renderer ( both initially set to 0.001 ).


oh, nice.



 In my test build I set large values until the scenery is loaded, then
 restore the default values.


I had some numbers that i posted on this lists some weeks ago. At first i
was limiting to 15fps
and was loading slower than without limiting. Limiting to 50fps seemed to
help.



 It also seems that large framerate ( more than 200 fps during splashscreen
 display, I even saw 600 at FSFO ) make the scenery load a bit longer.
 Curiouly, I see better loading time under Linux with an AMD Athlon XP 2400
 and a NV FX5850, than under Windows with a Quad core i9450 and a GTX200. I
 am defragmenting my disk just in case.


If those machines were dual boot, it'd be interesting to compare numbers
with swaped OSs. Can you
try with more than 1 osgdb thread?
Also, osgDB pre-compile was disabled by default some weeks ago in osg. It
seems you
are tracing that code now, is it still doing some compile in the db threads?



 -Fred

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-11 Thread gerard robin
On dimanche 11 janvier 2009, Durk Talsma wrote:
 Hi,

 Just a quick question. As far as I'm concerned, we'll be doing a 1.9.1 bug
 fix release soon. I would just like to get an impression how our progress
 is on the various problems that have been reported. I know that the black
 box problem is fixed now, but how are we doing on the other issues. In
 particular, some people seem to have reported that FlightGear got stuck in
 an endless scenery loading loop. Do we already have a handle on that?

 I also know that various people,  have reported other bugs. I am under the
 impression that most of these are actually problems that need to be
 addressed as part of our normal development cycle and not immediate
 showstoppers.

 As for a time frame, I'm thinking about mid- to late January, and I would
 indeed recommend that major updates to important system are held off until
 we have released 1.9.1. I can't guarantee a firm timeline yet, because
 temperatures have dropped below freezing, which means I spend my weekends
 ice skating. Rest assured, it's never freezing for extended periods of
 time, so this won't hold up the release indefinitely.

 Cheers,
 Durk


Hello Durk,
Are you confusing speed and quality ?
What about waiting for a stable OSG version ?
Are you sure we won't get any surprise with it ?
OR do you intend to deliver an other version behind 1.9.1.1.9.2
On our side we don't have yet built the  FG 1.9.
We can only notice that there is still with CVS that ugly blue edge  with 3D 
clouds.
here 
http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg

And these strange messages on the console when loading some aircrafts

Error: Setting mode 'GL_COLOR_MATERIAL' via osg::StateSet::setMode(mode,value) 
ignored.
   The mode 'GL_COLOR_MATERIAL' is set by the osg::Material 
StateAttribute.
   Setting this as a mode fools osg's State tracking.
Error: Setting mode 'GL_COLOR_MATERIAL' via osg::StateSet::setMode(mode,value) 
ignored.
   The mode 'GL_COLOR_MATERIAL' is set by the osg::Material 
StateAttribute.
   Setting this as a mode fools osg's State tracking.
Error: Setting mode 'GL_COLOR_MATERIAL' via osg::StateSet::setMode(mode,value) 
ignored.
   The mode 'GL_COLOR_MATERIAL' is set by the osg::Material 
StateAttribute.
   Setting this as a mode fools osg's State tracking.


Cheers




-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-11 Thread Frederic Bouvier
Durk Talsma a écrit :
 Hi,

 Just a quick question. As far as I'm concerned, we'll be doing a 1.9.1 bug 
 fix 
 release soon. I would just like to get an impression how our progress is on 
 the various problems that have been reported. I know that the black box 
 problem is fixed now, but how are we doing on the other issues. In 
 particular, 
 some people seem to have reported that FlightGear got stuck in an endless 
 scenery loading loop. Do we already have a handle on that?
   

My findings on that is that the pager thread needs to compile display
list in the main loop, and this process is framerate dependent. At that
time of the initialisation, there is only the splashscreen on screen,
but its refresh rate slow down the loading process. For instance, I
mesured it takes more than 1000 frames to display to correctly load a
terrain tile. Maybe there are parameters to tweak, like the number of
maximum display lists to compile each frames, and we could use more
aggressive values until the scenery is displayed. Just a thought.


 I also know that various people,  have reported other bugs. I am under the 
 impression that most of these are actually problems that need to be addressed 
 as part of our normal development cycle and not immediate showstoppers. 
   

The return to 0.1 as the near plane would save us a lot of complain.

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/   Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-11 Thread Melchior FRANZ
* Durk Talsma -- Sunday 11 January 2009:
 As far as I'm concerned, we'll be doing a 1.9.1 bug fix release soon.

Agreed.



 I would indeed recommend that major updates to important system are
 held off until we have released 1.9.1.

While I consider resizable dialogs a major feature (at least when
considering the time spend for them ;-), they shouldn't be a problem.
They should work just fine with the 1.9.0 base package. Of course,
dialogs aren't resizable then, but shouldn't have any negative side
effect. IOW: Easter Egg until later.  :-)

m.

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-11 Thread Tim Moore
Melchior FRANZ wrote:
 * Durk Talsma -- Sunday 11 January 2009:
 As far as I'm concerned, we'll be doing a 1.9.1 bug fix release soon.
 
 Agreed.
 
 
 
 I would indeed recommend that major updates to important system are
 held off until we have released 1.9.1.
 
I've established git repositories on repo.or.cz for SimGear and FlightGear at 
git://repo.or.cz/simgear.git and git://repo.or.cz/flightgear.git. You can 
browse 
them at http://repo.or.cz/w/simgear.git and http://repo.or.cz/w/flightgear.git 
respectively. The maint branch in each of those repositories contains just 
those commits made since 1.9.0 that are bug fixes (in git parlance, they've 
been 
cherry picked).

By the way, the cvs branches there are a mirror of the official CVS repo, and 
should also be the same as Martin Spott's repo, except it isn't updated 
automatically. The next branches contain the same content -- that is,
git-diff cvs..next should report no differences -- but are arrived at a bit 
differently: maint is merged into next when new fixes appear in maint.

I propose that the 1.9.1 release be made from these maint branches. This 
would 
let progress continue in CVS while hopefully achieving some stability in a 
maintenance release. If current committers would like write access to these 
repos, let me know privately.

Tim

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-11 Thread James Turner

On 11 Jan 2009, at 17:18, Frederic Bouvier wrote:

 My findings on that is that the pager thread needs to compile display
 list in the main loop, and this process is framerate dependent. At  
 that
 time of the initialisation, there is only the splashscreen on screen,
 but its refresh rate slow down the loading process. For instance, I
 mesured it takes more than 1000 frames to display to correctly load a
 terrain tile. Maybe there are parameters to tweak, like the number of
 maximum display lists to compile each frames, and we could use more
 aggressive values until the scenery is displayed. Just a thought.

Yon Uriarte has proposed a patch that limits the frame-rate to 60hz  
during the splash screen. Would that fix the issue, by freeing up  
cycles?

The patch has been around since November and I ran it locally for many  
weeks without seeing any problems.

James

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear 1.9.1

2009-01-11 Thread Yon Uriarte
Hi,
 all that can be set with environment variables. Best way would be to post
on the
forum asking for some testing.

hth, regrads,
 yon


On Sun, Jan 11, 2009 at 11:55 PM, Frederic Bouvier fredfgf...@free.frwrote:


 - James Turner a écrit :

  On 11 Jan 2009, at 17:18, Frederic Bouvier wrote:
 
   My findings on that is that the pager thread needs to compile
  display
   list in the main loop, and this process is framerate dependent. At
 
   that
   time of the initialisation, there is only the splashscreen on
  screen,
   but its refresh rate slow down the loading process. For instance, I
   mesured it takes more than 1000 frames to display to correctly load
  a
   terrain tile. Maybe there are parameters to tweak, like the number
  of
   maximum display lists to compile each frames, and we could use more
   aggressive values until the scenery is displayed. Just a thought.
 
  Yon Uriarte has proposed a patch that limits the frame-rate to 60hz
  during the splash screen. Would that fix the issue, by freeing up
  cycles?
 
  The patch has been around since November and I ran it locally for many
 
  weeks without seeing any problems.

 As I understand it, if you limit the framerate, you limit the slots the
 pager has to compile objects, as compilation is done in the draw thread,
 between two frames. I tried to give more time and allow the compilation of
 more objects between two frames by calling
 setMinimumTimeAvailableForGLCompileAndDeletePerFrame and
 setMaximumNumOfObjectsToCompilePerFrame on the pager and on the renderer but
 for me it makes no difference (there is no problem for me, even in the Paris
 area ). That's why I built a Windows binary to allow people with the problem
 to test the possible solution.

 The binary is here :

 ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun+fgfs-osg-win32-20090111.zip

 -Fred


 --
 Frédéric Bouvier
 http://my.fotolia.com/frfoto/  Photo gallery - album photo
 http://fgsd.sourceforge.net/   FlightGear Scenery Designer



 --
 Check out the new SourceForge.net Marketplace.
 It is the best place to buy or sell services for
 just about anything Open Source.
 http://p.sf.net/sfu/Xq1LFB
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel