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

Author Topic: Output streams  (Read 4840 times)

0 Members and 1 Guest are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Output streams
« on: November 01, 2015, 04:31:33 pm »
Out of this GitHub discussion, the idea of output streams -- which has been around already for a longer time -- has been revived.

Basically, the idea is to have a class with the following synopsis, which acts as a counterpart to sf::InputStream and can be used to save resources to custom destinations -- files, memory buffers, archives, network sockets, ...
class OutputStream
{
    virtual ~OutputStream();

    // return if successful (or should it be bytes written and -1 on error?)
    virtual bool write(const void* data, Int64 size) = 0;
};


Now, Laurent and I have discussed a bit about the semantics of the write() function. Here's a summary:
Quote from: Laurent
We should be consistent with sf::InputStream [i.e. return the bytes written, or -1 on errors].
Quote from: Nexus
What would the caller of write() (within SFML) do if not all bytes have been written? Call the function again with the rest of the buffer?
Quote from: Laurent
That. For example, we can imagine a buffered stream that rejects data if there's no more room in its internal buffer (concrete example: a stream that wraps a TCP socket).

But that means that every place that calls OutputStream::write() must be prepared to handle that (or we write some kind of abstraction). And does it make sense to just call the function immediately again, i.e. in a loop? If an output stream fails to process all bytes at once, why would it be able to do so one microsecond later? Or how can the call site meaningfully determine how to react in such cases?

I'm just thinking that if this bytes written return value exists purely for buffering purposes, it had better be implemented within the concrete `OutputStream` implementation itself, which knows the specific scenario (ideal buffer size, how to handle errors, etc.)

Maybe I'm also just thinking of the wrong use cases :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

BurningEnlightenment

  • Guest
Re: Output streams
« Reply #1 on: November 02, 2015, 08:17:02 pm »
Why yet another stream library? Why don't you simply use stl streams? They offer clear semantics, are battle tested and you can easily add new backends by implementing streambuf. So what is this feature needed for?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Output streams
« Reply #2 on: November 02, 2015, 08:36:18 pm »
Quote
Why don't you simply use stl streams?
Standard streams will be good candidates for replacing all this stuff in SFML 3, but until then we need a counterpart to sf::InputStream to keep the API consistent.

Quote
you can easily add new backends by implementing streambuf
I wouldn't say "easily"... and that's the reason why standard streams were not chosen in the first place. Even boost has to provide a simpler interface with its boost.iostream library.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Output streams
« Reply #3 on: November 29, 2015, 05:46:03 pm »
Any further considerations for the API of sf::OutputStream?
Should I start implementing it soon?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Re: Output streams
« Reply #4 on: November 29, 2015, 06:12:54 pm »
Seems good to me, so an implementation could be provided, which will probably bring up further discussion points.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Kori

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Output streams
« Reply #5 on: December 26, 2015, 09:43:58 pm »
I probably shouldn't post here (feel like mosquito between tigers), please delete this post after some time to keep topic clean, but imo Output stream is one of the most needed feature in sfml. It can be nice to have possibility of easy save edited in game texture,  however i think mostly about save states, especially on mobile devices. I personally spend over one month trying to make save function on android, using almost every tools in range (including editing whole library, to extract ANativeActivity <to get internal path> into main function). I really hope, that they will be available in near feature.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Output streams
« Reply #6 on: December 27, 2015, 11:10:16 am »
Of course you should post here, we're glad about all kinds of feedback.

If such an output stream is implemented, its main purpose will be to save SFML resources (like sf::Image or sf::SoundBuffer) to a sink (file, network, archive, ...), not user-defined data. It is of course possible to use it for your own stuff, but you still have to implement the sink, so I'm not sure if this is the way you imagine.

About the Android native activity, it's being exposed. Next time, you should probably reseach a bit and ask for help before spending more than one month ;)

If there's a specific problem with saving/loading regarding the Android APIs, you should open a new thread or continue the discussion here. The sf::OutputStream class will remain a platform-independent interface.
« Last Edit: December 27, 2015, 11:14:09 am by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: