   Game Loop
  before today my game loop was your standardgameloop(){  while(true)  {    draw()    doevents()  }}I just switched over to a timer based draw loop.....each time the timer tics (1 millisecond atm)  it calls render....this should pretty much do the same thing right?   
  yeah. but maybe you can better measure the elapsed time between renders and provide your doevents function this timestep.   ;  Both techniques are pretty much identical and suffer the same flaw: they are either CPU or GPU bound. If your computer takes more time to loop (say 2 ms) than the allocated timestep (say 1 ms), then your game will run at half its designed speed.To address this issue you should consider the time taken to loop, each frame:gameloop(){    lasttime = currenttime = gettime()    while(true)    {   currenttime = gettime()   delta = currenttime - lasttime // time taken to process previous loop   lasttime = currenttime   draw( delta)   doevents( delta) // may be optional here    }}   ;Check this discussion:http://www.gamedev.net/community/forums/topic.asp?topic_id=393475Hmm ... this topic pops up like every second week.   ;"Both techniques are pretty much identical and suffer the same flaw: they are either CPU or GPU bound. If your computer takes more time to loop (say 2 ms) than the allocated timestep (say 1 ms), then your game will run at half its designed speed."I think we are a little confused....that doevents call is for windows to process its events....and since i moved to the time based system i dont have to call that.right now my draw loop looks like this//this happens every time my game timer ticks at 1 millisecond //(so if it were fast enough 1000 fps :) )protected void RenderTick(object sender, EventArgs e){this._Draw.Render(this._regionManager, this._View);this._View.TotalFramesRendered++;}//this ticks every second to update the fps counter//since i set the total back to 0 every second i am not getting an//avg frames per second but i am getting the number of frames in//that specific second.void t_Tick(object sender, EventArgs e){_totalTimeElapsed++;this._View.FPS = _View.TotalFramesRendered;_View.TotalFramesRendered = 0;}also..as for game events....is it best to go multithreaded or just user timers to kick off events?;Quote:Original post by nex7also..as for game events....is it best to go multithreaded or just user timers to kick off events?I would simply call the tick function... no need to make things more complicated than they already are.   ;  Ok well i did some looking and it seems that no matter what i do with timers the game logic will still be tied to the render loop.I have got to get all of that information out into a separate thread that way my game can run at a constant speed while my render loop runs full bore.while( true){  dogamestuff()  render()}that just wont work..it will be tied directly to the render speed...or the render speed will be tied directly to the game code....so if i want true separation of powers here i need to go multithreaded.Im sure that this comes up all the time....Every newb has to start somewhere....I’ve been writing business apps for 8 years now....its always fun to find something so different in code than what your used to.;Quote:Original post by nex7I have got to get all of that information out into a separate thread that way my game can run at a constant speed while my render loop runs full bore.Do you mean that you want your game logic to run at a different speed than your drawing code? That just does not make sense.Jehan really hit the nail on the head; I don't know why you dismissed what he said. With his solution, which is what I use too, your game runs as fast as it can and all the update logic compensates.Your way will work, but (A) you limit your FPS so your game may not run as well as possible and (B) when run on a slower machine that cannot keep up with your imposed frame rate, everything will slow down.   ;  I'm sorry I didn't mean to be rude or anything...I was just under the impression that you want your rendering to be done as fast as possible while the other systems are running at a constant rate...so that the rendering is disjointed from the actual game logic.in Jehan's solution....isnt the game logic still tied down by the rendering speed?say on a really slow machine....if the rendering gets tied up the game logic would take a hit as well would it not?   ;Quote:Original post by nex7I'm sorry I didn't mean to be rude or anything...I was just under the impression that you want your rendering to be done as fast as possible while the other systems are running at a constant rate...so that the rendering is disjointed from the actual game logic.Well...you always want your rendering to reflect the current state of your game, in fact, that's rather *the point* of rendering in the first place: so the player knows what is going on with whatever game logic is in place.So if the rendering were to be done faster than the logic of updating game elements, all of the game elemnts would be the same and there would be nothing new to draw. Conversely, if the updating was done faster, the screen would be out of date which would likely confuse the player.The way you should do it is update everything that needs to be updated, and then update the display by rendering everything. Yes, you are tied down by rendering speed, but if you think about it, there's little point in the rendering "getting ahead" of the rest of your game, or of the update logic getting ahead of rendering.This is why it's necessary in most games to optimize the drawing code as much as possible!Good Luck [smile]   