[hironside]

 HI ,
 - I just want to know which key to use the keyboard to take screenshots in Freespace 2 SCP??
Thank you in advance for your help, BYE.
                                                                                             

[Jeff Vader]

"Prt Sc" or something like that.

Screenshots are saved in tga format to \freespace2\screenshots\ .

[FreeSpaceFreak]

Or, if you have a French keyboard, "Impr(imer) Écr(an)" or something similar.

[Thaeris]

By the way, why is the SCP still using .tga as an output? .png would be a much better format.

[The E]

Because noone was bothered enough by it to change the code to do png output.

[Zacam]

Well, except for me, but it just keeps slipping around.

[Fury]

I don't see any advantages in changing screenshot dumping from tga to png. With tga you get fast image dumping to a file, with png you get smaller file sizes. From image quality perspective they're the same. I'd rather keep faster dumping and so tga wins. Why the difference in speed? Tga format is simpler than png and png adds compression on top of it. FSO is still single-threaded monster, making the compression really slow. To compensate you'd either have to use lowest compression setting, but then you'd have zero advantages over tga. Or create external multi-thread capable process to handle the image dumping to a file. Sounds like a lot of work for questionable gain. Even with max png compression setting, jpg files would still a lot smaller. So most random screenshots would still be better off as jpg than png, requiring you to convert the screenshots anyway.

[Herra Tohtori]

Well, PNG is more compatible. If you specify compression level 0, the resulting PNG is uncompressed and the image dump should take the same resources depending on overhead, but quick test with GIMP by saving a 512^2 image with zero level compression as PNG, and non-RLE TGA yielded following results:

PNG: 788 373 bytes
TGA: 786 476 bytes

The PNG has a tiny bit more overhead, but difference is negligible. Actually I don't know if the TGA takes more processing to encode as the standard start point is bottom left; don't know what start point PNG generally uses. If the framebuffer info starts from top left, then it might be faster to dump it straight to PNG without need to use bottom left as starting point for TGA compatibility reasons. How does this work, what corner does framebuffer info start from and what corner does PNG use as starting point?


The advantages of PNG are remarkable for compatibility (preview option), although ideally I would offer users option to use legacy TGA and new PNG output. POossibly even option to force compression level for the PNG for those with monster CPU's, although that would, like Fury said, ideally require multi-core support as PNG compression of large files can take quite a while.

But, like said, using PNG with level zero compression (none) wouldn't increase the resources used, so I think that should be the default setting.

[The E]

Framebuffers are filled from top left.

However, for the purposes of dumping the frame to an image, it doesn't matter. In order to do a framedump, the texture is copied, then handed over to the tga encoder, at which point it's immaterial which bytes of the image were generated first.

[Fury]

HerraTohtori, you forget that users are stupid. If png with zero compression would be used, how many screenshots you'd expect end up getting uploaded as-is since users don't know better? At least when they're tga, users have to compress to jpg or png them prior to upload if they want people to view them. If png would be used, you'd have to have at least default compression level (which is afaik 6) to avoid people derping around and uploading screenshots that are practically uncompressed.

[Zacam]

And it's all idle speculation anyway until the actual code is written and available for testing, so rather than just making assumptions as to which is more or less efficient or what have you, let's just leave it at:

It is planned to test whether or not .PNG as a screenshot saving format is a viable option. Considerations for being "viable" are (and this is just my list):

• Must process no slower than the current screenshot saving code (preferable that it removes the "stutter")
• Must do so with accuracy
• Optional: May provide some means to be able to set a level of compression (either in-game or by flag).
  Failing that, the compression levels will be tested against the above two criteria and the one that satisfies them the most wins as the default level.