Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: The new graphics API in SFML 2  (Read 72315 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
The new graphics API in SFML 2
« Reply #120 on: October 07, 2011, 06:07:22 pm »
Ok, sold.
Laurent Gomila - SFML developer

laserbeams

  • Newbie
  • *
  • Posts: 6
    • View Profile
The new graphics API in SFML 2
« Reply #121 on: October 08, 2011, 03:40:08 am »
Quote from: "Laurent"
However, Vertex and VertexArray could suggest 3D as well. In fact the perfect name would be something that implies 2D. But I don't think it exists.

I realise you may be a bit beyond this, and I agree with the usage of vertex, but the only word I can think of that implies 2D would be net or network - but that also implies hollow.

I'm concerned about conflating an array or list of vertexes with something that's displayable as flat or textured polygons.  If I wanted a cloud of points, I'd use a vertex list, but there is none of the inherent grouping needed for face display in the concept of a vertex list, particularly if you intend to allow both tris and quads.  I've only ever seen a straight list of vertexes used to define a triangle strip, because then there is no ambiguity of order.

As a relative newbie, what I'd expect is a "face" object, which could be either a tri or quad, and essentially a tuple (is this the right word?) of several vertexes, perhaps with additional information that the vertexes alone wouldn't encode, like texture.  Would this be too much like a sprite?  Would this -be- a sprite?

I would also expect something like a "shape" object that could hold more complex geometry, but I can think of two ways to go about this.  One would be not much more than a "faceList".  The vertexes, texture coordinates, and textures would already be defined.  I realise this could be very inefficient with multiple textures referenced.  Alternatively "face" objects could leave out the texture, and texture could be a property of the "shape" or "geometry".

The other would be a "vertexList" along with an "indexFaceList", which would be the more traditional approach of referring to indexes in a vertex array for each polygon, so polygons can have shared vertexes (including texture coordinates).  Again, texture and such would be a property of the "shape".

Am I sort of on the right page?

Disclaimer:  I'm pretty new to this.

Lee R

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
The new graphics API in SFML 2
« Reply #122 on: October 08, 2011, 08:52:37 pm »
Having an array of vertices represent geometry is all about efficiency, since that is what most closely matches the machine model. I haven't seen anything in this thread which would lead me to believe that higher level abstractions wont be provided, so I think your concern is premature at best.

heishe

  • Full Member
  • ***
  • Posts: 121
    • View Profile
The new graphics API in SFML 2
« Reply #123 on: October 17, 2011, 09:53:31 pm »
Laurent, do you know how the XNA Framework does batching? I think the way their API works is really nice. There's a class called "SpriteBatcher" that does all the low level stuff for you. The only thing that the user can do (it's optional) is hand over parameters concerning the drawing mode, e.g. blending, sorting by textures and batching that way, etc.

You just hand over sprites/textures and the class does the rest for you.

It's incredibly fast as well. I get about 20000FPS (yes, 20k fps) in a demo where I draw about 100 small rects with three different 16x16 textures on them.

I think that style fits SFML best. The abstraction level where SFML is now (high level but it's very easy to get access to low level stuff) is pretty much perfect, and the SpriteBatcher as a performance boost would be a good addition to that, imo.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
The new graphics API in SFML 2
« Reply #124 on: October 18, 2011, 10:33:56 pm »
Quote
Laurent, do you know how the XNA Framework does batching? I think the way their API works is really nice. There's a class called "SpriteBatcher" that does all the low level stuff for you. The only thing that the user can do (it's optional) is hand over parameters concerning the drawing mode, e.g. blending, sorting by textures and batching that way, etc.

Batching can be done in SFML, but it would probably be more limited than in XNA. To be efficient, entities have to be reordered, but to do so they must have a depth, so that a different rendering order has no impact on the result.
Anyway, batching will probably come later, as an optimization on top of the new API, if performances require it.
Laurent Gomila - SFML developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
The new graphics API in SFML 2
« Reply #125 on: October 19, 2011, 10:12:13 am »
I haven't had a lot of time to work on this lately, but here are some news anyway.

First, I renamed classes to Vertex and VertexArray. If someone tells me that Point/Mesh were better names, I kill him :mrgreen:

The second point is a new concept. I was thinking about changing how render states (transform, texture, shader, blend mode) were managed. Currently, they can be read/written with accessors in sf::RenderTarget, and they are persistent between two calls to Draw.
Code: [Select]
window.SetTexture(texture);

window.SetTransform(transform1);
window.Draw(geometry1);

window.SetTransform(transform2);
window.Draw(geometry2);


I don't like persistent states because when you draw something you never know what value each state has, and you have to overwrite them all to be safe. But you also have to push/pop them so that the parent entity can find its states back if it needs to render other children.

My idea was to get rid of all getters and setters, and instead implement a new class named RenderStates, that would hold the states to use for a drawing operation.

Code: [Select]
class RenderStates
{
    BlendMode blendMode;
    Transform transform;
    const Texture* texture;
    const Shader* shader;
};

class RenderTarget
{
    void Draw(const Drawable& drawable, RenderStates states = RenderStates::Default);
};


States would be forwarded, modified if needed, along the hierarchy of Draw calls:
Code: [Select]
class Sprite : public Drawable, public Transformable
{
    void Draw(RenderTarget& target, RenderStates states)
    {
        states.transform *= GetTransform();
        states.texture = myTexture;
        target.Draw(myVertexArray, states);
    }
};

... and finally applied at the lowest level, when drawing a vertex array
Code: [Select]
class RenderTarget
{
    void Draw(const VertexArray& vertexArray, RenderStates states = RenderStates::Default)
    {
        // apply states
        // render vertex array
    }
};


For convenience, RenderStates will have implicit constructors taking a single state, so that you can write this kind of code:
Code: [Select]
window.Draw(entity, transform);
window.Draw(sprite, shader);
...
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
The new graphics API in SFML 2
« Reply #126 on: October 19, 2011, 11:58:31 am »
A struct sf::RenderStates sounds good, it goes away from the global statemachine (OpenGL style). Is sf::Transform now only stored in sf::RenderTarget, or do the geometries also own such a member?

And sf::Transformable is the mix-in class that provides GetPosition() etc. plus a convenient GetTransform() which is computed on-the-fly? I'm just not sure in which class the GetTransform() call in your code is ;)

But this approach might lead to many OpenGL calls because of state changes. Or do you plan to write some sort of cache to apply state changes only if necessary?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
The new graphics API in SFML 2
« Reply #127 on: October 19, 2011, 12:13:04 pm »
Quote
Is sf::Transform now only stored in sf::RenderTarget, or do the geometries also own such a member?

What do you mean?
The transform is a render state, so it is defined in sf::RenderStates. Only the Transformable base class has its own transform.
EDIT: indeed, GetTransform() is the computed transform from sf::Transformable ;)

Quote
But this approach might lead to many OpenGL calls because of state changes. Or do you plan to write some sort of cache to apply state changes only if necessary?

With this approach, every call to Draw(VertexArray) will trigger 5 OpenGL calls: one for each state, plus one to send the vertices. It could be a lot, but I hope that with the new API people will create optimized classes that use one big VertexArray instead of multiple sprites.

A render states cache is complicated to implement, because of three problems:
- it's hard to check if a transform is the same as the previous one (several floating point numbers to compare)
- even if a shader or a texture is the same, its internal state may have changed (texture updated, shader parameter changed, ...) so it sill needs to be bound again -- look at the many bugs that it currently causes in sf::Renderer :)
- if people use OpenGL calls in between, it's hard to keep the SFML cache up-to-date; but this can be solved with functions such as SaveGLStates/RestoreGLStates (they will probably change when the new API is ready)
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
The new graphics API in SFML 2
« Reply #128 on: October 19, 2011, 01:52:07 pm »
Maybe a hash could avoid expensive comparisons. But you're right, you shouldn't focus on a riskily optimized renderer cache if you provide the super-fast way via sf::VertexArray :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
The new graphics API in SFML 2
« Reply #129 on: October 20, 2011, 10:30:59 am »
The next step will be a redesign of sf::Shape. I don't like its API, and a lot of people don't understand the concept of local points/global position. And the API is going to be definitely bloated if I add support for texturing.

So I was thinking about writing one class for each specific shape (line, triangle, rectangle, circle, star, whatever), inheriting from a common base that provides most of the implementation. Of course, one of them will be sf::ConvexShape so that you can still get the full set of features, like before. And the base class will allow users to create their own type of shape very easily if they want to.

This way, users won't have to deal with local vs global positions anymore: all points will be implicitely created with (0, 0) as their local origin, like sf::Text and sf::Sprite. Only the sf::Transformable functions will be able to move the shape in the 2D scene.
Another benefit is that each class can define its own specific API: circle with radius, line with start/end, etc.

Most of the features will be kept: outline thickness, outline color, fill color (it will be one for the whole shape instead of one per point, but I'll create a new class sf::ColorGradient), and a new feature will be added: texturing.

I think this is a good compromise between simple features and flexibility. People who want very specific shape features can still build their own stuff with a sf::VertexArray.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
The new graphics API in SFML 2
« Reply #130 on: October 20, 2011, 04:35:24 pm »
Interesting! :)

I don't see the big difference between the base class (let's say sf::Shape) and sf::ConvexShape yet. You write that sf::Shape would allow custom shapes very easily, do you have something concrete in mind? I guess that AddPoint() will only be added in sf::ConvexShape...

And have you already spent some thoughts about the API of sf::ColorGradient?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
The new graphics API in SFML 2
« Reply #131 on: October 20, 2011, 04:48:04 pm »
Quote
I don't see the big difference between the base class (let's say sf::Shape) and sf::ConvexShape yet.

sf::Shape will define the common properties: outline, colors, texturing, as well as attributes inherited from Transformable and Drawable of course. It will also implement all the boring private stuff: computing the outline, computing the texture coordinates, applying the color gradient if needed, and rendering the geometry.
So sf::Shape's API will be quite useless alone. sf::ConvexShape is the one that will define the powerful API: points position, ... and ... hum ... that's all :lol:

Quote
And have you already spent some thoughts about the API of sf::ColorGradient?

Yep. It will be very simple, so that it can be mapped on any shape, even those with only 4 vertices (= rectangles):
- start color
- end color
- direction (horizontal or vertical)

If I can apply it to other drawables, I'll do it too.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
The new graphics API in SFML 2
« Reply #132 on: October 21, 2011, 06:42:22 pm »
Quote from: "Laurent"
Yep. It will be very simple
But will it be useful enough? Are there many people needing exactly a vertical or horizontal gradient with 2 colors so that an extra class is justified? Wouldn't one rather use shaders for such features (which allow much more)?

And how does it mix with single sf::Color attributes, will there only a SetColorGradient() and an implicit conversion from sf::Color to sf::ColorGradient? In this case, does extracting a single color (which is probably often used) always look like shape.GetColorGradient().GetFirstColor()?

Sorry for questioning everything ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
The new graphics API in SFML 2
« Reply #133 on: October 21, 2011, 11:03:13 pm »
No, you're totally right. This definitely needs more thinking ;)
Laurent Gomila - SFML developer

Mikademus

  • Newbie
  • *
  • Posts: 31
    • View Profile
The new graphics API in SFML 2
« Reply #134 on: October 22, 2011, 01:21:38 am »
Part of the point of vertices is that they have data, in this case colour. Thus gradients between points will be automatic. Therefore it would be better to be able to set the colour on a per-vertex bases. A per-shape colour would simply be a short-cut to setting all vertices' colour values to the same value. I doubt there can be a simpler or more flexible way than that.