Potroh

No, not just helis. Regarding the Q400 it is aprox 10% of the dynamic model that is external.

Indeed, a nicely working heli model would be really good. But just as a side-note: there are no existing external flight-models for the premium add-ons. Some of them are modeling a small portion of the flight-model externally (usually engines). Those experiments are far from being a complete external model. It hasn't been done yet and probably won't happen for a long time.

I guess all you need is a better CPU cooler. With my Thermaltake CL-W108-PL12SW-A Water 3.0 RGB 360 cooler, temps are always below 75, running at 4.8

The 7900x performs great because it has 10 cores and its inbuilt "turbo speed" speed is of 4.3GHz, way ahead of the earlier series. The 7900X has 10MB of L2 and 13.75MB of L3 cache for a 23.75MB total. One can disable the cores in Bios one by one and I did that test, with only 4 cores enabled you more or less get the known 4xxx performance. In P3D it made no difference here if I enabled HT, the result was only I had to reduce overclocking due to the excess heat. But the 7900x performs fabulously, I've never experienced such a smooth and stutter-free P3D performance ever...

No shock actually. It's not really wise to straightly compare two CPUs, one with a 4.0 base clock and another with more than double quantity of cores but a 3.3 base-clock. With a good water-cooling gear the 7900X can go much higher and it gives the needed and expected results but not as far as the mere FPS numbers go. I think Rob's original enthusiasm was a bit exaggerated, although I never had his previous CPU, so can't really tell. (He is using 4K, 30 Hz monitor, etc., so the FPS increase may have been significant for him, of course only if the 7900X was significantly overclocked). But the fact remains the same: there's no FPS increase with the 7900X compared to the 4770k and it is also logical, just because of the base-clock difference. The very same thing can be said about the change from a 980Ti to the 1080Ti, as far as FPS goes, there is no change whatsoever, although it is once again a much smoother and better experience but it doesn't IF you measure the FPS and nothing else.

In August I changed my 4770K and bought the 7900X. Had to change the mobo, bought more and better RAM, etc. Also changed my 980Ti to an 1080Ti. If I try to use the new CPU without overclocking (at 3.3) FPS is actually 20-25% lower compared to the 4770K (clocked at 4.5). So I use the 7000X overclocked at 4.7 (with a nice water cooling solution) and I get the EXACT same FPS as I used to with the former setup. I do not use HT, when I try HT, FPS remains the same, smoothness remains the same, only the temp is rising for the cores. BUT: the overall experience is great, the sim (v4) has never been as smooth as it is now. I think the tremendous FPS increase is just a myth in this regard...

When you visit your couple of favorite forums and all have the same interface or software, it just makes things too uniform... At least here in Europe the new interface is more than twice slower.

The new Flytampa KBOS is imminent... :-)

The 60's or 70's sims hardly had any visuals my friend, apart from a plotting-board with a moving camera. I often work on Level-D sims, doing exactly that, trying to upgrade their outdated dynamics data to the proper QTG one - if the client is capable to cover it financially that is. But if you insist that I'm just fooling myself, let it be... That means I know not what I'm doing and those who hire me for good bucks, neither know nothing about their own equipment.

No need for that... The old flight dynamics engine is actually a masterpiece and is still way ahead of anything that one could find for the PC. Even the 10-15 years old multimillion bucks Level-D simulators have less dynamic capabilities compared to this small old one. Of course it only works well if a given aircraft is designed very well... Potroh

Nope. They all are 1024 max.

Rob is right, apart from those special cases this entry should NOT be used. Depending on the system being used, if MaintainSystemCopyOfDeviceTextures is enabled, it can initially eat up 350 MBs of VAS. It's never a bad thing to do some initial and static VAS-tests though, specially if someone is using quite a few add-on dlls. These add-ons can cumulatively eat up a lot of VAS, so one needs to be careful. A very simple (static) VAS test clearly shows how much VAS memory initially allocated to different dlls. Let me just quote a few of these and their initial VAS usage: Using MaintainSystemCopyOfDeviceTextures=1 - 360 MBs FSLabs's Concorde (3 dlls) - 700 MBs PMDG737 - 500 MBs PMDG777 - 400 MBs FSTramp - 300 MBs RAASPro - 120 MBs AccuFeel - 100 MBs UT2 - 100 MBs SODE - 45-50 MBs GSX - 10 MBs These just show the initially allocated VAS, which can grow in flight. Potroh

Not easy to explain without proper pictures, but I do an attempt anyway... Look at these two screenshots: Max is set to 2048 on both pics. One shots depicts the a cloud of 2048x2048 and the other one is 512x512. I simply made colored blobs in place of the clouds, so one can see the scenario better. (As a cumulus01.bmp contains 16 different clouds, all are different in color in the bitmap I made.) This first one is the 2048x2048 texture. You can see that the clouds spread out finely back to the horizon and that their mipmaps are employed quite evenly. The render-engine tries to use as many variations from the same texture as possible. This is 512x512. You can see less clouds, less variation, and because the smaller mipmaps are way too small for the render-engine, they soon become transparent (due to the alpha content that being is similar for both texture sizes). One can also notice that on the clouds in the background there are no "variations" from the same texture, rather it tries to depict (draw) the higher mipmaps and then they face away, simply due to the lack of up-sampling in this case. So up-sampling happens or rather tries to happen, but sizes are too small for the purpose. Hope it's a bit clearer. Potroh

No, they will not always be up-sampled to the max value. The different AA methods do that but not according to the max value defined. (It would take just a couple of minutes or so to test the related difference if the "Application-controlled" and the "Enhance the application setting" or the "Overwrite any application setting" variables are selected in NI for AA would make any difference of how AA up-sampling reaches a max value in this case, but I've never tested that, so simply can't tell...) Potroh

Because they rightly suppose that a wise user will use the same texture size for both the clouds (runways, etc.) as per the max size defined in P3D or FSX. It's always the max value that counts, so in case the user has 2048 max texture size in P3D, then he should use 2048 cumulus coulds, which doesn't mean he can't have the cirrus clouds at a lower resolution, but never higher... Potroh

It's certainly dependent on the the AA type and level. The different AA types use different up-sampling methods, thus the final rendered size could be the result of a few down & up-samplings eventually. Max_texture_size will be the final one depicted. That's why the best is to use the texture-sizes as per the needed final and avoid the additional +- samplings as much as possible... Potroh

First the .dds is the Direct Draw Surface format that DirectX uses. The compressed .bmp is the exact same thing (regardless its header and if you can open them in different programs), they can be dxt-5. They are an inheritance from FS2004. You could make those dxt5 it was just FS9 that couldn't read them. One can read a lot of stuff on how textures are 'pumped' to the video-card, and what the shaders do there by 'clamping' the UV coordinates of the texture. There are two methods, 'sampling' or 'loading' a texture, etc. When there are no mipmaps (as in case of many "advanced" aircraft's external textures) no sampling is done and the full texture is loaded to the pipeline. (That is why un-mipmaped bitmaps - either aircraft or scenery related - can be a serious performance hog in FSX or P3D). When the textures are rightly mipmaped, a 512x512 dxt5 texture takes roughly 0.35 MBs of video memory, whereas a 4096x4096 takes 21 MBs. The 21 MB texture is getting loaded to the board, even if finally either a mipmapped or down-sampled version is displayed (rendered). So filling up the video-memory with 4096 textures is very easy. Upsampling? Usually three up-sampling methods are used: Multi-scale joint bilateral upsampling, accelerated joint bilateral filter and Detail aware texture optimization, but there are more. Whenever you use AA, MSAA, SSAA or SGSAA, etc. textures are getting up-sampled in the pipeline... If you restrict the max texture size defined in P3D, say you employ 1024 as max, but you still have some 4096 textures on the plane or scenery, they automatically get down-sampled to the max size, but ANY usage of the common anti-aliasing methods means up-sampling - at the same time. Potroh

With due respect Pete, I don't think you should compare Microsoft's, DoveTail's or LM's update policy to that of a a single-developer company. Large or larger companies need to be careful with updates, as all updates cost a lot of work for them - at or after the actual update - whereas a single developer (like yourself) can be much more flexible and actually quicker in development. If your own FSUIPC had only annual updates, I guess very few people would continue using it, if at all. If you optimistically looked ahead of an annual update in the fall, FSUIPC would be hardly P3D v2 compatible and users would avoid it as much as they could. I think the same stands for ProAtcX, it can go with its yearly updates and standing bugs, just as long as there's no serious competition. Whereas people can wish for changes or fixes in your forum and their wishes are usually fulfilled in two days, the ProATCX author does even appear in his own forum anymore and leaves the "dirty work" of defending company policy to the beta testers, which is a simple and transparent question of mentality only... Potroh

The logical "trick" is to always use the cloud-sizes EXACTLY the same as defined in P3D as the TEXTURE_MAX_LOAD=xxxx value. (If one uses 2048 as max texture size but has a lot of 4096 textures - either scenery or anything else - those bitmaps need to be down-sampled by the video-card at runtime). Soft-clouds are 512x512 in size so they need to be up-sampled if a higher max value is used. Whereas up-sampling (in some special cases) usually does not cause any performance hit, down-sampling a lot of bitmaps will definitely have its affect, as larger bitmaps take video-memory and good amounts of cycles for the sampling process. That's why it is the best to always stick with the same cloud sizes as the max texture size value being defined.

Try DXtory (http://exkode.com). It is far the best limiter available. It is not free but has a long trial period. Most "serious" gamers swear on it. It's mainly a video and screen grabber, so has neat other features too. One can configure its fps display wherever you want it on the screen and has different colors, transparency, etc.

Hi Rob, Although I've said my good-bye to you here, I write to you one last time. I guess you have read Adam Breed's words "...While this change was not exactly intentional ..." This is what I politely tried to tell you from the beginning. I think that after threatening to "cut me off" - here and elsewhere, and after all of your fuming "liar" sentences, you own me an apology. If you are the true general here, the true leader, you own me that much and to also those who did not really understood the delicacies of the problem, hence felt to be encouraged to continue bashing me and make fun of my humble and pragmatic sentences. A true leader is always strong enough to admit it if the battle was lost. I still admire your efforts towards the community, even if I sometimes do not agree with your points. I have no hard feelings towards you. I do hope it is mutual... Potroh

Well said. That's why I still have the feeling LM did not know that this change to their newer layering system will that badly affect the old one. Adam Breed posted this in the LM forum today: All, We are looking into the issue. We will provide more information shortly. Regards and thanks for the feedback, Adam This is a great news and at the same time it also shows that they were not necessarily aware of the almost global hit, so I happily accept Rob's apology... Many scenery designers would have already complied, the technical part is very easy, most of them had to chose between losing the seasons or having seasons with the old code. Those, who make their own dlls to circumvent the lack of applying conditions in the new LM code, are also aware, that each new dll for this purpose eats up VAS... I started this thread because nobody or just a very few were aware of the the global consequences - including the testers and perhaps LM itself. Potroh

The original statement mentions the SDK. So sceneries should strictly follow the SDK, whereas other products are allowed to use complementary methods? BTW, some of the products you name are only compatible with 3.3 after an update. Many sceneries will be updated too, but because of the huge quantity involved, it's a slightly different and much longer path...

Interesting statement. If PMDG, ASN, GSX, FS2Crew, A2A, ORBX, SODE and a dozen of other - innovative - companies followed JUST the FSX or P3D SDKs, you wouldn't have any of their products. Neither in the past nor today.