SFML community forums
General => General discussions => Topic started by: Laurent on December 02, 2011, 09:04:08 pm
-
Hi
I've pushed a first version of the new graphics API, so that you can test it. Please focus on the API, there's no optimization yet so the performances are worse than before. I can't upload the documentation, so you'll have to either generate it yourself, or directly look into header files.
The new API is available in the 'drawables' branch of the main repository.
It is for testing only, if you want a final and optimized version then wait until it is merged into the master branch.
Thanks :)
-
Great news, I'll test the new API as soon as possible! :)
-
I've experimented a little with the new shapes, and some points took my attention:
- Sometimes the shape isn't updated correctly. After the following code, the shape isn't ready to be drawn. But when uncommenting the last line, it works.
sf::ConvexShape shape;
shape.SetPointsCount(3);
shape.SetFillColor(sf::Color::Magenta);
shape.SetPoint(0, sf::Vector2f(10, 10));
shape.SetPoint(1, sf::Vector2f(50, 10));
shape.SetPoint(2, sf::Vector2f(10, 50));
//shape.SetOutlineThickness(0);
- Private members don't appear in the documentation. You should enable them because of virtual functions like GetOutlinePoint().
- In the ConvexShape::ConvexShape() constructor, you write "Let's define a triangle by default... just so that it's not empty"... I think an empty shape (e.g. nothing) is more intuitive than an arbitrary triangle -- and the behavior remains the same as in the old API. It allows to write shape = sf::ConvexShape(); to clear a shape.
- Or is it an invariant that the amount of points in a sf::ConvexShape must be at least 3? If so, you should probably check it in SetPointsCount(). Still, the default triangle is of no real use and looks like a workaround ;)
And why do you write "The default number of points of a polygon is 6"?
-
virtual isn't totally useless for a private member ?
ps : i wasn't in "drawable branch"
-
virtual isn't totally useless for a private member ?
No, it's not. Private virtual methods still can be overridden (really, overridden, not just shadowed) in derived classes.
-
Sometimes the shape isn't updated correctly
It's fixed. I forgot to call Update() in SetPoint and SetPointsCount.
Private members don't appear in the documentation. You should enable them because of virtual functions like GetOutlinePoint()
Or I could make them protected instead.
In the ConvexShape::ConvexShape() constructor, you write "Let's define a triangle by default... just so that it's not empty"... I think an empty shape (e.g. nothing) is more intuitive than an arbitrary triangle -- and the behavior remains the same as in the old API. It allows to write shape = sf::ConvexShape(); to clear a shape.
I made this to make the class consistent with other shapes (they all have a default definition which is a valid shape).
If I choose your solution, I should also use 0 for the radius of sf::CircleShape, for the size of sf::RectangleShape, etc.
I don't know which solution is the best.
Or is it an invariant that the amount of points in a sf::ConvexShape must be at least 3?
It is indeed forbidden to have less than 3 points, it is handled in the base class.
Still, the default triangle is of no real use and looks like a workaround
I totally agree :?
And why do you write "The default number of points of a polygon is 6"?
Just a typo ;)
-
Or I could make them protected instead.
Or directly public. At least, I have a use case in mind: My thor::ConcaveShape class should be able to create a copy of any sf::Shape, and this is not possible without accessing the single points. On the other side, I see that the single points can be an implementation detail, especially for circles. Hm... :?
Apart from that, I think it is a little bit confusing that there exists GetPoint() and GetOutlinePoint(), although they do the same (analogous for the count getter). Remember that you can also loosen access in derived classes, i.e. redeclare the method in the public section.
I don't know which solution is the best.
Me neither, I have to think about it more. I just think it has been comfortable to allow "empty" shapes, but with a better design they are probably not necessary. And the loss of class constraints is a high price.
Just a typo ;)
I've seen another one: "offseted" instead of "offset" :P
-
Or directly public. At least, I have a use case in mind: My thor::ConcaveShape class should be able to create a copy of any sf::Shape, and this is not possible without accessing the single points. On the other side, I see that the single points can be an implementation detail, especially for circles. Hm...
Apart from that, I think it is a little bit confusing that there exists GetPoint() and GetOutlinePoint(), although they do the same (analogous for the count getter). Remember that you can also loosen access in derived classes, i.e. redeclare the method in the public section.
At first it was exactly like this:
- GetPointsCount and GetPoint
- some classes just made them public
But I figured out that some classes may define public points that don't match the internal ones. For example, the number of points defined by sf::StarShape is the number of "branches". It must be multiplied by two to get the actual number of points composing the shape.
So I had to write this less elegant solution. However, if someone can find a synonym to "point" for the star shape (I spent hours on it, couldn't find anything :D), it can probably solve the problem as well, and I could revert to the first, more elegant solution. Then, making GetPoint and GetPointsCount public in the base class would be a good option ;)
I've seen another one: "offseted" instead of "offset"
I never know how to write this one in past tenses. Is this an irregular verb?
-
Just curious - is there any reason not to have "AddPoint", "Clear", etc. in ConvexShape?
About private virtuals: although this is a valid idiom, I have to wonder: how well will this map to other languages(e.g. .NET). Will there be an equivalent for those languages. Should there *be* an equivalent?
RectangleShape only has "size". No position. Is this intentional? Does this mean one would have to use RenderState(or whatever it is called) to set the position?
Also, RectangleShape should at least have two extra constructors:
1. RectangleShape(float sizex, float sizey)
2. RectangleShape(Vector2f size)
-
However, if someone can find a synonym to "point" for the star shape (I spent hours on it, couldn't find anything :D), it can probably solve the problem as well, and I could revert to the first, more elegant solution. Then, making GetPoint and GetPointsCount public in the base class would be a good option ;)
I have already wondered the same thing, and I'll see if I can find another term ;)
I never know how to write this one in past tenses. Is this an irregular verb?
Yes, verbs ending with "set" don't change in past forms. For example set, reset, offset, upset.
RectangleShape only has "size". No position.
It has a position, inherited from sf::Transformable.
Also, RectangleShape should at least have two extra constructors:
1. RectangleShape(float sizex, float sizey)
2. RectangleShape(Vector2f size)
I believe it is Laurent's design choice to remove these constructors for the sake of expressiveness. Other shape classes don't have them, and sf::Sprite or sf::Text don't have them either. Temporary constructions are no more possible, but expressions with unclear parameters like
sf::Shape::Rectangle(2.f, 3.f, 3.f, 5.f, sf::Color(255, 120, 100), 3.f, sf::Color(250, 250, 0)); are avoided.
-
Just curious - is there any reason not to have "AddPoint", "Clear", etc. in ConvexShape?
I think people always know how many points they need when they create a convex shape, so SetPointsCount is enough.
Clear() could be added, yes.
About private virtuals: although this is a valid idiom, I have to wonder: how well will this map to other languages(e.g. .NET). Will there be an equivalent for those languages. Should there *be* an equivalent?
Other languages adapt what they can't do to their capabilities. Even what they can do directly, is often modified to fit the language better. Bindings don't have to be a perfect mapping of the C++ API ;)
For example, the C binding will probably not provide the ability to create custom classes of shapes. And the .Net binding will have to recreate this hierarchy/virtual functions thing, since it's based on the C binding.
RectangleShape only has "size". No position. Is this intentional? Does this mean one would have to use RenderState(or whatever it is called) to set the position?
sf::Shape inherits from sf::Transformable ;)
Also, RectangleShape should at least have two extra constructors:
1. RectangleShape(float sizex, float sizey)
2. RectangleShape(Vector2f size)
The constructor that takes the size directly is definitely needed, and it's true for other shapes too.
I'm still not sure about the overload taking two floats. It's convenient but it would make me duplicate so many functions...
-
sf::Sprite or sf::Text don't have them either
They do!
sf::Sprite sprite(texture, rect);
sf::Text text(string, font, size);
-
I really miss the sf::Sprite::GetSize() and Resize() functions :( Did you remove them just for tidiness?
-
They do!
sf::Sprite sprite(texture, rect);
sf::Text text(string, font, size);
Indeed. The previous sprite constructor only took 1 parameter (while the one from SFML 1.6 took 5 parameters). Anyway, the current parameter lists of sf::Sprite and sf::Text are a good compromise in my opinion.
I really miss the sf::Sprite::GetSize() and Resize() functions :( Did you remove them just for tidiness?
There are GetLocalBounds() and GetGlobalBounds() to return the bounding rect.
About Resize(), I haven't ever used it... But you can achieve the same when directly modifying the scale.
-
I really miss the sf::Sprite::GetSize() and Resize() functions :( Did you remove them just for tidiness?
Yes:
- you can get the size with GetGlobalBounds (or GetLocalBounds + GetScale)
- you can set the size with GetLocalBounds + SetScale
-
Anyway, the current parameter lists of sf::Sprite and sf::Text are a good compromise in my opinion.
Yes. So, applying the same design to shape classes, they should provide a constructor that takes all the properties that they declare (size for rectangle, radius for circle, ...).
-
Alright yay! :D
I'll get into testing as soon as I can. So far my walls are built up with shapes so they can't have textures. I'll now start looking into using VertexArray instead for that.
Though before I can start play around with it I have to track down an annoying graphical glitch.
-
Okay, back to the star problem. Apart from "point" and "vertex", the term that soonest comes into question is "spike", but I'm not sure if it's really understandable.
But another question: Why do you want the user to access only the outer points (spikes or whatever)? I mean, he specifies the radius of the inner points, too. So he is aware of their existence, but has no access.
Maybe even one step further: Isn't a star shape too specific to deserve an own class in a basic multimedia library? Stars are rarely used as building blocks for more complex shapes. They are rather a nice feature for experiments, aka. "by the way, we have stars" ;) Additionally, I'd personally classify regular polygons (equilateral triangle, square) as more important. But in my opinion, both are a little bit too specific for SFML... At least that's my spontaneous view, perhaps this feature has been requested in the past.
To sum up, I think you shouldn't spend too much time on the interface of sf::StarShape, since stars are unimportant compared to the powerful new API, and they can be easily added later.
-
Stars might be real useful for particles, no?
-
Not really, too inefficient. A sprite with a star painted on it is much more efficient. When it comes to particles you want to limit as much as possible as of what you send to the graphics card as it becomes quickly the bottleneck. So increasing the amount of points is not good. (That's why with geometry shaders you can create the entire particle system on the GPU by sending data per cloud instead)
-
So far my walls are built up with shapes so they can't have textures. I'll now start looking into using VertexArray instead for that.
Just to make it clear: shapes can have a texture with this new API.
But another question: Why do you want the user to access only the outer points (spikes or whatever)? I mean, he specifies the radius of the inner points, too. So he is aware of their existence, but has no access.
I don't want users to only have access to the outer points. It's just that StarShape::SetPointsCount defines the number of spikes, it's more natural like this.
Maybe even one step further: Isn't a star shape too specific to deserve an own class in a basic multimedia library? Stars are rarely used as building blocks for more complex shapes. They are rather a nice feature for experiments, aka. "by the way, we have stars" Additionally, I'd personally classify regular polygons (equilateral triangle, square) as more important. But in my opinion, both are a little bit too specific for SFML... At least that's my spontaneous view, perhaps this feature has been requested in the past.
You're right, it's just to say "by the way we have stars", nothing more :mrgreen:
But it's the only valid shape that is not convex. So I thought it would be cool to provide it directly.
To sum up, I think you shouldn't spend too much time on the interface of sf::StarShape, since stars are unimportant compared to the powerful new API, and they can be easily added later.
So you suggest that I remove it, rename GetOutlinePoint/GetOutlinePointsCount to GetPoint/GetPointsCountand move them to the public part of sf::Shape?
-
Just to make it clear: shapes can have a texture with this new API.
I LOVE YOU! *cries a little* <3 :oops:
-
I don't want users to only have access to the outer points. It's just that StarShape::SetPointsCount defines the number of spikes, it's more natural like this.
But then, GetPoint() is expected to return only points in this range, too -- that is, the outer points. If GetPointsCount() returned the number of all polygon points, you could have the convention that even indexes refer to the outer and odd ones to the inner points, just as an example. Or you provide additional methods like Get/SetSpikesCount() which halve that number.
So you suggest that I remove it, rename GetOutlinePoint/GetOutlinePointsCount to GetPoint/GetPointsCountand move them to the public part of sf::Shape?
Yes, I would provide GetPoint() and GetPointsCount() as an iteration interface. And if the sf::StarShape API doesn't conflict with the rest of the design, you can also leave the class ;)
-
Now that I think of it, why not have SFML take advantage of initializer lists? Just add a preprocessor macro SFML_USE_CPP_0X so those parts can be disabled for non-compliant compilers and have the magical ones do all the good stuff.
Vector2f x = {1, 1};
Rectangle y = {1, 1, 2, 2};
-
I didn't see the API yet, sorry, but I think a star class should be used as an example of a custom shape, either on sfml examples or provided at the wiki. It doesn't sound very useful as a built in feature of SFML.
-
But then, GetPoint() is expected to return only points in this range, too -- that is, the outer points. If GetPointsCount() returned the number of all polygon points, you could have the convention that even indexes refer to the outer and odd ones to the inner points, just as an example. Or you provide additional methods like Get/SetSpikesCount() which halve that number.
But there's no problem here, the two possible solutions are:
- leave everything as it is now
- rename SetPointsCount in sf::StarShape (to SetSpikesCount, for example), and set GetPoint/GetPointsCounts in sf::Shape public
Yes, I would provide GetPoint() and GetPointsCount() as an iteration interface. And if the sf::StarShape API doesn't conflict with the rest of the design, you can also leave the class
... and I still need to find a name for the "spkies" of a star :D
Now that I think of it, why not have SFML take advantage of initializer lists? Just add a preprocessor macro SFML_USE_CPP_0X so those parts can be disabled for non-compliant compilers and have the magical ones do all the good stuff.
Yes, I'll probably add support for C++11 features in a future version of SFML 2.
-
I've added constructors to all shape classes. And default constructors now create empty shapes.
-
When I add points to sf::ConvexShape, do they have to be oriented clockwisely? The documentation only speaks about "ordered", the following example doesn't create a line as expected. What do I do wrong?
#include <SFML/Graphics.hpp>
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
sf::ConvexShape cs;
cs.SetPointsCount(4);
cs.SetFillColor(sf::Color::Cyan);
cs.SetPoint(0, sf::Vector2f(20.f, 20.f));
cs.SetPoint(1, sf::Vector2f(20.f, 21.f));
cs.SetPoint(2, sf::Vector2f(140.f, 21.f));
cs.SetPoint(3, sf::Vector2f(140.f, 20.f));
while (window.IsOpened())
{
sf::Event event;
while (window.PollEvent(event))
{
if (event.Type == sf::Event::Closed)
window.Close();
}
window.Clear();
window.Draw(cs);
window.Display();
}
}
And concerning the new semantics of SetPointsCount() and SetPoint() vs. the old AddPoint(): Is it always defined what happens when resizing? The problem is, there may now be invalid situations, when the amount of points is increased, but no new points are specified. Do these points get valid default values?
-
When I add points to sf::ConvexShape, do they have to be oriented clockwisely?
This example is strange, for me the result doesn't depend on the order of the points, but rather on the thickness of the line.
And concerning the new semantics of SetPointsCount() and SetPoint() vs. the old AddPoint(): Is it always defined what happens when resizing? The problem is, there may now be invalid situations, when the amount of points is increased, but no new points are specified. Do these points get valid default values?
They are (0, 0) by default.
-
This example is strange, for me the result doesn't depend on the order of the points, but rather on the thickness of the line.
At me, too, sorry. I just corrected it, but you were faster ;)
Might the problem be that you create two additional vertices in sf::Shape? Do you really need them? When I write an own shape class with direct access to sf::VertexArray, it works:
#include <SFML/Graphics.hpp>
struct MyShape : sf::Shape
{
virtual unsigned int GetOutlinePointsCount() const
{
return array.GetVerticesCount();
}
virtual sf::Vector2f GetOutlinePoint(unsigned int index) const
{
return array[index].Position;
}
virtual void Draw(sf::RenderTarget& target, sf::RenderStates states) const
{
target.Draw(array, states);
}
void SetPointsCount(unsigned int c)
{
array.Resize(c);
array.SetPrimitiveType(sf::TrianglesFan);
}
void SetPoint(unsigned int i, sf::Vector2f pos)
{
array[i] = sf::Vertex(pos, sf::Color::Yellow);
}
private:
sf::VertexArray array;
};
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
MyShape ms;
ms.SetPointsCount(4);
ms.SetPoint(0, sf::Vector2f(20.f, 20.f));
ms.SetPoint(1, sf::Vector2f(20.f, 21.f));
ms.SetPoint(2, sf::Vector2f(140.f, 21.f));
ms.SetPoint(3, sf::Vector2f(140.f, 20.f));
sf::ConvexShape cs;
cs.SetPointsCount(4);
cs.SetPoint(0, sf::Vector2f(20.f, 20.f));
cs.SetPoint(1, sf::Vector2f(20.f, 21.f));
cs.SetPoint(2, sf::Vector2f(140.f, 21.f));
cs.SetPoint(3, sf::Vector2f(140.f, 20.f));
cs.SetFillColor(sf::Color::Green);
cs.Move(0.f, 80.f);
while (window.IsOpened())
{
sf::Event event;
while (window.PollEvent(event))
{
if (event.Type == sf::Event::Closed)
window.Close();
}
window.Clear();
window.Draw(ms);
window.Draw(cs);
window.Display();
}
}
I've added constructors to all shape classes. And default constructors now create empty shapes.
You should make constructors that can be called with one argument explicit. I always forget this, too... :)
-
By the way, can't we flip drawables -- especially sprites -- anymore? There is neither a SetFlippedX/Y() nor a SetScale() allowing negative factors...
-
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.
-
Might the problem be that you create two additional vertices in sf::Shape?
This problem is now solved.
-
Wow SFML is amazing!
Question though....how will this affect existing code? Will most of it work?
-
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:
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.
-
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.
-
By the way, I'm now implementing support for vertex shaders.
-
By the way, I'm now implementing support for vertex shaders.
My love for you keeps on growing <3 ^^
-
My love for you keeps on growing <3 ^^
I was sure you would say that :mrgreen:
-
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.
-
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.
-
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?
-
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") ;)
-
Will the change have an impact on the performance of existing (thus using the old interface) code?
-
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.
-
I also forgot to say that textures can now be repeated (SetRepeated / IsRepeated).
-
Why couldn't you keep the AddPoint function on shapes? Ineffective sure but it's easier to get up and running and I don't see how it would interfere with the rest except being a nice natural way to add points with :)
Ow yeah on a side note, currently I'm doing my inter-thread messaging a bit lazy.... All I do is more or less send an ID, a drawable and what to do with it. Like a SpriteUpdate message would have me do a simple operation like:
*mySprites[ message.id ] = *message.spritePtr
And the same for shapes.
Though with this new API I am guessing that drawables will get heavier and I should start and do it properly? (Wrapper class on logic side and only have SFML stuff on render side)
Or will I still be able to stay with this lazy approach? :P
The less I need to implement the better ^^
Also maybe just me being lazy, but how about a GetSize and GetPosition on Rect classes? Just convenience functions really but would make code more elegant :)
Edit: Just did the conversion, holy shit ballz it's slow XD Just did it quite fast and ugly and will start looking at what is actually slow but daaaamn. I am having seconds per frame :P Must be stupidity on my side.
-
Why couldn't you keep the AddPoint function on shapes? Ineffective sure but it's easier to get up and running and I don't see how it would interfere with the rest except being a nice natural way to add points with
In what kind of situation would it be significantly better than using SetPointsCount + operator[]?
Though with this new API I am guessing that drawables will get heavier and I should start and do it properly?
It depends. Drawables are now heavier to copy, but it may be even heavier to update their internal vertex array after updating one of their properties. So it's up to you to decide wether you want
- lightweight messages, no heavy copy but potentially expensive updates of objects
- bigger messages, a big copy to update the objects but no expensive operation
Also maybe just me being lazy, but how about a GetSize and GetPosition on Rect classes? Just convenience functions really but would make code more elegant
I find it strange to be able to write both rect.Width and rect.GetSize() (direct access vs function call). These functions can easily be implemented outside the class.
Just did the conversion, holy shit ballz it's slow XD Just did it quite fast and ugly and will start looking at what is actually slow but daaaamn. I am having seconds per frame
Please focus on the API, there's no optimization yet so the performances are worse than before
-
In what kind of situation would it be significantly better than using SetPointsCount + operator[]?
None actually, I just find it natural and easier to use. Also in a case where we want a variable amount of points it would be easier. Though the more efficient way would be to discover the amount and do the SetPointsCount way of course.
It depends. Drawables are now heavier to copy, but it may be even heavier to update their internal vertex array after updating one of their properties. So it's up to you to decide wether you want
- lightweight messages, no heavy copy but potentially expensive updates of objects
- bigger messages, a big copy to update the objects but no expensive operation
Hmm sounds like I should wait and see and see how it becomes. Do small scale tests of both ways and profile them.
I find it strange to be able to write both rect.Width and rect.GetSize() (direct access vs function call). These functions can easily be implemented outside the class.
Well it's just that I often will have to write:
sf::Vector2f( sprite.GetGlobalBounds().Width, sprite.GetGlobalBounds().Height )
And having a simple sf::Rect::GetSize that does that for you would just be for convenience.
Please focus on the API, there's no optimization yet so the performances are worse than before
Well yeah I did read that but I was very surprised in the difference. So my initial thought was "I must have done something wrong"
-
None actually, I just find it natural and easier to use. Also in a case where we want a variable amount of points it would be easier.
Ok, I have to think about it. I guess adding Clear() and AddPoint() wouldn't make the class ugly ;)
Well it's just that I often will have to write:
sf::Vector2f( sprite.GetGlobalBounds().Width, sprite.GetGlobalBounds().Height )
Write a GetSize(sf::Rect<T>) function ;)
-
Lol I like how my game lags a lot but my logic update time is still 0ms / Update ^^
Anyway I haven't seen any direct bugs or anything like that. I could more or less copy-paste this thing in. The only thing needed to be changed was sf::Shape to sf::ConvexShape
And you said you added texture support? I only see a SetTexture.... So...it calculates UV itself? OMG THAT'S SO SWEET! Time to texture my walls! Finally :D :twisted:
-
it calculates UV itself? OMG THAT'S SO SWEET! Time to texture my walls! Finally
By the way, why don't you use sf::Sprite for your textured walls? Do you have non-rectangular walls? If so, I hope that it's not to fake a depth effect, because texture mapping will most likely not produce the result that you expect.
-
it calculates UV itself? OMG THAT'S SO SWEET! Time to texture my walls! Finally
By the way, why don't you use sf::Sprite for your textured walls? Do you have non-rectangular walls? If so, I hope that it's not to fake a depth effect, because texture mapping will most likely not produce the result that you expect.
DANG! Ah well I'll look into it tomorrow or something like that. Worst case, I just write my own custom drawable class to handle it ;)
You can see what I do here: http://youtu.be/CdcDim0yR70
The white shapes, are the wall shapes, and will probably be a custom class later. Depending if I get it general enough, should I share it with you?
-
I think you'll have to modify many things to get correct perspective mapping. So... why don't you do true 3D directly :?:
What's the purpose of a fake 3D renderer?
-
What's the purpose of a fake 3D renderer?
It's fun :D
Well most basic reason. But I actually like the look and at Nordic Game Conference I attended a seminar where they talked about how limitations fuel creativity where they mostly refereed to the just released Nordic indie game Limbo. (And to honest they only talked about the graphics, but programming a game makes you into an artisan as well as it is a form of art ;) So the same applies to us)
And getting correct look without perspective correct textures are possible. Doom uses Affine texture mapping ;) Doesn't look bad. It all depends on the angle and I only have one angle really. That's why it is possible for me to fake the 3D at all.
Characters and objects will be a bitch to work with it :P But most probably they will just be flat sprites drawn in a 45 degrees angle in the drawing application. So it becomes a 2D "people" in a 3D world :P
-
Hi, I've only tested the new API a few minutes, this is just an early feedback.
- I wish RectangleShape had a ctor which doesn't require a Vector2f object:
RectangleShape(float Width, float Height);
- Why did you rename sf::Blend::XYZ to sf::BlendXYZ?
- Where are the blend mode methods gone? (GetBlendMode/SetBlendMode)
Shouldn't they be implemented in sf::Drawable?
- I also miss several methods on transformable objects:
SetX, SetY, GetSize
Even if such operations can still be performed, I miss those higher-level methods, which I found convenient and avoid writing code like this:
sprite.SetPosition(42, sprite.GetPosition().y)
instead of:
sprite.SetPosition(42)
-
I wish RectangleShape had a ctor which doesn't require a Vector2f object
Already discussed in previous pages ;)
Why did you rename sf::Blend::XYZ to sf::BlendXYZ?
For consistency. I don't think it changes the user code significantly.
Where are the blend mode methods gone? (GetBlendMode/SetBlendMode)
Shouldn't they be implemented in sf::Drawable?
It is in sf::RenderStates. Basically, you can now write this:
window.Draw(sprite, sf::BlendNone);
sf::Drawable has a different role now, it's not supposed to provide any service other than a Draw function.
It could be added to each high-level class (sprite, test, shape), but I'm not sure that it would be necessary.
I also miss several methods on transformable objects:
SetX, SetY, GetSize
I tried to cleanup the API a little bit. There was too many functions in drawable entities.
Let's see if enough users want them back ;)
-
What a fast replay, as always :)
I wish RectangleShape had a ctor which doesn't require a Vector2f object
Already discussed in previous pages ;)
Missed this request, my bad!
For consistency. I don't think it changes the user code significantly
Indeed that's really no big deal, I was just curious.
Basically, you can now write this:
window.Draw(sprite, sf::BlendNone);
Ok! It seems fine as well.
I tried to cleanup the API a little bit. There was too many functions in drawable entities.
Let's see if enough users want them back ;)
Oh, it wasn't that bloated, IMHO.
To be honest, I would even take it one step further and request some extra GetX / GetY methods...
-
Is this a bug? I remember it looked like this if I turned on outlines on the old shape class but this just became visible when I added a texture to my shapes.
(https://legacy.sfmluploads.org/cache/pics/188_shape%20lines.png)
Also does it matter the order I create/use points with for the UV-coordinate generations? Let's say I would like to rotate the texture 90 degrees, so if I rotate the order of points would it then also be rotated?
Note: Damn your probably right, I should do this with 3D instead. =/
It's not fun anymore XD
-
Is this a bug?
Depends what you do to get it. A minimal and complete example would be appreciated ;)
Also does it matter the order I create/use points with for the UV-coordinate generations? Let's say I would like to rotate the texture 90 degrees, so if I rotate the order of points would it then also be rotated?
Nop, the texture is mapped according to the local position of points relatively to the local bounding rectangle. So the texture itself can't be rotated, you must rotate the shape.
But why don't you use sf::VertexArray directly? You obviously don't need shapes dor simple textured quads.
-
Here it's a very special case when the points are really close, but it could just be my math for calculating the points that are stupid, I don't know, though it doesn't show without the outline.
If you move the mouse towards one of the corners of the window it should show when the points become more or less parallel. I guess that's why the outline fuck up?
#include <SFML/Graphics.hpp>
#define SIZE 16.f
#define HALF_SIZE 16.f / 2.f
int main()
{
sf::RenderWindow window( sf::VideoMode( 800, 600 ), "Test" );
sf::Event event;
sf::ConvexShape shape;
shape.SetFillColor( sf::Color::White );
shape.SetOutlineColor( sf::Color::Red );
shape.SetOutlineThickness( 1 );
shape.SetPointsCount( 4 );
shape.SetPosition( 400, 300 );
sf::Vector2f position;
sf::Vector2f camera(0,0);
while( window.IsOpened() == true )
{
camera = static_cast< sf::Vector2f >( sf::Mouse::GetPosition() );
sf::Vector2f movement;
movement.x = ( 34 * SIZE - camera.x ) / SIZE;
movement.y = ( 34 * SIZE - camera.y ) / SIZE;
position = sf::Vector2f( -HALF_SIZE, 0 );
shape.SetPoint( 0, position );
position = sf::Vector2f( HALF_SIZE, 0 );
shape.SetPoint( 1, position );
position = sf::Vector2f( HALF_SIZE, 0 );
position.x += movement.x;
position.y += movement.y;
shape.SetPoint( 2, position );
position = sf::Vector2f( -HALF_SIZE, 0 );
position.x += movement.x;
position.y += movement.y;
shape.SetPoint( 3, position );
window.Clear();
window.Draw( shape );
window.Display();
while( window.PollEvent( event ) == true )
{
if( event.Type == sf::Event::Closed )
{
window.Close();
break;
}
}
}
return 0;
}
This problem was on the previous API as well but I just ignored it and thought that my point calculation fucked up. But seeing how it appears to be when the points are aligned is when it fucks up. I don't even know if it's possible for you to handle that case in your code.
And still, it can be that it's just my point calculations that go haywire?
Update: Checked the exact positions of the points when given to the shape, they are as follow when the camera vector is 872x545
0# -8x0
1# 8x0
2# -12x-0.0625
3# 0x0
So they are ALMOST parallel and no values are "wrong"
-
If the bug was already there with the old API, you should rather open a new thread, we're getting off-topic here ;)
-
I've pushed the support for vertex shaders, as well as an upgrade of the "shader" example.
-
I've removed the sf::StarShape class, added GetPointsCount/GetPoint in sf::Shape, and added SetPointsCount in sf::CircleShape.
I think everything's ok now, according to the feedback I got in this thread.
I can start working on improving performances.
-
Quick question, how is state's now if you want to mix it up with 3D? Is gonna try that next with the new graphics API.
Does it work like it did before where you have to preserve the states? (And will it change?)
-
There are two strategies.
1. PushGLStates/draw SFML/PopGLStates()
This one is simple but not optimized, SFML saves *all* the OpenGL states, even the ones that you don't care about
2. your own push/ResetGLStates/draw SFML/your own pop
Here you can save and restore only the states that you need, and ResetGLStates takes care of setting all the states that SFML needs for its own drawing.
-
Nice! Today, I have applied the changes to Thor, and the shapes work very well so far.
However I have a problem with my particle systems which use OpenGL and sf::Texture. Nothing is drawn anymore. I have renamed SaveGLStates() and RestoreGLStates() calls, but this is the only modification in my code. Apart from that, is there something to consider with the new Graphics API?
-
I've pushed the support for vertex shaders, as well as an upgrade of the "shader" example.
Any chance this could be pushed into the current SFML2 dev build?
Or is it possible to just take the new shader.hpp/cpp and swap them with current SFML2 dev build?
-
Any chance this could be pushed into the current SFML2 dev build?
Or is it possible to just take the new shader.hpp/cpp and swap them with current SFML2 dev build?
Vertex shaders don't make sense with the old graphics API, so I won't push them alone in the master branch. And no, you can't use the new version without the new API.
But why don't you switch to the new API anyway? It's just a matter of weeks before it becomes official.
However I have a problem with my particle systems which use OpenGL and sf::Texture. Nothing is drawn anymore.
I think we'll need a complete/minimal code ;)
By the way, have you tried to use sf::VertexArray instead of OpenGL? Unless you do something very specific, you should now be able to implement particle systems with SFML only.
-
Any chance this could be pushed into the current SFML2 dev build?
Or is it possible to just take the new shader.hpp/cpp and swap them with current SFML2 dev build?
Vertex shaders don't make sense with the old graphics API, so I won't push them alone in the master branch. And no, you can't use the new version without the new API.
But why don't you switch to the new API anyway? It's just a matter of weeks before it becomes official.
However I have a problem with my particle systems which use OpenGL and sf::Texture. Nothing is drawn anymore.
I think we'll need a complete/minimal code ;)
By the way, have you tried to use sf::VertexArray instead of OpenGL? Unless you do something very specific, you should now be able to implement particle systems with SFML only.
True, im using pure openGL the actuall API wouldnt bother me too much tbh i just wanted a wrapper around shaders that isnt my ugly code :P
I take it this https://github.com/SFML/SFML/tree/drawables is the new API
-
I run into a little bug in drawables branch: Sprites only display the first pixel of the texture scaled to fill the whole area. Everything works normally if I use master branch instead of drawables branch.
Here's complete example to reproduce the bug:#include <SFML/Graphics.hpp>
#include <iostream>
using namespace sf;
using namespace std;
int main(int argc, char *argv[])
{
if(argc<2){
cout<<"Usage: "<<argv[0]<<" image_to_display"<<endl;
return 0;
}
RenderWindow wnd(VideoMode(640,480),"Sprite/Texture Bug in New Graphics API");
Texture img;
img.LoadFromFile(argv[1]);
Sprite obj(img);
while(wnd.IsOpened()){
Event ev;
while(wnd.PollEvent(ev)){
if(ev.Type==Event::Closed)
wnd.Close();
}
wnd.Clear();
wnd.Draw(obj);
wnd.Display();
}
return 0;
}
-
I'll try to minimize the example as soon as possible. Yes, I have already thought about working with sf::VertexArray, but not implemented any corresponding code yet. I guess the performance is similar to direct OpenGL, but don't I lose some flexibility (blend function, texture mapping filters etc)?
-
I run into a little bug in drawables branch: Sprites only display the first pixel of the texture scaled to fill the whole area. Everything works normally if I use master branch instead of drawables branch.
Are you sure that you cleaned/recompiled things properly? I can't reproduce this bug.
What's your graphics card, OS, drivers, ...?
I guess the performance is similar to direct OpenGL, but don't I lose some flexibility (blend function, texture mapping filters etc)?
Like I said, it depends what you were using before.
You can still apply the SFML blending modes to the vertex array.
What are "texture mapping filters"?
-
You can still apply the SFML blending modes to the vertex array.
But only the 4 predefined ones. One cannot combine the modes like glBlendFunc(). Not that I needed this functionality right now, just generally :)
What are "texture mapping filters"?
I meant GL_TEXTURE_MIN_FILTER and GL_TEXTURE_MAG_FILTER. What's the correct term?
-
I run into a little bug in drawables branch: Sprites only display the first pixel of the texture scaled to fill the whole area. Everything works normally if I use master branch instead of drawables branch.
Are you sure that you cleaned/recompiled things properly? I can't reproduce this bug.
What's your graphics card, OS, drivers, ...?
Well I originally checked out the drawables branch and compiled it and installed it. This Ubuntu 11.10 (x64) didn't have any sfml installed prior that. When I run into this bug I checked out master branch to different directory and run "cmake . && make -j5 && sudo make install && sudo ldconfig" After that all worked as expected. If I go back to drawables branch directory and run "sudo make install && sudo ldconfig" the issue is back. (and gone again if I do the same on master branch directory)
My graphics card is HD 5770 and drivers are normal fglrx drivers that Ubuntu installs automatically. I can try this same thing using open source drivers and then I can try to install newest fglrx.
-
I can try this same thing using open source drivers and then I can try to install newest fglrx.
That would be really cool. Thanks for helping.
-
I can try this same thing using open source drivers and then I can try to install newest fglrx.
That would be really cool. Thanks for helping.
It seems to work when using open source drivers :)
Seems like the problem was with fglrx after all. (Or maybe it was with Ubuntu's default configuration of fglrx...)
This new API looks pretty flexible. I can propably do now everything I want by just using SFML API without need for custom OpenGL calls. (Yes, I have been using this library for sometime although I only now registered myself to forum)
-
But only the 4 predefined ones. One cannot combine the modes like glBlendFunc(). Not that I needed this functionality right now, just generally
You can never mix OpenGL with SFML this way. So if you use your own OpenGL states, you won't be able to rewrite it with a SFML class. Whether it is particles or anything else.
I meant GL_TEXTURE_MIN_FILTER and GL_TEXTURE_MAG_FILTER. What's the correct term?
This is the correct term, I just didn't think about them ;)
SFML texture filters are supposed to be ok for any 2D rendering (filters other than "nearest" and "bilinear" are mostly for 3D), are you using something else for your particles?
It seems to work when using open source drivers
Good news :)
I can propably do now everything I want by just using SFML API without need for custom OpenGL calls.
If you have such a use case, can you tell me more about it?
I like to know what problems the new API is now able to solve compared to the old one.
-
Hi,
Do you know, approximatively, when this new API will be merged in SFML2 ?
-
Do you know, approximatively, when this new API will be merged in SFML2 ?
Probably in one or two weeks.
But why is it important? It is in SFML 2, just in a different development branch.
-
Hi,
first of all, great job on the new API, it's looking great! I'm converting/rewriting my project for it right now, really looking forward to the speed boost once it's optimized.
There's something rather confusing about Vertices though: they allow you to set the coordinates of a texture, but I couldn't find any way to specify which texture a VertexArray should actually be rendered with. Am I overlooking something here or is that code just not written yet? A while ago, an example of the new API was posted, where sf::RenderTarget::SetTexture() or something like that was used, but that doesn't appear to be in the API (anymore).
-
The global states are now defined in sf::RenderStates, which you pass an instance when you call Draw.
sf::RenderStates states;
states.Texture = &texture;
window.Draw(vertexArray, states);
Which, using implicit constructors, can be shortened to:
window.Draw(vertexArray, &texture);
-
Ah, so that's what states are for. I'm rather new to hardware accelerated graphical programming and to the concept of Vertices in this context, so I was thinking it was some internal OpenGL stuff. Thank you for clearing it up! :)
-
Do you know, approximatively, when this new API will be merged in SFML2 ?
Probably in one or two weeks.
But why is it important? It is in SFML 2, just in a different development branch.
Because the next Ludum Dare is this week end? ;) Merging in the main branch means "it's stable enough" for a lot of devs.
Anyway I guess SFML 2 should be stabilized for the next one.
-
Merging in the main branch means "it's stable enough" for a lot of devs
Yes, that's exactly why it's still in the 'drawables' branch ;)
I'd say that the code is stable enough, the public API almost stable, but the internal code is not optimized at all, so it's not ready for the master branch.
-
Quick question: now that sf::Shape::Line is gone, how can I easily draw a line from point A to point B ?
-
If your line has a thickness, it's a rectangle and you can use sf::RectangleShape.
If it has no thickness, you can draw two vertices in sf::Lines mode.
-
How exactly do you want to optimize the new rendering code?
It seems to be pretty optimized allready so far, but why do you set the OpenGL states on every draw call even though the shader may have to changed?
Isn't it faster to check if a state, shader or whatever has changed and then update it?
Sorry if this question is stupid. I have never used OpenGL before only Direct3D9 and Direct3D11 :)
-
If your line has a thickness, it's a rectangle and you can use sf::RectangleShape.
But if the line is neither vertical (A.x != B.x), nor horizontal (A.y != B.y), we must use trigonometry to compute the line length (rectangle width = distance between A and B), and then rotate the rectangle.
If it has no thickness, you can draw two vertices in sf::Lines mode.
I've played a bit with those primitive types, it's a nice feature :D
I will probably stick to this is solution when dealing with lines without thickness, I guess this is more optimized than using shapes.
But don't you think drawing a simple line should be more user-friendly than using primitive types?
-
It seems to be pretty optimized allready so far, but why do you set the OpenGL states on every draw call even though the shader may have to changed?
Isn't it faster to check if a state, shader or whatever has changed and then update it?
Yes... and this is exactly what I'm working on right now to optimize the code ;)
But if the line is neither vertical (A.x != B.x), nor horizontal (A.y != B.y), we must use trigonometry to compute the line length (rectangle width = distance between A and B), and then rotate the rectangle.
Yes. It's not a big deal.
I will probably stick to this is solution when dealing with lines without thickness, I guess this is more optimized than using shapes.
Yes, it's definitely more optimized.
But don't you think drawing a simple line should be more user-friendly than using primitive types?
I think it's pretty simple:
void DrawLine(sf::Vector2f a, sf::Vector2f b)
{
sf::Vertex line[2] = {a, b};
window.Draw(line, 2, sf::Lines);
}
-
just tried running the shader example but i get this:
./shader
Failed to compile fragment shader:
0:27(31): error: Could not implicitly convert operands to arithmetic operator
0:27(31): error: Operands to relational operators must be scalar and numeric
0:27(31): error: if-statement condition must be scalar boolean
-
It's hard to fix because I don't see this error on my computer. I tried something, can you tell me if the new code solves the problem?
-
The new API is looking promising! Congrats! However I'm really going to miss that sf::Sprite::GetSize().. oh well that's life! Looks like your long term planning might be paying off on this :D
-
No error message on the shader example but the window just opens and closes now
-
No error message on the shader example but the window just opens and closes now
Strange. Would you mind running the debugger, and show me the call stack?
-
richy@R-Laptop:~/Desktop/LaurentGomila-SFML-78e1e87/make/examples/shader$ gdb ./shader
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/richy/Desktop/LaurentGomila-SFML-78e1e87/make/examples/shader/shader...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/richy/Desktop/LaurentGomila-SFML-78e1e87/make/examples/shader/shader
[Thread debugging using libthread_db enabled]
[Inferior 1 (process 4080) exited with code 01]
(gdb)
tried building the debug version but got this:
CMake Error at CMakeLists.txt:133 (add_subdirectory):
add_subdirectory given source "examples" which is not an existing
directory.
-
tried building the debug version but got this:
CMake Error at CMakeLists.txt:133 (add_subdirectory):
add_subdirectory given source "examples" which is not an existing
directory.
Hum. You probably did something wrong. Try to delete everything, download SFML again and compile it directly in debug mode.
-
Anything I draw onto a RenderTexture isn't displayed.
sf::RenderTexture texture;
if (!texture.Create(300, 300)) return -1;
sf::CircleShape circle(100);
circle.SetFillColor(sf::Color::Green);
texture.Clear(sf::Color::Blue);
texture.Draw(circle);
texture.Display(); // display the drawn circle
while (window.IsOpened()){
window.Clear();
sf::Sprite sprite(texture.GetTexture());
window.Draw(sprite);
window.Display();
}
Output: black screen with a blue square on top left; the green circle is missing.
Also, possibly a typo on documentation?
sf::RenderTexture::SetSmooth: This parameter is enabled by default.
sf::Texture::SetSmooth: The smooth filter is disabled by default.
-
Anything I draw onto a RenderTexture isn't displayed.
Would you mind providing a complete source code? I know that it's almost complete, but this evening I'm a little lazy and don't have much time ;)
Also, possibly a typo on documentation?
sf::RenderTexture::SetSmooth: This parameter is enabled by default.
Yes. Thanks.
-
It's really just that :P
#include <SFML/Graphics.hpp>
int main(){
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
sf::RenderTexture texture;
if (!texture.Create(300, 300)) return EXIT_FAILURE;
sf::CircleShape circle(100);
circle.SetFillColor(sf::Color::Green);
texture.Clear(sf::Color::Blue);
texture.Draw(circle);
texture.Display();
sf::Event event;
while (window.IsOpened()){
while (window.PollEvent(event)){
if (event.Type == sf::Event::Closed){
window.Close();
}
}
window.Clear();
sf::Sprite sprite(texture.GetTexture());
window.Draw(sprite);
//window.Draw(circle);
window.Display();
}
return EXIT_SUCCESS;
}
-
It works for me. Do you have an Intel integrated graphics chipset?
-
ATI Mobility Radeon X1400
-
Are your drivers up-to-date?
-
After trying a lot seems that I couldn't get new drivers for my graphics card.. my guess is either due to ATI acquisition by AMD or this card being too old (5 years or so). It's not a bad time to think on a new computer.
-
compiled the debug shader example and:
(gdb) run
Starting program: /home/richy/Desktop/SFML2a/examples/shader/shader-d
[Thread debugging using libthread_db enabled]
/home/richy/Desktop/SFML2a/examples/shader/shader-d: symbol lookup error: /home/richy/Desktop/SFML2a/examples/shader/shader-d: undefined symbol: _ZN2sf6ShaderC1ERKS0_
[Inferior 1 (process 12155) exited with code 0177]
-
undefined symbol: _ZN2sf6ShaderC1ERKS0_
Are you sure that your executable uses the right SFML libraries?
-
Think I have managed to get it working now :D
BTW do you thnk the whole intel rendertarget bug will be fixed with the release of SFML2?
-
BTW do you thnk the whole intel rendertarget bug will be fixed with the release of SFML2?
No. This is for SFML 2.1.
-
I'm wondering about a thing in the shader class. Why does the setter function for matrixes require a mat4 when sf::Transform is only a 3x3 matrix? You should be able to upload a 3x3 matrix to a mat3 right? Or you got a certain reason for that?
Also a sf::Transform3D will not be provided right? That would make sense to upload to a mat4 then. Though it would not make sense in the 2D api of SFML, except for maybe if someone wants to create some special effect in the shaders where he needs a 3D matrix. ( Lighting, shadows, water, motion blur, etc. etc. ) But a very special case.
Or am I missing something?
Also this one is confusing: sf::Shader::SetParameter(const std::string& name, CurrentTextureType);
It let's you set the sampler which is the current texture? The texture we are drawing to? Or? I don't get it, is it the sprites texture? And what is the second parameter supposed to be?
-
sf::Transform will most likely be applied to vertices, which are vec4. So it's easier if it's a mat4. Even if only two components are relevant, you do all your shader calculations with 4 components.
Moreover, a sf::Transform is internally a 4x4 matrix, so it would require an extra step with copies in order to upload it as a 3x3 matrix.
Also this one is confusing: sf::Shader::SetParameter(const std::string& name, CurrentTextureType);
I thought the doc was clear enough, obviously it's not :?
It maps a sampler shader variable to the texture of the object being drawn (that's what the doc says). So if you draw a sprite, it will be the texture of the sprite. I don't know how to explain it differently, sorry.
The second parameter must be sf::Shader::CurrentTexture, nothing else (the doc says that too). It's like a tag that selects the right overload of SetParameter, the value itself doesn't mean anything (it's an empty struct). It's more elegant than writing a function with a different name just for this specific case, it keeps the syntax consistent with all other overloads.
-
sf::Transform will most likely be applied to vertices, which are vec4. So it's easier if it's a mat4. Even if only two components are relevant, you do all your shader calculations with 4 components.
Moreover, a sf::Transform is internally a 4x4 matrix, so it would require an extra step with copies in order to upload it as a 3x3 matrix.
But the public interface don't let us use it as a 4x4 matrix right? Which is too bad, though if the variable myMatrix is protected we can inherit from sf::Transform and implement our own 3D version right? Or we can just use the GetMatrix() function for that without having to have myMatrix protected.
I thought the doc was clear enough, obviously it's not :?
It maps a sampler shader variable to the texture of the object being drawn (that's what the doc says). So if you draw a sprite, it will be the texture of the sprite. I don't know how to explain it differently, sorry.
Yeah I read it and now it seems obvious, I don't know why I saw it as obscure. Though there might be others, especially newbies.
The second parameter must be sf::Shader::CurrentTexture, nothing else (the doc says that too). It's like a tag that selects the right overload of SetParameter, the value itself doesn't mean anything (it's an empty struct). It's more elegant than writing a function with a different name just for this specific case, it keeps the syntax consistent with all other overloads.
After writing I guessed it was something like that.
-
Are you going to merge the drawables branch with the regular one anytime soon?
-
But the public interface don't let us use it as a 4x4 matrix right? Which is too bad, though if the variable myMatrix is protected we can inherit from sf::Transform and implement our own 3D version right? Or we can just use the GetMatrix() function for that without having to have myMatrix protected.
There's absolutely no point using the 3rd row/column of the 4x4 matrix, which are dedicated to the Z component. SFML only deals with 2D.
Stop requesting 3D features, you won't get anything :lol:
Are you going to merge the drawables branch with the regular one anytime soon?
As soon as it is optimized enough. I don't want the master branch to be 3 times slower than before the update.
-
There's absolutely no point using the 3rd row/column of the 4x4 matrix, which are dedicated to the Z component. SFML only deals with 2D.
Stop requesting 3D features, you won't get anything :lol:
You misunderstood, it was just a question if it would be possible to create a 3D transform class that behaves like SFML's one through that. You know make it myself for my own stuff, so instead of providing an entire new class called Matrix44 I can just adopt sf::Transform to custom::Transform3D and it should work perfectly by itself together with the rest of SFML, right ;)
-
Ok I see. But I don't think that you can extend sf::Transform, you'll have to create your own class from scratch.
-
But if the line is neither vertical (A.x != B.x), nor horizontal (A.y != B.y), we must use trigonometry to compute the line length (rectangle width = distance between A and B), and then rotate the rectangle.
Yes. It's not a big deal.
So it doesn't worth creating a LineShape class?
I've also a couple of questions about the split Transformable/Drawable :
- In the previous graphics API, we were able to inherit from sf::Drawable in order to draw items relatively to the drawable position (I mean: positions of the items drawn in the overridden Render method were offset by the drawable's own position).
I cannot reproduce this behavior anymore (I've tested inheriting from Transformable - using my own Show method, and from Transformable + Drawable - using the overridden Draw method).
Is this feature still exist? If yes, how do I achieve this?
- Why don't you use a reference to pass the RenderStates object in the Drawable::Draw method?
virtual void Draw(RenderTarget& target, RenderStates states) const = 0;
Thanks
-
I'll answer both of your questions with a simple piece of code:
virtual void Draw(RenderTarget& target, RenderStates states) const
{
states.Transform *= GetTransform();
target.Draw(some_child_entity, states);
}
-
Great, it works fine. Thanks Laurent.
-
I've changed the type of Vertex::TexCoords, they are now floats. This was needed because some ATI drivers don't seem to handle integers correctly.
This fixes the stretched textures problem that some have reported after testing the new API.
-
I've changed the type of Vertex::TexCoords, they are now floats. This was needed because some ATI drivers don't seem to handle integers correctly.
Wouldn't it be better to keep ints at the user interface and to convert them to floats internally? Floats in the API have the disadvantage that it's not immediately clear whether the coordinates are in the interval [0, size] or [0, 1] and whether it makes sense to use non-integral coordinates.
-
Wouldn't it be better to keep ints at the user interface and to convert them to floats internally?
I can't, vertex arrays are sent directly to the graphics card, in one single call where I give the pointer to the first vertex and the number of elements.
Floats in the API have the disadvantage that it's not immediately clear whether the coordinates are in the interval [0, size] or [0, 1] and whether it makes sense to use non-integral coordinates.
Yes... I wish I could keep integers but it doesn't seem realistic to ignore all those ATI cards.
But it makes sense sometimes to use decimal coordinates (I might need it in the future if I tweak pixel-perfect rendering again). Some people might even need to use normalized coordinates, if they use their own vertex shader. So in the end it's not as bad as it seems ;)
-
One question regarding the new graphics stuff: You're already using vertex buffers, why aren't you using vertex buffer objects (VBO)?
-
VBOs would make the implementation more complicated, and performances worse in most cases.
-
Ow yeah wondering, will Textures support the SRGB format? Or is that feature to modern to be added?
I hate to work manually in those spaces so would love to miss that one out xD
-
VBOs would make the implementation more complicated, and performances worse in most cases.
Why is it more complicated? You already have the VertexBuffer class with data that only has to be uploaded to VRAM, that's it. Instead of transferring all the data every rendering cycle, you'd do it once per manipulation and just call the buffer object when rendering. I don't think performance gets worse than client-side buffers.
Can you point out what exactly will be impacting performance and what's actually complicated? Can't really think of real show-stoppers.
-
VBO's are not gods solution to performance in graphics card. It depends on the situation when it is suitable to use.
VBO's will only improve performance on the CPU side by minimizing the amount of opengl calls. And even with that, if we check when Klaim was creating ICE3 he did test VBO's and found out that he in fact in some cases got worse performance.
Now VBO's main task is to improve performance when we have a lot of data to be sent over many times to the GPU. Does SFML have that? No. I have already suggested things like this to let SFML support Instancing but the answer is no because SFML does not have a lot of vertexes to send over(common case is 4 so performance would certainly decline) and the real improvement in performance would be when we reaches somewhere around ~5 000-10 000 draw calls which would be insane to do in a 2D application. And we'll be long by then be GPU bound instead of CPU bound.
http://stackoverflow.com/questions/430555/when-are-vbos-faster-than-simple-opengl-primitives-glbegin
Here you can see that the developer who are trying to measure but get's similar results are GPU bound, no matter what he does on the CPU side his frame rate stays the same. Now I don't know if that guy did it correctly or maybe he didn't use static VBO or something like that which we could utilize. But if Laurent says that he would get worse performance, I would understand why ^^
Found this little document which might be interesting if you like this sort of thing: http://developer.amd.com/media/gpu_assets/PerformanceTuning.pdf
-
Ow yeah wondering, will Textures support the SRGB format?
Before asking for a specific format, you should first ask if SFML will ever provide support for multiple formats ;)
Why is it more complicated? You already have the VertexBuffer class with data that only has to be uploaded to VRAM, that's it. Instead of transferring all the data every rendering cycle, you'd do it once per manipulation and just call the buffer object when rendering. I don't think performance gets worse than client-side buffers.
Can you point out what exactly will be impacting performance and what's actually complicated? Can't really think of real show-stoppers.
VBO data are stored in the graphics card memory. SFML needs it to be in system memory, because it may change frequently before being rendered (SFML is not high-level enough to ensure an optimal vertex data flow), and most important, it requires random read access.
With vertex arrays I'm already slower than immediate mode when drawing small vertex arrays (sprites), VBOs would just make things unusable.
Most people think that VBOs are always better than anything else, in any situation. But that's far from being true, things are more complicated.
-
I'm not claiming that VBOs will solve every FPS problem, but indeed there are a lot cases where you at least want to have the possibility to optimize.
A good example is SFGUI. By throwing in some classes for pure optimizations we were able to increase FPS by 500-1000% (depending on the system). It was GPU-bound before, and after we've done some simple(!) optimizations one of the slowest operations was dereferencing smart pointers, just to give you an idea (i.e. CPU-bound after).
We implemented display lists in which Draw() calls got compiled. Besides of that also culling has been applied, which again decreased frame time (this is not a general case however, depends on the application).
because it may change frequently before being rendered
Theoretically, yes. But seriously, when do you need to modify shapes after creating them? Sprites for example don't need to be changed at all except texture coordinates. In most cases you prepare your geometry and render it. And this isn't limited to 3D applications.
If SFML could give the choice of enabling buffer objects I assume that would indeed be used in many cases. It could be done similar to splitting up sf::Image into sf::Image and sf::Texture. For fixed geometry (which is the majority in my opinion) put the stuff into a buffer object, done. For dynamic geometry, either upload the buffer every rendering cycle OR update the buffer object when it actually got modified.
-
But you forget one very important thing: what needs to be optimized in SFML is the drawing of many small entities (where vertex arrays and VBOs are not good at all). Drawing one big vertex array is lightning fast, there's no need to optimize this use case at all.
Most use cases that were too slow with the previous API will be ok with the new one, just by grouping similar primitives into vertex arrays. I'm not worried at all about that. What causes me troubles are sprites and shapes, and I probably won't get them faster without some kind of batching.
Before trying to optimize SFML, one needs to understand how it works, and where the bottlenecks are. I'm open to all ideas, but if they are not applied to SFML's specific uses cases they won't help much ;)
-
Personally, I'm fine with whatever Laurent picks, provided that:
1. It's fast enough
2. It's simple enough to learn and use
3. It's widely supported
4. Does not rely on deprecated OpenGL functionality (e.g. features not available in Core Profile and OpenGL ES 2.0)
And option 4 does not even have to happen immediately for SFML 2.0 - it can happen gradually over the next few versions.
-
Before trying to optimize SFML, one needs to understand how it works, and where the bottlenecks are. I'm open to all ideas, but if they are not applied to SFML's specific uses cases they won't help much
We'll see how it works out especially with SFGUI and the new API. I'll try to port it as fast as possible, but I'm still convinced there'll be much more potential (we're also NOT using VBOs, because it doesn't make sense; just to show I'm no "VBO cures everything" guy). Sure, when the FPS counter says "1000", it's fast, but if it can show "1500", it's even faster. You once said such high FPS are not important; I think they are, it shows potential and places where things can be optimized. Hopefully I'm wrong. ;)
1. It's fast enough
Compared to what? :) Like said above, if something's running at 800 FPS and your vsync rate is 60 Hz, then yes, you may think it's fast. But if you can get even more which also means you can spend time (which is rare) on other things, wouldn't it be worth it?
2. It's simple enough to learn and use
I agree to that, however simple shouldn't mean that everything must be obvious at first glance. "RTFM" is always required. ;)
-
We'll see how it works out especially with SFGUI and the new API
That's a very interesting use case, let me know when it's done :)
Sure, when the FPS counter says "1000", it's fast, but if it can show "1500", it's even faster. You once said such high FPS are not important; I think they are, it shows potential and places where things can be optimized.
I have a slightly different point of view. If you can optimize further without making the code more complicated, and without touching the public API, then yes, optimize. But if it requires complicated tricks that make the code less maintainable, or adding dedicated functions to the public API, then is it worth the extra FPS?
2D is not as intensive as 3D, it doesn't require a lot of work to get very good performances. So, my plan is to see if everyone is happy with the new API, and optimize it only if it is required, after gathering enough feedback and use cases.
-
If you really want to go there and achieve most possible FPS you would like to implement pseudo-instancing(since SFML will be limited to OpenGL 2.0 I think it was, else we can do real) which will fit perfect for objects that are repeated a lot with small to no changes between draw calls(Sprites). The problem would be like Laurent says he wants to avoid, making the code less maintainable. Everything will have to be more or less constructed around that as it's core.
But this would require batching internally by SFML in order to keep the code simple enough. But like said, you won't be able to get better FPS than that. And Laurent has already put his foot down there and said no ;) Not going to argue with that.
Also, Merry Christmas!
Swede's celebrate it on the 24th ;)
-
That's a very interesting use case, let me know when it's done
Will do.
I have a slightly different point of view. If you can optimize further without making the code more complicated, and without touching the public API, then yes, optimize.
I also like "Don't do premature optimization" and "Design over performance", but if it's possible without "tricks", one should do it. We're not talking about dirty hacks here, instead we're talking about established and well-known and -used OpenGL features, not hacks.
But if it requires complicated tricks that make the code less maintainable, or adding dedicated functions to the public API, then is it worth the extra FPS?
I'm absolutely sure those optimizations are everything but complicated. I already mentioned it: By using a simple OpenGL display list we were able to boost FPS a lot. a) It's not complicated. b) It can live next to the regular public API, i.e. the user is not forced "to use the optimizations".
2D is not as intensive as 3D, it doesn't require a lot of work to get very good performances.
2D can be very intensive, too. Simple example: Imagine you've got a tilemap, 16*16 pixels for each tile. For a resolution of 1024*768, you've got 64*48 tiles, i.e. 3,072 quads = 12,288 vertices. With SFML you HAVE TO send those 12,288 vertices through the bus EVERY rendering cycle. It will still be "fast" if you compare FPS to a minimum value, but indeed you could go A LOT faster, having more resources for other stuff (logics, physics, etc.). And vertex arrays don't help you out here, too: You still have to send the array through the bus. Buffer objects however can save a lot of time (did it myself, HUGE benefit).
Again, we do it like that in SFGUI: In the beginning we had ~500 FPS with a good amount of widgets. And you could have stopped by saying "500 is good!". Now there're 1200+ FPS. That makes a bunch of extra frametime available to the developer using SFGUI, thus it's getting not as much into his way as before, which is good (especially for libraries!).
So, my plan is to see if everyone is happy with the new API, and optimize it only if it is required, after gathering enough feedback and use cases.
I really did it like you with SFGUI. Then binary1248 joined the party and optimized the hell out of it; seriously, I'm thankful for that: It showed what's possible with rather simple code. ;) In my humble opinion one should always try to get the best results than just making the "average user" just happy.
If you really want to go there and achieve most possible FPS you would like to implement pseudo-instancing(since SFML will be limited to OpenGL 2.0 I think it was, else we can do real)
Instancing is another side of the medal. However, saying SFML is limited to OpenGL 2.0 is wrong. It's not limited to anything. You can add fallbacks. Hardware supporting instancing can use it, the others will use fallbacks. It's done like that in so many games/applications..
The problem would be like Laurent says he wants to avoid, making the code less maintainable. Everything will have to be more or less constructed around that as it's core.
The real problem is that you don't have the choice really. In SFGUI we already had to work-around SFML's rendering pipeline "a bit" to make some optimizations possible. And I don'T see a clear reason why adding conditional features to a library makes it less maintainable. If those things were hacks, then yes, I fully agree. But we don't have hacks, we have normal features. You could also argue that adding vertex buffers is unmaintanable because you have OpenGL immediate mode, it's useless. ;)
But this would require batching internally by SFML in order to keep the code simple enough. But like said, you won't be able to get better FPS than that. And Laurent has already put his foot down there and said no Not going to argue with that.
Well, why has everything to be "simple"? If you don't need optimizations and "pro" features, don't use them. If someone doesn't need batching, because his Pacman game has great performance, everything's alright. But why don't allow the user to have more control of the whole pipeline? I think this is perfectly possible, without striping out the "S" out of "SFML". Simple is relative, too. ;)
And just because Laurent says "No" it doesn't mean I'll say "Alright". ;) I think such discussions are welcome and everybody should be able to think about it and honestly admit to be wrong if that's the case. If there's nothing left in SFML to be optimized without raping the whole API, then I'll paddle back and officially state a "Sorry, you were right". ;)
Also, Merry Christmas!
Swede's celebrate it on the 24th
Merry Christmas to you guys too. Same in Germany. ;)
-
I'm absolutely sure those optimizations are everything but complicated. I already mentioned it: By using a simple OpenGL display list we were able to boost FPS a lot. a) It's not complicated. b) It can live next to the regular public API, i.e. the user is not forced "to use the optimizations".
VBOs are not complicated, but using them efficiently in SFML can be tricky. For example, creating a 4-vertex VBO in each sprite would be very innefficient. It would also make sprites heavier than they are supposed to be (each copy would create a duplicate VBO on the graphics card). And how do you provide read access to the vertices? You have to add lock/unlock functions to every class in which you want to do it.
2D can be very intensive, too. Simple example: Imagine you've got a tilemap, 16*16 pixels for each tile. For a resolution of 1024*768, you've got 64*48 tiles, i.e. 3,072 quads = 12,288 vertices. With SFML you HAVE TO send those 12,288 vertices through the bus EVERY rendering cycle. It will still be "fast" if you compare FPS to a minimum value, but indeed you could go A LOT faster, having more resources for other stuff (logics, physics, etc.). And vertex arrays don't help you out here, too: You still have to send the array through the bus. Buffer objects however can save a lot of time (did it myself, HUGE benefit).
I get 500 FPS with a 100x100 tilemap (40000 vertices). I would be glad to get 1000 FPS, yes, but I don't think that it can be done without making the API ugly.
Again, we do it like that in SFGUI: In the beginning we had ~500 FPS with a good amount of widgets. And you could have stopped by saying "500 is good!". Now there're 1200+ FPS. That makes a bunch of extra frametime available to the developer using SFGUI, thus it's getting not as much into his way as before, which is good (especially for libraries!).
It's not even a millisecond. 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)? Like I already told you before, you should do your benchmarks with more things to draw and less FPS.
I really did it like you with SFGUI. Then binary1248 joined the party and optimized the hell out of it; seriously, I'm thankful for that: It showed what's possible with rather simple code.
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 ;)
And just because Laurent says "No" it doesn't mean I'll say "Alright". I think such discussions are welcome and everybody should be able to think about it and honestly admit to be wrong if that's the case.
Yes. Please don't stop discussing just because I said "no", I'm sometimes (often?) wrong ;)
-
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.
-
great work! :)
-
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:
-
Alright, let's see... :twisted:
Yeah :D
-
Optimisation is always good, can do more per frame :P
-
So when will the official release be? :)
-
So when will the official release be?
Soon.
-
Can you add some more hints in the documentation for methods like this?
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).
-
You're right, thanks for the feedback :)
-
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)?
-
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.
-
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
-
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:
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).
-
I'll investigate this issue as soon as I can. Thanks.
-
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.
-
Could you please post a complete and minimal example that reproduce the problem, for both issues?
-
Okay, I'm able to reproduce it.
#include <SFML/Graphics.hpp>
#include <SFML/Audio.hpp>
int main(void)
{
sf::Texture tex1, tex2;
sf::RenderWindow window;
sf::Sound test1[16]; // this will cause the "tons of threads" (Windows 7 x64 with MinGW32) running a X-Fi Xtreme Music
tex1.LoadFromFile("test1.bmp"); // this texture won't show up on Ubuntu 11.10 (x64 in VirtualBox) - it will show up as test2.bmp
window.Create(sf::VideoMode(320, 240), "");
sf::Sound test2[16]; // this is fine
tex2.LoadFromFile("test2.bmp"); // this is fine too
sf::Sprite spr1(tex1);
sf::Sprite spr2(tex2);
spr2.SetPosition(32,0);
while(window.IsOpened())
{
sf::Event event;
while (window.PollEvent(event))
{
if (event.Type == sf::Event::Closed)
window.Close();
}
window.Clear();
window.Draw(spr1);
window.Draw(spr2);
window.Display();
sf::Sleep(0);
}
}
Output on Windows 7 (x64):
(http://i.imgur.com/a5Tg5.png)
Output on Ubuntu 11.10 (x64; VirtualBox):
(http://i.imgur.com/kRSnJ.png)
The code above also causes the bug with tons of threads created over and over again (X-Fi Xtreme Music; not sure if that's important).
Regarding the two texture files, both are 128x128 pixels, test1.bmp is blue, test2.bmp is red.
-
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?
Wouldn't returning *this from setters allow setting any structure in "one-liners", like in Ogre::Procedural (http://code.google.com/p/ogre-procedural/)?
Example :
http://codepad.org/OQewh4E1
#include <iostream>
class Test
{
public:
Test( int k ) : m_k(k){}
int k() const { return m_k; }
Test& incrementK() { m_k++; return *this; } // note that it's not const
private:
int m_k;
};
int main()
{
std::cout << "Test value : " << Test(0)
.incrementK()
.incrementK()
.incrementK()
.k()
<< '\n'; // prints "Test value : 3"
return 0;
}
It's a very powerful idiom for types like Shape and it's child classes (and others I guess) because it allows the developer to provide simple constructor but still allow "in place construction" (where its not a big performance problem to setup the object outside the constructor -- meaning not in Verctor classes for example).
It would allow to write this :
rt.Draw(sf::RectangleShape( {0,0} ).SetSize( 100, 100 ) );
Or something similar.
It seems like a minor modification with a great (potential) impact for the user.
-
That would actually be a neat idea that won't break any existing code.
Well, it's not just about everything being on one line, but right now you have to use a variable with multiple calls, which can be rather annoying if you're trying to draw lots of small stuff you don't want to cache/store over several frames.
-
It seems like a minor modification with a great (potential) impact for the user.
No. It is a problem since some functions are defined in base classes, so no type information about the derived class can be kept in the return type.
I like the decision that the constructor only takes the most important arguments, even if this means to split code into multiple lines. It is much clearer than the old sf::Shape::Rectangle(20, 30, 100, 120, sf::Color(200, 30, 150), 3, sf::Color(100, 150, 100, 100));
If you want one-liners, you can still build free functions. For example, I implemented thor::Shapes::Line() (http://www.bromeon.ch/thor/v1.1/doc/namespacethor_1_1_shapes.html) to create lines.
-
Okay, I'm able to reproduce it
I can't, with the same platforms as you. Make sure that your audio/graphics drivers are up-to-date.
-
It seems like a minor modification with a great (potential) impact for the user.
No. It is a problem since some functions are defined in base classes, so no type information about the derived class can be kept in the return type.
True, this way of expressing it works only if real-type-specific functions are called first, then general types.
It would have worked better if CRTP was used I guess.
-
minor inconvenience sf::Text default Color is Black, while documentation says it's White.
-
minor inconvenience sf::Text default Color is Black, while documentation says it's White.
It's fixed, thanks.
-
minor inconvenience sf::Text default Color is Black, while documentation says it's White.
It's fixed, thanks.
Wow, fast!
Additionally I get error on exit in Windows7 when using default font for sf::Text
Have legacy ati card.
-
Okay, I'm able to reproduce it
I can't, with the same platforms as you. Make sure that your audio/graphics drivers are up-to-date.
They are, plus for the audio issue, I've been able to reproduce it with an alternative sound card set as default device, too. Will try a bit more tomorrow.
-
Hi, since I've been using the new API I can't execute SFML applications on my laptop. It's an Intel integrated 945 graphics chip. Drivers are up to date.
The executable crashes right after (or while) creating an sf::RenderWindow.
I get the error: Unhandled exception at 0x00000000 in Intel Graphics.exe: 0xC0000005: Access violation.
The program '[3796] Intel Graphics.exe: Native' has exited with code -1073741819 (0xc0000005).
This is the call stack for the application:
(http://img853.imageshack.us/img853/8263/semttulowv.jpg)
The source is here: http://www.sfml-dev.org/documentation/2.0/
Except I exchanged sf::Window with sf::Renderwindow
What can I do? Did I do something wrong?
Thanks in advance.
-
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.
That seems like a huge loss to me! :(
Are you sure that is the right choice? Or is there another way to easily create gradient effects in SFML now?
-
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?
I signed up for an account specifically to ask if the old one-liners could be put back into the API. I use them all over the place to add things like borders or bezels around pictures or text. I understand that I can still do this with the RectangleShape class, but if I have to draw 30 rectangles I would much rather write
Window.Draw( Shape::Rectangle( ... ) );
rather than
RectangleShape rect;
rect.SetPosition( ... );
rect.SetSize( ... );
rect.SetFillColor( ... );
rect.SetOutlineColor( ... );
rect.SetOutlineThickness( ... );
Window.Draw( rect );
I understand that the one-liner isn't as clear as calling the individual setters but that doesn't mean that it should be taken out. For example, if I just want to quickly draw a rectangle around a sprite during a debugging session to confirm that the bounding box is what I expect it to be, I don't need the clarity that using the setters would give, I just want to quickly write the single line of code and move on.
As Nexus said, we could write our own function or macro to get back the one-line functionality, but considering that the functions were already in SFML and are now being removed it seems like a straight downgrade with no upside.
-
Additionally I get error on exit in Windows7 when using default font for sf::Text
It's a known bug.
Hi, since I've been using the new API I can't execute SFML applications on my laptop.
Make sure that you made a complete recompile.
Are you sure that is the right choice? Or is there another way to easily create gradient effects in SFML now?
You can now use vertex arrays to do whatever you want.
And if I change the implementation to be GL 2.0 (shaders only) soon, I'll probably be able to put the global color back.
I understand that the one-liner isn't as clear as calling the individual setters but that doesn't mean that it should be taken out.
Shapes have more properties now (texture, texture rect) it's no longer possible to have them all in the constructor. The best solution now is really to create your own functions for building shapes, so that you can choose only the properties that you're interested in.
-
Hi, since I've been using the new API I can't execute SFML applications on my laptop.
Make sure that you made a complete recompile.
I did. Both SFML and every SFML related project. Strangely, the same applications compiled on the laptop work on another computer with an ATI card but not on the laptop. I'm guessing it's an Intel driver problem but no idea how to fix it. Any ideas?
Thanks in advance :)
-
Which line triggers the null call in RenderTarget::ResetGLStates()?
Is there any message in the console?
-
Tracked down the thread creation. It indeed happens outside SFML and for whatever reason calls to "joyGetPosEx()" with an index higher than the first joystick/gamepad spawn 2-3 threads (I've got a wired Xbox 360 controller connected as well as a wireless receiver (Xbox360 too) with no active controller). It sometimes stops after some seconds. Disconnecting the gamepad and the receiver didn't change anything, though.
Edit: It's something caused by my system's openal32.dll. If I copy the one from the SFML2 repository to my working dir, the issue is gone. So still something in the X-Fi drivers which influences all OpenAL usage for whatever reason.
-
Which line triggers the null call in RenderTarget::ResetGLStates()?
Is there any message in the console?
I was actually compiling in release when I posted that call stack, my mistake. When debugging I get the same error but a slightly different call stack:
(http://img442.imageshack.us/img442/6691/sfmlcallstack.png)
I think it's line 274 on myCache.UseVertexCache = false;
There aren't any messages on the console.
I also didn't mention but I'm compiling with the static libs.
-
And if I change the implementation to be GL 2.0 (shaders only) soon, I'll probably be able to put the global color back.
That catched my attention. Can you provide details?
-
I was actually compiling in release when I posted that call stack, my mistake. When debugging I get the same error but a slightly different call stack
Thanks. Can you try again with the latest revision?
That catched my attention. Can you provide details?
About the GL 2.0 implementation, or the ability to provide the global color with it?
-
About the GL 2.0 implementation, or the ability to provide the global color with it?
Both. ;)
-
In order to port SFML to mobile platforms, it needs to support OpenGL ES 2.0, which is shader only (it doesn't support the FFP at all). So eventually I'll switch to a shader only rendering architecture.
And if I use shaders, I can basically do whatever I want, especially add a global color ;)
-
I was actually compiling in release when I posted that call stack, my mistake. When debugging I get the same error but a slightly different call stack
Thanks. Can you try again with the latest revision?
It works! Thank you! :)
-
Looking a bit over internal sf::Color and sf::Texture related code, I noticed that there are quite some assignments and comparisons done byte by byte.
How about storing the value of sf::Color in a union, while having references providing backwards compatibility and easier access? Especially considering the fact sf::Color uses unsigned byte instead of float.
Essentially something like this:
public:
Uint32 &rgba;
Uint8 &r;
Uint8 &g;
Uint8 &b;
Uint8 &a;
private:
union _data
{
Uint32 rgba;
struct _components {
Uint8 r;
Uint8 g;
Uint8 b;
Uint8 a;
} components;
} data;
This could simplify quite some code (not sure how far this would be optimized by modern compilers).
Current code (color comparison):
bool operator ==(const Color& left, const Color& right)
{
return (left.r == right.r) &&
(left.g == right.g) &&
(left.b == right.b) &&
(left.a == right.a);
}
New code:
bool operator ==(const Color& left, const Color& right)
{
return left.rgba == right.rgba;
}
Current code (creating an image of a given color):
Uint8* ptr = &myPixels[0];
Uint8* end = ptr + myPixels.size();
while (ptr < end)
{
*ptr++ = color.r;
*ptr++ = color.g;
*ptr++ = color.b;
*ptr++ = color.a;
}
New code:
Uint32* ptr = (Uint32*)&myPixels[0];
Uint32* end = ptr + myPixels.size();
while (ptr < end)
*ptr++ = color.rgba;
There's still the issue of byte order, but this could be handled changing the order of the struct members (to ensure rgba has the right content).
-
There's absolutely no point to optimize this part of the code. I don't want to write ugly code for no gain, I prefer spending my time optimizing the real bottlenecks in SFML. Sorry ;)
-
I'm not even sure if I'd call it an optimization at all. A few points off the top of my head:
The added reference members increase the Color class' size by 20 bytes assuming 32 bit references, 40 bytes assuming 64-bit references. That is a potential 10x size penalty without even mentioning padding.
Accessing a reference member may incur an indirection (depending on the optimizer).
Copy construction and copy assignment become non-trivial (in the standard sense).
The last "New code" example breaks strict aliasing rules, invoking undefined behaviour (I'm ignoring the issue of union type punning, due to widespread compiler support).
-
The added reference members increase the Color class' size by 20 bytes assuming 32 bit references, 40 bytes assuming 64-bit references. That is a potential 10x size penalty without even mentioning padding.
And that makes sf::Color unusable in sf::Vertex, which assumes a strict memory layout.
-
Yeah, okay, forgot about that overhead while adding the references (booh!). :)
-
The references besides, the union layout seems spot-on. Just put it in public access. There have been some times I could have used an rgba member directly, and a layout like that (but with public members and sans the references) would both be an interface improvement and would allow the writing of more efficient low-level code for those that have a need for such. Also, it serves to document the colour component layout in code, the value of which shouldn't be underestimated.
-
Well, probably yes, although I'm not a fan of having to write a long chain of members and sub members (like color.data.components.r). Getters might be more interesting then, but at the same time it isn't something that requires immediate changes or attention, considering there are far more interesting things to fix/change first (like OpenGL ES).
Something different:
While working on custom sprite/animated sprite classes (to make access to frames/animations easier) I noticed, that I could save quite some code by subclassing sf::Sprite, which I know isn't intended and making some things impossible to do. So, just out of curiousity, anything speaking against making sf::Drawable::Draw() protected instead of private? In this case my plan was to let AnimatedSprite::Draw() update the frame to be shown (based on an internal state and the last frame's time) and then call sf::Sprite::Draw() to draw the sprite. Now I did it making the sprite a member instead of the base class, but I think subclassing would be the better way.
-
What code did you save by subclassing sf::Sprite? I think that your second solution is the best; for example, what happens if someone calls SetTextureRect (which is inherited) on your AnimatedSprite in the middle of a running animation?
Anyway, Draw is defined const so it wouldn't help to make it protected.
-
Ah, you're right, it's const. That's been the actual problem, not just the private/protected. Also something more important about making sf::Sprite not subclassable should be the fact that otherwise people might tend to use it as some kind of entity class otherwise.
But yeah, I'll most likely stick to the custom solution and add a Draw() that will just forward the call after updating the current frame.
-
Well, probably yes, although I'm not a fan of having to write a long chain of members and sub members (like color.data.components.r). Getters might be more interesting then, but at the same time it isn't something that requires immediate changes or attention, considering there are far more interesting things to fix/change first (like OpenGL ES).
Chained member access would be a nuisance, but I don't think that was the suggestion, and not what I would suggest either.
struct Colour
{
union
{
struct
{
unsigned char r;
unsigned char g;
unsigned char b;
unsigned char a;
};
sf::Uint32 rgba;
};
};
In this you access the members of Colour instance c by c.r, c.a or c.rgba directly.
-
In this you access the members of Colour instance c by c.r, c.a or c.rgba directly.
Don't forget that if you set one and read the other, the behaviour is undefined according to the C++ standard. In practice it works as expected on most (if not all) platforms, but it can still break one day.
Moreover, I think it's dangerous to provide access to all the components in a single variable, because of endianness issues.
-
Stumbled upon something else: The mentioned lack of RenderTextures for older hardware. How about adding PBuffer/Render_Texture support as a fallback? Think these were introduced with OpenGL 2.1 or so.
Also, especially without a (useable) fallback, there should be some way to check the availability of RenderTextures. At least I haven't found any such function outside their implementation classes. Just something like Shader's IsAvailable().
-
RenderTexture::IsAvailable() existed before, when I was using P-Buffer as a fallback to FBO. Now I use a regular context in a hidden window, so the fallback works on every platform, thus there's no need to test the availability.
There are still bugs with some drivers, but no "lack of RenderTextures for old hardware".
-
So should I see something actually rendered even without proper FBO support? Thought it's meant to be some dummy renderer.
Also just found a documentation bug for sf::Shader:
sf::RenderStates states;
states.Shader = shader;
window.Draw(sprite, states);
This no longer works (at least under MinGW), as sf::RenderStates want sf::Shader* instead of sf::Shader&. Instead I have to pass the address of the shader object.
-
So should I see something actually rendered even without proper FBO support?
Yes, but like I said there are some major bugs with the current implementation.
This no longer works (at least under MinGW), as sf::RenderStates want sf::Shader* instead of sf::Shader&. Instead I have to pass the address of the shader object.
The type of the "shader" variable is not given, it could be a sf::Shader* ;)
-
[...]Chained member access would be a nuisance, but I don't think that was the suggestion, and not what I would suggest either.
struct Colour
{
union
{
struct
{
unsigned char r;
unsigned char g;
unsigned char b;
unsigned char a;
};
sf::Uint32 rgba;
};
};
In this you access the members of Colour instance c by c.r, c.a or c.rgba directly.
Don't forget that if you set one and read the other, the behaviour is undefined according to the C++ standard. In practice it works as expected on most (if not all) platforms, but it can still break one day.[...]
If we're being pedantic, it's worth mentioning that ISO C++ doesn't define anonymous structs, thus the above construct relies on a compiler specific language extension.
-
If we're being pedantic, it's worth mentioning that ISO C++ doesn't define anonymous structs, thus the above construct relies on a compiler specific language extension.
C++11 does.
-
The type of the "shader" variable is not given, it could be a sf::Shader* ;)
I won't take that as a valid solution. :)
The previous code example (just some lines above), accesses members without dereferencing.
Also, this is actually something a bit weird in general. Almost all other SFML calls use references and don't expect pointers. These do so though.
-
Also, this is actually something a bit weird in general. Almost all other SFML calls use references and don't expect pointers. These do so though.
SFML uses pointers in the API when they can be null, references otherwise.
-
Ah, right, nullable... That one special case. :)
But something else, any reason for sv::VectorArray being non-transformable?
-
But something else, any reason for sv::VectorArray being non-transformable?
It's usually not the final entity, it's lower level than sprite/shape/text.
-
If we're being pedantic, it's worth mentioning that ISO C++ doesn't define anonymous structs, thus the above construct relies on a compiler specific language extension.
C++11 does.
Oh that's nice. FDIS reference?
-
What have you changed with sf::Text except GetRect -> Get*Bounds ?
I'm having troubles debugging my REALLY messy menu-system, wich draws lots of texts. No texts are drawn unless I tamper with them after I create them (like selecting another menu item).
I'm creating texts like this;
sf::Text meh;
Meh.SetFont(*FontPointer);
Meh.SetCharacterSize(8);
Meh.SetColor(sf::Color(255,255,255));
Meh.SetPosition(sf::Vector2f(x,y));
Meh.SetString("bleh");
Is there a post with full changes ?
-
It should work, sf::Text hasn't changed at all (except the GetBounds thing).
Can you reproduce the problem with a complete and minimal example?
-
I'm trying to convert my project to the new system, but I've come across a problem. There no longer seems to be a way to set individual point colours in ConvexShapes. I was previously using them to do this:
(http://i.imgur.com/ismFJ.png)
I could take the polygons that I draw (see below) and set a different fill colour for each one, but that won't interpolate between vertices and looks like coloured squares instead of a nice gradient.
(http://i.imgur.com/eRIVd.png)
Is this going to be a feature later on?
-
There won't be a replacement in the Shape API, you must use vertices (sf::Vertex) directly if you want more control.
-
There won't be a replacement in the Shape API, you must use vertices (sf::Vertex) directly if you want more control.
So there is a good way. I was really worried about this.
Could you give a short example of how to do, say, a quad with different colored corners in SFML2?
-
I can, since it works now:
sf::VertexArray va(sf::Quads, 4);
va.Append(sf::Vertex(sf::Vector2f(0, 0), sf::Color::Red));
va.Append(sf::Vertex(sf::Vector2f(100, 0), sf::Color::White));
va.Append(sf::Vertex(sf::Vector2f(100, 100), sf::Color::Black));
va.Append(sf::Vertex(sf::Vector2f(0, 100), sf::Color::Yellow));
rTarget->Draw(va); //any render target
after my fixes:
(http://i.imgur.com/LYULq.png)
Thanks!
-
Very nice! So exited about SFML2 now. Thank you.
-
Possible bug in shader handling (actually just some aggressive programming).
I forgot to check for shader availability on a Intel 45GMA (Eee PC), which essentially lead to a call to "RenderTarget::ApplyShader(0)".
This - for that PC - causes a segmentation fault (instruction pointer being set to 0) outside SFML's scope due to "glUseProgramObjectARB" pointing nowhere (which is called in RenderTarget.cpp at line 377).
Not sure if there should be a bit more defensive programming being used here.
-
How did you manage to reach this call with a null argument?
-
I have a game project that I was building with a version of SFML 2 from September. Last night I pulled the latest version of SFML and worked on updating my code to work with the new API.
Without looking at any resource other than the 2.0 documentation I was able to convert my project to the new API in about 2 hours. It was a breeze. I really like how things are structured now.
Just wanted to say thanks to you and all the contributors for the great work.
-
How did you manage to reach this call with a null argument?
Haven't had time to track it down yet, but it seems like that's happening due to RenderTarget::Draw() trying to unbind the shader used just before updating the vertex cache:
// Draw the primitives
GLCheck(glDrawArrays(mode, 0, vertexCount));
// Unbind the shader, if any
if (states.Shader)
ApplyShader(NULL);
// Update the cache
myCache.UseVertexCache = useVertexCache;
The issue here might be the integrated Intel graphics card supporting a lower shader version (I think OpenGL 1.4 is the last version being feature complete with the driver supporting some 2.0 features).
states.Shader is set to point to the shader object. Previous state's shader (don't remember name right now) is set to 0.
-
So you load and use a shader, whereas Shader::IsAvailable() returns false? Right?
-
It must be. Giving the program id 0 will set back OpenGL to use the fixed pipeline. I.E it's defined behaviour and should not act like that if shaders are supported. Could also be a delayed bug. It happens a lot earlier but doesn't crash until later. Experienced that a lot with intel.
-
So you load and use a shader, whereas Shader::IsAvailable() returns false? Right?
I completely forgot about the check, so essentially, yes.
It must be. Giving the program id 0 will set back OpenGL to use the fixed pipeline. I.E it's defined behaviour and should not act like that if shaders are supported. Could also be a delayed bug. It happens a lot earlier but doesn't crash until later. Experienced that a lot with intel.
As mentioned above, it's not due to the passed NULL. It's due to the function pointing nowhere (as it couldn't be loaded by GLEW).
-
Hello, I asked about a half year ago.
Is it possible to use debug mode, but do not debug graphics code (or what is it making so slow) ?
I use text/graphics a lot in my project, and that drops my FPS to 1-2 in debug mode, but 60+ in release. I of course would like to debug my actual "working" code and not SFML graphic library (which is working fine ).
and got this answer from Laurent
The new graphics API should be much faster in debug mode, there could even be almost no difference.
So my question now, is it already that fast? :)
And how much faster do you think it is?
I don't have good code for compare now, so I cant test it.
Thanks
-
Just test it. Also had a massive slowdown when run using GDB while working with many instances of std::set while rendering sf::Text. Could be another reason.
-
I asked, because I dont have code for that I did before and I dont have SFML compiled and that stuff...
I just only want to know if its faster than 1.6 already and if debug FPS almost == release FPS. Or if I should wait more, before using SFML again.
-
The new graphics API is not better in debug mode, but it allows you to do better things.
Example:
- if I draw 10000 individual sprites with sf::Sprite, I can get 50 FPs in release and 1 FPS in debug because there are 10000 OpenGL calls involved
- if I draw 10000 sprites with a single sf::VertexArray, I can get 350 FPS in both release and debug mode because there is 1 OpenGL call involved, it's the GPU which is busy not the CPU anymore
-
Ah, thanks.
Never used sf::VertexArray because sf::Sprite is kind of easy for use, hope that vertex array too...
I am not sure if I understand well, but couldn't the (almost) same fps be achieved by using release versions of SFML libraries in debug mode? (guess it wont work that way :/).
Or something like that? Like "I trust SFML, debug only my code"?
-
You can generally not mix debug and release. For example, Visual C++ has a different definition for STL classes in debug and release mode, so if you pass a std::string from your app (debug definition) to SFML (release definition) it will crash.
-
Shader's doc (http://sfml-dev.org/documentation/2.0/classsf_1_1Shader.php#details) says:
To apply a shader to a drawable, you must pass it as an additional parameter to the Draw function:
window.Draw(sprite, shader);
... which is in fact just a shortcut for this:
sf::RenderStates states;
states.Shader = shader;
window.Draw(sprite, states);
But I can't find a Draw(drawable, shader) method in RenderWindow or RenderTarget. Am I missing something?
-
Yes: the RenderStates(sf::Shader*) implicit constructor. A sf::RenderStates can be implicitely constructed from any of its members.
-
Thanks.
-
test.GetGlobalBounds()
Does not take end white space in to account and trims it?
and height seems to be wrong by half..
AM I right that it should return width and height of displayed text?
-
test.GetGlobalBounds()
Does not take end white space in to account and trims it?
http://www.sfml-dev.org/forum/viewtopic.php?t=6672
and height seems to be wrong by half..
Really? Can you show a complete and minimal code that reproduces this problem?
-
Just to be clear, the optimized version is not out yet, right?
-
test.GetGlobalBounds()
Does not take end white space in to account and trims it?
http://www.sfml-dev.org/forum/viewtopic.php?t=6672
and height seems to be wrong by half..
Really? Can you show a complete and minimal code that reproduces this problem?
eek, sorry, all tests show it does come back with the same height as shapes drawn next door.
Using gwen, it returns an odd height, but I can fix it be using the height of the font,and knowing no new lines will be used....but I cant get the correct width, because of spaces. + using a fixed font.
-
Just to be clear, the optimized version is not out yet, right?
It is.
-
Just to be clear, the optimized version is not out yet, right?
It is.
Amazing, I will be starting the transition then.
-
Laurent,
void DrawLine(sf::Vector2f a, sf::Vector2f b)
{
sf::Vertex line[2] = {a, b};
window.Draw(line, 2, sf::Lines);
}
How can I specify the line color this way?
-
Use Vertex's ctor : http://www.sfml-dev.org/documentation/2.0/classsf_1_1Vertex.php
-
Is it normal that when inheriting from Shape, I need to call Update() to see anything? (If I don't, the virtual methods never get called.)
From the doc, it's not obvious that you need to call it for a static shape.
-
You need to call it at least once, in the constructor.
-
The only way I figured it out was to read SFML's shapes' source. Update()'s documentation says that you must call it when the geometry changes, and it's not obvious that this includes when you haven't set the geometry yet.
I think it should be in the introduction as well, currently it's easy to believe that you only need to override the two methods.
In my Python binding, RenderTarget.draw() takes a list instead of a Vertex* a vertex count, so I'm considering removing VertexArray. But I'm wondering, why not use let the user pass a vector<Vertex> in C++ then?
-
The only way I figured it out was to read SFML's shapes' source. Update()'s documentation says that you must call it when the geometry changes, and it's not obvious that this includes when you haven't set the geometry yet.
I thought it was very obvious that the first time you define the geometry, it changes. I'll add something to the doc.
In my Python binding, RenderTarget.draw() takes a list instead of a Vertex* a vertex count, so I'm considering removing VertexArray. But I'm wondering, why not use let the user pass a vector<Vertex> in C++ then?
The C++ version allows to Draw a <Vertex*, count> too. So the user can pass anything he likes.
-
Hi
I've pushed a first version of the new graphics API, so that you can test it. Please focus on the API, there's no optimization yet so the performances are worse than before. I can't upload the documentation, so you'll have to either generate it yourself, or directly look into header files.
The new API is available in the 'drawables' branch of the main repository.
It is for testing only, if you want a final and optimized version then wait until it is merged into the master branch.
Thanks :)
Thanks for info