The new graphics API in SFML 2

[Laurent]

TextureRect is ok for me.

Now about the "something"-part, like Nexus said "rect" seems to fit the job for sprites as they are rectangular. But what about shapes ? If shapes also have texture ( ? ) then rect doesn't fit and having two different names can be confusing. So if they have texture then "area" seems better to me, otherwise I agree with TextureRect.

If sf::Shape had a SetTextureSomething which is not a rectangle, I don't know what it could be because SFML has nothing more complicated than rectangles

I still have to decide what sf::Shape will become. It will probably change a lot.

[Groogy]

Well it could still be a rectangle but when adding points to the shape you also specify where in the texture rectangle this point is. Normal UV mapping.

[Laurent]

Well it could still be a rectangle but when adding points to the shape you also specify where in the texture rectangle this point is. Normal UV mapping.

So you would give points inside a sub-rectangle of the texture? Why not just points inside the texture directly?

[Groogy]

Because then setting a sub rect for a shape would have no purpose
Also would make it possible to have sprite sheets with shapes I guess. I mean it wouldn't be a hazzle if you don't want to use t as it would only default to the whole texture size.

[Canadadry]

I've got an idea of a possible pattern for hiding vertex concept. This is just the beginning of what that could do. And just for the public side not for implementation.

What if we keep the old architecture (just to simplified my explanation) and then add 4 functions to the drawable class

Code: [Select]

beginStaticDrawing
endStaticDrawing
beginDynamicDrawing
endDynamicDrawing


This two couples of functions allow the user to define complicated sprite this way

Code: [Select]

myTileMap.beginStaticDrawing();
for(int i=0;i<myTile.size();i++)
    myTiles[i].draw();
myTileMap.endStaticDrawing();


Then I just need to to call draw function of myTileMap to draw the entire tile map. It act like a dispay list.

With the other function, you will build another kind of list which will allow you to move (or else ..) some of the tile which will update the data behind for the next draw.

I think this approach should allow basic user to build display list or vertex array without knowing anything of it.  
What do you think of it ?

[Laurent]

I had already thought about such a "bridge" between low-level vertex arrays and high-level classes. We can also call it "explicit batching".

But there are some problems to solve. To put several entities in the same vertex array, they must share the same texture and the same type of primitives.

This means that you can't put texts of different sizes/styles/fonts in the same batch, or sprites with different textures, or shapes. Or any combination of these classes of course. This new feature would be very limited.

But that's definitely something to keep in mind, and after the basics of the new API are well defined I'll probably think about batching again.

[luiscubal]

I believe some graphics cards support using multiple textures at once. It would be neat to have a SFML method like "GetMaximumNumberOfSimultaneousTextures"(with a better name). Then one would use this number to use multiple textures at once and improve batching. Wouldn't this improve the performance?

Perhaps preferably, SFML could automatically batch things internally, so all this would merely be an implementation detail and the programmer would be blissfully unaware of any batching at all.

So, if a GPU only supports one texture at a time.

1. UseTexture1
2. UseTexture1
3. UseText1
4. UseTexture2

In the above case, SFML would automatically batch 1 and 2 together, but not 3 and 4.

P.S: I know that I've suggested multiple textures support on Mesh before, but here what I have in mind is slightly different. Instead of using multiple textures for improved visuals, it'd be for improved speed. I'm not even considering how to implement this stuff in terms of Meshes.

[Laurent]

I believe some graphics cards support using multiple textures at once. It would be neat to have a SFML method like "GetMaximumNumberOfSimultaneousTextures"(with a better name). Then one would use this number to use multiple textures at once and improve batching. Wouldn't this improve the performance?

You can't use multi-texturing like this. Anything that is rendered always uses all the texture units. You can't assign specific texture units to different parts of a vertex array, and render the whole thing in one call.

Perhaps preferably, SFML could automatically batch things internally, so all this would merely be an implementation detail and the programmer would be blissfully unaware of any batching at all.

To be efficient, batching must reorder entities, which means that I must handle their drawing order with an explicit Z value. And that doesn't work well with alpha-blended entities.

[Canadadry]

But there are some problems to solve. To put several entities in the same vertex array, they must share the same texture and the same type of primitives.

That's a shame.... I haven't thought of that....  

[Lee R]

-1 for "Mesh". In English, the word "Mesh" cannot in any sense represent the notion of a list containing discrete (non-mesh forming) geometry (e.g. a list of quads).

-1 for "Point". I personally predict that users seeing the name "Vertex" along with a brief description of what that means, will be less confused than a seeing a "Point" class/struct containing all manner of data members which are completely unrelated to the notion of a position in space.

+1 for VertexArray (and/or possibly even QuadList, TriangleList .etc with the appropriate interface)

+1 for Vertex.

[Laurent]

-1 for "Mesh". In English, the word "Mesh" cannot in any sense represent the notion of a list containing discrete (non-mesh forming) geometry (e.g. a list of quads).

Correct. But I was thiking it would be ok, because 95% of meshes would truly be meshes; separate primitives would be a specific case -- the only use case that I can see is particles systems.
I don't like VertexArray, it's more an array of primitives (unlike OpenGL, the primitive type is an attribute of the class, it's not given at draw time). However it acts like an array of vertices (operator[] returns a vertex), so... I don't know.
What about sf::Geometry, or sf::Primitives? I guess they are bad too, because of the "array of vertices" semantics.

-1 for "Point". I personally predict that users seeing the name "Vertex" along with a brief description of what that means, will be less confused than a seeing a "Point" class/struct containing all manner of data members which are completely unrelated to the notion of a position in space.

It is a position in space, with some extra data attached to it.

+1 for VertexArray (and/or possibly even QuadList, TriangleList .etc with the appropriate interface)

I tried this approach before, but these classes would have to return a Quad/Triangle with their operator[], which is not very convenient.

[Lee R]

-1 for "Mesh". In English, the word "Mesh" cannot in any sense represent the notion of a list containing discrete (non-mesh forming) geometry (e.g. a list of quads).

Correct. But I was thiking it would be ok, because 95% of meshes would truly be meshes;

Then perhaps you would prefer 'MeshMostlyExceptWhenItsNot'

I don't like VertexArray, it's more an array of primitives (unlike OpenGL, the primitive type is an attribute of the class, it's not given at draw time). However it acts like an array of vertices (operator[] returns a vertex), so... I don't know.
What about sf::Geometry, or sf::Primitives? I guess they are bad too, because of the "array of vertices" semantics.

That would seem to argue in favour of QuadList, TriangleList etc. I'd also like to point out the amount of times you quite naturally used the word "vertex" there

-1 for "Point". I personally predict that users seeing the name "Vertex" along with a brief description of what that means, will be less confused than a seeing a "Point" class/struct containing all manner of data members which are completely unrelated to the notion of a position in space.

It is a position in space, with some extra data attached to it.

No. It is a vertex which has a position in space. For instance, it wouldn't be unheard of to see something like:

Code: [Select]


struct Point
{
    float x;
    float y;
};

struct Vertex
{
    Point position;
    // ...
};


+1 for VertexArray (and/or possibly even QuadList, TriangleList .etc with the appropriate interface)

I tried this approach before, but these classes would have to return a Quad/Triangle with their operator[], which is not very convenient.

I had actually thought it would have been more convenient. It would certainly make the tile-sheet code you presented earlier a lot more readable. I'm not at all attached to those structures, but I wonder what exactly you thought would be the inconvenience? dealing structure padding or?

[Laurent]

No. It is a vertex which has a position in space. For instance, it wouldn't be unheard of to see something like
[...]

Yes of course. If it was just me, the code would already look like this one.
I was just trying to find a word that would sound more "natural" to beginners (and generally non-3D people), but I guess that it doesn't exist.

I'll probably consider using Vertex/VertexArray again.

I had actually thought it would have been more convenient. It would certainly make the tile-sheet code you presented earlier a lot more readable. I'm not at all attached to those structures, but I wonder what exactly you thought would be the inconvenience? dealing structure padding or?

Padding is one thing, but I just need to find the specific #pragma or whatever for every supported compiler.

I don't like the way the code would be transformed:

Code: [Select]

vertices[i * 4].Position = ...;

// vs

quads[i].p0.Position = ...;
(I don't like "p0" nor "p[0]" or whatever to name the four points of the quad -- but anything cleaner would be longer)

Moreover, it means that the type of primitives must be chosen at compile time, and cannot be changed at runtime. I don't know if it's annoying, though.

On the positive side, I could add helper functions:

Code: [Select]

quads[i].SetFromTextureRect(sf::IntRect(...));
// 8 lines of code into 1
(just like a sprite)

[Lee R]

I wont be putting much effort into arguing for QuadList et al, since I share your concern over the possible annoyance of static typing there. I suppose people who really care about such things can write some sort of QuadView structure over a VertexArray or similar.

[Mikademus]

-1 for "Point". I personally predict that users seeing the name "Vertex" along with a brief description of what that means, will be less confused than a seeing a "Point" class/struct containing all manner of data members which are completely unrelated to the notion of a position in space.

It is a position in space, with some extra data attached to it.

Sure sounds like a vertex to me.

As you said, there is no a priori understandable terminology for this. Just go with the industry standard. The beginners will learn and you won't frustrate the non-beginners, which is just as important a consideration.