SFML community forums
Help => Graphics => Topic started by: Dr_Asik on November 05, 2009, 02:50:11 am
-
I am coding a remake of Space Invaders, and my artwork is consequently very low-res. I need it to be drawn with pixel perfect accuracy.
I am using the Sprite class to draw my artwork to the screen, unfortunately, they appear blurry, even if I don't scale/rotate them. Is this a known issue with SFML?
-
No, it's not even an issue. The problem is you didn't disable Image Smoothing.
-
Oh, thanks, wouldn't have guessed that.
By the way, the behavior for specifying the sub rectangle is a bit non-intuitive. When I type
sprite.SetSubRect(IntRect(
Intellisense tells me that the four parameters are:
LeftCoord, TopCoord, RightCoord, BottomCoord
So having a sprite in my spritesheet at [0-7], [0-7], I wrote:
sprite.SetSubRect(IntRect(0, 0, 7, 7));
But then it seemed I was missing a pixel right and one bottom. So I actually have to write this:
sprite.SetSubRect(IntRect(0, 0, 8, 8 ));
Which describes my sprite's sub rectangle as
[0-8[, [0-8[
A bit weird IMO. XNA was fool-proof:
public Rectangle (
int x,
int y,
int width,
int height
)
-
You're right, SFML rectangles are confusing and not consistent. They will be rewritten for SFML 2 :)
-
You're right, SFML rectangles are confusing and not consistent. They will be rewritten for SFML 2 :)
I hope you mean the internals and not the structure with Right and Bottom?
-
Well, maybe Width/Height would be less confusing than Right/Bottom, I don't know...
-
Thanks for the follow-up.
What confused me is that left/top are included, but bottom/right are excluded. The only way I could figure that out was through experimentation, and I was lucky to be using very small sprites, I might not have noticed a one pixel difference with larger ones.
Either have bottom/right included, or do it like XNA, IMO you can't go wrong with how XNA does things. :)
-
We already had the discussion about included and excluded coordinates. It's an info that's probably missing in the documentation, but sf::Rect is currently inconsistent, anyway.
I'm absolutely for Right/Bottom. Width and height could be set through SetWidth()/SetHeight() mutators. The other way around would be SetRight()/SetBottom(), which seems a bit odd to me.
Also I find it more logical: A rectangle is mostly described by giving two points, not one point and a size. This opinion may differ. ;)
-
I think that this is strictly identical, and it's mostly a matter of taste ;)
I'm personnally perfectly ok to describe a rectangle with a point and a size.
I was previously in favor of keeping the current members (right/bottom), but after reading this topic I realize that width/height is not confusing at all and doesn't have the "included/excluded" issue. Ok, I know, this must be documented anyway... ;)
-
It's not confusing, that's true. Like I said opinions may be different in that point. I guess I'm just used to it.
Btw, the "excluded coordinates problem" would not completely disappear. Wouldn't sf::Rect have accessors like GetRight()/GetBottom() when the members itself are Width and Height (I really would hate it to implement those myself ;))? But whatever, I like that behaviour, as long as it's documented.
I think it'd be interesting to hear more opinions about that, just out of curiosity. In the end it's already you, Laurent, who decides that. ;)
-
I think it'd be interesting to hear more opinions about that
Definitely :)
-
How about rotated rects?
-
Well, maybe Width/Height would be less confusing than Right/Bottom, I don't know...
I definitely agree. In my opinion, begin/size rects are far more intuitive and comfortable than begin/end ones.
By the way, I started this discussion half a year ago... ;)
http://www.sfml-dev.org/forum/viewtopic.php?t=1211
-
How about rotated rects?
I already thought about it. They would be useful for some features, such as providing the global bounding rect of drawables or views, or defining rotated render masks ; however I'm not sure whether this stuff should be implemented in SFML.
By the way, I started this discussion half a year ago...
You see, I finally changed my mind :lol:
-
You see, I finally changed my mind :lol:
Oh, no problem. I'm really glad you are sceptical to every design change in your library. Without clear guidelines, the SFML library wouldn't be as well structured as it is now. ;)
-
It took a little getting used to, but I actually like the bottom/right parts of Rect. Makes resizing subrects fast and painless (in the sense, that you can resize it to make it go straight up, or left, without extra math involved), as well as getting the right_x and bottom_y values.
The only thing that x/y/width/height really helps with seems to be initialization, in my opinion. Too bad there's no way to just overload that in..
-
The only thing that x/y/width/height really helps with seems to be initialization, in my opinion. Too bad there's no way to just overload that in..
True also on my side. I'm not using the width and height often. Else I can directly specify the right and bottom values. In my opinion there'll always be more math needed when working with widths and heights -- nothing big, of course, but that could be mostly avoided up to now.
Btw, you can easily specify your own initialization function for that:
template <class T>
sf::Rect<T> CreateRectWithSize( T Left, T Top, T Width, T Height ) {
return sf::Rect<T>( Left, Top, Left + Width, Top + Height );
}