For simple camera motion, it is fine to just use dt*speed, rather than a fixed step. Where a fixed step really becomes important is a) physics simulations, that can become unstable with high values of dt, and b) multiplayer, where slight mathematical error occurring on each machine can cause a de-sync.

Yes this is what I suspected as well. I just tried implementing the code I posted in my previous reply. I tried it out with enabling/disabling Vsync and it seems to work fine. One thing I've been wondering after looking through several resources is that people say dt*speed is enough for a frame-independent movement (well in case of a simple purpose). My corresponding code, from what I understand, would simply be this (assuming one coordinate to keep this short):

cameraPos.x = cameraPos.x + (rotMat[0].x*timeInterval);

rotMat[0].x would be the actual displacement while timeInterval is the time it takes to draw one frame as mentioned before. But running it like that was way too slow so I had to add in a weighting factor (moveSpeed in prev reply). Am I understanding something wrong here?

I suspect that what might be going wrong in your code is key repeat. It's been years and years since I bothered with Glut, but if I remember correctly by default it repeats keys. This means that it will send a sequence of keydown/keyup callbacks timed according to the timing of the system key repeat rate. Typically with games, you want to use glutIgnoreKeyRepeat so that keys won't be repeated and the callback for glutKeyboardFunc will store state for the key in a table. The callback for glutKeyboardUpFunc will clear that state. Then, in your update function, you query the state of this key table and move the camera accordingly.

I checked some sources and read about this as well. Supposedly in glut (or freeglut to be more precise) you press the button and keep holding it you should have a repeating pattern; your keydown/keyup callbacks are repeatedly called as you wrote. Out of curiosity I wanted to confirm this so I simply placed code for printing out a message in both callback methods to see if those messages would be shown repeatedly as I held some defined key down. The result was that the keydown callback was called repeatedly, the keyup callback wasn't called until I released the button. Quite different from what I expected and have read about the callback methods repeating. Well as you said you haven't used GLUT for years so you might not care for this but I thought it was interesting to note anyway

For simple camera motion, it is fine to just use dt*speed, rather than a fixed step. Where a fixed step really becomes important is a) physics simulations, that can become unstable with high values of dt, and b) multiplayer, where slight mathematical error occurring on each machine can cause a de-sync.

Yes this is what I suspected as well. I just tried implementing the code I posted in my previous reply. I tried it out with enabling/disabling Vsync and it seems to work fine. One thing I've been wondering after looking through several resources is that people say dt*speed is enough for a frame-independent movement (well in case of a simple purpose). My corresponding code, from what I understand, would simply be this (assuming one coordinate to keep this short):

cameraPos.x = cameraPos.x + (rotMat[0].x*timeInterval);

rotMat[0].x would be the actual displacement while timeInterval is the time it takes to draw one frame as mentioned before. But running it like that was way too slow so I had to add in a weighting factor. Am I understanding something wrong here?

I suspect that what might be going wrong in your code is key repeat. It's been years and years since I bothered with Glut, but if I remember correctly by default it repeats keys. This means that it will send a sequence of keydown/keyup callbacks timed according to the timing of the system key repeat rate. Typically with games, you want to use glutIgnoreKeyRepeat so that keys won't be repeated and the callback for glutKeyboardFunc will store state for the key in a table. The callback for glutKeyboardUpFunc will clear that state. Then, in your update function, you query the state of this key table and move the camera accordingly.

I checked some sources and read about this as well. Supposedly in glut (or freeglut to be more precise) you press the button and keep holding it you should have a repeating pattern; your keydown/keyup callbacks are repeatedly called as you wrote. Out of curiosity I wanted to confirm this so I simply placed code for printing out a message in both callback methods to see if those messages would be shown repeatedly as I held some defined key down. The result was that the keydown callback was called repeatedly, the keyup callback wasn't called until I released the button. Quite different from what I expected and have read about the callback methods repeating. Well as you said you haven't used GLUT for years so you might not care for this but I thought it was interesting to note anyway