SFML community forums

General => Feature requests => Topic started by: Critkeeper on May 27, 2015, 08:06:46 pm

Title: Can we make RenderStates and Drawable loadable resources?
Post by: Critkeeper on May 27, 2015, 08:06:46 pm
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.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Nexus on May 27, 2015, 08:08:12 pm
Use cases?
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Jesper Juhl on May 27, 2015, 08:10:30 pm
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)?
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Critkeeper on May 27, 2015, 08:16:16 pm
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.

Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: GraphicsWhale on May 27, 2015, 08:54:11 pm
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.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Critkeeper on May 27, 2015, 09:07:29 pm
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)
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: GraphicsWhale on May 27, 2015, 09:34:56 pm
Quote from: Critkeeper on May 27, 2015, 09:07:29 pm
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.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Jesper Juhl on May 27, 2015, 09:35:03 pm
Quote from: Critkeeper on May 27, 2015, 09:07:29 pm
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.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Critkeeper on May 27, 2015, 09:36:34 pm
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.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Jesper Juhl on May 27, 2015, 09:39:10 pm
It's serialization of a datastructure.
That has nothing to do with the lowlevel "handle media" responsabillity that SFML has taken on.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Critkeeper on May 27, 2015, 09:45:33 pm
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.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: eXpl0it3r on May 27, 2015, 09:55:35 pm
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.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Critkeeper on May 27, 2015, 10:00:03 pm
Quote from: eXpl0it3r on May 27, 2015, 09:55:35 pm
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

Quote from: eXpl0it3r on May 27, 2015, 09:55:35 pm
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.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: shadowmouse on May 27, 2015, 10:04:19 pm
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?
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Critkeeper on May 27, 2015, 10:05:13 pm
No, you would obviously zero out one of the dimensions of the mesh so that it is just a 2d connected triangle soup.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: therocode on May 27, 2015, 10:17:56 pm
How does being able to load collada and other such 3D vertex formats benefit the common use cases for a multimedia library?

The use case you stated was really contrived and complicated and I can't see that arise in even 1 out of 100 applications. You'll have to describe a more real-world general use case which actually sounds attractive to other people than your own very specific usage. Until you do that you'll not manage to convince anyone.

Also, saying "why not adding it?" is not a valid argument. Things are added for proper reasons, not lack of counter arguments. The burden of proof, so to say, is on you.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Nexus on May 27, 2015, 10:20:23 pm
I completely agree with therocode; it doesn't seem like your use case is a limitation that you actually encountered while writing an SFML application ;)

Please read also the points listed in the "Scope" paragraph here (http://www.sfml-dev.org/contribute.php#general-considerations). Most of those points apply to your feature request.
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: GraphicsWhale on May 28, 2015, 01:12:30 am
Using a 3D format to support 2D geometry is a terrible idea.

3D formats exist because 3D is notably more difficult than 2D, and unless you're creating a voxel engine it would be extremely difficult to create 3D models without some sort of modeling software. And of course, you need a specified format that your modeling software supports and a parser is available for it. Hence such a formats' existence.

2D almost never needs such a system. Pretty much any problem from rendering to collision can be handled without resorting to detailed geometry files. Which would greatly explain why such a format doesn't even exist.

SFML is fairly high level, and mostly is for taking away complexity where it doesn't benefit the developer (such as dealing with OpenGL, OpenAL, the native API, etc), but assumes you can handle everything that is irrelevant to it's libraries (system, sound, graphics, networking, etc). Parsing non-standard formats is one of those things.

You might want to parse X format, the next guy Y format, but we can't parse everything in existence. What SFML can do is utilize formats like PNG and WAV because they're ubiquitous. And A 3D format not utilized properly is still considered, at least by me, to be non-standard.

But I still don't know why you want to do this. If you want your game easily editable, do like I said and just use a scripting language, and if you want to simplify modding/development even more, have your engine work out the exact vertex coordinates on it's own.

After all, wouldn't:

draw.lua
local shader = graphics.getShader("shaders/custombutton.vert", "shaders/custombutton.frag")
function drawButton(button)
    graphics.useShader(shader)
    graphics.setTexture(button_texture)
    graphics.drawRectangle(button:getX(), button:getY(), button:getWidth(), button:getHeight())
end
 

Be easier to edit AND a lot more flexible than this?

button_vertices.obj
v 0.0, 0.0, 0.0
v 0.0, 1.0, 0.0
v 1.0, 0.0, 0.0
v 1.0, 0.0, 0.0
v 0.0, 1.0, 0.0
v 1.0, 1.0, 0.0
t 0.0, 0.0, 0.0
t 0.0, 1.0, 0.0
t 1.0, 0.0, 0.0
t 1.0, 0.0, 0.0
t 0.0, 1.0, 0.0
t 1.0, 1.0, 0.0
 

button_draw_details.txt
vertex_shader=shaders/custombutton.vert
fragment_shader=shaders/custombutton.frag
 
Title: Re: Can we make RenderStates and Drawable loadable resources?
Post by: Mario on May 28, 2015, 02:18:57 pm
If you want to load sf::VertexArray from a file, there'd indeed be some file format to use: SVG. However, implementing and loading would be another thing (and it can get complicated).

I agree, it would be cool being able to load vector graphics from files you can just edit in some editor (like Inkscape), but unfortunately it's a rather complex topic. :)

Doing so for 3D formats would make things even more complicated without any real gain.