56 minutes ago, Ray Proudfoot said:

I honestly don't understand the need for sloped runways. I know of two in the world. Manchester 05L/23R with a hump in the middle and Lukla in the Himalayas. Are there any other major ones with them? 

There are tons of runways out there that are not dead-on level. Just do an image search for "steep runway" for some fun examples. Here's a particularly entertaining one:

 

In mountain country there are some where you land up-slope to let gravity help you stop, and you take off down-slope so you don't ram into the mountain. It's kind of odd to be bush flying and have every runway be as level as my table saw. 😉

 

 

Edited May 20, 20197 yr by eslader

On 3/8/2019 at 4:16 PM, DellyPilot said:

the fact that BGLs hold compressed scenery (and textures)

and

On 3/8/2019 at 4:16 PM, DellyPilot said:

3. Support for uncompressed BGLs
As storage increasingly gets cheaper, I think a performance improvement could be made if we could un-compress BGLs ahead of sim time

I don't know of any BGL compression. BGLs are programs written in "Bruce's Graphical Language!" devised by FS's originator Bruce Artwick. The language has been much extended to do more and more things over the years, but it is basically a sound design that can do a lot.

Many of the new features remove backward compatibility when used, but the original features don't take up time or processing if not used. So removing that doesn't buy you anything as long as you only add sceneries designed FOR P3D4 or P3D5 using the newer techniques.

One of the problems with performance in this area now is likely simply because the DEFAULT sceneries have not been revised of re-done, probably since FS2004 let alone FSX.

Textures are compressible, and mostly that's already optional. There are utilities to do it using different algorithms. But with compression you need to strike a good balance between loading times and execution times. If disk access lags behind processing speed then it would perhaps be better to keep them compresses. I think a look-ahead algorithm, running in a separate thread (using different cores) would be more productive.

I think pretty much all performance and smoothness improvements has to come from making much better use of newer hardware. That may be where a different type of "loss of backward compatibility" will have the most pronounced effect. You'd force folks to update their PCs to move to P3D5, not so much purchase new versions of all their favourite addons.

Pete

 

19 minutes ago, eslader said:

There are tons of runways out there that are not dead-on level. Just do an image search for "steep runway" for some fun examples. Here's a particularly entertaining one:

In mountain country there are some where you land up-slope to let gravity help you stop, and you take off down-slope so you don't ram into the mountain. It's kind of odd to be bush flying and have every runway be as level as my table saw. 😉

If that suits your type of flying then fine. I fly IFR with jets so they're of no interest to me. Even if the hump was reproduced at EGCC it's unlikely to excite me. But if you're a VFR flyer and enjoy that kind of thing that's fine.

TrueSky https://simul.co/truesky/

 

27 minutes ago, Pete Dowson said:

and

I don't know of any BGL compression. BGLs are programs written in "Bruce's Graphical Language!" devised by FS's originator Bruce Artwick. The language has been much extended to do more and more things over the years, but it is basically a sound design that can do a lot.

Many of the new features remove backward compatibility when used, but the original features don't take up time or processing if not used. So removing that doesn't buy you anything as long as you only add sceneries designed FOR P3D4 or P3D5 using the newer techniques.

One of the problems with performance in this area now is likely simply because the DEFAULT sceneries have not been revised of re-done, probably since FS2004 let alone FSX.

Textures are compressible, and mostly that's already optional. There are utilities to do it using different algorithms. But with compression you need to strike a good balance between loading times and execution times. If disk access lags behind processing speed then it would perhaps be better to keep them compresses. I think a look-ahead algorithm, running in a separate thread (using different cores) would be more productive.

I think pretty much all performance and smoothness improvements has to come from making much better use of newer hardware. That may be where a different type of "loss of backward compatibility" will have the most pronounced effect. You'd force folks to update their PCs to move to P3D5, not so much purchase new versions of all their favourite addons.

Pete

 

That's exactly why I'm holding off getting a new PC, I can just about get by with my system now, the longer I wait the better system I'll be able to buy, I'm probably going to go down the AMD Zen 2 route, along with the 2nd best Nvidia GPU to give me the best Bang for your Buck value and performance.

7 hours ago, Pete Dowson said:

 I think a look-ahead algorithm, running in a separate thread (using different cores) would be more productive.

 

Yes -- this would be huge.  

I'm sure the sim does some of that now, but, I think there could be improvements where the main thread maxes 100%, particularly in areas with lots of autogen objects.   Right now, hitting 100% on the main thread risks a stutter, where, in fact, it would be ideal if that excess were pushed off to another core, rather than WAIT until the overhead is available on the main thread.

I bet it is no simple task though.  When I took my programming classes, there was no internet, and multithreading was that ugly sweater you got for Christmas.

8 minutes ago, Mace said:

When I took my programming classes, there was no internet, and multithreading was that ugly sweater you got for Christmas.

Programming classes? In 1963, when I started, you taught yourself. And I started with 0's and 1's actually making bootstraps on paper tape with a Unipunch (yes, it's as it sounds -- one hole at a time). That was at Leo Computers (LEO = Lyons (bakery) Electronic Office) in North Acton.

Ah, kids today. They don't know what it was like! 😃😉

Pete

P.S. Oh, I do feel old ...

 

55 minutes ago, Pete Dowson said:

P.S. Oh, I do feel old ...

Not old. Experienced !!

Jesse

Forget all the eye candy stuff, like a new graphics engine, terrain engine or sloped runways. I have two much more important suggestions! 

1. The ability to design airports (runways, taxiways, ramps, parking spots) in the sim graphically. Instead of having to use an external program to match the graphic design of a scenery and then having to reload the sim after every change to see what has been implemented.
   This would make both payware and freeware scenery design much faster and more accurate.
    
2. The linking of an aircraft 'title' to the atc_model=, atc_airline=, atc_parking_codes=, atc_type=, wing_span= and correct strobe fx in aircraft.cfg.
   Listing "American Airlines 737-800" in an aircraft title should be enough to drive all of this information from a set list (amendable) in a single source file that comes in the main Prepar3D folder.

 

Everything is far too manual and labour intensive at the moment. We are highly dependent on community updates from people being very generous with their time or spending hours ourselves making minor changes instead of flying.

Can you tell that I'm frustrated with errors and having to change parking spots, other airport information, user and AI aircraft details to get a sim experience that some developers should have gotten right in the beginning? 
 
Rant over. 
 

Edited May 21, 20197 yr by F737NG

11 hours ago, Ray Proudfoot said:

If that suits your type of flying then fine. I fly IFR with jets so they're of no interest to me. Even if the hump was reproduced at EGCC it's unlikely to excite me. But if you're a VFR flyer and enjoy that kind of thing that's fine.

I do most of my flying IFR in jets too. Though the Falcon 50 is one of those jets, and it can easily get in and out of some of those sine-wave runways.

But even though I only dabble in bush/VFR flying occasionally, I absolutely want the people that do it a lot to be happy. It takes all simmer interests to make P3d worthwhile for LM to keep developing it. If all the VFR guys go over to Xplane because, let's be honest, it's pretty good at the VFR game, then that's gonna be a significant chunk of change that isn't going into LM's pockets anymore.

And I've given up entirely on the idea that Xplane will ever be really robust in the kind of flying I like to do, so I'm very supportive of P3d being fun for all flying interests so that it continues to be available for mine.

 

Edited May 21, 20197 yr by eslader

As for taking LM FS to the next level, I would suggest:

Step one would be re-organizing the existing executable into multiple plug-and-play software modules that have a well defined user interface for communicating between them.

Then, work on one module a time (because doing it all in one big-bang approach could take years and get really confusing quick from an engineering perspective).  Separate the render engine, the terrain engine, the atmosphere engine, the flight modeling engine, AI engine, flight dynamics engine, etc. and then work on revamping each of them one step at a time.   Instead of throwing everything away and spending years rebuilding from scratch, it could be done in manageable phases.

But it all starts by carving up the existing MSFS code in modules that can be invoked, inserted, removed, and replaced with minimal impact to other modules.

Mark

 

On 5/20/2019 at 9:08 AM, Ray Proudfoot said:

 64-bit was massive and I don't think we'll ever have such a gigantic improvement again.

So you don't think we'll be saying, "This 128 bit version of P3D is the cat's meow." somewhere around 2030?

On 5/21/2019 at 3:38 AM, Pete Dowson said:

BGLs are programs written in "Bruce's Graphical Language!"

Thanks for the trivia 😄

7 hours ago, MDFlier said:

So you don't think we'll be saying, "This 128 bit version of P3D is the cat's meow." somewhere around 2030?

Do you know how much memory can be utilised by a 64-bit program? Up to 8Tb. I very much doubt we'll get anywhere near that limit in the next 30 years let alone in the next 11.

49 minutes ago, Ray Proudfoot said:

Do you know how much memory can be utilised by a 64-bit program? Up to 8Tb. I very much doubt we'll get anywhere near that limit in the next 30 years let alone in the next 11.

Actually I use in memory databases at work where everything is loaded into RAM for high speed access.

Our test database uses 1Tb to hold just test data while the production servers are using now near 5Tb of RAM.

Regards 

Simbol