Jump to content
Sign in to follow this  
Guest Foxtrot 125 Tango

Thoughts on FSX

Recommended Posts

There has been many suggestions around improving "this that and the other", and MS has shown themselves through the various screenshots that eye candy is high on their agenda. I just wonder whether there are other aspects that could be vastly improved generically to provide a slicker, smoother performing simulation.I would like to profer the following, not in any particualr order:# optimisation of performance overall through use of new coding techniques. Don't get me wrong, FS2004 is fantanstic as it is, but we all suffer from time to time with stutters and the like and the need to downsize on functionality. MSFS loyal fan base are not all about to throw away their current 2.4 - 3.0 mhz pcs and spend another


flyuk_sig.php?id=UKV3373

Share this post


Link to post
Share on other sites
Guest Fjorko

Good ideas...Especially the last one !!!I fear that FSX may be too far in development for them to incorporate any of these suggestions now though ! :-(

Share this post


Link to post
Share on other sites

Hi,I certainly hope they don't switch to a database format. The number of corrupted databases I've seen in my lifetime makes me very hesitant to trust it holding all of my valuable flightsim info. And once it's gone, you have little or no backup. With the current setup, I just make a few edits in WordPad and I'm good to go.Take care,--Tom GibsonCal Classic Propliner Page: http://www.calclassic.comFreeflight Design Shop: http://www.freeflightdesign.comDrop by! ___x_x_(")_x_x___

Share this post


Link to post
Share on other sites
Guest

I'd prefer a binary config file format so users can't go into them and make manual edits which invariable lead to problems elsewhere, which gets them to complain that some addon (of whatever kind) is "not working properly".I've seen corrupt databases, but I've seen far more ini-files corrupted by users like that who thought they were "fixing" something...

Share this post


Link to post
Share on other sites
Guest

Heres one more:# Only draw those planes/objects that are visible.

Share this post


Link to post
Share on other sites
Guest tdragger

We already use an indexed database for scenery files.

Share this post


Link to post
Share on other sites
Guest tdragger

Interesting thoughts, and 2.5 of 4 we always have done.

Share this post


Link to post
Share on other sites
Guest

what, no embedded MS SQL Server? :-rotor

Share this post


Link to post
Share on other sites

Thanks for responses, especially TDragger's who I think is part of the MS team.I fully appreciate MS already uses a compiled database file for the scenery, but why compile this from the scenery.cfg file rather than provide direct entry ability? When one has over 350 entries in the scenery.cfg like I do, this regeneration occurs on every launch of the application and takes unnecessary time.Working in IT myself, my thoughts were around the fact that it must be more efficient to access/read an mdb than a text file, and that perhaps the same could apply to aircraft and other aspects as well as just the scenery db.Further thought would be to speed up the initial 'create' flight screen by holding all the installed aircraft and liveries in an mdb, perhaps even containing a jpg/gif of the aircaft in a specific size to speed up generation of the screen. By holding in an mdb this should be more efficient too than, as it seems currently, whereby the application trolls through the file structure, reading aircraft.cfg and textures.The same would apply to all the settings in the FS9.cfg, which becomes potentially easily corrupted through users 'playing' around with the various parameters therein.I recognise the need to keep an 'open' platform in order to sustain the growth of the product through the many commercial and freeware developers, but this could still be maintained but with a tighter control around the configuration and at the same time bring general performance benefits.Out of interest, tdragger, which were the 2.5 of the 4 that you do already?Regards,Stuart Hyett


flyuk_sig.php?id=UKV3373

Share this post


Link to post
Share on other sites
Guest tdragger

Actually I should have said 3.5--I didn't read the rest of your comment all the way through. Here's the details on the points you raised.1. Coding techniques - What is this comment supposed to mean? We upgrade our code every version and continuously explore new techniques when it makes sense. FS used to be programmed in assmebly language. Today it is a multi-threaded, asynchronous, object-oriented application programmed in C++. 2. Structured database - As I said, we already do this. The CFG files aren't the database, it's simply the configuration options. The time it takes to rebuild indices has nothing to do with these files and all to do with how much data you have. Trust me, I know a little about MDB files, having written the book (literally) on Access development (http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author-exact=Mike%20Gilbert&rank=-relevance%2C%2Bavailability%2C-daterank/102-3842498-0784923). Relational databases have benefits as well as costs.3. File loading - The very reason we used a structured, spatial database is to manage file loading. Every scenery file has a header that lists its geographic bounds. The engine has a sophisticated algorithm to determine which files to load based on your location. If you're experiencing high memory usage it could be that your add-on content does not have these bounds set or has them set too large. As for textures, that's highly dependent on content. If a model calls for a texture the engine has to try to load it. We do use a dynamic LOD scheme for managing texture usage but we can't control what an add-on says it needs.4. Weather - We already do triangular interpolation between weather stations. Have you ever noticed that things like winds, temperature and pressure don't jump rapidly? If you're referring to what has become known as "the visibility bug" that has nothing to do with the interpolation. This is due to a limitation of using hardware fogging to represent visibility changes. Fogging is a very blunt tool. We can try to make this better.I'll give us a 0.5 deduction because our file loader still is not very smart about when to release file handles and because of the visiblity bug.

Share this post


Link to post
Share on other sites

Thanks tdragger - I feel suitably chastised !!!!!I am obviously not so technically aware as you are, with you being close to the coal face so to speak. My comments were merely meant to highlight the perception that we, as users, have with certain aspects of the sim. When certain addons are produced, which seem not to improve on the overall performance, one wonders whether more could be done with the defaults supplied. Don't get me wrong, I am in awe of the whole programme and those that put such code together, and was in no way sniping at the coders or MS.Re. loading times, I was not thinking in terms of loading specific sceneries, but more what happens during launching of the application. The more sceneries defined in the scenery.cfg and the more aircraft added, the longer the app takes to to get to the starting blocks. I was challenging whether there must be a more efficient way of managing this. Re. weather - I was thinking more of the suddden change in cloud cover - one minute you can be in overcast conditions and then suddenly clear skies - or vis-a-versa. I have no idea what causes this sudden shift, which doesn't happen in reality. Thanks again for taking the time to clarify and comment on my remarks. Finally, nothing is meant in a derogatory way - Flightsim is THE BEST simulation programme around and it's development over the years has been phenominal.Regards,Stuart Hyett


flyuk_sig.php?id=UKV3373

Share this post


Link to post
Share on other sites
Guest tdragger

Chastising was not the point--education was. The more you know the better you are (most of the time). ;)

Share this post


Link to post
Share on other sites
Guest

< ..application programmed in C++. Wow so in this version, the whole codebase was migrated from C into C++ ?

Share this post


Link to post
Share on other sites
Guest

why would that matter anyway?Is an application somehow inferior because it's written in language X instead of Y?btw, if you read Mike's post you see no mention of C at all.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...