ResourceStream class for custom resource loading

[Disch]

I'm going back and forth with Sean now about some changes to stb_image's API.  So I'll have to revise the files again in a bit.

It will be for the better, though.  Should have some performance increases when loading files, and less demanding requirements for streams.

[Disch]

OK this is with the official release of stb_image.  Now images can be loaded without the stream needing to be rewound.

So a few changes to stb_image.h and ImageLoader.cpp

https://legacy.sfmluploads.org/index.php?page=view_file&file_id=15

Hopefully now it's done for reals.

[Haikarainen]

OK this is with the official release of stb_image.  Now images can be loaded without the stream needing to be rewound.

So a few changes to stb_image.h and ImageLoader.cpp

https://legacy.sfmluploads.org/index.php?page=view_file&file_id=15

Hopefully now it's done for reals.

 Just wanted to say; Congrats on first real use of sfmluploads!

[Disch]

Thanks.  It's great to have an upload site that doesn't suck.  =)

[Laurent]

This feature is now included in SFML 2

[gsaurus]

hm I didn't know about this. That's great

[Disch]

Awesome!

*thumbs up*

[pdinklag]

Yay, it will be a fun challenge to implement resource loading from Java InputStreams.

EDIT:
I wonder what exactly the Seek method is needed for?

[Disch]

Fonts, mostly.  Font files can be huge, and the glyph data is scattered about.  When reading font data it will only want to get data from the glyphs it needs, so it will need to seek around the file to find them.

You could probably leave out seeking in an implementation and music playback and image loading would likely still work fine.  But it depends on the file.

[Laurent]

Reading a resource file is not always sequential, even for musics or images. The loader may have to seek backward or forward to navigate in the file header for example, or to skip useless data, or whatever.

Seek is pretty common in stream classes, in all languages.

[Disch]

I'm a little surprised I didn't notice this earlier... but there's an issue with name continuity.

right now we have Seek() and GetPosition().

Logically, one would expect the inverse of GetPosition to be SetPosition.  Having Seek as the inverse is kind of counter-intuitive.

That said, I find Seek/Tell to be more intuitive for Files/Streams than Get/Set Position.  But really I don't think it matters as long as one style is consistent.

Is it too late to rename one of these?

[Laurent]

Hmm you're right, this is inconsistent. And it's not too late (nothing's too late as long as SFML 2.0 is not released ).

[Laurent]

Done

[gsaurus]

Well, there is an InputStream already. Now what about an OutputStream? It's not unusual that one wants to create/update data and send it through some output stream to add compression/encryption/send through network etc.

Also I think it would be worth adding overloads of operator >> and << to read/write data to/from streams. Those overloads can be easily implemented using the pure virtual Read/Write operations.

To be more consistent, Packet class on the network package may inherit from InputStream and OutputStream, or separate it into two classes (InputPacket, OutputPacket, or something like that). That would fit better what is said about Inputstream being able to be used to read data from the network.

What do you think?

[gsaurus]

Any opinion/comment?  :roll:
The main purpose of InputStream is to read SFML resources from custom streams, so, a way to write them would be as good.
Finally the operators >> & << would provide a good generalization and become in conformance with the purposes of what the current Packet class is.
[/summary]