Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Image saving  (Read 26630 times)

0 Members and 1 Guest are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Image saving
« Reply #15 on: January 14, 2019, 12:18:52 pm »
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. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Image saving
« Reply #16 on: January 14, 2019, 01:04:27 pm »
Quote
SFML 3 comes after SFML 2.6
Really? Who's working on it? :P

Quote
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 Gomila - SFML developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Image saving
« Reply #17 on: January 15, 2019, 01:37:17 pm »
See https://github.com/SFML/SFML/issues/988. It links to a corresponding PR, and a discussion about sf::OutputStream.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Image saving
« Reply #18 on: February 11, 2019, 08:26:40 am »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Image saving
« Reply #19 on: February 11, 2019, 03:40:47 pm »
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 :D
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

gex

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Image saving
« Reply #20 on: February 11, 2019, 07:06:30 pm »
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

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Image saving
« Reply #21 on: February 15, 2019, 02:56:44 pm »
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

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Image saving
« Reply #22 on: February 15, 2019, 03:28:12 pm »
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
Back to C++ gamedev with SFML in May 2023

gex

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Image saving
« Reply #23 on: February 15, 2019, 04:18:08 pm »
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

  • Newbie
  • *
  • Posts: 22
    • View Profile
    • Email
Re: Image saving
« Reply #24 on: June 28, 2019, 08:33:40 pm »
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.
« Last Edit: July 01, 2019, 11:56:51 pm by Ventus »
King Crimson

Hapax

  • Hero Member
  • *****
  • Posts: 3346
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Image saving
« Reply #25 on: June 28, 2019, 10:13:27 pm »
Of your idea of the method proposal, I would say the buffer would go first as the format could have a default.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

Ventus

  • Newbie
  • *
  • Posts: 22
    • View Profile
    • Email
Re: Image saving
« Reply #26 on: July 01, 2019, 09:43:33 pm »
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");
« Last Edit: July 01, 2019, 11:57:02 pm by Ventus »
King Crimson

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Image saving
« Reply #27 on: July 02, 2019, 12:44:19 am »
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Image saving
« Reply #28 on: July 02, 2019, 02:42:03 am »
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.
Back to C++ gamedev with SFML in May 2023

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Image saving
« Reply #29 on: July 02, 2019, 07:09:32 am »
I thought we had a saveToFile on the font, but we don't, so it's okay to also not have a saveToMemory. :)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/