-
Maybe it's a good idea to add a method to sf::Image which fills the specified region(or whole) image with specified Color ?
-
Ah.. the constructor for this already existed.. :-\ but additional method could exist too.
sf::Image image;
image.create(100,100,sf::Color::Black);
image.fill(sf::IntRect(20,20,60,60), sf::Color::Red); // create big red dot
-
This might not be the most effecient method (most manual image manipulation is usually slow anyway) but you can do this with a temporary sf::Image (this does what your example code would do):
sf::Image image;
image.create(100, 100, sf::Color::Black);
sf::Image tempRectImage;
tempRectImage.create(40, 40, sf::Color::Red);
image.copy(tempRectImage, 20, 20);
If SFML allowed the image to be created in its constructor, it may be a lot nicer:
sf::Image image;
image.create(100, 100, sf::Color::Black);
image.copy(sf::Image(40, 40, sf::Color::Red), 20, 20);
-
What's wrong with the naive approach?
for (int x = minx; x < maxx; ++x)
for (int y = miny; y < maxy; ++y)
image.setPixel(x, y, color);
If you want something efficient don't use sf::Image anyway.
If SFML allowed the image to be created in its constructor, it may be a lot nicer
Looks like it could be done (the create function has no return value).
-
What's wrong with the naive approach?
Nothing and its the good way. I just wondering about possibility of simplify this because its "simple"(like S in SFML).
So sorry about my habit to prefer the solutions from box :P
-
If SFML allowed the image to be created in its constructor, it may be a lot nicer
Looks like it could be done (the create function has no return value).
Might be useful for temporary images as I demonstrated above but I'm not sure how common this would be to warrant creating a new constructor just so that is can also call create.
That version does remove some verbosity but I don't think that was the problem. The problem really is that the temporary image isn't very temporary. Obviously, it could be contained in a self-created function to fix this. However, it can, of course, be contained inline to limit its scope very simply (in case your only real problem is that the temporary image outlives its usefulness:
sf::Image image
image.create(100, 100, sf::Color::Black);
{
sf::Image tempRectImage;
tempRectImage.create(40, 40, sf::Color::Red);
image.copy(tempRectImage, 20, 20);
} // tempRectImage is destroyed here :)
So sorry about my habit to prefer the solutions from box :P
Create a simple function that fills the rectangle for you ;)
Remember that you can do these sorts of things easily with render textures and rectangle shapes:
sf::RenderTexture renderTexture;
renderTexture.create(100, 100);
renderTexture.clear(sf::Color::Black);
{
sf::RectangleShape rectangle({ 60, 60 });
rectangle.setFillColor(sf::Color::Red);
rectangle.setPosition({ 20, 20 });
renderTexture.draw(rectangle);
} // rectangle is destroyed here
renderTexture.display();
It opens up a lot more options of how to draw to the "image" when it is a render texture (you can use and re-use any SFML drawable, for example).
If you still need to have this as an sf::Image, you can then convert it from a render texture when you're finished:
sf::Image image{ renderTexture.getTexture().copyToImage() };
-
If you want something efficient don't use sf::Image anyway.
What do you mean by this comment? Efficient in terms of handling or performance? What part of SFML would you recommend then?
-
sf::Image is not the most performant when reading or writing pixels. You'll get the best performances with a raw std::vector<sf::Uint8> and direct access to pixel components.
-
SFML is inefficient because lot of parts of it are bloated with getters/setters and other high-overhead boilerplate...
Directly accessing arrays/members is so much cleaner and faster !
-
@ratatax, yet you want more overloads for those setters...
http://en.sfml-dev.org/forums/index.php?topic=20052.msg148515#msg148515
-
It depends.
I prefer direct member access if you let me choose (for actions that are safe to set an arbitrary value). But if i'm forced to go with setters/getters, i want them to be flexible so they don't annoy me with thinks like :
s.SetPosition(10, s.GetPosition().y)
while the same thing could be achieved by :
s.SetX(10)
-
"s.setPosition(10, s.getPosition().y);" Is that bad?
There can not be such method as "setX", becouse it doesn't tell anything about itself, it would have to be "setPositionX" which is pointless as you save… 20 characters? Or something similar.
-
SFML had those SetX/SetY but they were removed in version 2 or something
SetX is enough self explaining since you use it on a Sprite object...
I just like when things are simple and not overly verbose. That's probably why i prefer C over C++
-
I wouldn't say clarity is "overly-verbose".
SetX is enough self explaining since you use it on a Sprite object...
I disagree. It's not clear if this is position, origin, scale or even the texture rectangle's position.
-
SFML is inefficient because lot of parts of it are bloated with getters/setters
I beg to differ. If you take a look at the generated asm of an optimized build of the library + your application I think you'll be surprised how much of this "bloat" the compiler is actually able to strip away. If you can come up with a usecase/benchmark where this matters one iota in any realistic scenario, then I'll buy you a beer.
-
SFML is inefficient because lot of parts of it are bloated with getters/setters and other high-overhead boilerplate...
Directly accessing arrays/members is so much cleaner and faster !
Actually on release mode and optimizations enabled methods are almost ever inlined.
Remember that in ASM there is neither classes nor privacy at all.
sf::Sprite spr ;
float rot = spr.getRotation()
with properly optimizations enabled is the same that:
sf::Sprite spr ;
float rot = spr.rotation ;
However
//example A1
sf::Sprite spr ;
float x = spr.getPosition().x ;
float y = spr.getPosition().y ;
could be slower than:
//example A2
sf::Sprite spr ;
sf::Vector2f pos = spr.getPosition() ;
float x = pos.x
float y = pos.y
BUT a good compiler with full optimizations should be able to do CSE (https://en.wikipedia.org/wiki/Common_subexpression_elimination) (Common subexpresion elimination).
And the example A1 can be translated in A2.
If in the example A2 ( and in A1 too ) the variable "pos" its no used any more the compiler could do a "Allocation optimization"
Eliminating the allocation of pos and inling .x .y
ej:
//example A2
sf::Sprite spr ;
float x = spr.x // -> .x from spr's internal vector.
float y = spr.y // -> y from spr's internal vector.
Compilers nowadays are very capable. You only need to know how use it and how code.
So, please, before make an assertion research a bit more.
:D