shape.GetPointPosition error

[wasabi]

Lo and behold, another zoom issue coming from me.

I'm trying to create an "infinite line," one that stretches out no matter how far you zoom. I thought the easy way of doing that would be:

Code: [Select]


CurrentView.Zoom(0.9f);
shape.SetPointPosition(1,sf::Vector2f(CurrentView.GetCenter().x-CurrentView.GetHalfSize().x,950);
shape.SetPointPosition(2,sf::Vector2f(CurrentView.GetCenter().x+CurrentView.GetHalfSize().x,950);


This way, the horizontal line, which was created originally with CurrentView.GetRect().Left and CurrentView.GetRect().Right for it's coordinates' x-values, would be resized at every zoom. I didn't use .Left and .Right this time because myRect is only updated with an App.Draw(), not with .Clear(), .Display() or .SetView(), and I have nothing to draw before these corrections. Plus, I checked the math and .GetCenter() - .GetHalfSize() is equivalent to .GetRect() after the update.

However, while the line works fine when originally generated using .Left and .Right, the resize doesn't. The line is drastically reduced in length if zooming out and vanishes if zooming in. It still appears just fine if I pan without zooming, though, so it's not a problem involving my use of App.Draw().

[Laurent]

A line is made of four points, not two
It is a rectangle actually.

But why don't you scale it instead of messing with its points? Or recreate it with sf::Shape::Line?

[wasabi]

I've also noticed that sf::Shape::Line is actually composed of 5 points (at least for lines of length ~2000), not only 2 as one'd expect. However, these other points are all in the middle of the line, so I don't know how I should deal with them.

In fact, I just checked and noticed that the extremities of the line are actually on vertices 1 and 3 (not 0 and 1 as I'd expected). However, this seems to create an issue in regards to reliability. Is this always the case, given the ::Line generation algorithm? Or might the extreme vertices be in any location in the array?

EDIT: You beat me to it. Though it's actually five points, for whichever reason.

And I tried messing with Scale, but it made the other shapes go crazy, for whichever reason. Actually, quick question, what's the difference between Scale and SetScale? I can't seem to figure it out.

EDIT2: And I forgot to ask about recreation. Can you simply do that?

shape = sf::Shape::Line(...1);
shape = sf::Shape::Line(...2);

Some libraries don't much like that. And I don't know if there are any hidden dynamic allocations I should worry about.

[Laurent]

A line definitely has 4 points, if GetNbPoints returns 5, it's a bug

And the four points define its rectangular shape, they're not supposed to have such a random location.

I'll check this two things to see if there's any bug in SFML 1.6.

And I tried messing with Scale, but it made the other shapes go crazy, for whichever reason

Show me your code.

Actually, quick question, what's the difference between Scale and SetScale? I can't seem to figure it out.

SetScale replaces the current scale, Scale multiplies it. It's like SetPosition and Move, or SetRotation and Rotate

And I forgot to ask about recreation. Can you simply do that?

shape = sf::Shape::Line(...1);
shape = sf::Shape::Line(...2);

Absolutely.

Some libraries don't much like that. And I don't know if there are any hidden dynamic allocations I should worry about.

There's no hidden stuff in SFML, if it allows you to do something then it's most likely a good solution

[wasabi]

I just tried .Scale() and it seems to work quite well, but there's a curious error. The scale-factor clearly isn't based in the center of the object, since one side is clearly growing much more than the other.

Do you need to .SetCenter() first? Because I tried that and it came out a bit crazy.

Code: [Select]

shape.SetCenter(shape.TransformToLocal(sf::Vector2f(CurrentView.GetCenter().x,950))); shape.Scale(CurrentView.GetHalfSize().x/oldview.GetHalfSize().x,1);

That gets the center of the screen at 950 in depth (the depth of the line), transforms that coordinate into local shape coordinates and sets that as its center, right? And then I get the ratio between the oldview and the newview and scale accordingly, right?

That seems to work reasonably, except for the fact that TransformToLocal doesn't do that. I check the step-by-step and the Local and Global coordinates are exactly the same. That makes sense in regards to the x-value, since I always want the line to start at the window's edge, but the y-value should be 0 (or close, since there's thickness).

Due to this error, zooming out causes the line to move vertically as well as scale horizontally (which I just noticed makes no sense). As well, the line moves up, not down. Does this mean the local coordinate system is y-positive (while the global is clearly y-negative, i.e. y-values increase the lower you go)?

Without .SetCenter(), the scaling works almost fine. The line is extended, it remains at its position, but the scaling is uneven. One side is extended beyond the screen while the other end can be seen. If you pan to the side, the new length fits perfectly, but... well, you shouldn't have to pan.  :?

EDIT: Just saw your reply and simply replaced the old line with a new version of it and that works fine. Not to mention it's way simpler. Thanks for staying with me all day today. :p

EDIT2: And a Line most certainly has 5 points.

This code:

Code: [Select]

shape = sf::Shape::Line(CurrentView.GetCenter().x-CurrentView.GetHalfSize().x,950,CurrentView.GetCenter().x+CurrentView.GetHalfSize().x,950,0.003f,sf::Color(0,128,128),t,sf::Color(0,128,128));
If done with the step-by-step, gives the following points:

• position (378... , 950.0)
[1] position (-848... , 949...)
[2] position (1606... , 949...)
[3] position (1606... , 950...)
[4] position (-848... , 950...)

Obviously, the values themselves are irrelevant other than to show that they're not even repeated.

[Laurent]

If done with the step-by-step

You mean, the debugger? Don't do that, you'll see all the internal stuff (namely: the first point is the precomputed center of the shape). Use the public API to see what's relevant in the shape.

[wasabi]

Ah, that explains it, then.