Looks like your framerate is low or unsteady.
Ideally you want your rate of update a constant and high number, and you could log / display timings to check this.

Nick72c said:
How would you suggest I log / display timings to check this? It's not something I'm familiar with.

I meant simply to log the duration happening between each update, by tking the difference of current realtime to past realtime from previous frame.

I'll try to modify your code, maybe something pops out while doing so…

Uint64 prevTime = 0;

while (!window.isClosed())

{

const Uint64 curTime = SDL_GetTicks64();

std::cout << "frame duration: " << curTime - prevTime << std::endl;


prevTime = curTime;

const Uint64 timeout = curTime + 1000 / 60; // timout = now (total number of clicks since SDL initialisatom) + 1/60th of a second

pollObjects(window, hero); // check for user input and update main charccter position

buildmap(sky, grass, earth); // load and draw background

hero.draw(); // draw main character in new position

std::cout << "tick" << std::endl; // check ratio of delay loops (tocks) to main loops (ticks)


// blocking loop:
while (SDL_GetTicks64() < timeout) // add delay so that full loop + delay >= 1/60th second (frame rate 60fps)

{

SDL_Delay(1);

std::cout << "tock" << std::endl; // check ratio of delay loops (tocks) to main loops (ticks)

}


window.clear(); // draw new frame

}

Now i'm curious if you get constant or fluctuating values for frame duration.

I added a ‘blocking loop' comment. That's a way which traditionally might not work well, depending on the accuracy of hardware timers. (Which seems good on any recent computers, though.)

You could try to remove the SDL_Delay(1). Then it's a busy loop, will saturate CPU utilization for nothing, but accuracy might increase in case the delay function acts very inaccurately. That's no solution, but just to see if it makes a difference.
You could also try to do the delay for the precise duration as calculated, instead to use a loop: SDL_Delay(timeout - curTime);
But should be just a better way offered by SDL, which i don't have experience with.

Oh … I think i know the true reason: You forgot to include the time it takes to do your update. You always wait for the same constant time of 1000 / 60 after the unknown amount of update time has already passed, so no wonder it does not work that well.

A simple way to respect update time would be like this:

const Uint64 timeStep = 1000 / 60;
Uint64 timeout = SDL_GetTicks64();
while (!window.isClosed())
{

pollObjects(window, hero); // check for user input and update main charccter position

buildmap(sky, grass, earth); // load and draw background

hero.draw(); // draw main character in new position

const Uint64 curTime = SDL_GetTicks64();


#if 0

// blocking loop:
while (curTime < timeout) // add delay so that full loop + delay >= 1/60th second (frame rate 60fps)


	SDL_Delay(1);
#else
Uint64 delay = timeout - curTime;
if (delay > 0) SDL_Delay(delay);
#endif


timeout += timeStep;


window.clear(); // draw new frame

}

There is the famous ‘Fix Your Timestep’ article, easy ti find in case you don't know, with more details.

The question on how to do the time sync with SDL remains open, maybe somebody else knows…
Or you search for some SDL tutorials.

// load and draw background

Just saw that. Does it mean you load the level and images form disk each frame???

Ofc. you should do that after application startup just once, not inside the game loop! (I guess you have no fancy open world streaming yet.) ; )

Nick72c said:
I've not got to file handling yet and have the entire map on the stack, initialized in ‘static int const map[20][72]’

Ha ok, that's fine. Just fyi, a static array goes to the static memory, not dynamic stack or heap. Which is fine as well.

Nick72c said:
Scrolling works fine, but the map lurches and glitches horribly as it scrolls.

Video looks good? Probably you want smooth scrolling on pixel (or nowadays even subpixel) level. Currently you scroll by the width of a whole tile, which ofc. isn't nice.