The ideal System.Windows.Forms 3D Gameloop, Take 15.

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Don Alvarez — Thu, 31 Mar 2005 04:47:00 GMT

> I now have my “ideal” solution for the game that will appear in my upcoming book

Any chance you have an ISBN or some other way through which to pre-order the book? (I tried searching for hoskinson directx on amazon.com, but that didn't work...)

thanks,
-Don

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Rick Hoskinson — Thu, 31 Mar 2005 05:07:00 GMT

Heh, we’re still pretty far out on the book (we’re due to print sometime after Visual Studio 2005 ships). I’m hoping my publisher rectifies the author names and Title soon. In the interim, the ISBN is:

ISBN 0-672-32695-7

Sadly, that will still bring up a book by Tom Miller. I beleive I have a post from January that has the correct name and authors of the book listed. SAMS hasn't listed the new information yet, so I'll definately be asking them about it next time I talk to them.

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

ShadowChaser — Thu, 31 Mar 2005 06:05:00 GMT

Sending a message (WM_PAINT) per frame still seems like a bit of a hack to me - it's like driving in a circle for a mile when you need to go next door.

It's basically hacking the messaging system into an infinate loop so that a virtual hook can be placed into it.

That said, there's not much we can do. I've given up and manually create my windows and message loop from scratch. If only they had a way to attach a delegate into the main application loop. I imagine that although it would be slower than actually writing the code into your own app loop, it's probably going to be faster than routing kazillion messages through windows ;-)

Probably too late for Whidbey :(

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

bonk — Thu, 31 Mar 2005 09:07:00 GMT

Tom Miller told us recently at #manageddx on efnet that in the April SDK he will be having the infamous Doevents() introduced back in for the sampleframework because he recieved a lot of requests to avoid win32 completely and use windows.forms instead. He told us further that in one of the sdk updates after the april one he is going to eliminate doevents() (but still stay with windows forms).
Rick,
how does your solution relate to the one Tom Miller is planning. Are you discussing that issue with each other ?

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

bonk — Thu, 31 Mar 2005 09:19:00 GMT

Ooops, seems I did not read carefully enough. Looks like you have been discussing that with Tom Miller.
So let me rephrase my question:
Rick,
will your gameloop be the same as the one we will see in the sampleframework of the next sdk updates ?

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Rick Hoskinson — Thu, 31 Mar 2005 19:52:00 GMT

Hi Bonk, the April SDK has already been released and does in fact use a WinForms implementation and DoEvents.

Of course this technique will be reseached further before we can commit to puting it into DXMUT. You may find that we subtley change the idea to using a user event rather than a paint message, or a managed create message rather than a p-invoke. So we are working on an alternative to DoEvents() in the SDK, but the April release will be using it.

And ShadowChaser, I'm not really sure what you mean. Are you giving up on winforms altogether (which is the speediest solution, no doubt, but you lose a lot of .Net comforts)? Or are you implementing a PeekMessage-style loop?

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

ShadowChaser — Thu, 31 Mar 2005 22:44:00 GMT

I am using a combination approach.

For apps that require "Rich UIs" (like map editors) I am using Windows Forms. Then the 'core' game engine is constructed I pass in an IntPtr to the "drawing" window so that the game knows where to initialize Direct-X Graphics.

For the actual game itself I gave up on WinForms and I'm using a very low level approach - CreateWindowEx, etc. :(

Your solution is definately the best one I've seen so far, but it's still a little frustrating to need to do workarounds :-)

One change I might make when I implement your architecture into my WinForm version would be to use a custom message instead of WM_PAINT. (ie/ send a WM_USER+(whatever) and respond on both that and WM_PAINT). It's probably irrational, but WM_PAINT is so common I have this strange fear that other apps are going to hook into it and change the behavior and performance of the game in a bad way. Skinning applications might be an example.

Take a look at: http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=bd3ecd25-1bdb-4ca2-bcde-313f86876d4c

The suggestion probably will be cancelled or delayed, but it's worth a try :-)

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Mike Potter — Thu, 31 Mar 2005 23:18:00 GMT

I am certainly not an expert on the issue but:

Have you tried putting your Frame call in OnIdle()?
I found this to have very smooth animation but, I was just toying with MDX at the time. I did not analyize it with profiler. It allowed me to avoid PInvoke calls.

Just curious if this has been tried by someone else.

High Performance Game Loops in Managed DirectX

dwellerville — Thu, 31 Mar 2005 23:26:00 GMT

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Rick Hoskinson — Fri, 01 Apr 2005 01:40:00 GMT

Heya ShadowChaser, you actually hit the nail on the head with the user event, and doing it that way was my first instinct. I agree, I'm not sure how people are going to try to use my game code, and I want it to be as flexible as possible.

One of the ideas I'm playing with is pausing both my world update when the game window loses focus. Now the SDK samples handle this situation by throttling back thier update loop by inserting a mid-stream sleep. That keeps the app from starving other foreground applications. I wanted to take this a step further by pausing the world update and the render update completely, with the option to call just the rendering code if any part of the window is invalidated. That should drop the CPU usage in the background to a true 0% while giving me a more elegant looking WndProc. So to pseudocode:

case WM_PAINT:
if(Foreground) WorldUpdate();
RenderWorld();
if(Foreground) SendNotify(this.Handle, WM_PAINT);

Since the code is part of the teaching tool, this should be a realy straightforward way of acheiving the intended effect without abstracting away the Forms usage with my own code.

And Mike, I was wondering where you're catching the OnIdle event -- are you using the Application.Idle event or something else?

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Manuel — Fri, 01 Apr 2005 06:41:00 GMT

Why this cannot be put in a Windows.Forms 2.0 method by the Winforms team? I don't believe this is a dx only issue.

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Mike Potter — Fri, 01 Apr 2005 16:43:00 GMT

I just reviewed my old code. I was using the Application.Idle and calling Invalidate() to keep it circulating. It was much smoother then DoEvents() when I first started learning.

I switched the code to use the loop you specified above. Your method added about 50 to 100 FPS to the app in a windowed mode. This is most likely the overhead for Invalidate that you mention. The test app averages about 3400 fps on my box.

I also have the following in my OnIdle():

if (!this.Focused)
{
Thread.Sleep(10);
}

When I don't have focus, It drops my app down to about 100 FPS but, the other apps seem to run at normal speed.

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Mashiharu — Fri, 01 Apr 2005 18:36:00 GMT

I'm just wondering: Won't calling SendNotifyMessage from WndProc create recursiveness?

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Donavon Keithley — Fri, 01 Apr 2005 19:16:00 GMT

Looks like it's the Control.NotifyInvalidate method that's creating InvalidateEventArgs when it calls OnInvalidated. It's virtual, so I'm wondering if nulling it out could solve the problem.

Spelunking a little further, OnInvalidated calls OnParentInvalidated on the children and then fires the Invalidated event. So you'd lose those two things.

The nice thing about invalidating the window after rendering is that it keeps the message queue clean (since WM_PAINT isn't sent until all messages have been processed).

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Rick Hoskinson — Fri, 01 Apr 2005 23:00:00 GMT

"I'm just wondering: Won't calling SendNotifyMessage from WndProc create recursiveness?"

SendMessage will, SendNotifyMessage does not block.

Mike, I'm glad to hear the technique had positive results in your loop. I agree though that things will be trickier when you have children Control objects taht also need paint notification. Though I think that by using SendNotifyMessage you won't starve out other messages since it will be in-ordered with everything else that happened in the previous frame. I suppose Invalidate() gives a bit more deterministic state at the start of your next WM_PAINT handler.

Ideal Managed Code Game Loop

TrayGames Blog — Fri, 01 Apr 2005 22:44:00 GMT

If you are working in managed code on games you should check out this blog entry from Rick Hoskinson:...

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Zman — Sat, 02 Apr 2005 07:05:00 GMT

I posted a summary of *all* the Render loop posts over the past couple of years <a target="_new" href="http://www.thezbuffer.com/articles/185.aspx">http://www.thezbuffer.com/articles/185.aspx</a>

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Bernhard — Sat, 02 Apr 2005 08:39:00 GMT

Hello I have put your renderloop in my app too and the rendering works find. Unfortunately i have problems with the mouse events now! The game runs with appr 300 fps on my machine and some mouse events are lost (eg. if i do a short click). On another machine i only have appr. 100 fps (because if an old graphics card). Here the problem is much bigger, sometimes i do not get mouse events for up to one second! Does anyone see this problem too?

re: The ideal System.Windows.Forms 3D Gameloop, Take 15.

Bernhard — Sat, 02 Apr 2005 12:20:00 GMT

hello some hours ago i wrote you that i have problems with the mouse events. the information was not correct, the mouse events are fired perfectly - the problem is my mouse handling functions that are working completly different now. i have to find the problem here. sorry for that!

MDX: XBOX 360 Controller Windows Forms Application

Paul Stubbs — Mon, 13 Feb 2006 19:45:24 GMT

Now that the XBOX 360 controller works on windows I thought it would be fun to hook it up to a windows forms application using Visual C# Express and Managed DirectX (MDX).

Software Information » Rick Hoskinson’s Blog : The ideal System.Windows.Forms 3D Gameloop Take 15.

Fri, 25 Jan 2008 02:50:33 GMT

PingBack from http://softwareinformation.247blogging.info/rick-hoskinsons-blog-the-ideal-systemwindowsforms-3d-gameloop-take-15/