Talk:Switching default texture format to DDS: Difference between revisions

}}

At the end of it all, I have always found problems when I used proprietary formats for my programming work. Consider the case of Java, a language with which development every day, when Sun was a lot of promises on possibility to open Java development, but when became property of Oracle all Java technology become closed source. Fortunately, common sense prevailed and was made the open version that I use daily as 90% of the developers. I think the best thing is not to generate constraints, but make our environment "flexible", ie that it can use either format, depending on the constraints present in a given country. I do not like to think that a user embargoed, such as an Iranian person, FGFS can not use because the DDS is part of a proprietary technology which can be banned for export.<BR>In my work it is normal to try to make the system flexible. In this case I think it is better to write a few hundred lines of code in more and introduce a scheme like the one I included in the diagram:

[[File:Automatic format convert 01.jpg|thumb|800px|DDS-PNG-JPG Automatic format convert]]

The idea is simple, you can use various formats, such as SVG which is also very useful for liveries, when the format is read a process transforms it into the format you want to use for your graphics card, such as the DDS , PNG or S3TC, the transformation could also use an appropriate pixel density as a function of monitor used! The everything is sent to a cache that can only be in RAM or, as I often do, mixed RAM-HD according to the type of use. This approach allows to minimize the load of conversion and at the same time allows to have the images already ready for use. Normally a pilot flies in areas fairly restricted and then the cache may already contain all what interests him limiting in this way the load of the CPU. An index, if the cache is mixed RAM-HD can handle various things, such as whether a file has been updated and then redoing the conversion, manage LIFO etc ... This seems like a solution is not too complicated, but extremely flexible, which separates the authors of the texture from the problems of format and its licenses. When the cache is stabilized, the CPU load is very small compared with its other activities. Fact that I have always occurred when I implemented these features in Java. --[[User:Abassign|Abassign]] ([[User talk:Abassign|talk]]) 09:11, 6 September 2014 (UTC)