Can we make RenderStates and Drawable loadable resources?

[Critkeeper]

Texture and Shader are already both loadable members of RenderStates

It would be fairly trivial to store and load BlendMode and Transform, given how simplistic they are.

And that would allow us to make RenderStates a loadable resource.



If we also made Drawable a loadable resource then resource management would become so much simpler for the client. You could load up a drawable and renderStates and just tell the renderWindow to draw it.

idk, just seems like it would be easier to use for me personally. That doesn't mean its the right way to go, but I'm interested in hearing your thoughts.

[Nexus]

Use cases?

[Jesper Juhl]

If you need it can't you just serialize/deserialize it yourself? Why would it be a major win for the library to implement that for you (and other users)?

[Critkeeper]

Well for example, suppose you want to be able to persistently change the texture coordinates for a vertexArray without having to recompile your code. If vertexArray were a loadable resource, you could just change the data in that resource. This means you can change not only the textures of your entities in your compiled and shipped application through data, but also their shape.

You can change the texture coordinates of all the vertices in the vertexArray to point to something else in the same texture map, like a new skin for your character or object or GUI or whatever. Again, you could even change the shape and all other vertex qualities. You would want this information to persist. If the resource is savable/loadable you could easily make it persist without any trouble at all.

[GraphicsWhale]

There is no standard human-readable text format for such information that I'm aware of, but writing your own parser for vertex information and resource paths is trivial. std::fstream, std::stringstream and std::string should be all you need.

[Critkeeper]

No information in a computer is readable without some kind of editor or viewer. A text editor. A graphics editor. A vertex editor.

A vertex parser would be trivial, and so would the rest of what I suggest. A sprite class is also trivial if all its components have already been implemented, so why make a sprite class a part of the library? Because it makes the library easier to use and the cost of adding it is not high in terms of added complexity or time.

My question is why not make my suggestion a part of the library? It makes skinning GUI and characters easier, and it makes a few other tricks easier too, like loading animation sequences (sequences of changes in vertex and texture information)

[GraphicsWhale]

No information in a computer is readable without some kind of editor or viewer. A text editor. A graphics editor. A vertex editor.

A vertex parser would be trivial, and so would the rest of what I suggest. A sprite class is also trivial if all its components have already been implemented, so why make a sprite class a part of the library? Because it makes the library easier to use and the cost of adding it is not high in terms of added complexity or time.

My question is why not make my suggestion a part of the library? It makes skinning GUI and characters easier, and it makes a few other tricks easier too, like loading animation sequences (sequences of changes in vertex and texture information)

Have you considered using a scripting language for doing that? It would add the ability to do more complex graphical effects (beyond simply changing textures and shapes) that can be programmed in while maintaining ease-of-use and editing on the fly.

[Jesper Juhl]

My question is why not make my suggestion a part of the library? It makes skinning GUI and characters easier, and it makes a few other tricks easier too, like loading animation sequences (sequences of changes in vertex and texture information)

Sounds to me like you want to turn SFML into a higher-level library than it is.
SFML is a low-level multimedia library. It is not a game engine or boost or whatever else would provide highlevel constructs. It provides basic lowlevel building blocks - you build the rest.
At least, that's my take on it.

[Critkeeper]

How the heck is loading and storing an array of vertex information high level?

I mean c'mon.

Stop trying to come up with fake reasons and give me a real reason. "SFML is low level" is just a one size fits all cop-out response to any suggestion.

I value the simplicity of SFML and I value its utility. You have to balance these two things carefully. Too much utility and your library will be bloated and complicated. Too much simplicity and people will just write everything themselves because your library doesn't provide the necessary utilities to be convenient.

Its a matter of convenience. Loading and storing vertex information and render state information would be convenient.

[Jesper Juhl]

It's serialization of a datastructure.
That has nothing to do with the lowlevel "handle media" responsabillity that SFML has taken on.

[Critkeeper]

Oh really? because it looks an awful lot to me like a texture is just an array of color information. And you can load and store textures, therefore you are loading and storing arrays of color information.

VertexArray is hardly any different than ColorArray (ergo, texture) from a fundamental point of view.

Why not make it easier on the client by allowing them to load and store arrays of vertex information?


How usable would SFML be if the ability to load and store textures were taken away, and you had to do it per pixel? People would just end up writing their own load and store methods. Its the same exact thing with vertexes.

[eXpl0it3r]

As was already said, there's no common file formats, as such we would have to create our own format, which is definitely not what SFML is made for. We provide texture loading because there are common formats and because these formats are the standard way to provide image information, as such everyone would have to write the same code.

As for your request, you're the first one that wants a SFML specific format that can be loaded, as such neither the format nor the use case is common and thus such a feature would be specific to your code.

All the rest has been said above.

[Critkeeper]

As was already said, there's no common file formats, as such we would have to create our own format, which is definitely not what SFML is made for.

http://en.wikipedia.org/wiki/OpenCTM

We provide texture loading because there are common formats and because these formats are the standard way to provide image information, as such everyone would have to write the same code.

It looks to me like there is a bunch of different texture formats that people use, including and not limited to .png, .bmp, .jpg  etc. They don't just provide different behaviour, they are different formats.

So pick a few widely used 3d mesh formats, and treat 2d triangle soup as a 3d mesh with zeroed out third dimension.

Collada is another format you could use.

[shadowmouse]

That isn't particularly appropriate as that is all about 3d vertex arrays. Would that not be the equivalent of loading a texture from a 3d model?

[Critkeeper]

No, you would obviously zero out one of the dimensions of the mesh so that it is just a 2d connected triangle soup.