Hi Emilian, On Sunday, January 15, 2012 14:33:40 Emilian Huminiuc wrote: > There are a couple of isue with that though. Biggest one is it will increase > disk/RAM usage by at least 4 times, if not 8 depending on > texture/compression method used. That basicaly negates all the advantages > of the dds format, except for the embeded mipmaps. > > Is that acceptable? I remember some complaints about base package size > increase, and also repository size increase. > > btw: Tools for dealing with any of the dds compression formats, and access > to them is freely available under the MIT licence. > http://code.google.com/p/nvidia-texture-tools/ [...] > I believe the numbers are a bit reversed here, and the vast majority of > users has no issues with displaying these textures. But I agree there's an > issue with (un)available support for these extensions in the OSS drivers > (be they nvidia/intel/ati).
Counting the developers machines this is probably true. And exactly this is the reason for the message. If your machine would refuse to display this you, developing that, would probably just say 'nice try, but it does not work' before you check in something. In the case it displays fine, you probably say 'it works here, so I assume it works also for others, lets do'. And the message tells you, 'despite of just seeing this working on this current machine, it does not work for others'. Seriously, I think plenty people not being on this list today and probably never will be in touch with anybody here, will run into this issue. People here are those few guys from the power users that want to develop this stuff. I am not going to discuss the patent stuff. Please search the mesa-dev archives for the discussion and see there why they think that the nvidia tools and other stuff out there cannot be used. Really - it is not that the code for that is too dificult or unavailable. I am not a lawyer and I cannot change this world - even if I would like to in this regard. I agree that techically for drivers/gpus supporting these compression formats it would be best to use these precompressed files. Doing that differently will provide some overhead that could be kept at a minimum I think: For the disk usage, I think gzip compressing these will work sufficiently fine. Ram usage of the images should not hurt too much. Sure the images are bigger in memory. But fgfs is not just about images - far from that. On the GPU, you can still use compression for the textures as the internal format. This is what flightgear tries to do if the extension is supported (checked by osg). The major point is that there are several ways that use slightly more resources to get around this problem. But once the patented compression is on disk, there is *no* way back for people not having this feature. If you have better ideas that do not rule out intel and the oss drivers, you are welcome! Greetings Mathias ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
