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

[natchos]

Ok so I am using a fairly standard looped switch statement to poll/get events, how do I check for released keys?

It looks like this

                        while(App.pollEvent(Event))
                        {
                                switch(Event.Type)
                                {
                                case sf::Event::Closed:
                                        App.Close();
                                        break;
                                case sf::Event::EventType::KeyPressed:
                                        switch(sf::Keyboard::isKeyPressed)
                                        {
                                        case sf::Keyboard::isKeyPressed(sf::Keyboard::Left):
                                                theEye.move(-PlayerMove,0);
                                                break;
                                        case sf::Keyboard::isKeyPressed(sf::Keyboard::Right):
                                                theEye.move(PlayerMove,0);
                                        case sf::Keyboard::Escape:
                                                App.Close();
                                                break;
                                        case sf::Keyboard::isKeyPressed(sf::Keyboard::Space):
                                                 startingposition = Jump(pYVel,pJumped,ptheEye, ElapsedTime);
                                                 break;
                                        }
                                case sf::EventType::KeyReleased:
                                        switch(sf::Event::)
                                        {
                                        case sf::Keyboard::Left:
                                        case sf::Keyboard::Right:
                                                break;
                                        case sf::Key::Down:
                                                YReduceVelocity = 1;
                                                break;
                                        }
                                        break;
                        }
                }

The last portion is unfinished because I don't understand how to check for released keys.

EDIT: Just thought of something, could you case a false return? something like case !sf::Key::Down?
Trying that now.

[eXpl0it3r]

Since sf::Keyboard::"key" returns a bool

It does not, sf::Keyboard::isKeyPressed(key) does return a boolean.
There are multiple ways to do it, an easy one would be to use the event system which has a KeyReleased event.
Another way would be to use a boolean and set it to true when isKeyPressed() returns true and as soon as it returns false and the boolean is set to true, you know the key got released.

[natchos]

Aye, but can you differentiate between different keys being released or pressed simultaneously?

Also, I've begun delving in the new sf::clock code.
In 1.6 I constructed my own stopwatch clock, since sf::clock doesn't offer that, however I used float, which doesn't have all the precision I need.

Therefore, I was just wondering is there any way that you can get m_startTime directly, or do you have to create your own at initialization? I am hesitant to do that, since I generally use timeGetTime, and I'm not sure whether it is as accurate as the default m_startTime value that it gets in the sf::Clock ctor.

[eXpl0it3r]

Aye, but can you differentiate between different keys being released or pressed simultaneously?

Yes either with the event system (not recommended for key press events, since they only get triggered within a certain interval) or with multiple booleans that tell if a key is still being pressed or if once should call release.
For example

bool keyA = false;
while(window.isOpen())
{
    // Event handling
    if(sf::Keyboard::isKeyPressed(sf::Keyboard::A))
    {
        // Do stuff with key pressed
        keyA = true;
    }
    else if(keyA = true)
    {
        // Do stuff with key released
        keyA = false;
    }
    else
    {
        // Maybe do stuff if key is not pressed nor released
    }

Therefore, I was just wondering is there any way that you can get m_startTime directly, or do you have to create your own at initialization? I am hesitant to do that, since I generally use timeGetTime, and I'm not sure whether it is as accurate as the default m_startTime value that it gets in the sf::Clock ctor.

No there's no way to catch private internal varibles but you can use a sf::Time object and get time from the clock. With the sf::Time class you won't lose precision and you can always decide whether you want to have the result as seconds, milliseconds or microseconds. But keep in mind the sf::Clock is only as precice as the underlying system's "timer".

If this is no solution for you, you could take a look at SFML corssplatform implementation of the sf::Clock and copy it for your porject, but this won't be a trivial task if you don't know your way around building scripts...

Btw: Since you started ask various questions could you maybe update the title of your first post and add something like " and other questions", so one does not get confused.

[natchos]

Alright. Kind of seems like a two steps forward one step back approach to input but I should be able to fashion something for my needs.

As to the answer to my clock question, do you mean something like this

class Stopclock : public sf::clock
private:
sf::Time start_time
Stopclock::Stopclock()
{
start_time = this->getElapsedTime()
}
 

or is there a better way to do it?
Also, is sf::clock more accurate than timeGetTime? Else I'll just stick with my old clock I suppose, since it's been accurate enough sofar.

[Nexus]

What do you exactly want to achieve? If you need a pausable clock, you can take a look at thor::StopWatch in my library Thor, which works for SFML 2.

By the way, please open separate threads for separate topics.

[eXpl0it3r]

Alright. Kind of seems like a two steps forward one step back approach to input but I should be able to fashion something for my needs.

What are you trying to do? Maybe there's a better way of handling things.

As to the answer to my clock question, do you mean something like this

No sf::Clock is not designed for a parent class. You can use an sf::Clock internally. For example you have the functions Start() and Check(). In the Start() function your querying the clock for a time and save it into a sf::Time, now whenever Check() is called you can compaire the save time with the current clock time and the difference makes the runtime. Implementing Stop(), Pause() and Resume() won't be much harder.

Also, is sf::clock more accurate than timeGetTime? Else I'll just stick with my old clock I suppose, since it's been accurate enough sofar.

I don't really remember what SFML uses internally but I think for POSIX system it's using timeGetTime, so it will be equal, but using your own function calls to OS APIs will make your class non-portable and since you already got a nice layer with sf::Clock it's also not very logical to use your own calls.

[binary1248]

Also, is sf::clock more accurate than timeGetTime? Else I'll just stick with my old clock I suppose, since it's been accurate enough sofar.

I don't really remember what SFML uses internally but I think for POSIX system it's using timeGetTime, so it will be equal, but using your own function calls to OS APIs will make your class non-portable and since you already got a nice layer with sf::Clock it's also not very logical to use your own calls.

On Windows it uses QueryPerformanceCounter and QueryPerformanceFrequency which should get you the highest precision available on your hardware. On Mac OS X it is based on mach_absolute_time which also makes use of CPU counters and should get you the highest precision available on your hardware. On all other POSIX compliant systems (incl. Linux) it uses clock_gettime which has differing amounts of precision depending on the timers available for your hardware/kernel, most of the time and with newer hardware you can be sure it is in the nanosecond area. Just remember all these precision values are theoretical and clocks are always subject to inherent skew and so many other factors it isn't worth it to try to get an exact value. Therefore using one high-resolution timer over another should just be a matter of interface preference and not accuracy. And as eXpl0it3r already said, using sf::Clock is a free-of-charge guarantee that your code will work on almost all systems out of the box.

[natchos]

What do you exactly want to achieve? If you need a pausable clock, you can take a look at thor::StopWatch in my library Thor, which works for SFML 2.

By the way, please open separate threads for separate topics.

I use C++ 2008 which is why I do not use Thor, and I have no plans of doing so in the near future.
I would open seperate threads, yet I felt that it was unnecesary to flood the general board with 5 different topics which all pertained to the transition between 1.6 and 2.0.

[eXpl0it3r]

I use C++ 2008

There's no such thing as C++ 2008. There's C++98, C++03 and C++11.
Also you essentially don't need to use Thor but you could take a look at its source code and if you think the code does fit your needs you can just copy it.

[natchos]

I use C++ 2008

There's no such thing as C++ 2008. There's C++98, C++03 and C++11.
Also you essentially don't need to use Thor but you could take a look at its source code and if you think the code does fit your needs you can just copy it.

Meant Visual C++ 2008, which as far as I know does not use C++ 11

[natchos]

Alright. Kind of seems like a two steps forward one step back approach to input but I should be able to fashion something for my needs.

What are you trying to do? Maybe there's a better way of handling things.

I merely meant that since the code needed to check for a key being released was implemented in 1.6 it seems like a rather odd design decision to remove that inherent feature.

As to the answer to my clock question, do you mean something like this

No sf::Clock is not designed for a parent class. You can use an sf::Clock internally. For example you have the functions Start() and Check(). In the Start() function your querying the clock for a time and save it into a sf::Time, now whenever Check() is called you can compaire the save time with the current clock time and the difference makes the runtime. Implementing Stop(), Pause() and Resume() won't be much harder.

Also, is sf::clock more accurate than timeGetTime? Else I'll just stick with my old clock I suppose, since it's been accurate enough sofar.

I don't really remember what SFML uses internally but I think for POSIX system it's using timeGetTime, so it will be equal, but using your own function calls to OS APIs will make your class non-portable and since you already got a nice layer with sf::Clock it's also not very logical to use your own calls.

Well yes, but sf::clock is fairly useless on it's own except for very rudimentary timing tasks. That's why I will most likely be constructing my own stopwatch.

[Laurent]

I merely meant that since the code needed to check for a key being released was implemented in 1.6 it seems like a rather odd design decision to remove that inherent feature.

Nothing was removed. With both SFML 1.6 and SFML 2.0 you have two things:
- the key-released event: sf::Event::KeyReleased (same in both versions)
- the key-released state: !sf::Keyboard::isKeyPressed(key) (SFML 2.0), !window.GetInput().IsKeyDown(key) (SFML 1.6)
So what do you mean?
(sorry if I missed something, I didn't read the middle of this thread)

Well yes, but sf::clock is fairly useless on it's own except for very rudimentary timing tasks. That's why I will most likely be constructing my own stopwatch.

sf::Clock is not meant to be the final powerful timing class. But it provides a solid base for timing (best resolution and monotonicity), then it's up to you to add whatever high-level feature that you need on top of it.

[natchos]

In 1.6 you could directly check for released keys using
sf::Event::KeyReleased
atleast, I would assume that was what it did?

And yes I know that sf::Clock is meant to be built upon, I was merely trying to find a reason as to why I should use sf::Clock, instead of constructing my own using timeGetTime(), since I prefer a clock where I can access the start time directly, should that be necessary.
Now that binary so kindly supplied me with the information that sf::Clock should be more accurate than timeGetTime(), I will be building a clock class with an internal sf::Clock.

EDIT: One other feature which I feel that a clock needs is the ability to not only return elapsed time but also current time. That's what basically makes sf::clock not a completely perfect choice for me.

[eXpl0it3r]

In 1.6 you could directly check for released keys using
sf::Event::KeyReleased
atleast, I would assume that was what it did?

You still can check for KeyRelease that's the event system we've been refering to all the time (and which is already explained in the official SFML 2 tutorial...):

while(window.isOpen())
{
    sf::Event event;
    while(window.pollEvent(event))
    {
        if(event.type == sf::Event::KeyReleased && event.key.code == sf::Keyboard::A)
            std::cout << "The key A was released!" << std::endl;
    }
}

Now that binary so kindly supplied me with the information that sf::Clock should be more accurate than timeGetTime(), I will be building a clock class with an internal sf::Clock.

Not only that it's also more crossplatform.

One other feature which I feel that a clock needs is the ability to not only return elapsed time but also current time. That's what basically makes sf::clock not a completely perfect choice for me.

Date/time handling is already provided through the standard (ctime header), thus having this in SFML would be redundant and creating a date/time class is extremly hard if you want to satisfy everyone thus it's better to let such higherlevel wrapping to the user or they can choose other existing classes/libraries.