OpenGL goes really fast on other computers.

[Peram]

When I make an OpenGL game on this computer, it runs at normal speed. If I run it on literally any other computer, it goes really fast, making the games unplayable.
Does anyone know what might be causing this?

[gusano79]

What are the specs on your development machine? Usually this will happen if you have a simple main game loop that doesn't check the time--it will just run as fast as possible with whatever machine it's on. If this is what's happening, then you should probably try to separate your game logic from the frame rate.

[Peram]

Well, I tried playing around with that for a few days, but OpenGL applications still go very fast on other computers, and I haven't found anything about other people having this problem. :X

Edit: Of course, 5 minutes after I post that I fix it. *sigh*

[gusano79]

Of course, 5 minutes after I post that I fix it. *sigh*

That's usually how it works :)

What was the problem? Your solution might be useful to others who find this thread.

[cahitburak]

That's usually how it works :)What was the problem? Your solution might be useful to others who find this thread.

If you don't use any delay function you have to deal with this problem. The cpu or gpu tries to do the things as fast as possible so your program runs in different speeds depends on cpu's clock frequency or pc's performance but if you use a delay function (such as Sleep(ms)) on main function (for non-graphic operations) you'll define the limits.
Extra info: Human eyes can see about 24 frames in a second. That can be a reference 40miliseconds as usual.

[Serapth]

If you don't use any delay function you have to deal with this problem. The cpu or gpu tries to do the things as fast as possible so your program runs in different speeds depends on cpu's clock frequency or pc's performance but if you use a delay function (such as Sleep(ms)) on main function (for non-graphic operations) you'll define the limits.
Extra info: Human eyes can see about 24 frames in a second. That can be a reference 40miliseconds as usual.

Actually the human eye is capable of seeing substantially more than 24 frames per second and in some cases is substantially slower to process the information. In passive perception, like when watching TV or a movie, you are very unlikely to notice a lack of motion, even well below the start 23.9frames provided by NTSC ( or 29.8ish for PAL people ).

However, the inverse is not true when it is an active experience. IF you are using a PC and expecting to see a certain amount of movement, the lack of that movement is easily perceptible, even if sampling at well over 24fps. This is why the mouse cursor operates on a hardware cursor independent to everything else. If your mouse visibly updated at 24 fps, unless moving slowly or stationary, it would drive most people bonkers.

As to the topic at hand, "sleeping" is generally a bad idea, unless yielding back to the OS in some form. Generally best practice for a situation like this is to seperate your render loop from your update thread and run as fast as possible. If no bottlenecks are encounter, simply smooth your animation out be applying the elapsed time against the amount of animation, this way things will run at the same speed on different class of machines. It's when your machines aren't capable of hitting a minimum performance level that things get tricky...

[cahitburak]

Actually multithreading is so complicated to answer an easy question.

[Serapth]

Actually multithreading is so complicated to answer an easy question.

Who said anything about multithreading?

[cahitburak]

Wiki says 29,97fps for PAL and 25fps for NTSC :). Are there any necessary/unnecessary details you'll say?
Don't think about it. You are right. I'm serious.