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.

No Rob, I didn't miss what Beau said in their forum. What he said is perfectly understandable. Were you, as a tester, aware of this change? Were you aware of it's immediate abrogation to quite many scenery products? The answer is easy: no, you were not, just as usual you asked me to prove the existence of the problem. So if even you were not aware of the consequences, my stipulation saying that it may have been an unintentional change, and the change was not tested against older airports, is still valid. As many users expressed here and elsewhere, LM has been kind and straight forward enough towards the users on the road, so if they knew it will happen with 3.3, they would have definitely warned you, the testers and the users alike. Now that the problem is acknowledged by LM, you try to sail away from the pragmatic issue, mainly by personally attacking myself here. But I admit, this is your territory. If you are happier by not having frank and pragmatic, even speculative discussions on the topic, then let it be. good-bye Potroh

Come on Rob, yes you are a software engineer since WWII, as I'm a designer since WWI, but if I can politely ask you: don't try to teach me in scenery design please... If you know how it's done, yes, if there are five layers, then 5 numbers indeed need to be changed by five clicks. That's why I mentioned a simple "recompile" because writing a forum answer here definitely takes much more time that those 5 clicks + testing. No use to bring individual designers or companies into this discussion. All well versed designers know, that producing a P3D only version is no big deal. As far as the dropping support goes, first the FS2004 ASM compatibility was partially dropped and now the 2002 has followed. I would have understood it at 3.0 but at 3.3 it is a bit strange and doesn't sound as a well thought over decision. Too heavy consequences... It's evening for you in the US, so can't say you woke up with your left foot, so what happens with you? Who is accusing LM or Beau of anything???? Do you really think your moderator or tester status is equal to using the weight of your voice to take every word as an assault or attack, if other round sentences do not meet your expectations or do not match the agenda you try to represent? I understand that you dislike my opinion, but this is not the tone you should ever use as a moderator. You should respect differing opinions and mine have been expressed in a very polite and very pragmatic manner. Cutting me off??? Come on Rob, are you unable to bear this much of non-personal criticism towards a company decision which is not even yours? Potroh

I see Vic what is happening and I do not necessarily like it, until I also see the benefits. Right now (as a user, not as an old-timer developer) I see that my 400+ airports, carefully collected for my full cockpit, will become useless. I do like to go forward and use the polished updates from the first day. So far... But this change makes me stay with 3.2 which is not my actual choice but something being forced on me, in the form of a tiny change, which could have been done more carefully. Mind it please, it's not a major change, it doesn't AT ALL brakes the compatibility with the 2002-SDK stuff, it simply renders it useless. Why didn't LM remove the entire code-part? Because they did not intend to, as yet. They changed something ELSEWHERE and just accidentally turned out it makes a much worse change towards the old stuff. Yes, I understand the necessity to move forward, but this is not the way to do it. Of course the afterclap explanations will focus on the future, simply because something was not done carefully and not tested carefully. The average user will always take and digest the slogans and afterthought explanations aiming towards the glorious future, but myself being an old-time FS developer have seen more to be as innocent as that... So to answer your sentence, I do see what is happening but don't necessarily like it... The "little steps" concept is acceptable, understandable, but this one is anything but a little step. It's an unnecessary large move at the moment, which creates a huge gap and leaves admirable (scenery) corpses behind... It's not nice to talk about his/her future (reincarnation or resurrection) of the beloved one - in a farewell speech. Potroh