   a bunch of directx questions
  1.how do i know the optimum number of back buffers to use , should i try looping and justusing the maximum amount possible. cause as i see making more surfaces uses up the dead time instead of doing nothing.2.why does creating too many back buffers generate errs , is it because iam abusing the video memory by creating too many surfaces.3. is using D3DPRESENT_INTERVAL_DEFAULT , then setting the refresh rate to a certian value (that is supported by driver) , a good way yo control FPS.   
  You only need one back buffer. For 3D applications, they would some times use more for depth and/or stencil buffers. But pretty much, the term back buffer usually means the off screen surface in a double buffered rendering scheme-the back buffer. You only need one of these so making more then one could cause errors. There are such things as triple buffering, but double buffering is good enough for most cases. So I would stick with just one. The dead time you experience should be used by your application to perform off-hand tasks such as memory management or other logic based things.If you want to control the frame rate in your application try using a frame timer or time bases movement. This article on GameDev suggests frame rate independent movement; if that is what you are after. Direct3D uses the presentation interval to set the maximum rate of which a "back buffer" is rendered. It describes the relationship between adapter refresh rates. For a more detailed explanation, consult your DirectX SDK documentation under D3DPRESNT, or click here.I my self, usually use D3DPRESENT_INTERVAL_IMMEDIATE because I like to update the scene as fast as possible with no v-sync lock. Hope this helps!;  Setting the refresh rate seems like a bad way to control the FPS. Ideally, you don't want to limit the fps, but have your graphics run at any speed. This will ensure that the game can be run even if a computer can't manage 60 FPS.   ;  well that true in most cases , but sometimes the game becomes too fast. so iam just taking precautions.i came up with a little method to limit FPS , i would love it if someone would pointout any inefficiency i.e tell me if it's baaaaaaaaaaaad .if ((1/(GetPTime() - time)) > (FPSLimit)){float STime=1,ETime=FPSLimit;//GetPTime gets the time since the system has started in seconds// time was set to the value GetPtime before the frame was rendered//GetPTime() - time = time needed to render one frameETime = (STime/ETime)-(GetPTime() - time);Sleep(ETime*1000); }   ;  When you try and limit the fps, what happens if the computer can only run half that speed? Then all your graphics are going to move at half the speed. This can make you game easier, or even annoying to play on older computers. Of course, for a simple 2D game, this really isn't a problem nowadays, so you must use your own discretion.You can make your graphics update by how much time has past. IF an object moves at 100 pixels/meters per second, it will move the same no matter how fast the game runs. If it runs at 20 FPS, it will move ~5 pixels per frame. If it runs at 50 FPS, it will move 2 pixels per frame. this will create consistent and fluid motion at any speed.   ;  iam not sure if i understand, basicly this tests if the framepersecond are MORE than the limit decided , if true, it computes the more time needed to even things , then sleeps that time then continou normally. in case the the pc can't run at that speed , it wouldn't be a problem, since it only sleeps if the current frame rate is more than the one decided , so basicly it would do nothing.   ;  While it is probably better to use time-based rather than frame-rate-based rendering and so on, Drew Benton once posted a very good link:http://www.mvps.org/directx/articles/writing_the_game_loop.htmthat shows how to limit your rates in the main Windows message loop. I've been using this recently and works very well if you are content to make a given frame rate (I'm using 60fps) the minimum requirement for your games.HTH Paul   ;  but he wastes all that extra time , i think it's better if the app yeilds some processing timeback to the os. baiscly there is no much diffrence between the two methods , at leastmy way insures that time goes unwasted ,no?.   ;  The linked code has been confirmed to be accurate with FRAPS. If you want to compare the two methods, test yours with FRAPS and see how accurate it is. I don't think sleep() is very accurate but I don't know much about it to be honest.   ;  sleep is not the most accurate , but at most i get +2 , -2 frames. so it isn't that inaccurate either.the way i see it , is that this time is wasted anyway, so why not make the most out of it.   