sfml 1.6 sprite::GetSize equivalent? and general 2.0 questions

[natchos]

So I'm back with another fairly stupid question

Is there a 2.0 equivalent to 1.6 sprite::GetSize() function, or is getGlobalBounds() the closest thing to that that we get?

I'm just wondering because I am in the middle of changing my project from 1.6 to 2.0, so I would just like to know, since it would change the structure of some crucial functions.(Not in a bad way, I just wonder whether I have to rewrite them )

[eXpl0it3r]

Is there a 2.0 equivalent to 1.6 sprite::GetSize() function, or is getGlobalBounds() the closest thing to that that we get?

Why "closest thing"? getGlobal/LocalBounds() is the function for getting dimensions.

[natchos]

Aye, but it returns a rect whereas GetPosition returns a vector
Also localbounds returns the size, right? Whereas globalbounds return the size and position and rotation?

Thanks for the fast reply

EDIT: Sorry, meant GetSize

[eXpl0it3r]

Aye, but it returns a rect whereas GetPosition returns a vector
Also localbounds returns the size, right? Whereas globalbounds return the size and position and rotation?

GetPosition has nothing to do with GetSize, there's still a getPosition() function.
The local bounds will return a rect with top = left = 0 and the width and height of the initial sprite size, whereas the global bounds acctually represents more the bounding box of the sprite, i.e. it takes into account the rotation, scale and position.

[natchos]

Ya, sorry wrote wrong I meant GetSize, anyhow, thank you very much for the clarification.

[natchos]

New question!
Is there any specific reason as to why sf::rect.offset() was removed from 2.0?

EDIT: Also, why the removal of Right and Bottom coordinates in a rect?

[FRex]

I guess it's mostly qeustion for Laurent but I guess it's kind of useless/feature bloat and in 2.0 the rect is defined by left,top,width,height so if you want to move it, it's just 2 changes to left and top and in 1.6 it was defined by left,top,right,bottom so moving it would take 4 changes to each of these, which is a bit much already.

Edit: Again it's very Laurent focused question BUT it seems extremely unituitive to have right and bottom instead of width and height. And it makes getting width and height in 1.6 a pain if you're not careful and use two methods(2 more methods = more feature bloat).

[natchos]

Ah yea, I see your point.

Still, now you have to change 2 values, instead of just calling a single function.
But I'm no expert on the inner workings of either Laurents mind or SFML, so I'll just accept the new classes as they are

[Laurent]

sf::Rect members are public, so there's nothing you can't implement yourself on top of it -- like an offset function. Don't stop at what SFML directly provides, such functions are mostly for convenience (they don't bring new features), so add whatever is convenient for you

[natchos]

So was Randomizer completely removed in 2.0? I can always construct my own randomizer, but if SFML already has one I see no reason to make my own instead of adding to the existing one.

[Laurent]

So was Randomizer completely removed in 2.0?

Yes. It was nothing more than a very thin wrapper around std::rand.

[natchos]

Aight, I'll get to making my own then

[natchos]

Time for next question

Why was getFrameTime removed? Feature bloat? Is there any good way to get the frame time?

EDIT: Can sf::RenderWindow::pollEvent in 2.0 be used in a similar way to sf::RenderWindow::GetInput from 1.6?
EDIT2: Nope it cannot I saw now. How should you handle inputs in 2.0?

[eXpl0it3r]

Why was getFrameTime removed? Feature bloat? Is there any good way to get the frame time?

It was a design decision; it's actually a bit too highlevel and can get easily implemented with a sf::Clock:

sf::Clock clock;
float dt = 0.f;
while(window.isOpen())
{
    dt = clock.restart().asSeconds();
    // ...
}

Nope it cannot I saw now. How should you handle inputs in 2.0?

The Input class got replaced by the three classes sf::Mouse, sf::Keyboard and sf::Joystick. See the documentation and/or tutorials for more information on the usage.

[natchos]

Alright I will. Thank you for the helpful reply

EDIT: How do you check for a released key?
Since sf::Keyboard::"key" returns a bool on whether it is pressed or not, how do you check for a released key as opposed to a key which was never pressed?