Advice for a game using DirectX

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

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 on other sites
I'd update before rendering. I'm not completely sure about this but if you update after you render it may feel like your game is constantly one frame behind.

Share on other sites
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 on other sites
Thank you for the advice, I will modify my game to draw then update instead of updating then rendering.

Share on other sites
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 on other sites
Quote:
 Original post by Anonymous Posterjust 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 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 on other sites
Quote:
 Original post by BoderI'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 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 on other sites
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)

1. 1
2. 2
3. 3
Rutin
21
4. 4
5. 5
gaxio
10

• 14
• 30
• 13
• 11
• 11
• Forum Statistics

• Total Topics
631778
• Total Posts
3002310
×