17 hours ago, ADamiani said:

I just took the liberty of cutting this quotation and sending it to a friend of mine.

On the other hand, I find it interesting that you love organ music and are located in Hammond :-)))))

Andrea

Irony of the first order, that. Although I chose to re-purpose an old Conn Artiste as the basis for my digital pipe organ, because of the similarity to "Con Artist" which my digital organ certainly is. Unless I explicitly tell someone that a recording I've made was generated by a computer's sound card from a Hauptwerk digital sample of a real pipe organ, they cannot tell the difference. 

22 hours ago, SolRayz said:

Not sure why you're getting dips to 6fps at KORD

it happens around the general area, not necessarily at the airport, I get a big studder-fest along the shoreline just north of chicago (there is a golf coarse and a baseball field)

11 hours ago, Noel said:

My question once again:  what is the native resolution of textures used in MSFS and P3D?

That's for MSFS.    But, as above, texture resolution itself doesn't give you the full picture.

Good find.  So the native resolution is less than 4K.  How does that reconcile with this:

   21 hours ago,  kaosfere said: 

This is also why 8k textures can be relevant even on a 4k screen.  You rarely put the whole texture on screen at once, and the denser the portion you do put on screen the better.

Then low resolution textures on a 4k screen will also be relavent in the opposite direction it would seem.

 

9 minutes ago, Noel said:

Good find.  So the native resolution is less than 4K.  How does that reconcile with this:

 

   21 hours ago,  kaosfere said: 

This is also why 8k textures can be relevant even on a 4k screen.  You rarely put the whole texture on screen at once, and the denser the portion you do put on screen the better.

Then low resolution textures on a 4k screen will also be relavent in the opposite direction it would seem.

 

Of course. Look at some textures in the JF Piper or so. If a texture gets stretched beyond it's own resolution it looks blury.

But "native resolution" is not super interesting, I think, when (for example) an ASI DDS file has 1024x1024 pixel. Usually on the screen you fill an area of 1 to 2 inches with it (I took the measure on my 24'' and my 32'' screen 🙂 ). Those screens have a resolution between 90 ppi (smaller 1080p) and 150 ppi (larger 4k) or so. That means that you have to more or less fill your screen with the gauge to see any blur. On the other hand 8k might not be enough for small details on a 747. For that purpose we have those "decals".

And as I said before (in somewhat confusing words): Glass cockpit screens are not filled with pixel graphics but with SVG vector graphics (produced for example by the JavaScript egine, if I am not wrong) and vector text. They always look sharp even in the highest resolution when you put your nose on it.

1 hour ago, Noel said:

Then low resolution textures on a 4k screen will also be relavent in the opposite direction it would seem.

Not necessarily.  Say you are drawing a square on the screen that comes with a 1024*1024 texture, and that the height of this square is half of the screen height.

On a 4k monitor, which has a vertical resolution of 2160px, the rendered square will be 1080 pixels high.  If the texture is mapped in full onto that square, you will be able to render it almost 1:1 (actually, scaling it up by about 5%).  

On the other hand, on a 1080p monitor, the square will have a height of 540 pixels.  This means the texture needs to be scaled down by almost half before it is drawn on the object.  There is an inherent quality loss in that because you're removing 3/4 of the original information.

So even though a 1024*1024 texture is smaller than the resolution of even the 1080p monitor, having the higher resolution on the 4k means that the scaled rendering of the texture in the scene has the possibility of being a higher quality.

(This is simplifying the way textures on 3D graphics are stored and rendered, but it's for the sake of example.  The principles still hold.  And, as @crimplene has noted, the glass cockpits aren't rendered in textures, they make heavy use of vector drawing, and the benefit of higher resolution there is inherent.)

Edited March 22, 20215 yr by kaosfere

I find this topic interesting, so much I feel compelled to add my 2 cents.

@kaosfere is right in his explanations, both monitor and textures. This is very basic digital signal stuff. And actually if you have a 1K monitor you can try it out right now! Just set NVidia DSR to 4x, configure FS2020 to use that resolution, take a screenshot on the 1K monitor. Then disable DSR, reconfigure FS2020 to use your monitor resolution, take a screenshot. Compare the 2.

Sure, past a certain distance you can't discern individual pixels, but this doesn't mean the couple neighboring pixels merging into a single one visually are providing less information to the eyes either. Both source pixels are merging their light information to your eyes. In other words, a black/white pixels pattern is rendering as grey on 4K once looking from farther away because you can't discern individual pixels. They are merging. Said like this, some might be right assuming you can't discern the individual features and there is no need for 4K. Instead, if displaying on 1K monitor, the simulator will just render grey pixels instead. And this is where the logic is wrong, and why it is also important to take into consideration the source data displaying on the monitor is computer generated and different from video materials, with different properties regarding the signal/data resolution. It might not ring a bell to some of you, but there is a signal theory explaining some of the issue with digital sampling (and therefore restitution): https://en.wikipedia.org/wiki/Nyquist_frequency

@ADamiani as for the loudspeakers from 16hz to 30000hz, I believe there is another factor worth taking in account: no loudspeaker is capable to reproducing every single frequency in its entire range at the same level. This kind of loudspeaker is somewhat guaranteeing it can reproduce equal level over the human hearing frequencies instead (to simplify 20-20K).

Edited March 22, 20215 yr by RXP

21 hours ago, SolRayz said:

Hmmm interesting. I loaded the 320Neo with the latest FBW mod at FlyTampa Sydney at interestingly, virtual core 15 is pegged, all others around 20%. I'm not sure what is going on, but I guess this is normal. 

 

This one is raising more questions to me, because when working on my own work-stealing task scheduler about 5 years ago, it was clear to me, both in the literature, and by experimenting, you certainly wouldn't want your task scheduler to peg a thread on the HT pair, but on the CPU core instead. The Intel architecture was giving at the time poorer instruction scheduling if you'd do. There is a reason after all you still find reports FS2020 is running better when you disable HT at the Bios level...

Now what is interesting is that the FS2020 task scheduler seems to use the HT pair on the last core of your CPU. You might want to manually try changing process affinity and compare. I've posted about this a while back already:

https://forums.flightsimulator.com/t/dreadful-performance/130689/1113?u=cptlucky8

More details: https://forums.flightsimulator.com/t/psa-nvidia-has-found-the-root-cause-of-stuttering-and-vr-performance-in-their-drivers/348179/167?u=cptlucky8

 

PS: If you do have for example 8 cores / 16 HT, select 4 cores too but this time every other 2 (i.e. core0, core2, core4, core 6)

 

Edited March 22, 20215 yr by RXP

21 hours ago, kaosfere said:

In the end, you get much the same performance you would if everything were written in C++ and compiled to DLLs as it was in FSX.  The "crazy" performance bottleneck you're asserting simply doesn't exist.

I believe you are right, generally speaking. Furthermore, in having the C++ code converted to byte code for a stack based runtime, there are new optimization opportunities which are not available at a semantic level (not so much different than the optimizations possible thanks to translating to an IL with LLVM).

However, there are also a number of optimizations no longer possible, like these:

- optimizations you'd gain in having a direct access to the data bits, and not to the symbolic representation of these bits. Typical use case is branch-free code, SWAR techniques, data compression to make fitting in a 64 bytes cache line, etc...

- optimizations you'd gain in using pointer arithmetic. Typical use case is when testing access boundaries in the inner loop when otherwise the CPU branch predictor would be mostly wrong.

- optimizations you'd gain in packed arithmetic in order to release the pressure on the register and avoid spilling (very bad in the inner loop).

- optimizations you'd gain in using the hardware to its fullest (actually using what 70% of the CPU transistors are there for, which is SIMD instructions)

 

These are usually found in most "graphics" inner loop code, and they do make a difference in terms of performance (we save some resources in doing so in the RXP products indeed). I believe we're a few 3rd party developers pushing the envelop this far though, but there is no denial without these, you couldn't make the Reality XP WX 500 Weather Radar running entirely on CPU and costing virtually no fps (even back then on FS9 where the best CPUs where core2 duo), nor you could run the A320 simulation (AirlinerXP) update loop, refreshing and displaying 6 EFIS and 2 FMS screens, and simulating the entire set of airbus computers, pipes, valves, electric circuits, fuel systems, with FS2004 running at the same time, in about 5ms (on a core2 duo at the time as well).

I'm honestly not trying to say mine is bigger here, just that the technology has come a long way and WASM is helping a lot, but I'd say WASM code is running in par with JS/HTML performance, but both, by their very nature, are shielding away from some of the most effective to-the-metal optimizations opportunities and these are only attainable with C/C++ (or similar languages) 🙂

PS: just to make it clear, I'm fine with WASM and JS/HTML and this is not the point. There is no problem running the user facing interfaces in these layers and the deeper simulation code in pure C++, in theory. The problem is the SDK is lacking both in terms of inter-process communication and latency/bandwidth guarantees, rendering such techniques non usable as-is, or such optimization opportunities moot.

 

Edited March 22, 20215 yr by RXP

On 3/22/2021 at 3:55 AM, 40track said:

1080p medium settings Vsync 30 fps nuff said till they can restore back proper multithread performance (hopefully). 

Just an addition to this setting Terrain Vector Data off and Texture Resolution low helps. Multithread part im not sure of anymore as its looking like bugs+Vram limitations.

Edited March 23, 20215 yr by 40track

Glad I found this thread; I keep an eye on the MSFS forums for ones just like this one.

I was musing whether or not to take the plunge and finally buy the sim as I've been holding since launch in the naive hope that 7 months down the line everything would have been sorted out.  Judging by all the previous; clearly not so my cash will have to stay in my wallet for a bit longer.

I was also taken aback when I read on another thread that if one buys the sim at this very moment, it doesn't include the updates!

7 minutes ago, ArkRoyal said:

I was also taken aback when I read on another thread that if one buys the sim at this very moment, it doesn't include the updates!

That would only be true if you purchased the DVD version. The DVD was based on the initial release in August. Once the DVDs were made, they were made - they can’t be updated, and they certainly can’t produce new physical DVDs every time a sim update comes out - that would be a logistical nightmare. When the DVD version is initially installed, the first thing it will do when the installer is launched is to download all updates that have come out since August 

If you purchase and download the game online, either from the MS Store or from Steam, you always get the very latest version.

I had many flights after the update, but since yesterday I get 5 fps, even the menu and the world map are unplayable, what happened?
GPU is not used at all, it goes from 15 to 50%, cpu also low usage on all but one core which goes from 80 to 100%

1 hour ago, ArkRoyal said:

I was also taken aback when I read on another thread that if one buys the sim at this very moment, it doesn't include the updates!

Some people spread misinformation on a professional level. 🙂 Glad that we could rectify this.

Yes, I agree, is unpayable, bugs, CTDs, VFR map freezes... Let's demand a refund!