SFML 3 - What is your vision?

[therocode]

Support texture packer.

The other week I tried using texture packer but it is not a free product. You have to pay to use it and the trial version makes some sprites red with the text "trial version" on them. IMO SFML which is a free library should not integrate with non-free products.

[Deathbeam]

I think SpriteBatch would be great addition for SFML 3 and it is even not that hard to do.

[eXpl0it3r]

It's nice seeing all this feedback, rest assure we'll be discussing most of the points and some have already been kind of agreed on before this thread started.

As for sprite batching, you suggest it as addition to the normal sprite rendering, but is there any advantage not to batch all sprites or what's the difference between batching and non-batching?

[Deathbeam]

It's nice seeing all this feedback, rest assure we'll be discussing most of the points and some have already been kind of agreed on before this thread started.

As for sprite batching, you suggest it as addition to the normal sprite rendering, but is there any advantage not to batch all sprites or what's the difference between batching and non-batching?

You can sort them, pass same values easily to large group of sprites (for example, when user do not want to use views becouse it is corrupting drawing of his GUI - yep that is my case - you can do it like XNA, and so passing camera with transformation matrix to sprite batch), pass blending to large group of sprites easily and so. Imo, sprite batch is better for bigger projects, and for small ones, it is better to use normal rendering (becouse it is pointless to create new spritebatch f.e. for 2 sprites). Look for example at my implementation of SpriteBatch to my engine. It is working exactly like drawing sprites to RenderWindow, you can pass there IDrawable (for example Sprite) and spritebatch will enqueue it. It is highly modified version of krzat´s spritebatch https://bitbucket.org/krzat/sfml.utils/src/ce2ec1656e13424141b23583b495197b60bd2fcf/SpriteBatch.cs?at=master

P.S Sorry for my english

[eXpl0it3r]

Isn't that mixing two different concepts? What has been discussed here before was sprite batching as in making something like a vertex array more automated/accessible. While what you describe sounds more like a node system. Is that the same?

(for example, when user do not want to use views becouse it is corrupting drawing of his GUI - yep that is my case - you can do it like XNA, and so passing camera with transformation matrix to sprite batch)

Sounds like you didn't understand how to use views properly. You can use multiple views to render things independently without "corrupting drawing", unless you meant something else.

[Deathbeam]

Isn't that mixing two different concepts? What has been discussed here before was sprite batching as in making something like a vertex array more automated/accessible. While what you describe sounds more like a node system. Is that the same?

(for example, when user do not want to use views becouse it is corrupting drawing of his GUI - yep that is my case - you can do it like XNA, and so passing camera with transformation matrix to sprite batch)

Sounds like you didn't understand how to use views properly. You can use multiple views to render things independently without "corrupting drawing", unless you meant something else.

I think it isn´t mixing different concepts. You can imagine SpriteBatch like another drawable (your example with VertexArray is perfect). Some pseudo-codes
You can use (for single sprite)

Code: [Select]

RenderWindow.Draw(Sprite);
For multiple sprites:

Code: [Select]

SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);

And for sorting and other fancy stuff you can overhaul Begin (or End, idk where it belong better, for demonstration, let´s say begin)

Code: [Select]

SpriteBatch.Begin(Sort.Inverse, TransformMatrix, Blending.Add)

And for views, I mean using for example

Code: [Select]

RenderWindow.SetView()
For scaling, zooming, moving entire screen. And I do not want to create new render textures just for using 2 different views. Correct me if I do not got views functionality correctly.

[Haze]

One feature I would love to see added in the Graphics module is rendering masks, especially texture-based masks.
There's already a task in the tracker: issue #1 - Implement rendering masks
I understand this is something quite big but it's been 3 years already, and some user has already proposed a working implementation. Please see this post, you can see in the screenshots what kind of neat tricks you can achieve with this feature.

[Jebbs]

As for sprite batching, you suggest it as addition to the normal sprite rendering, but is there any advantage not to batch all sprites or dwhat's the difference between batching and non-batching?

A sprite batch is just a way to reduce the number of draw call for things that use the same texture.

This code for example:

Code: [Select]

SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);


If all of those sprites used the same texture, it would essentially create a vertex array and then draw everything with one draw call internally.

[Deathbeam]

A sprite batch is just a way to reduce the number of draw call for things that use the same texture.

This code for example:

Code: [Select]

SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);


If all of those sprites used the same texture, it would essentially create a vertex array and then draw everything with one draw call internally.

For such thing, you can simply create vertex array. If I would wanna use spritebatches only for drawing sprites with same texture, I wouldn´t use them. Yes, spritebatch should reduce draw calls, but imo efficient spritebatch reduces it to number of different textures what are added to it. Example directly copied from SpriteBatch in my engine:

Code: [Select]

                ////////////////////////////////////////////////////////////
/// <summary>
/// Draws all queued sprites for this vertex batch. Call
/// this only after calling End().
/// </summary>
////////////////////////////////////////////////////////////
public void Draw(SFML.Graphics.RenderTarget target, SFML.Graphics.RenderStates states)
{
uint index = 0;
foreach (var item in _textures)
{
states.Texture = item.Texture;

target.Draw(_vertices, index, item.Count, SFML.Graphics.PrimitiveType.Quads, states);
index += item.Count;
}
}


[Jebbs]

A sprite batch is just a way to reduce the number of draw call for things that use the same texture.

This code for example:

Code: [Select]

SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);


If all of those sprites used the same texture, it would essentially create a vertex array and then draw everything with one draw call internally.

For such thing, you can simply create vertex array. If I would wanna use spritebatches only for drawing sprites with same texture, I wouldn´t use them. Yes, spritebatch should reduce draw calls, but imo efficient spritebatch reduces it to number of different textures what are added to it.

Perhaps I oversimplified it by mentioning only one texture, but yeah, sprite batches should work regardless of the thing being drawn has the same texture as anything else in the batch. That was just supposed to be a basic example to explain the underlying concept to eXpl0it3r.

[Carlitox]

- Change the developement direction to a game programming framework not being only a media layer.
- Integrate thor library
- Create an entity system
- Create a TiledMap class
- Messaging systems
- Lua scripting class that exposes entities, camera and the map
- Scripted quest system


One way to do it it's create another layer.

[select_this]

- Scripted quest system

I think this is way too specific for a library. I can think of many games (let alone applications) that would never, ever need this. A lot of game engines (which SFML is not) don't even go to these sorts of lengths.

[Carlitox]

- Scripted quest system

I think this is way too specific for a library. I can think of many games (let alone applications) that would never, ever need this. A lot of game engines (which SFML is not) don't even go to these sorts of lengths.

Yes it is.

Abstract that could be difficult but challenging,

[ChronicRat]

Don't forget that SFML by the first is SIMPLE. And library. Not an engine. SFML does not need any engine features, but crossplatform interfaces. I think that current of I/O routines are necessarily need to improve and extend.

[Deathbeam]

- Change the developement direction to a game programming framework not being only a media layer.
- Integrate thor library
- Create an entity system
- Create a TiledMap class
- Messaging systems
- Lua scripting class that exposes entities, camera and the map
- Scripted quest system


One way to do it it's create another layer.

You must remember that SFML is multimedia library, NOT game engine Most of things what you listed are not even essential for game framework, you cannot think that with SFML you will have "pre-made" game

A sprite batch is just a way to reduce the number of draw call for things that use the same texture.

This code for example:

Code: [Select]

SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);


If all of those sprites used the same texture, it would essentially create a vertex array and then draw everything with one draw call internally.

For such thing, you can simply create vertex array. If I would wanna use spritebatches only for drawing sprites with same texture, I wouldn´t use them. Yes, spritebatch should reduce draw calls, but imo efficient spritebatch reduces it to number of different textures what are added to it.

Perhaps I oversimplified it by mentioning only one texture, but yeah, sprite batches should work regardless of the thing being drawn has the same texture as anything else in the batch. That was just supposed to be a basic example to explain the underlying concept to eXpl0it3r.

Yep, you oversimplified it