884
edits
Talk:Switching default texture format to DDS: Difference between revisions
Jump to navigation
Jump to search
Talk:Switching default texture format to DDS (view source)
Revision as of 20:24, 6 September 2014
, 6 September 2014no edit summary
No edit summary |
|||
| Line 61: | Line 61: | ||
:: Thus, it would make sense to use a heavily down-stripped test case, such as texturing the ufo this way to exclude other Nasal code from showing up in the profile. Let us know if you need help doing that. Thanks --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:36, 6 September 2014 (UTC) | :: Thus, it would make sense to use a heavily down-stripped test case, such as texturing the ufo this way to exclude other Nasal code from showing up in the profile. Let us know if you need help doing that. Thanks --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:36, 6 September 2014 (UTC) | ||
:::Excuse me, I'd insert the SVG format only as a simple example to understand the flexibility of my proposal. Canvas However I find it fantastic and definitely want to be taken to implement some instruments in the G91 we are doing. The basic concept is to clarify whether this proposal makes sense, and it may be the key to solving the problems of compatibility between formats. My proposal is an attempt to have the maximum flexibility in size of all the graphic objects in FGFs and make compatible the simulation environment of FGFs in any context. At this point I ask the question to those who can develop in C ++ for FGFs, what I'm proposing is practicable? And What I am proposing can solve the problem of non-free formats? --[[User:Abassign|Abassign]] ([[User talk:Abassign|talk]]) 19:29, 6 September 2014 (UTC) | :::I use SVG as well for liveries or instruments, like gooneybird and many others. SVG is a scalable vector based graphics, so we can easily create liveries of different sizes without loss of quality, and compared to GIMP or Photoshop even with much finer quality. That's why I prefer paintkits with SVG over GIMP-paintkits. | ||
:::But we still convert them to PNG for use in FGFS. SVG does not only have layers. Each line, cubes, circles etc. are objects aka elements. The more you have the more computer power it needs, at least when creating a SVG-file. | |||
:::That's my concern about, that a complex SVG-file drawn in FlightGear needs a whole lot of computer ressource - completely independant of the underlying nasal-script or anything else. | |||
:::But it is still an assumption and nothing I could proven yet. | |||
:::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 20:24, 6 September 2014 (UTC) | |||
::::Excuse me, I'd insert the SVG format only as a simple example to understand the flexibility of my proposal. Canvas However I find it fantastic and definitely want to be taken to implement some instruments in the G91 we are doing. The basic concept is to clarify whether this proposal makes sense, and it may be the key to solving the problems of compatibility between formats. My proposal is an attempt to have the maximum flexibility in size of all the graphic objects in FGFs and make compatible the simulation environment of FGFs in any context. At this point I ask the question to those who can develop in C ++ for FGFs, what I'm proposing is practicable? And What I am proposing can solve the problem of non-free formats? --[[User:Abassign|Abassign]] ([[User talk:Abassign|talk]]) 19:29, 6 September 2014 (UTC) | |||
:::::The idea sounds nice, but converting a PNG to DDS or any other format needs already several seconds here on my computer. Looking at the large amount of textures we have and we need of course, it doesn't sound all to practicable to me. But I'm not sure if I understand your proposal correctly. I heard from another developer off-line, that FGFS is already doing something like that. But I'm sure that I have doubts in using SVG for liveries without converting them to PNG before. | |||
:::::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 20:24, 6 September 2014 (UTC) | |||