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

Jump to navigation Jump to search
svg for liveries - hmmmm....
(svg for liveries - hmmmm....)
Line 48: Line 48:
[[File:Automatic format convert 01.jpg|thumb|800px|DDS-PNG-JPG Automatic format convert]]
[[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)
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)
:about svg usefull for liveries: I'm not sure about. Of course, with canvas it would allow for new features (and I have many ideas, what can be done with... ;-)).
:But svg-files aren't that cheap like a simple bitmap. I fear the more objects a svg-file has, the more computer ressource it will need. And a detailed livery will need a lot of objects. With canvas I already see a decrease of fps, and I'm not sure that only non-optimized nasal-scripts are the reason for.
:But for .png and .jpg -files your approach sounds good, and I'm not sure if even X-Plane already uses this approach.
:Cheers
:--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 10:30, 6 September 2014 (UTC)
884

edits

Navigation menu