New graphics API ready

[Nexus]

By the way, can't we flip drawables -- especially sprites -- anymore? There is neither a SetFlippedX/Y() nor a SetScale() allowing negative factors...

[Laurent]

Might the problem be that you create two additional vertices in sf::Shape? Do you really need them?

I don't know, I have to investigate this issue. But I don't think that it has something to do with the two additional vertices. The first one is the center, and the other one is a copy of the first vertex to close the shape.

You should make constructors that can be called with one argument explicit. I always forget this, too...

Thanks :lol:
(the keyword should be "implicit", not "explicit"...)

By the way, can't we flip drawables -- especially sprites -- anymore? There is neither a SetFlippedX/Y() nor a SetScale() allowing negative factors...

I've removed these functions for now. Negative scales are now allowed, and you can also easily create your own flipable sprite. I think I'll wait for more feedback.

[Laurent]

Might the problem be that you create two additional vertices in sf::Shape?

This problem is now solved.

[asdatapel]

Wow SFML is amazing!
Question though....how will this affect existing code? Will most of it work?

[Groogy]

Alright just doing some quick checks for the future. And I will be using sf::*::GetGlobalBounds() a lot for testing occlusion and culling. And for my test level with low detail with shadows disabled I have +4000 draw calls. So I checked the source just to be sure if I should cache the value between frames or just depend directly on the function.

And I saw this:

Code: [Select]

FloatRect Shape::GetGlobalBounds() const
{
    return GetTransform().TransformRect(GetLocalBounds());
}

I guess TransformRect is not heavy but doing it each frame for an increasing amount of objects will become heavy eventually.

And I guess you want to keep the memory use as minimal as possible so you don't want to save away the global bounds if it can be calculated like this right? So I should more or less expect myself to do the cache when it comes to things like this right? Plus it would be unnecessary for someone who don't have the exact same needs as me.

[Laurent]

Question though....how will this affect existing code? Will most of it work?

Yes. Existing classes have slightly changed, but the most important modification is the addition of a lower-level layer that allows much more flexibility.

So I should more or less expect myself to do the cache when it comes to things like this right?

Yes (but test it first, the difference may not be significant ). However I can't say that I'm keeping the memory use as low as possible, so I might cache it myself in the future if it's really needed.

[Laurent]

By the way, I'm now implementing support for vertex shaders.

[Groogy]

By the way, I'm now implementing support for vertex shaders.

My love for you keeps on growing <3 ^^

[Laurent]

My love for you keeps on growing <3 ^^

I was sure you would say that :mrgreen:

[Nexus]

I've removed these functions for now. Negative scales are now allowed, and you can also easily create your own flipable sprite. I think I'll wait for more feedback.

I like this approach, but the documentation says "scale.x and scale.y must be strictly positive".

This problem is now solved.

Thanks! I am only able to test it (and other features) next weekend.

[Laurent]

I like this approach, but the documentation says "scale.x and scale.y must be strictly positive".

It's a mistake, I'll correct the documentation.

[luiscubal]

OpenGL defines the concept of indexes in addition to vertexes. Will this merely be sequential in SFML?

Also, although OpenGL seems to define glVertexPointer, modern OpenGL seems to define glGenBuffers, glBindBuffer, glBufferData and glVertexAttribPointer functions. I'm guessing SFML doesn't take advantage of this, but wouldn't a "Lock()"(or some other better name) in VertexArray improve the opportunities of optimization by ensuring that a given Vertex Array would never be modified again?

[Laurent]

OpenGL defines the concept of indexes in addition to vertexes. Will this merely be sequential in SFML?

SFML doesn't handle indices (this is not needed in this context, really).

Also, although OpenGL seems to define glVertexPointer, modern OpenGL seems to define glGenBuffers, glBindBuffer, glBufferData and glVertexAttribPointer functions. I'm guessing SFML doesn't take advantage of this, but wouldn't a "Lock()"(or some other better name) in VertexArray improve the opportunities of optimization by ensuring that a given Vertex Array would never be modified again?

SFML doesn't use VBOs (vertex buffer objects), only VAs (vertex arrays). Again, this is not necessary for what SFML does.

I understand that people wonder why SFML doesn't use the most powerful things that OpenGL allows, but this is not the right question to ask. The first step is to find a good/clean/efficient design, and then to find the best implementation for it. Doing things the other way round ("VBOs are so cool, let's use them") would potentially lead to bloated design ("I need a Lock() function") for virtually no gain ("I get 5100 FPS instead of 5000")

[Mr. X]

Will the change have an impact on the performance of existing (thus using the old interface) code?

[Laurent]

Will the change have an impact on the performance of existing (thus using the old interface) code?

If I succeed to implement a bug-free render states cache, no.