Managed Direct3D via IronPython Tutorial Part 2 - Interactive control of a Managed Direct3D Device

In this tutorial, we show you how to create a WinForms Form via the IronPython console, embed a Direct3D device within the form and control the Direct3D device interactively. This is an extremely cool thing that is currently only possible to do with IronPython and vividly illustrates why dynamic languages and .NET's CLR are a match made in heaven.

First, fire up the IronPython console ipy, set up the necessary modules, then import the winforms module found in the IronPython tutorials\ directory. Module winforms is very short and well worth studying how it does its magic. What it does is to enable forms to execute in a separate thread, making it possible to interact with them via the console. Without it, a form will appear, but it will block forever waiting for the ironpython console to return execution to it.

References and imports needed for these tutorials

> ipy
>>> import clr
>>> clr.AddReference("System")
>>> clr.AddReference("System.Drawing");
>>> clr.AddReference("System.Windows.Forms")
>>> clr.AddReferenceByName(
      "Microsoft.DirectX, Version=1.0.2902.0,
       Culture=neutral, PublicKeyToken=31bf3856ad364e35" )
>>> clr.AddReferenceByName(
      "Microsoft.DirectX.Direct3D, Version=1.0.2902.0,
       Culture=neutral, PublicKeyToken=31bf3856ad364e35" )
>>> from System.Windows.Forms import *
>>> from System.Drawing import *
>>> from Microsoft.DirectX import *
>>> from Microsoft.DirectX.Direct3D import *
>>> import winforms

You are now all set to begin your learning adventure. Creating an empty Winforms form in IronPython is ridiculously easy compared to C# or C in Win32:

Two lines is all you really need to show a WinForms Form in IronPython

>>> f=Form()
>>> f.Show()

Yes, woohoooooo! This is all the goodness of Python brought over to the CLR. I'd like to take a moment to thank Jim Hugunin and the rest of the IronPython crew for their wonderful gift. Now,

Create the Managed Direct3D device and bind it to the form

>>> pp=PresentParameters()
>>> pp.Windowed=True
>>> pp.SwapEffect=SwapEffect.Discard
>>> d=Device(0, DeviceType.Hardware, f.Handle, CreateFlags.SoftwareVertexProcessing, pp)

A complete discussion of the calls you see here is beyond the scope of this tutorial and you should refer to the Managed DirectX 1.1 SDK documentation for the full (and gory) details. But to summarize, what you did was to set some parameters in a PresentParameters object and send that, along with some additional flags, to the Device() constructor. You also used the form's handle, f.Handle, as the 3rd parameter in the Device() constructor to bind the device to our form f. Now that you have a device, you can manipulate it and its surface as shown below, and whenever you call d.Present(), it will update the device to reflect the changes you made.

Clearing the device viewport and drawing rectangles on its surface

>>> d.Present()  # update to what the device surface contains at the moment, might be garbage

>>> d.Clear(ClearFlags.Target, Color.Green, 1.0, 0 )
>>> d.Present()  # clear the device viewport to green

>>> surf=d.GetRenderTarget(0)  # get a reference to the 'Render Target' surface

>>> d.ColorFill(surf,Rectangle(10,10,40,40),Color.Blue)
>>> d.Present()
>>> d.ColorFill(surf,Rectangle(100,100,80,10),Color.Lavender)
>>> d.Present()

As you can see, the API is rather schizophrenic and there are many subtleties involved here. You can clear the device viewport by calling it directly without referring to a surface. But to do some drawing, you need to get a specific surface, the 0th render target surface (depending on the hardware, there may be multiple) and then tell the device to draw on that particular one. Why wasn't the API designed so that we can just ask the surface to draw itself and avoid the complexity of having to refer to the device, since the surface ought to know which Device it belongs to? I am hypothesizing that this is because the Device object would be responsible for any hardware assisted rasterization (sounds logical enough), thus any and all rectangle drawing code was put into this object instead of Surface.

Part 1 - Importing and Referencing the MDX 1.1 Assemblies

Part 3 - Rendering alpha-blended sprites

Discussion:

Back to Top

© 2008 by Andy Sy
last updated: 2007-Sep-9