This comes down to preference depending on your requirements. I personally run my logic and input at a fixed tick rate, then render as many times as possible until the next tick is due. If the ticks take too long, I just force a draw and let the program slow down. This would rarely happen as those rates are normally under 30 per second. Interpolation becomes a requirement with this method because your render rate is not fixed.

I handle interpolation like this (You need a Prev Position, Current Position, and Draw Position - in this case spritePrevPos, spritePos, and testSprite):

In your logic update you need to have your spritePrevPos = spritePos before any updates happen to track. Then when you move your object you're updating your spritePos. In the draw phase you would interpolate the visual spot the sprite should be at to smooth out motions base on the time passed.

(This happens outside of of your logic and update loop)

interpolation = float(((mainClock.getElapsedTime().asMilliseconds() + skipTicks) - nextTick)) / (skipTicks);

testSprite.setPosition(spritePrevPos.x + ((spritePos .x - spritePrevPos.x) * interpolation), spritePrevPos.y + ((spritePos .y - spritePrevPos.y) * interpolation));

gameWindow.draw(testSprite);

Then draw testSprite to the screen. All your main collision calculations are with spritePos, while testSprite is just for interpolation of your sprite graphic.

I hope this helps! I'm also using deWitters by preference with the added interpolation.

*Edit: I corrected the formula! Sorry I was copying and pasting mine from my test source code, but mixed up the example variables in the post! Fixed!

Hello @Josheir you have to take into context what those variables mean within the loop.

I'll break it down so you understand what values are being placed and how they're associated.

For the above:

interpolation = float(((mainClock.getElapsedTime().asMilliseconds() + skipTicks) - nextTick)) / (skipTicks);

testSprite.setPosition(spritePrevPos.x + ((spritePos .x - spritePrevPos.x) * interpolation), spritePrevPos.y + ((spritePos .y - spritePrevPos.y) * interpolation));

gameWindow.draw(testSprite);

My code is as follows before the loop even starts:

const float ticksPerSecond = 30.f;
const float skipTicks = 1000.f / ticksPerSecond;

sf::Clock mainClock;
double nextTick = mainClock.restart().asMilliseconds();

float interpolation = 0.f;

The actual loop simplified (I'm not posting everything here just enough for the example) - I do not include the loops for max frame skips for catching up in this example.

// Logic and Input
while (mainClock.getElapsedTime().asMilliseconds() > nextTick)
{
  spritePrevPos = spritePos;
  
  if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up))
  {
      spritePos.y -= spriteSpeed;
  }
  
  nextTick += skipTicks;
}

// Draw
interpolation = float(((mainClock.getElapsedTime().asMilliseconds() + skipTicks) - nextTick)) / (skipTicks);

testSprite.setPosition(spritePrevPos.x + ((spritePos .x - spritePrevPos.x) * interpolation), spritePrevPos.y + ((spritePos .y - spritePrevPos.y) * interpolation));

gameWindow.draw(testSprite);

The nextTick and skipTicks is so the loop will run one time per 0.0333 seconds, then wait until nextTick equals enough time for the next tick to be due after applying the skipTicks (time between each update call), ect... before calling the loop again, while drawing the rest of the time. (I didn't include the max update part which handles moments if you get trapped in the logic updates for too long, it will force your draw).

This will make sure the graphics are moving at a smooth rate by taking into account your Time Step variables. You can see the difference just by making a toggle (just make an event for F1 or something to toggle the boolean):

if (toggleInterpolation == true) {
  testSprite.setPosition(spritePrevPos.x + ((spritePos .x - spritePrevPos.x) * interpolation), spritePrevPos.y + ((spritePos .y - spritePrevPos.y) * interpolation));
}
else {
  testSprite.setPosition(spritePos.x, spritePos.y);
}

Quote

Secondly, where is the sleep_Time condition located as compares to the rest of the code use by Rutin's preference?

I don't want to say 'never' but I truly believe you should never ever use sleep commands in game loops. You can only guarantee the sleep will be called, but there is no guarantee it will come back within (x) time. Also, using any form of sleep command to wait until your loop is ready for an update goes against letting your logic run at (x) updates per second, and freeing your draw step by keeping it variable. The Time Step should be Fixed Logic/Input, Variable Draw. If you run your logic/input/draw in the same update "locked at 60 FPS" then you don't need to really worry about interpolation.

46 minutes ago, Josheir said:

Well I decided to start with Rutin's advice to start with for now.  I created a fixed step with interpolation.  I benefited from the structure of the non sleep usage because there is no longer a slight variation in speed with the ship.  However after all the work when I tried the game with the ship uninterpolated I saw no difference in the now acquired smoothness.  The ship is just as smooth now using interpolation as not interpolated!  I don't know how to feel about this because I spent a while and achieved the desired effect, but it is not because of the interpolation.  I'm wondering if I should leave the interpolation in the program.

 

As far as Kylotan's advice I suppose I could now start reading up on Lerp and using Alpha with a variable timestep, but I doubt it's necessary with the movement now looking okay?  

 

The Lerp is another way to interpolate and each vector is an x and y  position?  Why are they called in and out?

 

The problem was the sleep really, so perhaps I've done what I need to do with your help.  Or maybe I need to use the Lerp to complete the project more polished in your opinion?

 

What I did was put the input and the changed the values of the x and y in the input/logic half and in the second half I checked for collisions, applied the interpolation, and drew and displayed.  The first screen has about 14 images including the bullets and there all moving fine now.

 

I still haven't learned how this works too which I think is important enough to know.  How should I learn what these two formulas and the Lerp are actually doing?  They're not terribly difficult and I have taken some college mathematics so how should I go about this?  I suppose I start by googling interpolation.  Any help would be greatly appreciated!

 

 

I didn't expect the program to work right without the interpolation so I'm still pretty surprised,

Josheir

 

 

 

Do you mind sharing the code? It's extremely unlikely to have a limitless frame rate running at the max possible fps with smooth moving graphics, and interpolation showing no difference.

It might only be smooth if you've matched your draw step to the logic and input loop at the same refresh rate as your monitor while keeping it fixed.

Please post your entire game loop so I can break down what is happening. Or, if you can provide a project file for me to run to see. I've never seen draw rates that run as fast as possible on today's machines with smooth graphics unless you're using interpolation, or extrapolation. You normally need to run with vsync, or render graphics at the same refresh rate to get that smooth look otherwise.

52 minutes ago, Josheir said:

From what I understand VSYNC is about double buffering and it is on automatically with SFML.  Here is the address for the project:     https://github.com/Joshei/asteroids

The asteroids and bullets were pretty smooth.  The Ship graphic had some very slight variation with it's motion.  This is just a simple game, but changing things around I think I now have an acceptable experience.

I tried changing the ticks per second to 50.f and it was also working well.

Look forward to hearing from you,

Josheir

I use SFML a lot, and it's not on by default unless you call it. I've looked through your code and do not see it turned on unless I missed it. To turn VSYNC on you would use: window.setVerticalSyncEnabled(true); Keep in mind that your Video Card settings will override this if you have it to run all applications with VSYNC, or not.

What I've noticed so far is this:

When using pollEvent, do not use it within your logic/input update. You should be checking for events outside of that loop, and only using (sf::Keyboard::isKeyPressed(sf::Keyboard::Up)) inside the input loop. The event manager is not meant to be handled this way.

Do this:

while (mainWindow.isOpen()) {

		// Event Processing
		sf::Event event;

		while (mainWindow.pollEvent(event)) {
			// Closing Window
			if (event.type == sf::Event::Closed) {
				mainWindow.close();
			}
		}

		while (mainClock.getElapsedTime().asMilliseconds() > nextTick) {

			testSpritePosPrev = testSpritePos;

			if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up)) {
				testSpritePos.y -= testSpriteSpeed;
			}

			nextTick += skipTicks;
		}

		// Clear Window
		mainWindow.clear();

		// Draw to Window
		mainWindow.draw();

		// Display
		mainWindow.display();
}

After your input/logic loop you're calling checkCollisionsShipWithAsteroids(); on line 1213, and again more checks after. This should never be outside of the loop handling input and logic checks. You're also checking a lot of other logic outside of this, put it all under your input/logic loop.

Based on what I've seen if it's running smooth (I cannot fully test) it's because interpolation is already running on the draw side. I want you to try this as a test to see if you notice a difference. You'll have to use a test graphic to run it (get something 50x50 and name it a.png). You can alter the testSpriteSpeed variable to see more examples.

#include <SFML/Graphics.hpp>

void main(int argc, char** agrv[]) {

	// Create Main Window
	sf::RenderWindow mainWindow(sf::VideoMode(1024, 768), "Test Game", sf::Style::Close);

	// Timer for 30 INPUT LOGIC UPDATES PER SECOND
	const float ticksPerSecond = 30.f;
	const float skipTicks = 1000.f / ticksPerSecond;

	sf::Clock mainClock;
	double nextTick = mainClock.restart().asMilliseconds();

	float interpolation = 0.f;

	bool toggleInterpolation = false;

	// Sprite
	sf::Sprite testSprite;
	sf::Texture testTexture;
	testTexture.loadFromFile("a.png");
	testSprite.setTexture(testTexture);
	sf::Vector2f testSpritePos;
	sf::Vector2f testSpritePosPrev;
	int testSpriteSpeed = 5;

	// SET POS
	testSpritePos.x = 0;
	testSpritePos.y = 0;

	while (mainWindow.isOpen()) {

		// Event Processing
		sf::Event event;

		while (mainWindow.pollEvent(event)) {
			// Closing Window
			if (event.type == sf::Event::Closed) {
				mainWindow.close();
			}

			if (event.type == sf::Event::KeyPressed) {
				if (event.key.code == sf::Keyboard::Space) {
					toggleInterpolation = !toggleInterpolation;
				}
			}
		}
      
		while (mainClock.getElapsedTime().asMilliseconds() > nextTick) {

			// Updates - LOGIC
			testSpritePosPrev = testSpritePos;

			if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up)) {
				testSpritePos.y -= testSpriteSpeed;
			}

			if (sf::Keyboard::isKeyPressed(sf::Keyboard::Down)) {
				testSpritePos.y += testSpriteSpeed;
			}

			if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left)) {
				testSpritePos.x -= testSpriteSpeed;
			}

			if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right)) {
				testSpritePos.x += testSpriteSpeed;
			}

			nextTick += skipTicks;
		}

		interpolation = float(((mainClock.getElapsedTime().asMilliseconds() + skipTicks) - nextTick)) / (skipTicks);

		if (toggleInterpolation == true) {
			testSprite.setPosition(testSpritePosPrev.x + ((testSpritePos.x - testSpritePosPrev.x) * interpolation), testSpritePosPrev.y + ((testSpritePos.y - testSpritePosPrev.y) * interpolation));
		}
		else {
			testSprite.setPosition(testSpritePos.x, testSpritePos.y);
		}

		// Clear Window
		mainWindow.clear();

		// Draw to Window
		mainWindow.draw(testSprite);

		// Display
		mainWindow.display();
	}
}

You can toggle interpolation with the 'SPACE BAR'. You should see a clear difference. Let me know.