I want to know how to control the moving speed of a object. My thought was to have the move function to be executed every x millisecond, but well I would need to use multi-threading wont I? And i keep reading that rendering main screen from other thread is very bad and i shouldnt use so i donno what to do?!
@Damadger. There are a few ways to call your move function at regular time intervals without multi-threading.
1) If you have a windows callback function responding to windows messages then setup a timer and call your move function when WM_TIMER messages are received.
2) Simple: call move() in the render loop before drawing. The rate may vary from machine to machine though. If you sync to the refresh rate for rendering then your move function would be called at the vsync rate. My monitor is set for a 60hz refresh rate, so on my computer move() would get called 60 times per second.
V-sync is tough to code for, not sure a straight SDL/OpenGl combo can do it. I've actually found that setting v-sync manually for my graphics card has better results than v-sync a game might try to implement anyway.
You don't want to link the speed of your sprite to the framerate, use a clock. Looks like SDL has a timer SDL_GetTicks();.
Basically, your sprite class (or however you're doing it) keeps track of the time the last time it moved. Then when you move it, you give it the current time. The difference between these two is coefficient to the speed of the sprite. It will move at the same speed no matter the framerate. Acutally, it moves the same speed no matter how slow/fast any part of the program is.
My guess, you don't need to worry about multi-thread. By using the timer, you can calculate a framerate (or perhaps just display framerate from you graphics card). Chances are your program will have no trouble displaying 60 fps, maybe it can do 1000+ at this point. If you're doing stress tests and it goes below, well, maybe this is the time to try to multi-thread.