Compiling without zlib

[svrtgujbhk]

I want to add PhysFS to my project, but there's a conflict: both PhysFS and SFML include zlib. I'd like to compile them both without zlib. How can I do that for SFML? (I'm using Visual Studio 2010.)

[Laurent]

What kind of conflict do you have? It's not included in public headers, and if you link dynamically the linker shouldn't complain about it.

Another solution is to switch to SFML 2, it doesn't depend on zlib anymore.

[Disch]

png support without zlib?  o_O

even libpng uses zlib.

[Laurent]

I don't use libpng

[Disch]

whatever you're using must be using libpng.  I can't imagine anyone* reinventing the wheel in such a horrific fashion.


(*unless bound by license restraints, like Microsoft or something)

[svrtgujbhk]

Atm I'm linking SFML statically (when I finish the code I'll switch to DLL, most likely). PhysFS, the other library that uses zlib, I also link statically. The conflict is caused by multiple definitions of the functions from zlib (they are defined in both libraries).

I want to have static libraries for both SFML and PhysFS that don't include definitions for the zlib functions: I want to statically link zlib.lib myself. How can I remove the zlib fucntion definitions from SFML?

[Laurent]

whatever you're using must be using libpng. I can't imagine anyone* reinventing the wheel in such a horrific fashion.

This guy loves reinventing the wheel.
Single file, no dependency at all, everything's written from scratch. I'm not a huge fan of such things, but as long as it works the same with less dependencies, it's good for me.

How can I remove the zlib fucntion definitions from SFML?

You can't. If you plan to use dynamic libraries in the end, why don't you do it now? That would solve the problem.

[Disch]

That's crazy.  But I guess it's good in a way.  Looking at it reminded me of another issue though....

Is there any way to do custom I/O with resource loading in SFML yet?  I remember asking about it a while ago, and I didn't see anything in the docs.

For instance if I want to load a png from a custom stream or something (and not from a file or memory)

[Laurent]

Is there any way to do custom I/O with resource loading in SFML yet?

Yes, it's easy. Load your pixels and use LoadFromPixels to put them in a sf::Image.

[Disch]

No I mean like....

Let's say I have a png file, but it's in a .zip file.  I have a class that can read the zip and extract the data, but how can I tell SFML to interact with that class?

Same scenario with .ogg or a font, or any other such file.


This is often done with a callback mechanism, or by deriving from an API defined abstract class.

Currently the only way I can see to do it in SFML would be to extract the entire file into memory, then use the load-by-memory functions.  But that's a tremendous waste.

If you're using that link for font/png/ogg loading, I don't see a way to do it with his interface (although I didn't look closely), although his code should be easily modified to accomidate.

Any plans for this?  If I started working on adding such a machanism to that guy's code, would it be implemented?

[Laurent]

There was a plan for an "abstract I/O stream" interface in the past, but it can't be implemented: SFML relies on many different libraries for resource loading, and not all of them support this kind of mechanisms. The common denominator is LoadFromFile and LoadFromMemory.

But:
- sf::Image, sf::Shader and sf::SoundBuffer can be loaded from raw data (resp. LoadFromPixels, LoadFromMemory and LoadFromSamples)
- sf::Font needs the entire font file to be available in RAM while it's being used, so you would end up loading the whole file and calling LoadFromMemory anyway
- only sf::Music could use such an abstract I/O stream interface

So it's definitely not worth implementing.

[Disch]

That's rather disappointing.  Hopefully I can change your mind!

SFML relies on many different libraries for resource loading, and not all of them support this kind of mechanisms

Most should.  It's pretty standard as far as resource loading libs go.  At least from what I've seen.

Unless you have really obscure ones like that one guy who you linked to.  But like I said I would be willing to fill in the gaps there.

Is there some way to get a list of all the libs you're using so that I could look into fixing them adding this functionality to them?  If that functionality existed in the libs, wouldn't you be willing take the time to write a few quick functions to make use of them in SFML?

sf::Image, sf::Shader and sf::SoundBuffer can be loaded from raw data (resp. LoadFromPixels, LoadFromMemory and LoadFromSamples)

Right, but then you can't take advantage of all the file format recognition and loading that SFML provides.  Having to write your own png loader to extract the pixel data so that you can give it to SFML seems kind of silly, wouldn't you agree?

sf::Font needs the entire font file to be available in RAM while it's being used, so you would end up loading the whole file and calling LoadFromMemory anyway

That seems unreasonable.  Especially if you have exceedingly large fonts.  The MS Ariel Unicode font is several dozen (hundred?  I haven't checked lately) MB, most of which will go unused in programs.

Why is there such a limitation here?  What can you do with a memory buffer that you can't do with a seek-and-read interface?



I hope I don't sound like I'm nagging.  I think this is a really important feature for a robust library and I really would like to see it implemented.  Like I said I'm willing to assist by modifying the libs in question to support it.  All you'd really have to do is write a few new LoadFrom functions that wrap around the added interface.

[Laurent]

Most should. It's pretty standard as far as resource loading libs go. At least from what I've seen.

Is there some way to get a list of all the libs you're using so that I could look into fixing them adding this functionality to them?

Here is a summary of the libs and their features:

stb_image (sf::Image)
LoadFromFile and LoadFromMemory

FreeType (sf::Font)
LoadFromFile, LoadFromMemory and LoadFromCustomStream (I haven't looked at the details but it looks ok)

OpenGL (sf::Shader)
LoadFromString, but this one is special (only one format to support, and files are relatively small) and doesn't need to be compatible with the custom stream feature

libsndfile (sf::SoundBuffer & sf::Music)
LoadFromFile and LoadFromVirtualIO (based on custom filelength, seek, read, write and tell functions)

That seems unreasonable. Especially if you have exceedingly large fonts. The MS Ariel Unicode font is several dozen (hundred? I haven't checked lately) MB, most of which will go unused in programs.

Why is there such a limitation here? What can you do with a memory buffer that you can't do with a seek-and-read interface?

I only meant that the source has to be available as long as the font is used, whether it is a file or a custom stream. So I guess it would be compatible with the feature indeed.

I hope I don't sound like I'm nagging. I think this is a really important feature for a robust library and I really would like to see it implemented. Like I said I'm willing to assist by modifying the libs in question to support it. All you'd really have to do is write a few new LoadFrom functions that wrap around the added interface.

Sometimes I don't really have the time to focus on such features and investigate them deeply, so I really appreciate your help.
I have nothing against adding it to SFML, but I must tell you that I'm very picky about design (99% of features are rejected because of design issues, not technical ones), so before you start working on it we should talk about the public API that would result from this feature, and make sure that I'm 100% happy with it

[Disch]

Awesome.  I'm at work now so I can't go over stuff, but when I get home (~11 hrs from now -- freaking commute)  I'll whip up a design idea and run it by you.  I suppose I'll put it in another thread since I've kind of derailed this one.

[Laurent]

I suppose I'll put it in another thread since I've kind of derailed this one.

Yes please