Jump to content
  • Advertisement
Sign in to follow this  
Xadeu2005

OpenGL Managed DirectX: Best way to make animations smooth?

This topic is 4845 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

Hello all, I would like an explanation of what the best way is to make my game run smoothly using Managed DirectX. Before when I was writing the game using OpenGL I would use a loop that would "waste" cycles so that the game would run slow enough and "smoothly" on my computer. This worked but not efficiently. I guess my question is what is the best way to control the speed of my game and why? I noticed a link to Tom Miller's Blog about render loops is this what I am looking for? I am not sure about alot of terminology and an explanation of some terms or some good resources would be helpful so I could do some R&D on my own. [Edited by - Xadeu2005 on August 9, 2005 11:10:33 PM]

Share this post


Link to post
Share on other sites
Advertisement
Hi there Xadeu2005,
Fantastic question.
I would say it all depends on how your game is structured.

[The problem]
What is the "best" way to not waste CPU cycles and get a high framerate?

[The Solution]
I would say that you should make full use of your cpu cycles that are available and also keep your state changes to a minimum.
What does this mean you ask?

Follow the Performance Optimizations that the DirectX docs gives you.
Other than that.
The general structure that I follow is the following

[source lang = c#]
//create your form
class Window : Form
{
public Window()
{
//do your initialization
}
public void BeginRender()
{
//Clear the target surface
//BeginScene
}
public void FinishRender()
{
//EndScene
//Present the BackBuffer
}
public void DisposeDevice()
{
//dispose of your device.
}
}

//new class
class Core
{
private Window window;
public Core()
{
//do initialization of your objects
window = new Window();
}
public void Update()
{
//update object positions etc...
}
public void Render()
{
window.BeginRender();
window.FinishRender();
}
public void Run()
{
window.Show();
while(window.Created)
{
Update();
Render();
Application.DoEvents();
}
window.DisposeDevice();
}
}


//new class
//your game to keep implementation apart from your core engine
public class Game
{
public static void Main()
{
Core core = new Core();
core.Run();
}
}



Just follow general rules and then you can output the time it takes to render a scene in your debug window or a text file or something...

I really hoped this helped a bit.
keep cool.

Share this post


Link to post
Share on other sites
Thought I'd add my own 2 n00bie cents:

You could try to start off with the sample framework included with the SDK. It already defines a render loop (and AFAIK it is also update with the outcome of said discussion) and offers tons of other facilities, like a GUI system, camera's, HLSL effects etc.

This sample framework also includes the option of using a fixed framerate (at 60 fps) to make sure you don't have to compete for cycles with the graphics when doing other stuff. At least you could take a look at the source to get a good idea of how the MDX team takes on the render loop question.

Share this post


Link to post
Share on other sites
If I understand you correctly, you are asking how to slow down the movement and animations so it will run the same at all times on different PCs? The easiest way to do so is to just cap the framerate, but this will still create problems if the FPs drops below the cap. A better solution is to use time based modeling. Basically, you have to find how much time passed since the last frame, and update based on that. If the time is longer, then the objects/animation progresses more.

Share this post


Link to post
Share on other sites
Or just use the sample framework ;)

I got a semi-offtopic question related to this discussion. I was just reading Tom Miller's blog (linked to in the 1st post), where he posted his final answer to the managed render loop question:

[source lang=c#]
public void MainLoop()
{
// Hook the application's idle event
System.Windows.Forms.Application.Idle += new EventHandler(OnApplicationIdle);
System.Windows.Forms.Application.Run(myForm);
}

private void OnApplicationIdle(object sender, EventArgs e)
{
while (AppStillIdle)
{
// Render a frame during idle time (no messages are waiting)
UpdateEnvironment();
Render3DEnvironment();
}
}

private bool AppStillIdle
{
get
{
NativeMethods.Message msg;
return !NativeMethods.PeekMessage(out msg, IntPtr.Zero, 0, 0, 0);
}
}


And the declarations for those two native methods members:

[StructLayout(LayoutKind.Sequential)]
public struct Message
{
public IntPtr hWnd;
public WindowMessage msg;
public IntPtr wParam;
public IntPtr lParam;
public uint time;
public System.Drawing.Point p;
}

[System.Security.SuppressUnmanagedCodeSecurity] // We won't use this maliciously
[DllImport("User32.dll", CharSet=CharSet.Auto)]
public static extern bool PeekMessage(out Message msg, IntPtr hWnd, uint messageFilterMin, uint messageFilterMax, uint flags);



Looks all nice and clean, but essentially it will only update and render when there are no messages waiting on the window's queue, right? Won't this approach lock up, or at least 'miss' an unacceptable number of frames, when there is a lot of user input to process, for example when mouse movement tracking is activated?

Share this post


Link to post
Share on other sites
Quote:
Original post by remigius
Looks all nice and clean, but essentially it will only update and render when there are no messages waiting on the window's queue, right? Won't this approach lock up, or at least 'miss' an unacceptable number of frames, when there is a lot of user input to process, for example when mouse movement tracking is activated?


This is essentially what the recommended C++ loop does too, so I think it's pretty safe.

Share this post


Link to post
Share on other sites
remigius,

could you point to the specific framework sample you were talking about?

Before what I would do is something like

//should restrict MAX FPS to 60 only update every 17 ms
//rotate 10 degrees 9 times to achieve a full 90 degree
//rotation in half a second.

while(graphicsTimer->TimeElapsedSinceStart() <= 16.666667) {}


this way i could control the speed of movement in the game.

Is this what you are talking about...I think that example framework would
help.

Thanks,
Xadeu2005

Share this post


Link to post
Share on other sites
Quote:
Original post by Xadeu2005
remigius,

could you point to the specific framework sample you were talking about?

Before what I would do is something like

//should restrict MAX FPS to 60 only update every 17 ms
//rotate 10 degrees 9 times to achieve a full 90 degree
//rotation in half a second.

while(graphicsTimer->TimeElapsedSinceStart() <= 16.666667) {}


this way i could control the speed of movement in the game.

Is this what you are talking about...I think that example framework would
help.

Thanks,
Xadeu2005


The problem with this is that if the game runs slower than 60 FPS, the game will still slow down. This may not be a problem on a great system with a 2D game, but I haven't played a 3D game in a while that didn't dip below 60 FPS on decent settings on my hardware (which definately isn't low end).

Share this post


Link to post
Share on other sites
SR_Guapo,
well with that being said...

I still don't know how to implement Tom Miller's code on render loops
(would his code benefit me at all?)

would I still need a timer if I chose Tom Miller's code on Render Loops?

Or should I use your suggestion on Time Based Modeling?
If so, could you elaborate more on this topic?

Thanks,
Xadeu2005

Share this post


Link to post
Share on other sites
By the way, I think most 3rd party physics engines have their own timers. I use it to control my framerate.

Every second I look at how high my framerate is. I then use a formula to determine how accurate the "timestep" for the physics is.

basically, the slower the framerate, the sloppier the physics are... but the speed is constant.

Just something to think about.

V.

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!