Graphic is bugging because of sf::Clock

[moin354]

Hello Community,

First apology if this isnt the right position for this question. Now to my problem at the beginning i've moved a sprite only by move and a x.xx number. Now i try to move it with sf::Clock to not be bound at the framerate. But then sometimes the sprite moves through the texture. My OS is Windows 7 home premium. Here is a little snippet of the code:

               
window.setFramerateLimit(60);
sf::Clock clock;       
while (window.isOpen())
        {              

                sf::Time elapsedTime = clock.restart();
                speed = elapsedTime.asSeconds() * Game::speed;
                sprite.move(speed, gravity);
                //checking for collisions etc.
                }

For more code just ask.

P.S: Sorry for the bad english.

[Laurent]

But then sometimes the sprite moves through the texture

What does that mean?

[Ixrec]

If you're asking why your player falls through the floor sometimes (just guessing), that probably has more to do with how you test for collisions than anything else, so you should probably show us that code.

[kerp]

hello, i think i know what moin is talking about.

you just need to enable vertical sync just before window.display() call
with the  window.setVerticalSyncEnabled(true) function

i see he has the vertical refresh rate value already put in too....
 

[Ixrec]

Like the tutorials say, you're not supposed to use Vsync and a framerate limit at the same time.  They just end up fighting each other and neither wins.

[moin354]

If you're asking why your player falls through the floor sometimes (just guessing), that probably has more to do with how you test for collisions than anything else, so you should probably show us that code.

Hi but with the max. framerate my sprite dont fall through the floor, but here is the code:

                if(playerrect.intersects(rect)){
                if(playerrect.top - playerrect.height < rsprite.getPosition().y && playerrect.left + playerrect.width > rect.left + 1 && playerrect.left < rect.left + rect.width - 1 && playerrect.top + playerrect.height < rect.top + rect.height + 1)
                        collisiontop = true;
                    currentcollision = true;
        }else
                collisiontop = false;

        if(playerrect.intersects(rect)){
                if(psprite.getPosition().y > rsprite.getPosition().y)
                        collisionbottom = true;
        }else
                collisionbottom = false;       
       
        if(playerrect.intersects(rect)){
                if(psprite.getPosition().x < rsprite.getPosition().x)
                        collisionleft = true;
        }else
                collisionleft = false;

        if(playerrect.intersects(rect)){
                if(psprite.getPosition().x > rsprite.getPosition().x)
                        collisionright = true;
        }else
                collisionright = false;



        if(collisiontop == true){
                Game::jumpable = true;
                Game::collisiontop = true;
        }

        if(collisionleft == true && collisiontop == false){
                Game::collisionleft = true;    
        }

        if(collisionright == true && collisiontop == false){
                Game::collisionright = true;
        }

        if(collisionbottom == true){
        Game::collisionbottom = true;          
        }

        if(Game::collisiontop == true && collisiontop == false){
                currentcollision = false;
        }

        if(posY < rect.top - 250 && currentcollision == true){
                Game::up = false;
                currentcollision = false;
        }

[Ixrec]

Well that's hardly complete and minimal code (not to mention extremely redundant code), but my guess would be that your character moves enough pixels per frame that there simply is no frame during which he intersects the rectangle yet is still above it.

You need to design some collision logic that doesn't rely on frames taking specific lengths of time.  The simplest approach I know of is looking at where the player is and "should" move to (given player input, gravity, momentum, delta time, etc), and see if there are any obstacles between the two points.

[moin354]

Well that's hardly complete and minimal code (not to mention extremely redundant code), but my guess would be that your character moves enough pixels per frame that there simply is no frame during which he intersects the rectangle yet is still above it.

You need to design some collision logic that doesn't rely on frames taking specific lengths of time.  The simplest approach I know of is looking at where the player is and "should" move to (given player input, gravity, momentum, delta time, etc), and see if there are any obstacles between the two points.

Ok, thanks for the answer. But i have no idea how to realize this, can you give me any tips or something?

[The Hatchet]

calculate where the player SHOULD move to (don't actually move them), with the new coordinates check for collision, if there is none then move the player.  Rinse and repeat until you get a collision, then just calculate the difference of the current position to the edge of the collision and move the player that much. 

It's pretty simple and will allow the player to butt-up against walls and floors with pixel perfect accuracy*(depending on your own calculations)

*results may vary

[anthnich]

Might be a good idea to implement a time step to ensure that you are checking your collision/ticking at a set rate. If you collision checks fluctuate based on a clock, then the check resolution is going to vary.

[Tobberoth]

Might be a good idea to implement a time step to ensure that you are checking your collision/ticking at a set rate. If you collision checks fluctuate based on a clock, then the check resolution is going to vary.

This is probably the best way to do it and is covered in the SFML book. Basically, you count the milliseconds/ticks each loop and only when it hits a set limit do you do your logic. Thus, you know exactly how far a sprite will move each time and can make sure there's no way your character can pass through an object in such a step.