Image saving

[eXpl0it3r]

You could start now, because SFML 3 comes after SFML 2.6 and we don't really need to wait to get the first things started for SFML 3 IMHO.

[Laurent]

SFML 3 comes after SFML 2.6

Really? Who's working on it?

we don't really need to wait to get the first things started for SFML 3

? Nothing is ready for working properly on SFML 3.

[Laurent]

See https://github.com/SFML/SFML/issues/988. It links to a corresponding PR, and a discussion about sf::OutputStream.

[Nexus]

An advantage of adding sf::OutputStream before SFML 3 would be that we might get feedback to improve. If the API is not ideal initially, we're not stuck with it forever.

[eXpl0it3r]

If you want to get anything in before SFML 3, then start working on it, as SFML 2.6 will be the last SFML 2.x release.

I feel like some of you may have missed the planned road map: https://en.sfml-dev.org/forums/index.php?topic=24372.0

[gex]

An advantage of adding sf::OutputStream before SFML 3 would be that we might get feedback to improve. If the API is not ideal initially, we're not stuck with it forever.

I would really love to see that in 2.x (if 2.6 shall be last 2.x release, then in 2.6 ;-) ). At the moment I need to write a tmp file and the read it again for further usage. Obviously that is not ideal.

I don't feel experienced enough in C++ development and SFML in specific to get enganged in neither the discussion regarding implementation and nor in contributing code. However I'd be more than happy to give feedback!

[gex]

Today I solved my issue by using stb_image_write.h in my code in order to save images into memory without use of temporary files. Therefore my urgent need is gone, although I sill think it would be a great addition to SFML if it was possible directly using SFML API.

Again, many thanks for your great work.

[FRex]

And you're linking dynamically, right? Because there is a small issue with using your own STB image and image write along statically linked SFML: https://en.sfml-dev.org/forums/index.php?topic=25011.msg166598

[gex]

And you're linking dynamically, right? Because there is a small issue with using your own STB image and image write along statically linked SFML: https://en.sfml-dev.org/forums/index.php?topic=25011.msg166598

Thank you for the hint. Yes, currently I am linking SFML dynamically and will probably stick to it.

[Ventus]

Before anything, sorry for reviving an old thread like this.

I've implemented a saveToMemory function and it has worked quite well for me.
I've been thinking of making a PR regarding this change, but first I need to know two things:

• Would this be a good idea?
• What syntax should be used for this?

In regards to the syntax, I've written something like:

bool sf::Image::saveToMemory(const std::string& format, std::vector<sf::Uint8>& buffer);

To be used as:

sf::Image image;
//fill the image with data
...
std::vector<sf::Uint8> buffer;
image.saveToMemory("png", buffer);

While this is perfectly functional, I feel like this API is very inconsistent with the rest of SFML. What is the general opinion about passing the buffer as a parameter? Also, should the format be determined using an enum? I'd usually go for that, but I wanted to be at least a bit consistent with the saveToFile API.

[Hapax]

Of your idea of the method proposal, I would say the buffer would go first as the format could have a default.

[Ventus]

Of your idea of the method proposal, I would say the buffer would go first as the format could have a default.

So for now, this is the current syntax:

bool sf::Image::saveToMemory(std::vector<sf::Uint8>& buffer, const std::string& format = "png");

[eXpl0it3r]

One of the issues with any design is, that it would need to be adapted for audio and font as well.

With the current design, one needs to be aware that the buffer can be resized by the save function. It should also be defined what happens with an already allocated buffer and with an over-sized buffer.

Also one thing to consider whether sf::Unit8 is the best binary data representation.

Otherwise, I think it's the most straight forward approach.

[FRex]

Audios yes but why fonts? There's a ton of ways to make an image and a few ways (stitch or mix two buffers, record, create samples programmatically) to make audio but there isn't any font editing/mixing/making in SFML. If you want to 'save' a font to a file in memory just take the file you're using and load it all into memory somehow and that's it there.

[eXpl0it3r]

I thought we had a saveToFile on the font, but we don't, so it's okay to also not have a saveToMemory.