it should. Can you post your code ?

I just did a little more testing, and it seems that changing the timer speed does affect it after a point.

volatile int counter = 0;

LOCK_VARIABLE(counter);
LOCK_FUNCTION(timer);
install_int_ex(timer, MSEC_TO_TIMER(1));

while(1) {
  if(counter >= 1) {
    //Main loop
  }
  //Drawing
}

EDIT:
Code change...

Forgot to mention, there is already a counter = 0 in the main loop. Sorry.

EDIT:
Anyway, I can remove the bit about timers on Linux and it still runs the same speed.

EDIT2:
I must go now. I may be back tomorrow. Thanks.

What? How would that bypass the timer?

It almost looks as though your counter is based on 1 ms increments. That alone could be the source of your problems. Running your game at an internal framerate of 1000 FPS is going to cause speed variations you never considered.

I'm also going to assume you are running a fixed time engine instead of a real time engine. In that case, the speed difference you are experiencing has to do with one of your computers/OSes being less able to keep up with a 1 ms timer than the other.

Instead of MSEC_TO_TIMER(1) try BPS_TO_TIMER(30) to do a 30 ticks per second timer, and then alter all your code to move at that rate. That should take care of your speed issues. (Provided both computers/OSes you are running this game on can handle 30 ticks per second of your game.)

--- Kris Asick (Gemini)
--- http://www.pixelships.com

I usually run 60 hz timer logic myself.

But low enough to know if that was the problem or not upon implementing it!

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Yes you definitely want the server using up all available resources so it is at no less then 100% cpu usage at all times. End Sarcasm

Server is much more important then the client, as if someone decides to hack your client and your server doesn't follow logic speed, then they can use that to a pretty massive advantage. The client should be restricted as well, but the server is what synchronizes play between clients, not the other way around (this is in a client/server setup, p2p behaves differently).

Secondly, though I'm sure a server might be able to take it, it's probably not in your best interest to have a server running as fast as it can when the cpu usage can be best used for other things (like resting, as cooling can be an issue in a tightly packed server environment).

The same goes for network traffic for obvious reasons.(I hope).

But now that I've said that, next time you may want to start a separate thread and not hijack someone else's.

30 BPS will be too slow for you. I'd go for at least 60.

Yes, who cares about those people who might have better computers than you and might want to run the game without stutter? Shame on them for even suggesting it!

Because of the presence of motion blur, which mitigates the stuttering effect. Computer games generally don't simulate motion blur, which means you need much higher framerates to avoid choppiness.

I read somewhere that 50fps is about the amount the eyes/brain can cope with. More is (in terms of visible aspects) unnecessary...