New graphics API ready

[Laurent]

I've merged the 'drawables' branch into master.

I've implemented a render states cache similar to what I did before -- but hopefully with less bugs. Performances are not as high as before (immediate mode seems to be the best for single quads), but with vertex arrays I think that all problems can be solved.

I've also uploaded the updated API documentation.

[Hiura]

great work!

[Tank]

For example, creating a 4-vertex VBO in each sprite would be very innefficient.

Of course. Nobody would even want to do that.

And how do you provide read access to the vertices?

GL_(STREAM|STATIC|DYNAMIC)_READ? Or even copy and keep the data in RAM if you need to do modifications on it. IMHO this is more rare than static geometry.

I get 500 FPS with a 100x100 tilemap (40000 vertices).

I think 500 FPS for 10,000 quads is way too worse.

I would be glad to get 1000 FPS, yes, but I don't think that it can be done without making the API ugly.

Do you already have an idea of it? I mean you always state it would be ugly, so I guess you already thought of it?

Are you sure that the benefit would be the same at 50 FPS (x2.5 -> 120 FPS), and that it's not a fixed improvement (+0.5 ms -> ~52 FPS)?

I'm absolutely sure. Luckily we test with enough different systems, and the FPS improvements do not happen at high-end machines only. At one machine FPS went up from below 60 FPS to above 100, which is a lot (you can check it out yourself by using older SFGUI commits before those with "optimization" or similar in it).

Like I already told you before, you should do your benchmarks with more things to draw and less FPS.

That's what we always do.

If someone sends me a patch that improves the overall performances of SFML without making neither the internal code nor the public API ugly, I'll be happy too

Alright, let's see... :twisted:

[Laurent]

Alright, let's see... :twisted:

Yeah

[Elgan]

Optimisation is always good, can do more per frame

[batzer]

So when will the official release be?

[Laurent]

So when will the official release be?

Soon.

[Tank]

Can you add some more hints in the documentation for methods like this?

Code: [Select]

void sf::ConvexShape::SetPoint(unsigned int index, const Vector2f& point)

It's not obvious what happens if an invalid index is given and that a previous call to SetPointCount() must be made (or the proper equivalent through the ctor).

[Laurent]

You're right, thanks for the feedback

[Mario]

Okay, took me just 5 mins to adjust to the Drawable changes. Nice.

However, there are some downsides I wanted to mention here and I guess they're just some oversights or whatever:

The old one-liners like rt.Draw(sf::Shape::Rectangle(...)) are no longer available. I thought they're rather handy for quick debug drawings. sf::RectangleShape isn't a real perfect replacement due to lacking constructor parameter (you should still be able to set position, colors and thickness through the constructor).

Also, maybe I missed it, but it's (for now?) no longer possible to create a sf::Shape with different colors at different points? Tempted to reimplement that, cause I thought it's been rather handy for gradients and such.

Also, think we're definitely missing simple primites like a LineShape or something similar (well, probably not a shape, but still useful). Wouldn't like to abuse a rectangle or convex shape for this.

Edit:
(I also noticed that using Sprite::SetScale(-1,1) won't simply mirror the sprite, but also change its position? I'd expect the given coordinate/position to stay the top left corner, no matter how the sprite is scaled.) Okay, this can be "fixed" moving the origin, due to it being applied as a real transform, still not that happy about this change.

Edit 2:
How about changing CircleShape to be an EllipseShape and making CircleShape a specialization (i understand it can be done using scaling, but that's still a bit off)?

[Laurent]

Thanks for your feedback

The old one-liners like rt.Draw(sf::Shape::Rectangle(...)) are no longer available. I thought they're rather handy for quick debug drawings. sf::RectangleShape isn't a real perfect replacement due to lacking constructor parameter (you should still be able to set position, colors and thickness through the constructor).

The list of arguments would be really huge, and not as clear as calling individual setters.
Is it really important to be able to fully construct and configure a shape with one line of code?

Also, maybe I missed it, but it's (for now?) no longer possible to create a sf::Shape with different colors at different points? Tempted to reimplement that, cause I thought it's been rather handy for gradients and such.

You're right, this feature was removed. I admit that I was not happy to drop it, but with the new API I can no longer have both a global color and a color for each point, so i had to choose.

I also noticed that using Sprite::SetScale(-1,1) won't simply mirror the sprite, but also change its position? I'd expect the given coordinate/position to stay the top left corner, no matter how the sprite is scaled.

It's consistent with how transformations are applied. The scale is applied around the origin of the entity, which is (0, 0) by default. If you don't want the sprite to move, set its transformation origin to its center.

How about changing CircleShape to be an EllipseShape and making CircleShape a specialization (i understand it can be done using scaling, but that's still a bit off)?

That would make sense. I have to think about it.

[Laurent]

Sorry I forgot one point

Also, think we're definitely missing simple primites like a LineShape or something similar (well, probably not a shape, but still useful). Wouldn't like to abuse a rectangle or convex shape for this.

It was already discussed there:
http://www.sfml-dev.org/forum/viewtopic.php?p=42810#42810

[Mario]

Just noticed something else by accident. I haven't had time to further investigate, but it seems reasonable (but still missing any notes in the docs then?):

By accident I loaded a texture before my window is created (no existing context yet). Under Windows 7, the texture still worked fine (so I didn't notice), but under Ubuntu 11.10 (inside VirtualBox) the texture always appeared with the contents of the first texture loaded after creating the window. It still used the scaling/mapping of the original texture (the one I tried to load) but used the first OpenGL texture created after creating the window.

Essentially something like this:

Code: [Select]

tex1.LoadFromFile(512x512px);
window.Create(...);
tex2.LoadFromFile(256x256px);

Trying to draw the top left 10x10 pixels of tex1 would now result in drawing the (upscaled) top left 5x5 pixels of tex2 (due to different tex coord scaling).

[Laurent]

I'll investigate this issue as soon as I can. Thanks.

[Mario]

Hm... there might be a similar issue with sounds (readding sounds as ogg playback works now for me).

When using "sf::Sound[16]" as a class member, my process keeps creating new threads over and over again (visible in GDB; window is still created in constructor). This doesn't happen if I allocate the array after my window is created. This might be some other issue, but it's still a very odd behaviour.