[.net] .NET form rendering

If you want a maximum framerate (so that animations don't appear super-fast), set a maximum (60 or so) number of frames per second. Impose this by checking how many microseconds have elapsed since the last rendering, and if it's too few then don't rerender yet. You should know how many ticks per second there are if you're using TimeSpans / DateTimes, in which a tick is a tenth of a microsecond.

Typically if you want to render as fast as possible, you'll use a custom game loop instead of a timer. (Plus the lowest resolution of Windows timers aren't terribly low IIRC.) See this article for a sample game loop.

Basically in a normal winform app, your Main method creates a main form and calls Application.Run(yourform). That Run method contains a loop that processes messages (such as mouse movement on the form, window repaint requests, and certain types of timers). If there are no messages, the program sits and waits for new ones. The first solution in the above article reimplements this loop and renders without pausing. The final solution they arrive at hacks in rendering to the loop.

Not sure if that second part helps. Too lazy to delete.

I add a .Net timer onto my form from the toolbox. Is its tick frequency 1000 ticks per second? That way I can render a maximum of 1000 times per second (over kill). I know how to implement a game loop in Win32 not .Net you see.

If you want a serious gameloop using Managed DirectX and C#, you should use the technique described at Tom Miller's blog. It's insanely faster than the typical Application.DoEvents() solution. When I implemented this into my spritebased game, the framrate went from 100 to 200 fps.

However, I had some problems with compiling the code given at the blog, but by replacing

public struct Message{    public IntPtr hWnd;    public WindowMessage msg;    ...}

with

public struct Message{    public IntPtr hWnd;    public IntPtr msg;    ...}

I got rid of the compiling error and now it works great. He probably made a typo or something...

I've seen that loop before and maybe someone can explain why its better than the loop in the sample frameworks. If it is. The loop in the sample frameworks is set up pretty much exactly like one in a regular Win API app - it hooks the message proc, does Translate/Dispatch - the works.

What is the benefit of running that through the AppIdle event? As far as I can tell, its functionally the same but dispersed around a little differently.

The nice thing about the full-on message pump version is you have first-crack at all your incoming messages and can use them for stuff like text (which is a pain in DirectInput).

Quote:

Original post by Enselic If you want a serious gameloop using Managed DirectX and C#, you should use the technique described at Tom Miller's blog. It's insanely faster than the typical Application.DoEvents() solution. When I implemented this into my spritebased game, the framrate went from 100 to 200 fps. However, I had some problems with compiling the code given at the blog, but by replacing public struct Message{ public IntPtr hWnd; public WindowMessage msg; ...} with public struct Message{ public IntPtr hWnd; public IntPtr msg; ...} I got rid of the compiling error and now it works great. He probably made a typo or something...

Actually, he just copied the code from the SDK sample framework. WindowMessage is an enumeration.

Quote:

Original post by Cacks I add a .Net timer onto my form from the toolbox. Is its tick frequency 1000 ticks per second? That way I can render a maximum of 1000 times per second (over kill). I know how to implement a game loop in Win32 not .Net you see.

I suggest doing what mushu posted. If you set the interval of a timer to 1000, then the event will only fire once per second (or 1000 milliseconds). I have found that maximum number of events the timer in .net will fire is about once every 15-16 milliseconds ie approximately 60 frames per second (this is probably dependent on my system, you may see differing results). Regardless using a timer as a message/game loop in .Net is a bad idea.

Quote:

Original post by dalep I've seen that loop before and maybe someone can explain why its better than the loop in the sample frameworks.

I'm convinced that that technique is the best because of two reasons:

• My framerate increased from 100 to 200 fps when I implemented it.


• Tom miller said it was the best technique so far, and Tom Miller is highly involved in Managed DirectX development, he has for instance talked about MDX in the .NET Show on MSDN.

This is what Tom wrote on his blog about the technique:

Quote:

Simple, elegant, effective. No extra allocations, no extra collections, it just works.. The Idle event fires when there's no messages in the queue, and then the handler keeps looping continuously until a message does appear, in which case it stops.. Once all the messages are handled, the idle event is fired again, and the process starts over.

So basicly, by using this technique, you get rid of timeconsuming processes like memoryallocations.

Quote:

Original post by dalep I've seen that loop before and maybe someone can explain why its better than the loop in the sample frameworks. If it is. The loop in the sample frameworks is set up pretty much exactly like one in a regular Win API app - it hooks the message proc, does Translate/Dispatch - the works. What is the benefit of running that through the AppIdle event? As far as I can tell, its functionally the same but dispersed around a little differently. The nice thing about the full-on message pump version is you have first-crack at all your incoming messages and can use them for stuff like text (which is a pain in DirectInput).

read the links on this page it explains it all
http://www.thezbuffer.com/articles/185.aspx

http://www.thezbuffer.com/articles/185.aspx

You have a misconception. You don't want to limit the number of frames per second. You want to limit the game updates per second. Set a maximum of around 60--- not 1000, or players with faster computers will be going 5 or more times faster. When repaint calls your method make sure it's been 1/60th of a second since the last update before you update the world, but ALWAYS render.

Thanks for the link Enselic and daviangel. Interesting stuff. But I could find nothing that addressed my specfic question at all - nothing compares that loop to the Sample Frameworks loop. There were references to "maintaining compatibility with managed input" maybe that's all there is to it.