PETZOLD BOOK BLOG

Charles Petzold on writing books, reading books, and exercising the internal UTM


Recent Entries
< PreviousBrowse the ArchivesNext >
Subscribe to the RSS Feed

Introducing DirectX Factor

January 3, 2013
New York, NY

I am thrilled to announce that beginning in the January 2013 issue of MSDN Magazine, I will be writing a new column called DirectX Factor focusing on using DirectX in Windows 8 (and Windows Phone 8) applications. You can read the first installment on line, as well as Michael Desmond's Editor's Note about the new column.

Like many developers, I've been very intrigued by the strategy Microsoft has taken with Windows 8. For writing Windows Store applications, three general approaches are available, all of which combine a markup langauge and a programming language:

Regardless of the implications of Alan Turing's famous 1936 paper on computability — that all programming languages satisfying a minimum set of capabilities are equivalent — many of us have given up pursuing the grail of a single programming language and a single platform suitable for all applications. In real life, there is no such thing. Turing's analysis says nothing about important issues such as syntactic and semantic flexibility and concision, programmer productivity, ease of debugging, program assurance, and performance. Every programming language has different strengths, and the choice of a programming language and programming interface must be based on a balanced analysis of all these needs.

If your needs don't require intense number crunching or high-performance graphics or audio, you'll probably gravitate towards the conveniences of a managed language like C# or Visual Basic, or the familiarity of JavaScript, in writing your Windows 8 programs.

But for those needs where every nanosecond counts, you have the option of using a language that compiles into native machine code, and which gives you access to the powerful audio and graphics facilities of DirectX. The challenges of using C++ with DirectX in Windows 8 (and Windows Phone 8) applications is the focus of this new DirectX Factor column.

Yes, I know about SharpDX and SlimDX that provide access to DirectX through managed languages. And I have experience with XNA, first on the Zune HD and then on Windows Phone 7. But think about it: If you're using DirectX for performance, isn't it a little bizarre to begin the job by wrapping all the APIs in another layer of code just so you can access them from a managed language?

If you want to write the bulk of your program in C# or Visual Basic or JavaScript, it makes much more sense to write the high-performance code directly in C++ and consolidate it in a Windows Runtime Component that can then be accessed from these other languages.

This new DirectX Factor column in no way implies that I've "given up" on C# and XAML. If I encounter a Windows 8 programming job that requires rather simple graphics — or none at all — I'm still much more inclined to favor a C# and XAML solution. I can code faster, debug faster, and get the program running faster, and I don't have to worry about free, delete, and Release.

But the year 2013 marks a 10-year anniversary* for me of doing C# and XAML programming, and there are times when both programmers and writers need a fresh challenge. DirectX is nothing if not challenging, and I'm getting real kicks from working with it.

I'm very excited about DirectX Factor. I hope to do many cool things with Windows 8 and DirectX in the months ahead, and I hope you'll come along for the ride.


* A 10-year anniversary working with XAML is indeed coming up for me: In April 2003 I signed a contract for a book entitled Programming the Windows Client Platform that eventually became my first WPF book, Applications = Code + Markup, and in the late summer of 2013 [Correction: 2003] I wrote the article "Create Real Apps Using New Code and Markup Model" that described the platform then known as Avalon.


Comments:

"and in the late summer of 2013 I wrote the article "Create Real Apps Using New Code and Markup Model" that described the platform then known as Avalon."

In 2024, Charles successfully invents time travel.

Looking forward to the series though. I really need to brush up on my DirectX - every time I've played around with it, I've ended up being diverted into something else, so I'll put aside the time to follow this.

— Pete O'Hanlon, Thu, 3 Jan 2013 11:39:48 -0500

Yet what about WebGL? :P

zproxy, Thu, 3 Jan 2013 13:13:37 -0500

The DirectX Factor column is about DirectX programming in Windows 8 and Windows Phone 8. Hence, the column will not cover WebGL. If I were writing a column about WebGL, I wouldn't be discussing DirectX. Does that not make sense? — Charles

finally my favorite author is going to teach about my favorite and toughest topic DIRECT X... Can that be used to create normal games directly using direct x with cpp that is WITHOUT windows 8 RT app store games...

Vignesh, Thu, 3 Jan 2013 17:29:13 -0500

I'm sure the concepts can be applied to non-Windows Store apps. — Charles

Could you kindly help us the fallen c# victim by updating our beloved free ebook:

.NET Book One

What the C# Programmer Needs to

Know About C++/CX and the DirectX

— c#boy, Fri, 4 Jan 2013 05:11:04 -0500

Thank you for the great news!!!

If I'm not mistaken, we can always read the magazine online for free. otherwise, I will have to purchase it.

Thanks,

Francisco, Fri, 4 Jan 2013 10:45:52 -0500

Looking forward to the column! Just reading about XAudio has filled another gap in my (lack of) DX knowledge.

— John Schroedl, Fri, 4 Jan 2013 13:44:39 -0500

By using smart pointers in C++ the advantage that C# has in automatic memory management fades. Objects referred to by an auto_ptr template class are destroyed when the object falls out of scope. (In C++11, auto_ptr was deprecated in favor of unique_ptr.)

There's a lot of C# in the Microsoft stack: web code in ASP.NET; Windows Azure PaaS books use C# examples; even the Kinect programming books have examples in C# (though some use pointers and 'unsafe' code to improve performance). You have to wonder with the world moving to low-power ARM-based processors what the future holds for managed code. The Dalvik VM on Google Android faces the same issues.

— PaulS, Sat, 5 Jan 2013 04:23:02 -0500

There is one more case where you have to use DirectX:

If you have more than - let's say - 5000 graphics items (e.g. lines, rectangles), XAML will be too slow. But this has nothing to to with C# being a managed language. If you use C++ and XAML it is the same: XAML is too slow for 5000 items. So you have to use DirectX right now.

I wish there was some way to draw like in the old days (drawLine(), drawRectangle() etc.)

— John, Tue, 8 Jan 2013 08:59:09 -0500

Yes. Several times when coding for Windows Phone 7, I ran into a graphical brick wall using XAML, and responded by moving the code to XNA. But with Windows 8 (and Windows Phone 8), it's nice to have the option of dropping to a lower level entirely with DirectX. — Charles

Yes, of course, it is good that we can use DirectX and thus we are able to do anything we want. But the catch is that it is a little bit complicated.

So we have XAML: easy but (in some cases) slow

DirectX: complicated but fast

What I wish from Microsoft is a third, additional way in between: easy but faster than XAML (and of course slower than DirectX)

Some XAML element where one can override an OnDraw method and then use methods like drawLine(), drawRectangle(). These operations would be forwarded to DirectX internally.

I think there are many cases where XAML is too slow but 1/2 or 1/3 of DirectX speed would be sufficient.

Hoping is free of charge.

(In version 4 of Silverlight, Microsoft finally implemented the wishes of the developers. So let's hope for Windows 11)

:-)

— John, Wed, 9 Jan 2013 03:44:22 -0500

The speed of DirectX mostly comes from the GPU doing the work and not from the code running in the CPU.

Building performant graphic apps nowadays is an exercise in restructuring your code so images, meshes and even animations are uploaded to a GPU and rewritten so that compositing, effects and even the animation are performed by shader code on the GPU.

There is no question that C++ has performance benefits but graphic intensive apps and in particular games benefit from the redesign of the software stack to offload much of the work to the GPU.

So this statement that the binding is the problem is just plain incorrect.

Miguel de Icaza, Wed, 9 Jan 2013 12:59:26 -0500

I take great objection to the statement - "If your needs don't require intense number crunching or high-performance graphics or audio, you'll probably gravitate towards the conveniences of a managed language like C#".

Over my entire career of writing HPC/GPGPU application in C#, I've noticed the following things:

  • When most people say they're writing C++ - they're really writing C with a smattering of OO. Very few developers really leverage all the C++ has to offer - and almost all of them understand how cool C# is as a language.
  • Due to the broken nature of libraries that span C++ (and the platforms it supports) - there are very few universal libraries that can be successfully leveraged in a corporate environment. This means that most developers "bake their own solutions" and this becomes brittle over time. Most C/C++ codebases I've seen are tangled messes of proprietary code and bad "interfaces" with little or no thought paid to architecture. Deployment is hard - testing tools are again homebrewed. Contrast this with the extensive support and broad availability of tools in the .NET/Mono space.
  • Language and library features not only increase productivity - they prevent bugs from ever happening. This is what .NET, Mono and C# (and F#) along with the host of language features available does for a developer
  • Metaprogramming - C# and F# (and a class of .NET languages) are so amazing when it comes to metaprogramming. Used with care, I have seen even simple reflection and dynamic method generation replace a host of manual, error-prone steps in various stages of development and build in a C++ environment.
  • C# and .NET can be used to write applications that perform just as well as native code - in much lesser time and with far fewer bugs. When using GPUs and libraries like OpenCL or DirectCompute this argument holds even more because the majority of the work is offloaded to the device and has nothing to do with the host code.

My argument here is very similar to yours about Turing. Sure - can the best C++ programmer write much better code than the best C# programmer? Possibly - but take into account all the factors above and the situation becomes different. Unfortunately, this attitude does more than just tarnish the image of C#. It actively prevents Microsoft from providing the bindings and/or tools required to even try HPC/GPGPU/Rendering with C#. The massive resurgence of XNA (as MonoGame) after Microsoft decided to kill it - the stable DirectX bindings (SlimDX) after Microsoft stopped Managed DirectX, the almost entire population apps in the Windows Store written in C# indicate the popularity of the programming language, but for reasons I cannot fathom - I see Microsoft steering developers away from trying to program for the GPU in C#.

At this time - thanks to efforts by Xamarin and Mono, C# and .NET run on almost every conceivable platform and with excellent performance. It is a shame that Microsoft, the company that invented is not behind their fantastic brainchild a 100%.

Ananth Balasubramaniam, Fri, 11 Jan 2013 13:43:53 -0500

Looking forward to it! Thanks, Charles.

— Paul O, Fri, 11 Jan 2013 14:44:53 -0500

C++11 and COM both has smart pointers which remove the need for explicit memory management in C++ (free, delete, Release). shared_ptr is reference counted smart pointer and automatically destroys containing raw pointer, when last reference to raw pointer is freed. COM also has reference counted smart pointers like CComPtr, etc. unique_ptr is scope related, owns the pointer and ensures that only one reference to raw pointer can exist at any time. When it goes out of scope containing raw pointer is destroyed.

— Nikola, Tue, 22 Jan 2013 10:58:44 -0500

With the email announcement about the end of xna and directx by Microsoft to their MVP , I wonder if Microsoft is planning a new graphics engine. Of course, me later said that they will continue to develop/support directx. What do you know?

Francisco, Mon, 25 Feb 2013 20:27:27 -0500

If you need 3D or other high-performance graphics or audio in a Windows Store application, you'll be using DirectX. What else is there to know? — Charles

I was saying if you know if Microsoft is thinking to discontinue DirectX?

Francisco, Wed, 27 Feb 2013 06:02:27 -0500

No idea. I don't even know what it might mean to "discontinue" DirectX. — Charles

No problem... thanks for the info..

Anyways... thanks for all your hard work..

here is the definition of "discontinue"

1.Cease doing or providing (something), typically something provided on a regular basis.

2.Stop making (a particular product)

Francisco, Mon, 4 Mar 2013 07:48:03 -0500

I'm interesting in doing some directx programming with windows phone 8. Where should I get started?

— bradley, Sat, 13 Apr 2013 00:19:57 -0400


Recent Entries
< PreviousBrowse the ArchivesNext >
Subscribe to the RSS Feed

(c) Copyright Charles Petzold
www.charlespetzold.com