>Could we see MS moving from Direct X to OpenGL to improve>performance?That really doesn't make sense - MS created DirectX, and there are plenty of games that run and look absolutely great in DirectX (HL2, FarCry, the new game F.E.A.R, etc) It's the way the FS engine doesn't fully take advantage of what DirectX can do that's the problem, not the API itself.

No way we should give Microsoft a pass on backward compatibility. At the very least, a clean migration strategy is required. There is no reason that new functionality cannot be supported along with compatibility or migration. Don't you think Microsoft has to deal with this on their other products: OS, Office, database, web? This is a huge element of any responsible software or system development effort. Don't worry, the two are not mutually exclusive by a long shot. The challenge has to be to provide BOTH new features AND compatibility or migration.Regards -- Dick Bixler

As one who designs scenery, backward compatibility is important but not at the expense of a new more effecient engine as referred to in the thread.Adam

"I agree the engine should be brought up to standard with thelatest games and technology, but Im convinced it wont makemuch difference.FS is about flying, and it already does that very well. What iwould like to see, is phsyics introduced so that you can haveyour plane land on its belly (gear up) and react like itshould.Over brake on landing and you get a lovely trail of smoke asthe tyers lock up. Xplane type physics (no I dont think x plane is better) but itdoes have an edge.All the eye candy is already good if you ask me, but .bmpsshould be outed in favour of jpegs, shurley rendeing 200K isbetter than nearly 3.5meg for some textures?"I disagree, for me FS is about what I am flying and thw world I am flying in. I already feel the aircraft part is close, but the scenery part is far from being there. We have default aircaft that simulate the real thing well, but the world out of the box is far from the real thing up close. Granted many say "you can't see anything at FL350" fine, but what about when you start, TO, land, etc, there is a whole living, dynamic world around us and while it is possible with current design tools to recreate it to a better degree, it's not feasible due to the game engine.Regards, MichaelKDFWhttp://www.calvirair.com/mcpics/mcdcvabanner.jpgCalVirAir International

>Backwards compatibility should be important ... to an extent.> I have purchased several addons recently, and I'd be unhappy>if they were incompatible with the next version of FS :(>>At the very minimum, the following should be compatible:>>1) FSDS2 and GMAX planes designed for FS2002 and FS2004>>2) Most gauges from the previous two versions>>3) Basic scenery from FS8 and FS9, that comply with the SDKsWith your suggestions, there would be NO CHANGE! Those are ALL the things that need to change. :-rollCarmine http://forums.avsim.net/images/wave.gif

I'm afraid it's probably a little bit more complex than that.It's not that just by throwing away backward compatibility, the engine will automatically become more powerful and efficent.From a scenery point of view, the engine has ALREADY trown away a lot of compatibility with the past to get better performances.For example "SCASM" code ( I called it like this to make it simple, altough it's not entirely accurate, since SCASM it's just a compiler ) is no longer executed in real time like it used to be up to FS2002, but it's pre cached and pre otimized, basically converting it into FS2004 code while loading. Lots of instructions doesn't work anymore, due to the fact the code is rearranged and executed in a different way.FS2004 RIFF file format has been choosen to optimized speed of execution, because is better structured.The fact it's still possible to load, in some way, "old" code, doesn't mean the real run time behaviour is automatically unefficent. Maybe the loading could be complex, not necessarily so the actual execution.Remember when it was possibile to change a BGL and see the results without quitting FS ? It's not longer possibile, and this has lot to do with the "loading and optimizing" process explained before.No, unfortuntely the problem is more complex, and it has to do about HOW FS IS.First, it's not a "level" based engine, like Unreal or Far Cry. These programs are assuming the playfield is limited in scope. No need for a global coordinates system, no need for the need of having, say, 60 miles of visibility. You can easily put a fog layer 2 km away from the player, and still having a lot of good-looking stuff around you, in a ground-based sim.The scenery has to look belivable at both low, mid and high altitude.The enviroment has to be live and dynamic. Take PS2 Gran Turismo 4. Sure, it looks stunning, at least a couple of generations ahead compared to FS. But, for example, when you load a racetrack in GT4, the season, time of the day, the lights, it's all staged and precalculated. You can't choose to race at Laguna Seca at noon, if the scenery has been designed for 15:00 PM, it will always look ( stunningly ) the same.FS engine has to be able to deliver a belivable enviroment that changes globally, reacts to seasons, weather, local areas. This goes against any possible pre optimization. So, for example, some light effect that can be pre calculated in a game were it's exactly known the time of the day for each scenery, in FS have to be calculated in real time. So they will be either slower, or they will look worse.Think Splinter Cell, sure it look incredibile, but that night mission will *always* take place exactly at that precise time. And, you can easily force the player, by means of goals and/or closed paths, to go in a specific direction, when you have put the nice stuff. In FS, because of the free roaming nature of the game, it's by definition impossibile to anticipate where the player will want to go, so the scenery needs to have a reasonably even quality, worldwide.And, most important of all, FS is designed to be EASILY expanded. I don't say "expanded", I said *easily* expanded. Lot of difference. Any game engine can be expanded, of course, but none compares in the scope of customization like FS.Some important optimizations are simply not possibile, if we want to keep it AS EASY to be expanded as it is now.So, it's not as simple as asking "do we want to have backward compatibility or not", but it's rather "are we prepared to have a sim that could be LESS easily expandable than it is now, if this means having a much more efficent engine" ?And, this is a question were the response it's quite a bit more uncertain. I, would be very glad to throw all backward compatibility, but I'm not entirely sure if it would be enough to have a Far Cry or a Splinter Cell like kind of quality. I fear that a flight simulation, by definition, can't be as efficent as other games can.Umberto Colapicchioni

Good job Ken. Now this is a post geared towards making forward progress. :-)

>All the eye candy is already good if you ask me, but .bmps>should be outed in favour of jpegs, shurley rendeing 200K is>better than nearly 3.5meg for some textures?well, this doesn't make much sense. We already have a lossy compression available. Just because they have a BMP extension, doesn't mean much, it's the format that counts. DXT1 and DXT3 are certainly faster than any JPG could be, because they are kept compressed in the HD, sent compressed through the bus, and used compressed as they are by the graphic card.JPG would only save HD space, but once loaded they have to be decompressed, because no graphic card can understand JPG, so they will actually be much slower than DXT.regards,Umberto Colapicchioni

Somehow I don't quite get this compatibility vs features discussion, and from a software engineering point it doesn't make any sense either.Firstly, FS as an application has 2 sides to it. Algorithms/implementation/software code vs data structures. It's the algorithms that make the new features, ie are they coded for multi-processors, GPU, deliver stunning graphics, physics, etc. Data structures on the other hand supply the data for the algorithms and determine backward compatibility. So compitibility doesn't per se exclude progress at all. Whether the rivers and roads are of format ABC or XYZ doesn't have any influence on how they are rendered, if they support real waves and are animated, or if the are rendered as plain blue lines. The next FS version could have a lot of new cool stuff and still be backwards compatible, without much extra efforts on the FS team's behalf. Of course, there comes a point in time when it makes sense to change data structures, but the FS team has done this over the last versions and done this also with a lot of foresight. There is no call for radical changes at this point in time, given current technologies.Secondly, scrapping everything done and starting from scratch doesn't make sense at all. There is a lot of good stuff in FS, why throw it away? If the FS team were to rewrite from scratch, we'll see the next version in 5 years time, and we'll get a bunch of bugs, since FS is such a complex program that there'll be plenty of pitfalls in the coding progress. There is a reason MSFS doen't have much competition. Programming a civil flight simulator as complex as this from scratch is a major investment. Throwing everything away would be like throwing millions of dollars out of the window.As for using opengl - why would a team within Microsoft use a competing library? On top of that Microsoft developped DX because they didn't think an open consortium (opengl) would meet the challenge of future innovation. So why would they use opengl?!? That would be like openly admitting they lost the race (which btw has no winner as yet)!I hope my ramblings make sense. I'm sure the next version will have neat new features, but I'm sure we won't see a revolution, and I'm glad we won't either.Cheers,Christian

>Whether the rivers and roads are of format ABC or XYZ doesn't>have any influence on how they are rendered, if they support>real waves and are animated, or if the are rendered as plain>blue lines. It can be true right now, looking at how VTP works, because MS choose a very clever way of doing it. They simply compile the scenery when loading ( the "Loading Terrain" screen ), creating texture on the fly, based on landclass information + vtp vectors. That's why VTP lines, as long as they don't contains too much autogen, do not impact much the frame rate. They simply do not exists anymore, after the scenery has been loaded: it's all in the texture. A very complex VTP scenery, once loaded, has basically the same frame rate of a sparse one, only the loading time differs.The downside of it, of course, it's the limited resolution. The vectors, once compiled in the textures, become pixels, so there is a limit on the resolution that can be reached. VTP lines looks very bad at close distances.The real challenge would be seeing if it would be possibile to keep the existing data structure, but integrate it with Shader programming. And, I don't know how much the current "vectors become pixels" approach can be further enhanced, or if it's time to change it entirely.Umberto Colapicchioni

135 votes to date. That will really impress Microsoft!

>Could we see MS moving from Direct X to OpenGL to improve>performance? Not a snowball's chance in an oven... ;)Look for what DirectX 10.x will offer...

Personally, I think that the sim should stay at a level that can be improved upon, but at which existing addons will still work. Lets face it, at the moment this simulation is fantastic ( otherwise, why would so many of us be so deeply invloved with it? ) and with just a little imagination you can be anywhere, anytime, any weather and do the same again the next day differently.Sure there are some issues, but I'm also sure these can each be improved upon without the need for a completely new "engine". We could have, say, an improved ATC, some improved textures, better weather etc but at 6 monthly (or whatever) intervals which just keeps adding to the sim and not destroying it in favour of another new version.As for me, I still have not explored everything FS9 has to offer as I can't keep up with the hardware requirements. I am just looking forward to getting a new pc to run my own scenery using FS9 and then getting some of the addon stuff available. Long live FS9, but please MS, keep improving it not changing it completely.Colin Colin

>The real challenge would be seeing if it would be possibile to>keep the existing data structure, but integrate it with Shader>programming. FS9 includes shaders already, the water is programmed as DX shaders. So the answer is yes, it can be done, because it already is done with the existing data structure.>And, I don't know how much the current "vectors>become pixels" approach can be further enhanced, or if it's>time to change it entirely.This is the most modern approach of doing this. There isn't any better algorithm to date. Texture resolution depends on graphics card memory and fragment/pixel processing power, not data structures. This is exactly the same as the resolution of your cockpit textures - or all textures in general. There is an upper limit your hardware can do. Christian

Hmm lets see......Minimum requirements to get decent frame rates with FS10New PC with 6 Gig processor 64 bit $3500All new scenery and Mesh for FS10 $400New Aircraft for FS10 $400Other add-ons like ASVl, UT, FE... $200Actual time spent to get the bugs, crashes, and kinks out of the new program times $10 an hour for the new owner $1000+Total cost $5500+. And in 28 months you get to do it all over again with FS11........... That's about $200 a month to fly MSFS.. Hmmm.......;) Now how much was that real Cessna 150???????