What is graphic format better to use?

As with any other image format, Construct still converts imported DDS images to PNG, and fully decompresses them in VRAM. Also, I'm not convinced DDS stays compressed in video memory because I thought it's impossible to read from compressed formats efficiently on the GPU - is there documentation somewhere which says it really does do that? However, it might be able to upload to the video card in DDS format, which could slightly improve load times but have a larger filesize (but Construct doesn't support DDS yet anyway).

I'm not convinced DDS stays compressed in video memory because I thought it's impossible to read from compressed formats efficiently on the GPU - is there documentation somewhere which says it really does do that?

It stays compressed in VRAM and decompressed is made on the fly because the hardware has specific native support for the DXTn compression formats.

To reduce the amount of memory consumed by textures, Direct3D supports the compression of texture surfaces. Some Direct3D devices support compressed texture surfaces natively. On such devices, when you have created a compressed surface and loaded the data into it, the surface can be used in Direct3D like any other texture surface. Direct3D handles decompression when the texture is mapped to a 3D object.

Documentation on the MSDN:

http://msdn.microsoft.com/en-us/library/bb204843(VS.85).aspx

http://msdn.microsoft.com/en-us/library/bb204842(VS.85).aspx

http://msdn.microsoft.com/en-us/library/bb206307(VS.85).aspx

DXT compression isn't loss-less, but if it were possible to add the support to either use loss-less PNG or lossy DXTn for an specific texture and use it when needed, it'd definately be a great improvement over the current VRAM usage.

Links look to be out of date. Also the quote says some devices, so if only higher end cards can use it whats the point?

Links look to be out of date. Also the quote says some devices, so if only higher end cards can use it whats the point?

The links just didn't parse properly, the url with the whols .aspx works fine.

And if this has been around since DX6 then I would assume most cards nowadays can run it?

I'm pretty sure all (or nearly all) DX9 compliant cards are capable of using compressed textures. And if that wasn't the case, I'm pretty sure the drivers should have fallback mechanisms to send the texture uncompressed. It's all a matter of checking it out.

First question:

I've had one experiment.

I created two cap files. In the first scene I loaded sprite animation (21 frames, PNG format, sprite size is 96x104), see screenshot.

In the second file I loaded the same animation, but in DDS format (21 frames, DDS format, sprite size is 96x104), see screenshot.

As you can see there is no difference in FPS and VRAM. However, quality of sprites has a bit changed and CAP file size became 2 times smaller.

Tell me, why have you written that Construct doesn't support DDS if the program displays it properly?

Here you can download cap files with animation in PNG and DDS and see for yourself.

PNG Cap: http://www.fileqube.com/shared/qVfpJe1492384

DDS Cap: http://www.fileqube.com/shared/HPHfYCznk1492377

PNG I converted to DDS using special GIMP plugin.

Second question:

For example, I have the sprite 500x500 pixels and its file size 100 kb, and I have another sprite 512x512 and its file size 120 kb... to achieve a maximum perfomance I need to use 500x500 or 512x512? Or is there no difference except file size? What is better to use?

As stated, DDS isn't supported.

The two textures will likely use the same VRAM, as the 500x500 will occupy a 512x512 texture.

Does anybody know how to reduce PNG file size not changing its resolution?

GIMP maximally compresses png file to a certain size, but is there another programm which much more compresses png?

You don't quite understand. Construct immediately converts any image you import to the image editor in to PNG format, using its own PNG encoder. If you import a PNG file it is decompressed then recompressed using Construct's PNG encoder. If you import a PNG file that has been run through PNGCrush it is decompressed and encoded as a (probably larger) PNG file. If you import a DDS file, it is decompressed and converted to PNG etc. etc. etc. By the time you click run, everything has been converted to a PNG file and the runtime decompresses that on startup, so currently, the image format you use makes no difference at all to VRAM usage or how fast it runs, except that if you use a lossy format like DDS, you lose image quality - no gains, only loss.

When we come to make Construct 2, though, we will use external project images and the format won't be changed. So you can use DDS, jpeg, whatever is supported. That's a long way off though.

Also, frankly I think the DDS compression looks crap! Why would anyone want that?

Ashley, Thank you for detail explanation!