a bunch of directx questions

Started by
8 comments, last by Code Fusion 17 years, 10 months ago
1.how do i know the optimum number of back buffers to use , should i try looping and just using 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.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
Advertisement
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!
Take back the internet with the most awsome browser around, FireFox
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.
Sean Henley [C++ Tutor]Rensselaer Polytechnic Institute
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 point
out 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 frame

ETime = (STime/ETime)-(GetPTime() - time);


Sleep(ETime*1000);

}
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
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.
Sean Henley [C++ Tutor]Rensselaer Polytechnic Institute
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.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
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.htm

that 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 time
back to the os. baiscly there is no much diffrence between the two methods , at least
my way insures that time goes unwasted ,no?.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
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.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."

This topic is closed to new replies.

Advertisement