I remember something like this from many years ago.
Do you notice the stutter if you look away from the screen and use your peripheral vision? I seem to recall that some people are more sensitive to it than others, and that it tended to disappear as scene complexity grew.
Also, are you sure your monitor is at 60hz? Many run at 59 *or* 60 (my Dell can be set to 29, 30, 59 or 60) - perhaps there is a hardware mismatch somewhere.
I ran your sample (on Windows) and I don't see any stuttering, though the timings in the console log varies a lot, some are 1ms and some are 15 etc, but the actual animation seems smooth.
Not that I would be likely to notice anything wrong as the image moves so slowly and quickly goes off screen.
Window mode usually doesn't have perfect vsync, and often can't have perfect vsync (as it shares the sync with other apps). You have to go to exclusive fullscreen.
I have no idea how Linux drivers work, but as long as other games work correctly and you swap in fullscreen mode with time to spare until vsync I don't see why you would get stuttering.
Erik, thank you very much for running it on your system. I really appreciate the help.
I am definitely running in windowed mode, and I noticed when I went to fullscreen in Windows the problem almost completely disappears. In windowed mode though, the stutter can still be seen and this problem does not occur with other games. Your explanation of not being able to have perfect VSync makes sense though, thank you.
As for Linux though, it still does not explain why the stutter is so prevalent - and this is with glut or with SDL. It's like it takes the Windows problem and enhances it. And I have the latest drivers on 12.04 and on 13.04, but for 13.10 it is just rolled into the OS. I wonder if this happens on CentOS or another distro....
Still doesn't make sense to me why other games don't have the same problem, such as the Gish game. Same environment, with no apps running, etc.
I remember something like this from many years ago.
Do you notice the stutter if you look away from the screen and use your peripheral vision? I seem to recall that some people are more sensitive to it than others, and that it tended to disappear as scene complexity grew.
Also, are you sure your monitor is at 60hz? Many run at 59 *or* 60 (my Dell can be set to 29, 30, 59 or 60) - perhaps there is a hardware mismatch somewhere.
Yep, definitely happens if I look away and use peripheral. Didn't know that could happen though, that's cool. I will check now to ensure that the monitor is in fact at 60hz, but if it isn't then VSync should be able to figure that out I would hope. There is something with frames being dropped though, some way some how.
Edit:
I had stuttering issues myself, but it only happened on windowed linux and windowed AND fullscreen windows
My imperfect solution was to interpolate player camera rotation and movement (separately)
I didn't interpolate movement or rotation before, so when i did with rotation it became really smooth.
After that I just added weight to player position (very stupid 'fix',) but it actually works ok
like
player.xyz = oldPlayer.xyz * weight + newPlayer.xyz * (1.0 - weight);
where old and new are only updated each time the physics thread is updated
I'ts not a solution, but if it makes things smooth for you, like it did for me, at least we both know the reason 
the physics thread just didn't update regularly enough because of the variable amount of background work it does and the irregularities in the update frequency
Also, for rotation i just interpolated pitch/yaw/roll, because that made things simpler (no need for slerp)
I had stuttering issues myself, but it only happened on windowed linux and windowed AND fullscreen windows
My imperfect solution was to interpolate player camera rotation and movement (separately)
I didn't interpolate movement or rotation before, so when i did with rotation it became really smooth.
After that I just added weight to player position (very stupid 'fix',) but it actually works ok
like
player.xyz = oldPlayer.xyz * weight + newPlayer.xyz * (1.0 - weight);
where old and new are only updated each time the physics thread is updated
I'ts not a solution, but if it makes things smooth for you, like it did for me, at least we both know the reason
the physics thread just didn't update regularly enough because of the variable amount of background work it does and the irregularities in the update frequency
Also, for rotation i just interpolated pitch/yaw/roll, because that made things simpler (no need for slerp)
I'm not sure I understand this one completely, but the way I interpret it is having the player's movement depend on the delta between frames? If that is so, then it does do that already. Same for the scrolling of the background and everything else. The whole environment runs off a delta (which made me think of taking that out and seeing what happens when it doesn't - which is why I made the sample program I put on Github to take out all the variables I could).
Do you have a virus scanner active?
No sir, I do not. In fact I killed all running processes that were not critical in both Windows and Linux - and even reformatted Linux (and also upgraded it to Ubuntu 13.10 and installed only the SDL2 libs), AND reinstalled my video drivers in both Linux and Windows.
Not sure why I didn't think of this before, but is it possible that your stuttering is caused by the fact that you're writing to the console window every frame? I just tested the sample code on Windows... The regular size for the console window buffer is 80x300 characters, and with that setting, I get no/low stuttering. When I changed the buffer size to 3000x3000, it started stuttering the way you describe, and it was worse when I maximized the console window. The Linux console window probably also has this issue.
Another way I can think of to reproduce this would be to pipe the output of your program's stdout to a file.
IF you comment out the code that prints to the console, do you still get the stuttering?
Not sure why I didn't think of this before, but is it possible that your stuttering is caused by the fact that you're writing to the console window every frame? I just tested the sample code on Windows... The regular size for the console window buffer is 80x300 characters, and with that setting, I get no/low stuttering. When I changed the buffer size to 3000x3000, it started stuttering the way you describe, and it was worse when I maximized the console window. The Linux console window probably also has this issue.
Another way I can think of to reproduce this would be to pipe the output of your program's stdout to a file.
IF you comment out the code that prints to the console, do you still get the stuttering?
Sorry for the very delayed response - been out of the country the past couple weeks. I did try removing all the output statements, piping them to a file, limiting them, etc. and the problem still persists.
I'm out of ideas, sorry.
Haha, it's okay. I am too, and I'm baffled. If I ever figure it out I'll be sure to post. Thank you very much for the help though everybody!!! :)
