Show your implementation of GetTickCount(). Depending on what it is doing it could be a problem.

Prevent things from over-flowing by starting your timers at 0 every time your game is run. Search my article for the text, “Updating your timers has its own nuances”.

The section of my article just after that explains why you add SKIP_TICKS rather than just setting the current time etc.

L. Spiro

Suppose John walks 1 meter per second and takes 2 long steps to do so. Jane also walks at a speed of 1 m/s but needs 4, shorter steps.

After 1 second, both John & Jane have walked 1 meter. After 2 seconds, both will have traveled 2 meters.

However, what happens after 0.25 seconds? John will have travelled 0m because he's still trying to do his first step. However Jane will already have travelled 0.25m because she has already taken a step, and is getting prepared to perform her second one.

Logic & Physics update is the same. We use interpolation in Graphics so that to the eyes (what we render) looks like John & Jane are taking the similar number of steps (and after 0.25 seconds, both John & Jane look like they traveled 0.25m). How many steps look like they're taking will depend on the rendering framerate.

We could do this for logic too, but it's advised not to do so. This interpolation can have undesired side effects (particularly with extreme interpolation/extrapolation values) and can induce into very rare and hard to find bugs that are triggered because it broke one of your logic's system assumptions or triggered a corner case.

What is worse, is that the probability of triggering these logic bugs depends on the speed of the CPU, so while everything works fine in your PC, the game is buggy as hell in a faster machine..... or slower ones. (Older games had these types of bugs. One game I can recall that was affected by those is Grim Fandango, there are more)

It also breaks determinism, which is a very desirable property. Without determinism, each run given the same input (i.e. key strokes, random seed) may yield different results, while a deterministic game will always give the same result (given the same input & after isolated all sources of undeterminism, such as user input, random seed).

Determinism is desirable because it allows you to reproduce bugs & crashes in no time (imagine trying to reproduce a bug that happens one in a thousand player matches!!)

Interpolating in Logic from fixed steps has almost the same effects as using variable frame rate (instead of fixed). All of this applies to Physics as well (which is the main point of Gaffer's article), but physics engines have the additional problem that simulations become unstable and the "bullet through paper" problem

So, in short, you could interpolate values for logic, but this doesn't mean you should. Just do it for graphics.

For GetTickCount() I'm using gameTime.getElapsedTime().asMilliseconds() where gameTime is an sf::Clock (using SFML). It's the next_game_tick that overflows since it's always having a number get added to it (SKIP_TICKS) but nothing gets subtracted from it.

 
const int TICKS_PER_SECOND = 25;
    const int SKIP_TICKS = 1000 / TICKS_PER_SECOND;
    const int MAX_FRAMESKIP = 5;
    sf::Clock gameTime;
    //First tick is at 0.0 next tick is at 
    long int next_game_tick = 0;
    int loops;
    float interpolation;
 
    bool game_is_running = true;
    while( game_is_running ) {
 
        loops = 0;
        while( gameTime.getElapsedTime().asMilliseconds() > next_game_tick && loops < MAX_FRAMESKIP) {
            std::cout << "Updating" << std::endl;
 
            next_game_tick += SKIP_TICKS;
            loops++;
        }
 
        interpolation = float( gameTime.getElapsedTime().asMilliseconds() + SKIP_TICKS - next_game_tick )
                        / float( SKIP_TICKS );
        std::cout << interpolation << std::endl;
    }

This is exactly the problem (and it is 2-fold).

That is one key point to remember, but even this has a nuance. Request the current time once and only once per frame. Then store it and use that as a reference for everything else you want to do. This is not about performance, although that is one consideration (polling the current time is slow on some CPU’s). This is about consistency. Consider the extreme opposite in which you request the current time every time you need it. Suddenly one of your objects is falling faster than the rest simply because the time value it got was higher, so it considered that more time had passed since its last update, and thus it fell further. Note that this is to be followed strictly as far as “what happens inside the game simulation”, but don’t read my bolded text blindly; you are free to request the current time as often as necessary on other threads, such as the input thread or sound thread if you want to time-stamp certain events (and you should).

#1: You can’t be requesting the current time every time you need a time value. Think about how it affects your inner loop when your time function returns a different value every time it is called. My article gives one example of the problems this can cause, as quoted.
#2: As I mentioned before, clock() is forbidden as a game timer. Use QueryPerformanceCounter() and friend.

Firstly, you need a solution to #2. You need to make your own CTime class (call it whatever you want) that is designed for handling times in games.
Core functions:
#1: Get the real time when created, store it as m_ui64LastRealTime. Also m_ui64CurTime = m_ui64LastTime = 0ULL.
#2: Once every frame, call Update() on that timer. The code is in the article.

	/**
	 * Gets the real system time.  Not to be used for any other purpose besides random-number
	 *	seeding.
	 *
	 * \return Returns the real system time in system tick units.
	 */
	LSUINT64 LSE_CALL CTime::GetRealTime() const {
		LSUINT64 ui64Ret;
		::QueryPerformanceCounter( reinterpret_cast<LARGE_INTEGER *>(&ui64Ret) );
		return ui64Ret;
	}

	/**
	 * Update the time.
	 *
	 * \param _bUpdateVirtuals If true, virtual values are updated as well.
	 */
	LSVOID LSE_CALL CTime::Update( LSBOOL _bUpdateVirtuals ) {
		LSUINT64 ui64TimeNow = GetRealTime();
		// Wrapping handled implicitly.
		LSUINT64 ui64Dif = ui64TimeNow - m_ui64LastRealTime;
		m_ui64LastRealTime = ui64TimeNow;

		UpdateBy( ui64Dif, _bUpdateVirtuals );
	}

	/**
	 * Update the time by a certain amount.
	 *
	 * \param _ui64Amnt Number of ticks by which to update the time.
	 * \param _bUpdateVirtuals If true, virtual values are updated as well.
	 */
	LSVOID LSE_CALL CTime::UpdateBy( LSUINT64 _ui64Amnt, LSBOOL _bUpdateVirtuals ) {
		m_ui64LastTime = m_ui64CurTime;
		m_ui64CurTime += _ui64Amnt;
		…

#3: Notice that GetRealTime() is called only once per frame. The time since the last update is then calculated and all the timer counters are adjusted by that much. Never get the real time more than once per frame. It’s changing, and nothing related to time should be changing until your next update (actually this is not quite true but I won’t confuse you with the details for now, especially not until you have made a game-suitable time class which is instance-based—never work with global time objects).
#4: The game loop begins by calling Update() on its timer. It uses the microseconds since the last update to determine how many logical updates it needs to do. This calculation is done before is actually does any logical updating. IE you can’t know how many logical updates you need to do by using a time value that is changing every time you call it. This is prepared in advance.

clock() is very inaccurate (I assume SFML is using this).

And you can’t do math with variables that are constantly changing.

Calculate everything up-front and then go.

L. Spiro

#2: I looked up sf::Clock (well more like asked on the sfml forums) and it seems sf::Clock does use QueryPerformanceCounter() on windows and the equivalents on mac and linux platforms (so it's a cross platform clock). That being said, I should be able to use it just fine then as long as I getelapsedmilliseconds once and store it to a variable per frame correct?

How would I fix the overflow of next_game_tick?

Wouldn't gameTime.getElapsedTime().asMilliseconds() eventually wrap around as well?