I think its still important to do basic DirectX dev on the form despite WinFX being on the horizon. For truly dynamic UI, WinFX should be able to handle custom components that render DirectX scenes into a viewport on the form and provide design time support to allow scripting these controls in XAML. How Low level functionality will be handled, for example, extending behaviorwhen inheriting a Button control, remains to be seen (well for me at least since I haven't installed it yet!).

Your source builds and runs perfect, even in 2005. I tried it on my low end test machine (1Ghz Athlon, TnT2) and got good perf (+60fps when rendering) and mem usage (~23Mb - steady).

Certain peculiarities of using DirectX on the form: For one rendering your scene during OnPaint,
there's no viable way around that. And for the most part performance is good enough to justify it.

But the next stage, animating user interaction will require a render loop. I've sort of been sticking to the model provided by the Sample Framework which comes with the SDK.

Anyway, I took the liberty of starting to translate your library into an Empty Framework Project..and it looks good.

For starters the carousel control can simply be added to framework window's control collection and responds to UI events as expected. Next I would extend the framework dialog control as a carousel object so it's own rendering event can be controled from the framework window, instead of waiting for the entire control to repaint.

What's nice is each control gets a chance to handle the message pump. This will come in handy when capturing
UI events. Also the ModelViewerCamera provides a nice ArcBall virtual cintematography instance for rotating around models.

Lastly, blur effects like those suggested in the MSR article are handled in HLSL. It's also easier to set
matrix transforms and alpha values and such so let me know what you think of this tact of using shader
processing to offload most of the animation logic...

ok,
aq

Screenshot:
<img src=http://www.okaq.com/cf/FrameworkCarousel_ss1.jpg />

Source:
http://www.okaq.com/cf/CarouselFramework.zip

bshankle wrote:

bshankle wrote: I emailed Tim about a CLR build of Unreal. I'll let you know what he says.

Regarding a port of Unreal to use the CLR, Tim says, basically, No:

Hi Bruce,

 

We talk to Microsoft about this from time to time, but decided against it.  There are too many unanswered questions about where the CLR is going in the future.  Is it going to be an open standard as a multi-platform runtime, is Microsoft going to use patents or threats of patents to shut down porting efforts, etc.  We really don't want the engine to be associated with it, even informally with an effort like this, until things are clearer.

 

-Tim

So there you have it folks, guess we won't be seeing Unreal on the CLR for the foreseeable future.

-Bruce

I recall in a MS Chat Session on C# not long ago that someone said to the effect that the compiler y'all are using internally is not what the outsiders, such as myself, have access to. If I am using the latest stable release,  v7.10.3052.4, I lack certain capabilities or enhancements that may be available to developers using something approaching v8 or later.

Is there any chance, a csc nightly build snapshot, could be in the offing. Or does this completely violate the release methodology? Would a later compiler still target the Framework v.1.1.4322, or does the entire shmlemiel have to be upgraded?

thanks,
aq