rich135

That is the behavior I have seen so far through all XP10 betas thus far, before and after the changes to the cloud sliders. Clouds are mosly opaque near and in the layers, but transparent when well above. This may be for performance reasons. Hoping we can get solid overcast at some point with no peaking through.

As many of you, I purchased previous versions of X-plane with great hope, only to quickly abandon. X-plane 10 has finally won me over. It is far from perfect, but it has so many things I really like.Clouds, night lighting, IFR = AWESOME. Very immersive.One texture size = no blurries.Frame rates 30-50 on a decent rig. Very few stutters. Leverages GPU and cores.Great plugin model and SDK.Very stable.Continuous software updates and fixes.Default airplanes are lacking. Good 3rd party airplanes available. x737 + XHSI + UFMC + Goflight = Great.Daytime, VFR, airports, and scenery are lacking. However, the fundamental approach has so much potential. I am glad they released it now so 3rd parties can start working. I think within a year, it could be very nice.I am pulling for Austin and team. They are passionate and committed... unlike the other guys who are in, then out, then back in.For $80, I am very pleased.RichPP-ASEL-IA

Thanks for the feedback Nick and Dirk. Indeed, I see a slight increase of jaggies and shimmer with this adjustment... so definitely a trade-off.Regards,Rich

>>> My experience is identical to Nick's. At 4096, performance can drop to 6-10 FPS on a high-end optimized system under heavy weather. I am using GEX as well, but usually see 30 FPS locked outside of these weather conditions.UPDATE: I was using nHancer to set AA and AS in the nVidia driver. After defaulting back to "application control" and setting AA + AS in FSX, I no longer see the perf hit; I went from 6 FPS to 30 FPS in same weather scenario. I suspect setting application controlled in the driver allows FSX to apply AA and/or AS to certain objects, whereas setting in driver forces the GPU to process AA and/or AS on all objects (confirm?). In any event, this made a huge difference for me.Regards,Rich

>>> I haven't noticed anyone else reporting a performance hit and I'm certainly not getting any additional stutters or issues.My experience is identical to Nick's. At 4096, performance can drop to 6-10 FPS on a high-end optimized system under heavy weather. I am using GEX as well, but usually see 30 FPS locked outside of these weather conditions.Regards,Rich

Hi Clayton,Thanks for asking. Unfortunately developments in my day job have slowed the project to a crawl.Regards,Rich

>> Even with Phil and staff's expertise, they have to get re-tooled to the latest Game technology development tools. It is time to retire C++.Is that so?

Hear Hear. Anybody who has been in Phil's position understands EXACTLY where he is coming from.

<<>>Exactly right Bill!

<<>>A valid point. System requirements on the box...XP/SP2 - 256MB RAMVista - 512MB RAMProcessor 1.0 GHzVideo Card - Direct X 9.0 with 32MB of RAM and support for hardware transform and lighting.Hard to imagine any enjoyment from this system.

My son (age 9) has been flying with me since age 5, both sim and real life. In the sim he has far surpassed me in air races and aerobatics. Just got him the RealAir SF260 for a good report card; he is loving it.

Waiting to see what the FEX and REX weather engines bring to the table. And waiting...

Its a bug in the GPS map code. Same happens with GPS 500.

Please disregard reply.

Thanks for the feedback and encouragement Chris.<>Yes. There is no requirement to connect to a SIM to generate flight plans. A connection is made only if you switch to GPS mode.<<>>Dragging the route line to add waypoints, as in FS9 and FSX, is the primary way to add waypoints in this software.<<>>Yes, both input methods will be available. Auto routing might not be there in the first round, but you will be able to see the airways on the map.FS9 flight planning will be supported. In the early releases, you may have have to use a third party BGL decompiler to import data from FS9. FSX data import will be available in the first round. Moving map for FS9 would come later, as I would backtrack and support FSUIPC.<<>>Me too. I am a private pilot/instrument rated, but have been grounded due to the skyrocketing fuel prices. To stay in the game, I am slowly creating an RJ cockpit in my spare time. The underlying technology in the planner had to perform well enough to be a panel in the overall RJ flight deck software I am building (see link below). Eventually it has to have all the features of an FMS; not necessarily in the same application.RJ personal project: http://picasaweb.google.com/rich.lucas.maps/RJCockpit

Thanks for that data Bill.

Not entirely. Only the in-process map is in question.With one machine you could:1. Plan a flight and even load it via Simconnect.2. Run the moving map in a separate process (window). For this I would recommend a quad core CPU with one core set aside for add-ons. On my dual core system, FSX/SP2 is using both cores at 99%. So this would be my general advice to anyone running add-ons on the FSX machine.That said, I understand the desire/need to run in FSX full screen mode and would hope that is achievable at some point.

Nothing is on or off the table. Some of the requested features will require some help from the community. Therefore, I am going to work towards a basic free planner and moving map for now, using this as an entry point. There are several big picture items that require some feedback prior to implementing extensive features. These include:1. Initial user experience and feedback.2. Level of interest.3. Issues with WPF/.NET framework (mainly setup)?4. Issues with Simconnect (mainly setup)?5. Issues with scanning, obtaining and maintaining nav data?6. Issues with FSX/SP1/SP2?7. Variety of file formats (plans, sid, star, approaches)?8. Integration with 3rd party software and formats.9. Why are big names leaving the space?10. Why are big names entering the space and what will they bring?11. Can this remain fun at the same time? ;-)I also think we are a long way from payware. Maybe some day if the quality is there and level of effort requires.Regards,Rich

Thanks Jonas.I agree with your assessment.Rich

Chris,Tentatively yes, and I think you would need options for those trade offs to be made. I am assuming most folks are getting 20-30 FPS in flight, and 10-20 in areas with detail scenery. The good news is that FSX/SP2, seems to be maxing full use of the cores now. The bad news is that add-ons do not have much headroom (unless the user starts adjusting affinity masks and all that good stuff).This is also assuming that WPF would co-exist with FS in the same process. Although the map software would run in the FSX process, I think WPF may not. Both use DirectX, and XP/DX9 may be limited to one app at a time in full screen mode (need to verify this). I think DX10 make provisions for multiple apps/threads to share the display.Regards,Rich

Thank you for all of the great feedback.I now see a curve ball which I should have seen before.Earlier I mentioned that an in-process map was a possibility down the road, primarily due to performance concerns. As I am reading the "why I liked FSNav posts", it appears that the in-process map was one of its biggest reasons for adoption. I define "in-process" as the ability to see (and possibly manipulate) the map on the FSX computer/screen while FSX is running in full screen mode.The primary reason I started this project was to OFFLOAD the moving map from the FSX computer onto a 2nd system dedicated to panels. The frame-tax to run the Garmin GPS-500 was up to 6 frames per second with stutters (in terrain mode) -- and this is on a E6700/GTX8800 rig overclocked to 3.2 GHZ. At the big airports on a cloudy day, this was the difference between 20 FPS (usable) and 14 FPS (not usable).I am not confident that the average simmer's hardware can deliver the horsepower needed to run this in-process without impacting FSX -- a common problem in the add-on space these days. Perhaps this will change as the hardware plays catch-up, as we saw with FS2004.If in-process is a "must have" and a criteria on which the success is ultimately judged, I may have to pass for now. It appears there are other stealthy projects out there. Perhaps they can reasonably address this need. I will keep working on this in the background and see what others bring to the table over the coming weeks.Best Regards,Rich

The software makes heavy use of vector graphics to achieve clean lines and curves at all zoom levels. The terrain elevation coloring currently uses raster imaging with different data sets for the various zoom levels.A brief comparison of the two methods can be found here:http://www.logodesignworks.com/blog/vector...hics-differenceWindows Presentation Foundation (WPF) is a graphical subsystem. It is pre-installed on Windows Vista. XP users get WPF by installing the .NET 3.0 framework. WPF is based on DirectX under the hood. If you have a DX9 or DX10 graphics card, WPF will offload most of the image rendering to the graphics processor. This allows rendering of complex visuals while maintaining reasonable frame rates.

Thanks to Simconnect, there is much potential. There are three possibilities.1. Second computer. Already working, no CPU/FPS impact on FSX machine.2. Along side FSX in separate process. Also possible, but need to study the impact on frame rates and smooth task switching.3. Inside the FSX process. Very nice to have as this would allow tight integration with an aircraft's panel. WPF inside FSX process requires some further study. My hat is off to Bill Leaming and other gauge programmers who can do #3 so well.Regards,Rich

<Right now I am considering a freeware basic version. This would generate FSX flight plans and provide moving map via SimConnect.As usual, the moving map feature would be ideal for a second computer. Unless you have a quad core machine, I would hesitate to cut into FPS by running along side FSX on the same CPU.Once I understand the ongoing interest and support issues, I could potentially expand to an upgrade version that supports advanced planning features, SIDs, STARs, and 3rd party navigation data. Fairly easy to implement, but somewhat harder to maintain.Much depends on what the other projects are providing as we get down the road in '08. If the features are well covered in other offerings, I would be sensitive about "watering down" a small space where other add-on developers are trying to make an honest living; some full-time.Best Regards,Rich

Thanks Tim.That looks very good too. It is great to see others are stepping up given the recent interest.The vector quality in WPF is really worth the effort (compared to GDI+). You will not be sorry. However, I think there is a catch. To get acceptable performance, I really had to dig down into the low-level WPF functions. These include heavy use of StreamGeometry, overriding OnRender(), GlyphRun objects, and freezing any objects (Brushes, Pen's, etc.) that can be frozen. Higher level WPF objects, even FormattedText can really eat up CPU.Getting SimConnect to work from WPF in C#.NET can also be a little tricky, as all the examples in the SDK assume Windows Forms. Fortunately I solved that one a while ago: http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchGood luck with your project and WPF!Regards,Rich