Jump to content
  • Advertisement
Sign in to follow this  
adam23

Advice for a game using DirectX

This topic is 4550 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am making a 2D rpg adventure using DirectX for a college project. The main question I have is this: When I am rendering graphics, I am calling classes that update specific sprites. Here is what I am talking about. //start rendering if (d3ddev->BeginScene()) { //erase the entire background d3ddev->StretchRect(back, NULL, backbuffer, NULL, D3DTEXF_NONE); //start sprite handler sprite_handler->Begin(D3DXSPRITE_ALPHABLEND); cLevel->Draw(cLevel->getLevel()); knight->Walk(currDirection); //stop drawing sprite_handler->End(); //stop rendering d3ddev->EndScene(); } Now take cLevel->Draw, I am calling a function that updates all of the level's objects for example, I have a lion walking so is this the most efficient way to do this, or should I have everything updated before I start rendering graphics?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
the main advantage of drawing first and updating afterwards is that you would be updating while the gpu is working. if you are only using simple graphics this approach probably isn't going to give you anything however.

simple not so nice graph :)


update first, draw later.
Updating render calls IDLE
CPU |========|============|=======|
IDLE Drawing
GPU |========|====================|

draw first, update later
render calls Updating
CPU |============|========|
Drawing
GPU |=====================|


its not exact though, there will be some idle time in the second case aswell. since the rendering won't ever be done exactly at the same time as the update.

however, as you can see, the first method would lower your framerate dramatically if you increase either cpu or gpu load, in the second case you can increase load on the one that isn't a bottleneck without affecting the performance too much.

Share this post


Link to post
Share on other sites
Thank you for the advice, I will modify my game to draw then update instead of updating then rendering.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
just remember that you should NOT swap the bufferes until after you've updated.
i assume d3ddev->EndScene() swaps the buffers for you. (im mainly using opengl myself so im not 100% sure about the d3d stuff).

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
just remember that you should NOT swap the bufferes until after you've updated.
i assume d3ddev->EndScene() swaps the buffers for you. (im mainly using opengl myself so im not 100% sure about the d3d stuff).


The buffers should not be switched until he calls present.

Share this post


Link to post
Share on other sites
I've wondered about this. I suppose you might only notice that you are one frame behind if your FPS got low (say 20-30), but if you stay at 60+ frames/sec I imagine you wouldn't even notice.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Boder
I've wondered about this. I suppose you might only notice that you are one frame behind if your FPS got low (say 20-30), but if you stay at 60+ frames/sec I imagine you wouldn't even notice.


well you will always be behind, the question isn't how many frames behind you are, its how long time. if you update first and then draw you would always be updatetime+drawcommandtime+rendertime behind (nothing gets displayed until everything is drawn). and since every object in the game has to use the same deltatime for their updates that time has to be taken at the start of the update. if you draw first and then update you would get.

drawcom - drawing - display - drawcom - drawing etc etc
- updating - - updating
- get dt here




this would only put you at drawcommandtime+max(rendertime, updatetime) behind.

Share this post


Link to post
Share on other sites
Nice reply AP. I've thought about it a lot and I think you are overlooking one thing.

The user would only notice how responsive user input seems to be in comparison to the picture he sees on the screen. Let us assume that vsync is off and input is obtained at the beginning of the update phase.

+ Input, Update 1 +
+ Draw Commands, Rendering +
+ Visual = Update 1 +

The time between input and display in this classic model is
time(Update + Rendering)
The new model gives us

+ Draw Commands for Update 1 +
+ Rendering + Input, Update 2 +
+ Visual = Update 1 +
+ Draw Commands for Update 2 +
+ Rendering + Input, Update 3 +
+ Visual = Update 2 +

The time is now
time(max(Rendering, Update) + max(Rendering, DrawCommands + Update))


Note: I've left out the time for the screen refresh and only included DrawCommands for the second method

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
mm thats true boder, you loose some responsiveness, but get improved performance, The loss of responsiveness isn't noticeable at high framerates (25+) and the improved performance can make the difference between 15fps and 25-30fps.

if you have a heavy renderphase and simple updatephase however you would only loose responsiveness (bad), and ofcourse if you have a simple renderphase and a heavy updatephase aswell.

if both are roughly equally heavy doing them at the same time on different hardware (GPU/CPU) can almost double your performance and the slight loss of responsiveness is negligable.

a good advice is to profile it and see how much time the cpu wastes while waiting for the gpu to render and then find something to do during that time. (it doesn't have to be updating, AI can be a better candidate to fill that time with)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!