Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Torsten Dreyer
Am 06.11.2012 22:16, schrieb Durk Talsma:
 Yes, I also talked to Martin Crompton. James told me later on that you had 
 been in touch with him. My action was rather spontaneous, so I asked him 
 whether we could try to support Saitek products, without me knowing that you 
 were also working on it. I hope we can join forces. I got their radiostack to 
 try, and this looks like it's going to be a little more involved, since it 
 may need its own USB driver. I'll try to send Martin just a quick note later 
 tonight.

You might want to check out the event input system, I have implemented 
some time ago. It's much more flexible than our joystick input system as 
it handles more events (relative axies e.g.) and is able to send events 
_to_ the device, too (switching LED's e.g.). Tat implemented this for 
the OSX, so it should be working there, too. The Windows implementation 
is still missing, unfortunately.
Also, Melchior implemented raw HID communication using Nasal for the 
Thrustmaster Warthog, but limited to Linux use.

If the Saitek devices don't use HID at all, things will become _very_ 
tricky and probably impossible to get them running cross platform.


Torsten

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Durk Talsma
Hi Torsten,
 
 You might want to check out the event input system, I have implemented 
 some time ago. It's much more flexible than our joystick input system as 
 it handles more events (relative axies e.g.) and is able to send events 
 _to_ the device, too (switching LED's e.g.). Tat implemented this for 
 the OSX, so it should be working there, too. The Windows implementation 
 is still missing, unfortunately.

Thanks for these pointers. I can probably need all the help I can get. For 
windows, the Saitek products have their own USB driver, so that shouldn't be a 
problem. Only trick is how to read/write to/from them. 

 Also, Melchior implemented raw HID communication using Nasal for the 
 Thrustmaster Warthog, but limited to Linux use.

Sounds like this might be a good start to look at. 

 
 If the Saitek devices don't use HID at all, things will become _very_ 
 tricky and probably impossible to get them running cross platform.
 
 
I just plugged in the device, linked the USB device to my virtual Windows 8 
box, where it showed up as using two devices. One of them was HID, so I think 
we're good. 

Also, Martin Crompton, my contact at Saitek appears to be very forthcoming in 
providing me with documentation, etc. We haven't talked about licensing issues 
jet, but he was very helpful in providing either documentation, additional 
hardware to test, or even do some work on the more lower level stuff. I just 
have to make sure I don't get carried away too quickly. 

Cheers,
Durk
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread James Turner

On 8 Nov 2012, at 09:04, Durk Talsma wrote:

 I just plugged in the device, linked the USB device to my virtual Windows 8 
 box, where it showed up as using two devices. One of them was HID, so I think 
 we're good. 
 
 Also, Martin Crompton, my contact at Saitek appears to be very forthcoming in 
 providing me with documentation, etc. We haven't talked about licensing 
 issues jet, but he was very helpful in providing either documentation, 
 additional hardware to test, or even do some work on the more lower level 
 stuff. I just have to make sure I don't get carried away too quickly. 

Fantastic. It's worth pointing out, whatever work you do, probably also helps 
support of X-Plane on Linux and Mac, if that is not already supported. 

Regards,
James

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] little cosmetic patch on src/FDM/YASim/proptest.cpp

2012-11-08 Thread James Turner

On 7 Nov 2012, at 17:50, Alexis Bory wrote:

 The purpose of this little cosmetic patch is to ease the use of proptest's 
 output in a ploter.

Committed, thanks.

James


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Renk Thorsten
Thanks for the responses, I think I understand the issue much better.

 The eye catcher is not the gem, but things you see, and notice, from a 
 distance,
 like a huge flag with free writen on it.

I guess it'd just be a matter of setting things up. Sure, on a laptop things 
tend to get lost. But just a simple example - on googling 'FSX sunset' images I 
find that FSX doesn't seem to have anywhere Mie scattering on clouds. We do, 
and it looks pretty darn impressive when clouds illuminated from behind  light 
up in low light. So all it'd take is to get a weather situation in which this 
happens set up and project it on a sufficiently large screen, and voila - 
here's a potential eye catcher.

Of course, overall we're still going to lose that game in the long run though. 
Almost by definition, a commercial product is going to focus all resources on 
the things that people notice first. Say to get a good FDM takes five full 
working days, to get the last 10% takes another 100 days. But only a tiny 
fraction of users will notice the last 10%, and only after some trying out, but 
they make your product 20 times more expensive - and thus a commercial product 
will develop things on average only to a break-even point so that it makes most 
users happy at minimum effort. 

And that's where Flightgear is very different, because now and then people put 
an insane amount of work into something that will never be noticed by vast 
majority of users - because for someone a particular detail is important and so 
it gets lots of attention, way more than would ever be economically viable.

We just don't care too much about appearances because the problems are so 
simple :-) - I think for instance consistently removing unrated, non-functional 
or unfinished airplanes from the main download page would go quite a way in 
making Flightgear look more professional in the eye of the casual user who is 
just curious and wats to try -  if we ever wanted to do so - but we're not 
going to do it, because it's a boring administrative problem, and nobody likes 
those when he can tackle an interesting problem (me not being the exception 
here...).

And we're losing out on resources. I don't know how much manpower a commercial 
sim typically has, I think I remember MS Flight had a team of 20 or so. That 
looks about like the number of active major contributors here, except that if 
my coding time is representative, I get about 1/10 to 1/20 of the workload of a 
full-timer done, so we're losing by more than an order of magnitude. It doesn't 
always help us that with an open source product we have a potentially unlimited 
 number of contributors, since for some tasks you need a highly coordinated 
workforce.  

If I think what I would need in order to make the sky visuals better than any 
FSX screenshots I've seen, it's mainly down to things like raw data and image 
processing - e.g. I lack aerial images which tell me what I am aiming at. For 
instance, my worst problem is - how does a high altitude scene look like when 
the sun is at the horizon and I look *away* from the sun? You can simply forget 
googling images for that, because everyone points the camera the other way. 
I've twice sort of seen it by being on the right side of the plane during a 
transatlantic, but it's not the same as having an image which you can use to 
sample rgb values. I also know some of the cloud textures could benefit from a 
better extraction procedure and better raw images - if I had a graphic artist 
which can do these things, we'd be good, but if it's down to my 12 year old 
digicam pointing at the sky and my GIMP skills, there's a limit to the quality 
of the final product. Lots of things don't require coding but just patient 
testing of parameter values - I remember getting a different (rgb) triplet for 
the base sky color from someone, which made things look much better - but that 
simple color info is  worth for me several days of tests. If I had an artist 
adjusting parameters to get scenes right, we'd be in much better shape.

But even with a potentially infinite pool of contributors, we don't get people 
to do what we need when we need it - because volunteers work on what they want 
when they want. So, also in terms of resources, commercial products have an 
edge here. 

I think generically, we can only win in areas where people are really obsessed 
over details, and the fact that FGFS is superior in that particular detail will 
never be eye-catching. I also think if we really wanted, we could do a lot to 
make a more professional appearance to new users - well defined standards on 
the download page, a consistently designed GUI maintained by a co-ordinated 
task force rather than everyone adding as he thinks fit, standards on 
documentation updates, all the nasty things,...

Well, that's my 2 cents at least...

* Thorsten
--
Everyone hates slow websites. So do we.
Make 

Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Gijs de Rooy






Hi all,

Now that my last exams of 2012 are over, I finally have some time to write a 
lengthy email :-)

FSweekend
Too sad I could only join 
on Saturday (due to exams), but I'm glad I did come! Meeting James, 
Alexis and Christian in person was really nice, and so was the rest of the 
day. Next year I hope to be there three full days, but I'm afraid the 
examperiod will be around the same weeks...

Despite the somewhat 
less organised event, I think we did pretty well overal. We had some 
interesting talks, and we definitely attracted some new users.

Some of my observations at FSweekend:
We
 missed the big banners. Without clear name badge for the project, we 
cannot expect people to know/find us. A few people did read our T-shirts and 
found us that way, but I'm sure some people had the intention to visit 
the FlightGear booth, but were unable to find it (or forgot about it and
 because there was no big banner, so they simply didn't get a mental reminder 
while walking by).Looking at pictures on other simulator websites, it looks as 
if lots of people did not visit the Uiverzaal (the room where FG was located). 
Probably because it is somewhat tucked away in a corner. Maybe this is 
something that needs to be forwarded to Frans?Nevertheless I think I spoke to 
more people that knew about FlightGear than ever before.
 That seems to get better every single year.. Maybe it's because the 
same people visit Lelystad every year; maybe it's because people start 
looking for alternatives to MSFS...Beamers are great, as they can provide a 
view to many more spectators than you can gather around an ordinary screen.
 We did have the largest screen so far, but it was floating somewhere in
 the room, so there was no clear connection to our booth.
Being able to give 
people a  DVD/CD/USB (the installer is 640 MB for Windows, that should fit on a 
CD...) with the latest version of FlightGear would probably 
encourage them to install it and actually try the software. We do tell 
people to download it from our website, but most of them will forget 
about it. If you bring a CD home with you, you will probably at least look at 
it 
before you throw it away. Of course this costs money, so we may need to 
look at some fundraising (sponsoring?).That's enough for now :-)

SaitekDurk, in case you didn't find Stuart's article yet, here is the link: 
http://wiki.flightgear.org/Hardware_Review:_Saitek_Pro_Flight_Cessna_controls

Collimated display
Hm, thinking about it, I could try to get 
something going at my university. We recently bought a 727 home 
cockpit, which is used as promotion material on open days. The builder 
of that cockpit still owns it partly, but the university uses it. It could 
make sense to make the display for the university (using their 
machinery), donate it to them and in return have it shipped to Lelystad 
once a year...

Comparing with MSFS and X-Plane
Feel free to use the wiki to make a list of unique features and/or 
comparison to other simulator.
Someone started this a while ago, but it could use some loving care: 
http://wiki.flightgear.org/Unique_Features
I once started on a key binding comparison, (hopefully) making it easier for 
people to switch: 
http://wiki.flightgear.org/Key_commands_compared_to_other_simulators

In this series, we can also add a dictionary (eg. what we call liveries are 
called paintjobs in certain communities) etc..

Listing the differences would also make a good feature request list, so we 
can work on great features that other sims have, but we lack. I think people 
would like to have at least the same, and possible better/more features before 
they'd consider switching.

Aircraft download page
I have a fully functional revamped download page set up at 
http://flightgear.byethost31.com/aircraft/aircraftpage.html, but there were 
some issues getting it operational on flightgear.org intialy, so we decided to 
push the old scheme for this release. We can always add this interactive page 
though, and now that my last exams of 2012 are over, I'll have a closer look at 
it again. Feedback is welcome!

Cheers,
Gijs


  --
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Windows SG DLL build - NO GO!

2012-11-08 Thread Geoff McLane
Hi all,

Wow, I recently had the occasion to 
experiment with building the SG shared 
library, DLL, in Windows... a NO GO ;=((

Well, with a fresh SG clone, yesterday I
think, first I needed to patch the 
simgear/CMakeLists.txt to get cmake to 
even start building - patch given below...

The two changes are to add the winsock2 library, 
and since in windows there are two components 
built, you MUST provide a 'target' for each.

In general the .lib goes in the 'lib' directory as 
usual, but the DLL is a 'runtime' component, thus 
must go in the 'bin' directory with the executable.

But that was just the tip of the iceberg ;=))

While that succeeded in getting the Windows DLL 
SimGearCore.dll built, NO archive library was 
generated. And without such a 'library' you can 
not 'link' to the DLL. It 'exports' nothing, and 
is quite useless...

Now, as the windows people know, there are just 
two ways to 'export' functions, variables, classes 
from a windows DLL build -

1. Use __declspec() 
2. Use a DEF file

1. Use __declspec() 


This declaration has to be added to each and every 
function, variables, class you want to export.

This is usually done with a macro of the form -

#ifdef WIN32
 #ifdef SG_LIBRARY /* building the library */
#define SG_EXPORT __declspec(dllexport)
 #else /* link with application */
#define SG_EXPORT __declspec(dllimport)
 #endif
#else /* not in windows */
#define SG_EXPORT extern
#endif

This could probably go in say compiler.h...

Then every function exported needs this 
declaration, like -

SG_EXPORT int foo();
SG_EXPORT class X {} varX;
SG_EXPORT ULONG ulDataInDll;

Like in say xml/easyxml.hxx, in part...

class SG_EXPORT XMLAttributes
{
public:
 // ...
};
...
SG_EXPORT void readXML (istream input, ...);
SG_EXPORT void readXML (const string path,...);

And so on, and On, and ON ;=)) For each SG 
header that exports something as part of the 
SG API...

2. Use a DEF file
=

In this Module-Definition file EVERY function, 
variable to be exported has to be declared!

EXPORTS
   foo @1
   ulDataInDll DATA
   readXML
# and onward for all SG API items

Not sure how classes are declared in here...
and the assignment of an ordinal value, like @1 
to @N, is optional...

And then that simgear.def file added to the 
cmake list file for the windows build. cmake 
handles it without problems...

And that DEF file has to be maintained. 
Function names removed or added as the API 
changes...

And then another matter noted...

3. SG SO Version


At present it seems only one DLL is produced,
 SimGearCore.dll
without a 'version' indication... like say 
 SimGearCore29.dll
 SimGearCore29.lib

In a fast changing API, like SG is, then it 
is essential that the DLL be version-ed... like 
I assume it is in unix...

And like say the OSG Windows DLLs are, like ...
osg92-osg.dll, but just noted they do not 
add this to the libraries - it is always just 
osg.lib.

But that is ok since which ever osg.lib you 
link with, will automatically 'force' a version 
DLL...

So likewise maybe one name, SimGearCore.lib 
would be ok...

But this version is important, since 
if you built say the 2.8 DLL they can NOT 
be used for 2.9 due to several API changes...

And in this case that is ignoring that 
2.8 would be 20+ DLLs, versus 2.9 of two...

But here I am talking about API changes like -
 sgGetMagVar(lon, lat, elev, ...
to
 sgGetMagVar(SGGeod, ...
which may have happened even before 2.8... 
did not check the date of this change...

And this SO version would needed to be 
kicked for EACH API change... more maintenance,
which I hope IS being done in unix...

Conclusion
==

As you can see, this would be *L*O*T*S* of 
work and FOREVER continued maintenance... 
although using 1, once developers got into 
the habit of using SG_EXPORT, then this could 
be minimized...

But maybe we would be better off removing the 
SIMGEAR_SHARED option if WIN32 ;=))

That is do NOT offer an option that can NOT 
be used!

And of course, I really wonder WHY we added 
a 'shared' version of SG at all... but that 
is another topic...

I assume someone had a 'good' only-for-UNIX 
reason ;=))

In general, in Windows, using a DLL is a 
real PITA!

HTH.

Regards,
Geoff.

patch
diff --git a/simgear/CMakeLists.txt b/simgear/CMakeLists.txt
index d505998..9bb8dce 100644
--- a/simgear/CMakeLists.txt
+++ b/simgear/CMakeLists.txt
@@ -64,7 +64,10 @@ if(SIMGEAR_SHARED)
 target_link_libraries(SimGearCore ${ZLIB_LIBRARY} ${RT_LIBRARY} 
 ${EXPAT_LIBRARIES}
 ${CMAKE_THREAD_LIBS_INIT})
-
+if (WIN32)
+target_link_libraries(SimGearCore ${WINSOCK_LIBRARY})
+endif (WIN32)
+
 if(LIBSVN_FOUND)
 target_link_libraries(SimGearCore ${LIBSVN_LIBRARIES})
 endif(LIBSVN_FOUND)
@@ -86,10 +89,19 @@ if(SIMGEAR_SHARED)
 ${OPENGL_LIBRARY}
 ${JPEG_LIBRARY})
 
-install(TARGETS SimGearScene LIBRARY DESTINATION
${CMAKE_INSTALL_LIBDIR})

Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Vivian Meazza
Gijs wrote:

 

http://wiki.flightgear.org/Unique_Features

 

Hmm . that's an underwhelming list, and I can't come up with anything that's
really any better. Does that encapsulate the problem?

 

Our USP is that FG is FREE - yes FREE. We might not have as much eye-candy
as other sims, some of our ac as good as other sims (and some aren't) but
hey - it's free, and cross platform. 

 

Anything else? 



 

.snip

Comparing with MSFS and X-Plane
Feel free to use the wiki to make a list of unique features and/or
comparison to other simulator.
Someone started this a while ago, but it could use some loving care:
http://wiki.flightgear.org/Unique_Features
I once started on a key binding comparison, (hopefully) making it easier
for people to switch:
http://wiki.flightgear.org/Key_commands_compared_to_other_simulators

In this series, we can also add a dictionary (eg. what we call liveries
are called paintjobs in certain communities) etc..

Listing the differences would also make a good feature request list, so we
can work on great features that other sims have, but we lack. I think people
would like to have at least the same, and possible better/more features
before they'd consider switching.

snip

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Windows SG DLL build - NO GO!

2012-11-08 Thread ThorstenB
On 08 Nov 2012 Geoff McLane wrote:
 But maybe we would be better off removing the
 SIMGEAR_SHARED option if WIN32 ;=))

No objections. Indeed it wasn't intended for Windows.
I'll remove the option for WIN32.

 And of course, I really wonder WHY we added
 a 'shared' version of SG at all... but that
 is another topic...
 I assume someone had a 'good' only-for-UNIX
 reason ;=))

Exactly.
It improved support for Linux distributions a lot, which do have fixed 
rules to use shared libs. Since shared lib support is now in SG, all 
distros can/could drop their local makefile patches, which they had to 
use before. It has removed a major obstacle preventing distros from 
quickly updating to the latest FG release: they no longer need to wait 
for a volunteer to update their local makefile patches for every single 
FG release.

Please let's not discuss the reasons here why Linux packagers are so 
strict with using shared libs (they have very good reasons), it's futile 
and beyond our power anyway...

cheers,
Thorsten


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)

2012-11-08 Thread Stuart Buchanan
On Wed, Nov 7, 2012 at 5:03 PM,  John wrote:
 second,  we also run fgfs on a multi-core machine with three graphics cards.
 Performance is around 50-60 fps for each core.  and thanks to Jan Comans the
 3d clouds are sync aross all three displays.

Hi John,

I'm confused.  From my reading of Durk's post, 3D clouds would appear to work
fine for a multi-display system out-of-the-box, but your comment
here indicates
that there is an issue that requires fixing by restricting the random seed.

Can you explain a bit more about how you are running FG in this instance?

In particular are you running multiple instances of the simulator?

I _should_ be the case that if you're running multiple cameras on a single
scene-graph, the existing code will Just Work.  However I've not got the
option to test this myself.

-Stuart

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Stuart Buchanan
On Thu, Nov 8, 2012 at 11:27 AM, Gijs de Rooy  wrote:
 Beamers are great, as they can provide a view to many more spectators than
 you can gather around an ordinary screen. We did have the largest screen so
 far, but it was floating somewhere in the room, so there was no clear
 connection to our booth.

+1.  In particular it makes it much easier for the people not actually using the
sim to see what's going on - something that's particularly important if people
are going to have queue for 5 minutes before they get the opportunity to try
for themselves.

One other nice side-effect of using a projector is that their reduced resolution
relative to a LCD display means one can run more eye-candy or get better
frame-rates.

 Being able to give people a  DVD/CD/USB (the installer is 640 MB for
 Windows, that should fit on a CD...) with the latest version of FlightGear
 would probably encourage them to install it and actually try the software.
 We do tell people to download it from our website, but most of them will
 forget about it. If you bring a CD home with you, you will probably at least
 look at it before you throw it away. Of course this costs money, so we may
 need to look at some fundraising (sponsoring?).

Curt - at one point you sold FG CDs/DVDs.  What's the cost per DVD with a
nice label?

 Comparing with MSFS and X-Plane
 Feel free to use the wiki to make a list of unique features and/or
 comparison to other simulator.
 Someone started this a while ago, but it could use some loving care:
 http://wiki.flightgear.org/Unique_Features

I agree with Vivian, currently this list is rather un-inspiring, and really
doesn't address the question Why should I switch from FS-X?.  I'll have
a think about how to address that question for the next release so we've
got some collateral to go with our release note.

 Aircraft download page
 I have a fully functional revamped download page set up at
 http://flightgear.byethost31.com/aircraft/aircraftpage.html, but there were
 some issues getting it operational on flightgear.org intialy, so we decided
 to push the old scheme for this release. We can always add this
 interactive page though, and now that my last exams of 2012 are over, I'll
 have a closer look at it again. Feedback is welcome!

We should absolutely have aircraft-rating filters on the main download page.
The aircraft raitings have been around long enough now. I suggest that we
mention this explicitly when we announce the beginning of the release process
so that aircraft authors have plenty of time to add ratings.

Note that this requires a bit of cleverness when writing the parsing script,
as some ratings are not stored in the -set.xml file, but rather a file
that is included
withing that one.

I'd also suggest that by default it should only show aircraft with a 3+ rating,
so that a completely new user will only see the best aircraft we've
got available.

Gijs - some direct feedback:  I can't see anyone wanting to only show aircraft
with a rating less than a given value, so I think the sliders should
just consist
of minimum values.

-Stuart

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Durk Talsma
Hi Stuart,


 
 One other nice side-effect of using a projector is that their reduced 
 resolution
 relative to a LCD display means one can run more eye-candy or get better
 frame-rates.
 

Just a quick (and admittedly not completely serious) response for now:

Not quite true: I specifically bought a full HD projector, so that I can a) run 
Flightgear at full res at FSWeekend, and b) maximize  it's utility at home for 
watching blu-rays. :-)

I'll write a more serious repley regarding your other remarks tomorrow.

Cheers,
Durk

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Gijs de Rooy
Hi stuart and Jaroslav,

thanks for the aircraft page feedback!

 the quick search works on authors only

Oops, that's a bug :-)

Actually, I have two versions of the script. The other is at 
http://flightgear.byethost31.com/wordpress/download/download-aircraft (don't 
mind the layout, that was just another test, but I'll convert it to the current 
layout). That one has functional keyword search, but the rating filtering is 
slightly confused. I'll mix both scripts and then we should end up with a 
working example.

 Note that this requires a bit of cleverness when writing the parsing script, 
 as some 
 ratings are not stored in the -set.xml file, but rather a file that is 
 included  withing 
 that one.

That's not an issue. The script can already deal with nested -set files (eg. 
all Emmanuel's -base.xml aircraft are parsed fine). The only real issue that 
we have right now is how to filter on a per -set.xml base. 

We provide the downloads on a per-directory base. This was never a real issue, 
but now it is, because one directory can contain aircraft with different 
ratings. At the moment I show all these as individual aircraft, so some 
aircraft in the list link to the same download package (eg. 777-200, 777-200ER, 
777-200LR)... 

Ideas are welcome. I've been unable to come up with a good solution so far.

 I can't see anyone wanting to only show aircraft with a rating less than a 
 given value

It may be interesting to aircraft developers. If you want something to work on, 
you'd be looking for low rated aircraft. I've left it in to show what's 
possible, but maybe we should indeed leave it out. It may confuse new users.

Gijs  --
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)

2012-11-08 Thread castle . 64
Yes, your are correct it you run a single instance of fg with three displays 
with whichever scheme you use; e.g. using the XML file to create a left, 
center, and right camera for the scene or one of the video splitters to break a 
single large camera into three channels for each display. 

However, if you run an instance of fg using, for example, the center as the 
master FDM, then create two slave fg's using the FDM=NULL option for each 
left and right instance each instance starts with a different random seed. This 
occurs whether you run all three instances on a single CPU or, as in our case, 
each instance on a single core of a multi-core machine since each instance 
creates it's own scene graph. The advantage of the multi-core machine is 
performance limited only by the bandwidth of the busses and graphics pipelines 
and GPUs. have not really drilled down just where or what are the limiting 
factors using a multi-core machine with multiple video cards; just know it is 
faster based on fps for each core versus running everything on a single core 
machine. The disadvantage is many of the dynamic features like clouds, AI 
traffic, etc are not sync'd across processes. 

Jan Comans solved the problem by using a *fixed* random seed ( another oxymoron 
;-) ) for the 3d clouds at least. 

Another approach, perhaps a bit more complicated to make it cross-platform 
compatible, would be to use shared memory to have one 3d cloud generator as the 
master and the slaves would simply read the data from shared memory. 

BTW the warping code will run in a single core machine with multiple displays 
and the performance hit is minimal. 

John 

- Original Message -
From: Stuart Buchanan stuar...@gmail.com 
To: FlightGear developers discussions 
flightgear-devel@lists.sourceforge.net 
Sent: Thursday, November 8, 2012 3:24:37 PM 
Subject: [Flightgear-devel] 3d clouds on multi-display systems (was Re: 
FSWeekend 2012...) 

On Wed, Nov 7, 2012 at 5:03 PM, John wrote: 
 second, we also run fgfs on a multi-core machine with three graphics cards. 
 Performance is around 50-60 fps for each core. and thanks to Jan Comans the 
 3d clouds are sync aross all three displays. 

Hi John, 

I'm confused. From my reading of Durk's post, 3D clouds would appear to work 
fine for a multi-display system out-of-the-box, but your comment 
here indicates 
that there is an issue that requires fixing by restricting the random seed. 

Can you explain a bit more about how you are running FG in this instance? 

In particular are you running multiple instances of the simulator? 

I _should_ be the case that if you're running multiple cameras on a single 
scene-graph, the existing code will Just Work. However I've not got the 
option to test this myself. 

-Stuart 

-- 
Everyone hates slow websites. So do we. 
Make your web apps faster with AppDynamics 
Download AppDynamics Lite for free today: 
http://p.sf.net/sfu/appdyn_d2d_nov 
___ 
Flightgear-devel mailing list 
Flightgear-devel@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/flightgear-devel 
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel