Develop Reference

Writing cross-platform application with a complex GUI

I’d like to develop an application with a complex GUI (combobox with animation, charts with spline, transparent layers, …). I have good experience with C# 2.0 and I’m studying WPF, but I read that, unfortunately, there is no plan to port WPF to Mono.
If I stick with C# and create custom GUI controls using OpenGL (via OpenTK), I feel it will be a hard work (integration with GTK#, debugging, hard to use to design forms).
I can use Java (with JOGL), but I’m not very skilled with it, and I don’t know about performance issues.
Last option is C++, but I have to do a big revision (years since last time I used it), and I find it hard to develop GUI and portable applications in C++. (Maybe I’m wrong! Still, I’m quite afraid to develop such complex application with this language.)
What is your advice? Had I better choose C# + OpenTK, Java + JOGL, or return to C++?

I would go with Qt. Take a look at http://qt.nokia.com/products/ . If you are afraid of C++ (but there is no reason to be afraid of it), you can try with Java Swing. I think that those are the best options to go with multi platform desktop GUI development.

I would suggest Mono and GTK#. Developing apps with .Net is far more effective than doing it in C++ vanilla. Sure, you have to stick with C# 3.0 and .Net 2.0 (some features from 3.5 is implemented, like LINQ). But it still gives you a lot more than C++ with, for instance QT, would give you.

Go C# for productivity. Nothing against C++ but it's a bit verbose.
As for the GUI library, I think WinForms used to work on Mono. Alternatively, GTK#.

I would not suggest using wpf for it is a platform dependant platform. Silverlight might be a better option.
But if you are developing a web application, jquery would be a nice option you also might consider adobe flex and adobe air; http://www.adobe.com/products/air/

Does multi-platform have to include iDevices? Can it be on the web? Those are 2 questions you have to answer first.
If you can live without iPad/iPhone suppport, then Flex/Flash/Air is good option for highly graphical things. It is multi-platform for sure and easily integrates to the web. Probably your best option for this case with the limited details given.
Qt could work for you as well, although I can't say for sure if it's graphic library will make it easy. I've personally never worked with it, so other would have to answer that. But since it is in C++, you could use other libraries as well.
Java Swing sounds rough to me for this complex of a GUI. Making some basic stuff isn't too bad, but if you are expecting an experience like with C# I think you will be frustrated. Just a personal opinion of course.
Lastly, if it can be a web app, why not stick with C# and Silverlight? A .NET solution may work well for you since you are already learning it.

Silverlight runs on Windows/Mac/Linux and some handhelds, and is being ported to more handhelds. I believe Silverlight will ultimately be ported to every popular device.
Silverlight is:
Much, much more powerful than Flex/Flash/Air.
Much, much more powerful than Qt.
Ridiculously more powerful than GTK+ or GTK#.
Ridiculously more powerful than JOGL.
Silverlight has all of the features you have requested.
Silverlight works very well with C#, which is a much more productive language to work in than C++.
Silverlight is basically a very large subset of WPF, so if you already know WPF, you already know Silverlight.
Unless you absolutely require iPhone/iPad support I think the decision is perfectly obvious.
See this comparison of WPF and Cocoa to get some feeling of how WPF/Silverlight compares with the likes of Qt, Flash/Flex/Air, and GTK#, all of which use a primitive WinForms-like object model similar to the one used by Cocoa.

At my day job (a well-known microprocessor company) we develop complex engineering apps with Java, Eclipse RCP, and Java OpenGL. Performance is good -- we can easily get many millions of polygons/second and up to 100 frames/second. The SWT widgets in Eclipse are fast enough where we haven't had to render any custom controls with JOGL.
I've got a set of tutorials that shows how to get started with this kind of programming. The series starts with http://wadeawalker.wordpress.com/2010/10/09/tutorial-a-cross-platform-workbench-program-using-java-opengl-and-eclipse/.

First, don’t use C# for anything that should be portable. Mono is a bad option for GUI for two reasons:
Mono goes always several steps behind .NET.
Mono does not support WPF, so the only way to develop GUI is using something like GTK#.
My personal opinion – use C++. It would give you very good portability and independence.
You have two options:
Qt4 – very good GUI toolkit, makes GUI development very easy, and highly portable.
GTKmm – also very good toolkit, but it feels less natural on Windows.
Also, Java has Swing toolkit that comes with JDK and is available on all Java platforms, even very strange ones like OpenVMS.

How to decide between MonoTouch and Objective-C? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
After sitting through a session today on Mono at a local .Net event, the use of MonoTouch was 'touched' upon as an alternative for iPhone development. Being very comfortable in C# and .Net, it seems like an appealing option, despite some of the quirkiness of the Mono stack. However, since MonoTouch costs $400, I'm somewhat torn on if this is the way to go for iPhone development.
Anyone have an experience developing with MonoTouch and Objective-C, and if so is developing with MonoTouch that much simpler and quicker than learning Objective-C, and in turn worth the $400?

I've seen this question (and variations on it) a lot lately. What amazes me is how often people respond, but how few answer.
I have my preferences (I enjoy both stacks), but this is where most "answers" start to go wrong. It shouldn't be about what I want (or what anybody else wants).
Here's how I'd go about determining the value of MonoTouch - I can't be objective, obviously, but I think this is pretty zealotry-free:
Is this for fun or business? If you wanted to get into consulting in this area, you could make your $399 back very quickly.
Do you want to learn the platform inside-out, or do you "just" want to write apps for it?
Do you like .Net enough that using a different dev stack would take the fun out of it for you? Again, I like both stacks (Apple and Mono), but for me MonoTouch makes the experience that much more fun. I haven't stopped using Apple's tools, but that's mainly because I really do enjoy both stacks. I love the iPhone, and I love .Net. In that case, for me, MonoTouch was a no-brainer.
Do you feel comfortable working with C? I don't mean Objective-C, but C - it matters because Objective-C is C. It's a nice, fancy, friendly OO version, but if pointers give you the heebie-jeebies, MonoTouch is your friend. And don't listen to the naysayers who think you're a dev wuss if it happens that you don't like pointers (or C, etc.). I used to walk around with a copy of the IBM ROM BIOS Pocket Reference, and when I was writing assembly and forcing my computer into funny video modes and writing my own font rendering bits for them and (admittedly trashy) windowing systems, I didn't think the QuickBasic devs were wusses. I was a QuickBasic dev (in addition to the rest). Never give in to nerd machismo. If you don't like C, and if you don't like pointers, and if you want to stay as far away from manual memory management as possible (and, to be fair, it's not bad at all in ObjC), then... MonoTouch. And don't take any guff for it.
Would you like to target users or businesses? It doesn't matter much to me, but there are still people out there on Edge, and the fact is: you can create a far smaller download package if you use Apple's stack. I've been playing around with MonoTouch, and I have a decent little app going that, once compressed, gets down to about 2.7 MB (when submitting your app for distribution, you zip it - when apps are downloaded from the store, they're zipped - so when figuring out if your app is going to come in under the 10MB OTA limit, zip the sucker first - you WILL be pleasantly surprised with MonoTouch). But, MT happiness aside, half a meg vs. nearly three (for example) is something that might be important to you if you're targeting end users. If you're thinking of enterprise work, a few MB won't matter at all. And, just to be clear - I'm going to be submitting a MT-based app to the store soonishly, and I have no problem whatsoever with the size. Doesn't bother me at all. But if that's something that would concern you, then Apple's stack wins this one.
Doing any XML work? MonoTouch. Period.
String manipulation? Date manipulation? A million other little things we've gotten used to with .Net's everything-AND-the-kitchen-sink frameworks? MonoTouch.
Web services? MonoTouch.
Syntactically, they both have their advantages. Objective-C tends to be more verbose where you have to write it. You'll find yourself writing code with C# you wouldn't have to write with ObjC, but it goes both ways. This particular topic could fill a book. I prefer C# syntax, but after getting over my initial this-is-otherworldly reaction to Objective-C, I've learned to enjoy it quite a bit. I make fun of it a bit in talks (it is weird for devs who're used to C#/Java/etc.), but the truth is that I have an Objective-C shaped spot in my heart that makes me happy.
Do you plan to use Interface Builder? Because, even in this early version, I find myself doing far less work to build my UIs with IB and then using them in code. It feels like entire steps are missing from the Objective-C/IB way of doing things, and I'm pretty sure it's because entire steps are missing from the Objective-C/IB way of doing things. So far, and I don't think I've sufficiently tested, but so far, MonoTouch is the winner here for how much less work you have to do.
Do you think it's fun to learn new languages and platforms? If so, the iPhone has a lot to offer, and Apple's stack will likely get you out of your comfort-zone - which, for some devs, is fun (Hi - I'm one of those devs - I joke about it and give Apple a hard time, but I've had a lot of fun learning iPhone development through Apple's tools).
There are so many things to consider. Value is so abstract. If we're talking about cost and whether it's worth it, the answer comes down to my first bullet item: if this is for business, and if you can get the work, you'll make your money right back.
So... that's about as objective as I can be. This is a short list of what you might ask yourself, but it's a starting point.
Personally (let's drop the objectivity for a moment), I love and use both. And I'm glad I learned the Apple stack first. It was easier for me to get up and running with MonoTouch when I already knew my way around Apple's world. As others have said, you're still going to be working with CocoaTouch - it's just going to be in a .Net-ized environment.
But there's more than that. The people who haven't used MonoTouch tend to stop there - "It's a wrapper blah blah blah" - that's not MonoTouch.
MonoTouch gives you access to what CocoaTouch has to offer while also giving you access to what (a subset of) .Net has to offer, an IDE some people feel more comfortable with (I'm one of them), better integration with Interface Builder, and although you don't get to completely forget about memory-management, you get a nice degree of leeway.
If you aren't sure, grab Apple's stack (it's free), and grab the MonoTouch eval stack (it's free). Until you join Apple's dev program, both will only run against the simulator, but that's enough to help you figure out if you vastly prefer one to the other, and possible whether MonoTouch is, for you, worth the $399.
And don't listen to the zealots - they tend to be the ones who haven't used the technology they're railing against :)

There is a lot of hearsay in this post from developers that have not tried MonoTouch and Objective-C. It seems to be mostly be Objective-C developers that have never tried MonoTouch.
I am obviously biased, but you can check out what the MonoTouch community has been up to in:
http://xamarin.com
There you will find several articles from developers that have developed in both Objective-C and C#.

So, my answer to a previous similar question is to learn Objective-C. (Also, don't forget about debugging support)
This will probably offend some but to
be honest, if you are going to do any
serious development, you should learn
Objective-C. Not knowing Objective-C
in iPhone development will just be a
hindrance. You won't be able to
understand many examples; you have to
deal with the quirks of Mono whereas
if you had a working knowledge of
Objective-C you could get a lot more
out of the platform documentation.
Personally, I don't understand the
position that says increasing the
amount of information you need in
favor of using Mono over the
platform's native language. It seems
somewhat counterproductive to me. I
think if this is a very expensive
proposition (learning a new language)
then it may be worthwhile spending
some time on fundamental programming
concepts so that learning new
languages is a fairly cheap
proposition.
Another user also wrote this:
Monotouch is easier for you now. But harder later.
For example, what happens when new seeds come out you need to test against but break MonoTouch for some reason?
By sticking with Mono, any time you are looking up resources for frameworks you have to translate mentally into how you are going to use them with Mono. Your app binaries will be larger, your development time not that much faster after a few months into Objective-C, and other app developers will have that much more of an advantage over you because they are using the native platform.
Another consideration is that you are looking to use C# because you are more familiar with the language than Objective-C. But the vast majority of the learning curve for the iPhone is not Objective-C, it is the frameworks - which you will have to call into with C# as well.
For any platform, you should use the platform that directly expresses the design philosophy of that platform - on the iPhone, that is Objective-C. Think about this from the reverse angle, if a Linux developer used to programming in GTK wanted to write Windows apps would you seriously recommend that they not use C# and stick to GTK because it was "easier" for them to do so?

Using Mono is not a crutch. There are many things that it adds to the iPhone OS. LINQ, WCF, sharable code between a Silverlight app, an ASP.NET page, a WPF app, a Windows Form app, and there's also mono for Android and it will work for Windows Mobile as well.
So, you can spend a bunch of time writing Objective-C (You'll see from many studies where the exact same sample code in C# is significantly less to write than OC) and then DUPLICATE it all for other platforms. For me, I chose MonoTouch because the Cloud App I'm writing will have many interfaces, the iPhone being only one of them. Having WCF data streaming from the cloud to MonoTouch app is insanely simple. I have core libraries that are shared among the various platforms and then only need to write a simple presentation layer for the iPhone/WinMobile/Android/SilverLight/WPF/ASP.NET deployments. Recreating it all in Objective-C would be an enormous waste of time both for initial dev and maintenance as the product continues to move forward since all functionality would have to be replicated rather than reused.
The people who are insulting MonoTouch or insinuating that users of it need a crutch are lacking the Big Picture of what it means to have the .NET framework at your fingertips and maybe don't understand proper separation of logic from presentation done in a way that can be reused across platforms and devices.
Objective-C is interesting and very different from many common languages. I like a challenge and learning different approaches... but not when doing so impedes my progress or creates unnecessary re-coding. There are some really great things about the iPhone SDK framework, but all that greatness is fully supported with MonoTouch and cuts out all the manual memory management, reduces the amount of code required to perform the same tasks, allows me to reuse my assemblies, and keeps my options open to be able to move to other devices and platforms.

I switched. Monotouch let's me write apps at least 3-4 times as fast (4 apps per month compared to my old 1 per month in Obj C)
Lots less typing.
Just my experience.

If this is the only iPhone app you will ever develop, and you also have zero interest in developing Mac applications, ever, then MonoTouch is probably worth the cost.
If you think you'll ever develop more iPhone apps, or will ever want to do some Mac native development, it's probably worth it to learn Objective-C and the associated frameworks. Plus, if you're the type of programmer that enjoys learning new things, it's a fun new paradigm to study.

Personally I think you'll have a better time just learning Objective-C.
In short:
"Learning Objective-C" is not a daunting as you might think, you may even enjoy it after just the first few weeks
You are already familiar with the "C style" syntax with lots of *&(){}; everywhere
Apple has done a very good job of documenting things
You'll be interacting with the iPhone the way Apple intended, which means you'll get the benefits directly from the source not through some filter.
I have found that the projects like Unity and MonoTouch are supposed to "save you time" but ultimately you'll need to learn their domain specific language anyway and will have to side-step things at times. All that is probably going to take you just as long as it would to learn the language you were trying to avoid learning (in calendar time). In the end you didn't save any time and you are tightly coupled to some product.
EDIT: I never meant to imply anything negative about .NET I happen to be a big fan of it. My point is that adding more layers of complexity just because you aren't yet comfortable with the quirky objc bracket notation doesn't really make much sense to me.
2019 update: It's 7 years later. I still feel the same way if not more so. Sure, 'domain specific language' may have been the wrong term to use, but I still believe it's much better to write directly for the platform you are working with and avoid compatibility layers and abstractions as much as possible. If you are worried about code reuse and re-work, generally speaking any functionality your cross platform app needs to perform can probably be accomplished with modern web technologies.

To add to what others have already said (well!): my feeling is that you're basically doubling the number of bugs you have to worry about, adding the ones in MonoTouch to the ones already in iPhone OS. Updating for new OS versions will be even more painful than normal. Yuck, all around.
The only compelling case I can see for MonoTouch is organizations that have lots and lots of C# programmers and C# code lying around that they must leverage on iPhone. (The sort of shop that won't even blink at $3500.)
But for anyone starting out from scratch, I really can't see it as worthwhile or wise.

Three words: Linq to SQL
Yes it is well worth the $.

Something I'd like to add, even though there's an accepted answer - who is to say that Apple won't just reject apps that have signs of being built with Mono Touch?

I would invest the time in Objective-C mainly because of all the help you can get from sites like this. One of the strength's of Objective-C is that you can use C and C++ code, and there is a lot of projects out there that are well tested.
Another thing is that you're code (language of choice) will be supported by apple. What it iOS 5.x for instance removes the support for a third party solution like MonoTouch? What will you tell your customers then?
Maybe its better to use a platform independent solution like HTML5 if you're not entire ready to move to Objective-C?

I've been using MonoTouch for a few months now, I ported my half finished app from ObjectiveC so I could support Android at some point in the future.
Here's my experience:
Bad bits:
Xamarin Studio. Indie developers such as myself are forced into using Xamarin Studio. It is getting better every week, the developers are very active on the forums identifying and fixing bugs, but it's still very slow, frequently hangs, has a lot of bugs and debugging is pretty slow also.
Build times. Building my large (linked) app to debug on a device can take a few minutes, this is compared to XCode which deploys almost immediately. Building for the simulator (non-linked) is a bit quicker.
MonoTouch issues. I've experienced memory leak issues caused by the event handling, and have had to put in some pretty ugly workarounds to prevent the leaks, such as attaching and detaching events when entering and leaving views. The Xamarin developers are actively looking into issues like this.
3rd party libraries. I've spent quite a time converting/binding ObjectiveC libraries to use in my app, although this is getting better with automated software such as Objective Sharpie.
Larger binaries. This doesn't really bother me but thought I'd mention it. IMO a couple of extra Mb is nothing these days.
Good bits:
Multi-platform. My friend is happily creating an Android version of my app from my core codebase, we're developing in parallel and are committing to a remote Git repository on Dropbox, it's going well.
.Net. Working in C# .Net is much nicer than Objective C IMO.
MonoTouch. Pretty much everything in iOS is mirrored in .Net and it's fairly straight forward to get things working.
Xamarin. You can see that these guys are really working to improve everything, making development smoother and easier.
I definitely recommend Xamarin for cross platform development, especially if you have the money to use the Business or Enterprise editions that work with Visual Studio.
If you're solely creating an iPhone app that will never be needed on another platform, and you're an Indie developer, I'd stick with XCode and Objective C for now.

As someone with experience with both C# as well as Objective-C, I'd say for most people Xamarin will be well worth the money.
C# is a really good designed language and the C# API's are good designed as well. Of course the Cocoa Touch API's (including UIKit) have great design as well, yet the language could be improved in several ways. When writing in C# you will likely be more productive compared to writing the same code in Objective-C. This is due to several reasons, but some reasons would be:
C# has type inference. Type inference makes writing code quicker, since you don't have to "know" the type on the left-hand side of an assignment. It also makes refactoring easier and more saver.
C# has generics, which will reduce errors compared to equivalent Objective-C code (though there are some work-arounds in Objective-C, in most situations developers will avoid them).
Recently Xamarin added support for Async / Await, which makes writing asynchronous code very easy.
You'll be able to reuse part of the code base on iOS, Android and Windows Phone.
MonoTouch largely implements the CocoaTouch API's in a very straightforward way. E.g.: if you've got experience with CocoaTouch, you'll know where to find classes for controls in MonoTouch (MonoTouch.UIKit contains classes for UIButton, UIView, UINavigationController, etc..., likewise MonoTouch.Foundation got classes for NSString, NSData, etc...).
Xamarin will give users a native experience, unlike solutions like PhoneGap or Titanium.
Now Objective-C has some advantages over C#, but in most situations writing apps in C# will generally result in less develop time and cleaner code and less work to port the same app to other platforms. One notable exception might be high-performance games that rely on OpenGL.

The cost of the MonoTouch library is entirely beside the point. The reason you shouldn't use Mono for your iPhone apps, is that it is a crutch. If you can't be bothered to learn the native tools, then I have no reason to believe that your product is worth downloading.
Edit: 4/14/2010 Applications written with MonoTouch aren't eligible for the iTunes Store. This is as it should be. Apple saw plenty of shallow ports on the Mac, using cross-platform toolkits like Qt, or Adobe's own partial re-implementation of the System 7 toolbox, and the long and short of it is they're just not good enough.

How is WinForms programming in Visual C++/C# different from Windows programming in Visual C++(MFC)

How is winforms programming in visual c++/c# different from windows programming in visual c++(MFC).
Also I want to know whether C# is strong enough to do Windows programming as in other than forms.

I'm not sure if anyone can give one single answer to this question, I can just try to point out a few of the many differences:
C# and C++ are quite different: Memory management, package structure, class layout, events/delegates, generics/templates... Even writing non-GUI apps is completely different in C++ and C#. Many of the features of the C# language are very helpful if not even designed for GUI development.
Winforms has a very good visual designer support if compared to MFC. For 95% of all apps, you'll be a lot more productive using winforms. This is especially true for custom controls (either your own or third party)
MFC on the other side provides more framework support (document/view structure etc.).
For some applications, MFC apps may seem more responsive. In most of these cases, a winform application can be optimized to have the same performance, but this is above the average winforms developer level (which is generally lower than the knowledge level of MFC programmers).
MFC encapsulates the WIN32 API more directly than Winforms do. There are cases where you need to access the WIN32 API even from winforms directly. Then it is not always clear (and not well documented), how to do this. Again, a typical winforms programmer has less knowledge of the WIN32 API than a MFC programmer, so in these cases he will run into troubles more likely.
I think winforms is well supported and you can solve pratically all GUI/NON-GUI tasks. For most tasks, it will be easier to write a C# program.
I'm sure, there are much more arguments pro/contra, I just noted the few that came into my mind...

There are a few notable differences:
You'll eventually be more productive as it is much easier to do (.net)
The language helps you from making a lot of common mistakes (null pointers, overflows, leaks)
The framework is a lot (and really I mean a lot) more clean than MFC
In essence you can do almost anything. The least common 0.01% of things you need to do through direct win32 DLL invokes (or use a wrapper or library someone else made)

As a professional, I have to admit that I prefer to use Delphi instead of C++ for any WIN32/Desktop development. If you're going to build GUI applications that are client applications or stand-alone applications then you might find that Delphi (and C++Builder) has far more visual components than .NET, at this moment. That's because .NET is still more popular for web development and service applications.
Doesn't mean that Delphi (or C++) is more powerful than .NET, since .NET is gaining quickly on the GUI application level. WPF/Silverlight is going to promise a lot of new possibilities for developers.
Another reason why many people are still using Delphi/C++ for WIN32 is because they still have lots of legacy code. And some of this code has already been working for over a decade and only needs additional maintenance. Rewriting those projects in C#/.NET would be way too expensive. People are considering this but existing code has proven itself already. New code will introduce new bugs.
With C# you're not going to do Windows development. You're doing .NET development and some parts of .NET will allow you to use the Windows functionality. However, a major part of the .NET classes are actually wrappers around the Windows API, making it easier to use those functions. But not everything is already implemented in .NET, so there's still a lot of work that needs to be done.
The danger of .NET development is what I like to call, the ".NET Hell". When .NET was introduced, people said it was going to end the DLL Hell that was bothering every C++ developer on Windows. Well, It did end the DLL Hell, only to replace it with the .NET Hell, where multiple versions of the same assembly are still able to cause lots of problems. So, in that regard, nothing much has changed. You're still depending on a certain runtime version of a specific library (especially with third-party libraries) so there's no real gain here.
Still, I really like .NET development, most of all because more and more applications are run as a service (SAAS) instead of the old-fashioned desktop application. Basically, you'd only need a web browser to use those applications, thus becoming less dependent on certain hardware requirements. Here lies the real strength of .NET development.

Is it worth porting a small C# "engine" to C++ or similar?

So, following a tutorial I found on MSDN I've created what you might call an "engine" using DirectX and C#. I haven't seen a lot of this sort of thing (Personally, that is) done in C# and the majority seem to favour C/C++ so I'm curious as to whether using C# will come back to bite me, or whether I should just go ahead?
The reason I ask is that the tutorial stopped rather suddenly and so there's a basis of something but it's small enough to be ported without much hassle. I like C# myself, but I don't know whether there's something everyone else knows that I don't.

Well Peter, the main reason is C++ is platform agnostic, while C# isn't in the true sense, despite Mono (I don't think you can run Mono C# on most cellphones, the Nintendo DS or the Playstation3, for example).
Anyways most of these engines support DirectX and OpenGL, and/or software renderers, thus they are engineered from the ground up to be agnostic. But as with any agnostic system, this requires a lot of effort, and resources.
Now from what you say, your engine is C# + DirectX, meaning your engine right now may run on PC, Xbox, Zune, and some Window's powered cell-phones. This isn't a bad range of platforms to be honest. So if your happy with this degree of freedom, and you prefer C# over C++ than you might as well stick with what you have, and spend the time improving your engine. However if you want to run your engine on anything not Microsoft, you'll need to make the jump to C/C++ sometime.
For an idea of what I'm talking about my team's engine supports Xbox,PS3,Wii,PSP,PC, and possibly other platforms as-well if we spend the effort, however we have 15 full-time engineers working on it, so... you see it's a big cost. Now if you want something like this for a free project, and you know C++ you may try any of the many open source engines out there such as Ogre or Irrlicht.

I suggest staying with what you are familiar with. Use of C or C++ should only be considered in your situation if you intend to do some lower level functionality, like implement your own image processing or create custom filters or transforms (depending on what you are using directx for).
Graphic applications can have computationally intensive aspects. Most of these have been addressed in the DirectX api- which is just as fast if you use it from C++ or from C#.
Where you would consider lower level language: If you are creating some image processing which could perform quicker natively- this only applies if it is not offered by the directx api, such as creating some custom encoders/decoders. In this case you could create the custom component in another language- and then load it in your C# application separately. If you are- look into using C++ Intrinsics, which allow you to program for your CPU, and also take a look at GPGPU API's like CUDA.

As a hobbyist game developer I greatly prefer C# (with a 3rd-party library call SlimDX) over C++. Yes, a game written in well-optimized C++ will probably run better than the same game written in well-optimized C#. But the time I save by using C# (I'm guessing very roughly 30-40%) can be used to optimize my algorithms such that a C# game will actually run faster than had I written it in C++ in the same amount of time.
As pointed out above, there's also the cross-platform compatibility issues because for most practical purposes a C# game will only run on Microsoft platforms.
Another issue to consider is that if you write your application in C# then it will require the .Net Framework to be installed on the computers it runs on. This can make distributing your application cleanly somewhat more of a hassle, though this is by no means an insurmountable obstacle.

There are a few studios using c# for games.
You can also have a look at XNA, there is also a port of quake3 engine flying around the internet ported to c#.
So it should be ok.

If you feel more comfortable in C# and there are no performance issues forcing to switch to a language closer to the CPU, then I see no need to change.
However, depending on what you plan to do in the future and how far this engine should be taken, that might change dramatically and C# might turn out to be the wrong choice. But this only time can tell, unfortunately. The right educated guess requires much more detail about the current implementation and about your future plans.

Future proofing a large UI Application - MFC with 2008 Feature pack, or C# and Winforms?

My company has developed a long standing product using MFC in Visual C++ as the defacto standard for UI development. Our codebase contains ALOT of legacy/archaic code which must be kept operational. Some of this code is older than me (originally written in the late 70s) and some members of our team are still on Visual Studio 6.
However, a conclusion has thankfully been reached internally that our product is looking somewhat antiquated compared to our competitors', and that something needs to be done.
I am currently working on a new area of the UI which is quite separate from the rest of the product. I have therefore been given the chance to try out 'new' technology stacks as a sort of proving ground before the long process of moving over the rest of the UI begins.
I have been using C# with Windows Forms and the .net framework for a while in my spare time and enjoy it, but am somewhat worried about the headaches caused by interop. While this particular branch of the UI won't require much interop with the legacy C++ codebase, I can forsee this becoming an issue in the future.
The alternative is just to continue with MFC, but try and take advantage of the new feature pack that shipped with VS2008. This I guess is the easiest option, but I worry about longevity and not taking advantage of the goodness that is .net...
So, which do I pick? We're a small team so my recommendation will quite probably be accepted as a future direction for our development - I want to get it right.
Is MFC dead? Is C#/Winforms the way forward? Is there anything else I'm totally missing? Help greatly appreciated!

I'm a developer on an app that has a ton of legacy MFC code, and we have all of your same concerns. A big driver for our strategy was to eliminate as much risk and uncertainty as we could, which meant avoiding The Big Rewrite. As we all know, TBR fails most of the time. So we chose an incremental approach that allows us to preserve modules that won't be changing in the current release, writing new features managed, andporting features that are getting enhancements to managed.
You can do this several ways:
Host WPF content on your MFC views (see here)
For MFC MDI apps, create a new WinForms framework and host your MFC MDI views (see here)
Host WinForms user controls in MFC Dialogs and Views (see here)
The problem with adopting WPF (option 1) is that it will require you to rewrite all of your UI at once, otherwise it'll look pretty schizophrenic.
The second approach looks viable but very complicated.
The third approach is the one we selected and it's been working very well. It allows you to selectively refresh areas of your app while maintaining overall consistency and not touching things that aren't broken.
The Visual C++ 2008 Feature Pack looks interesting, I haven't played with it though. Seems like it might help with your issue of outdated look. If the "ribbon" would be too jarring for your users you could look at third-party MFC and/or WinForms control vendors.
My overall recommendation is that interop + incremental change is definitely preferable to sweeping changes.
After reading your follow-up, I can definitely confirm that the productivity gains of the framework vastly outweigh the investment in learning it. Nobody on our team had used C# at the start of this effort and now we all prefer it.

Depending on the application and the willingness of your customers to install .NET (not all of them are), I would definitely move to WinForms or WPF. Interop with C++ code is hugely simplified by refactoring non-UI code into class libraries using C++/CLI (as you've noted in your selection of tags).
The only issue with WPF is that it may be hard to maintain the current look-and-feel. Moving to WinForms can be done while maintaining the current look of your GUI. WPF uses such a different model that to attempt to keep the current layout would probably be futile and would definitely not be in the spirit of WPF. WPF also apparently has poor performance on pre-Vista machines when more than one WPF process is running.
My suggestion is to find out what your clients are using. If most have moved to Vista and your team is prepared to put in a lot of GUI work, I would say skip WinForms and move to WPF. Otherwise, definitely look seriously at WinForms. In either case, a class library in C++/CLI is the answer to your interop concerns.

You don't give a lot of detail on what your legacy code does or how it's structured. If you have certain performance criteria you might want to maintain some of your codebase in C++. You'll have an easier time doing interop with your old code if it is exposed in the right way - can you call into the existing codebase from C# today? Might be worth thinking about a project to get this structure right.
On the point of WPF, you could argue that WinForms may be more appropriate. Moving to WinForms is a big step for you and your team. Perhaps they may be more comfortable with the move to WinForms? It's better documented, more experience in the market, and useful if you still need to support windows 2000 clients.
You might be interested in Extending MFC Applications with the .NET Framework
Something else to consider is C++/CLI, but I don't have experience with it.

Thank you all kindly for your responses, it's reassuring to see that generally the consensus follows my line of thinking. I am in the fortunate situation that our software also runs on our own custom hardware (for the broadcast industry) - so the choice of OS is really ours and is thrust upon our customers. Currently we're running XP/2000, but I can see a desire to move up to Vista soon.
However, we also need to maintain very fine control over GPU performance, which I guess automatically rules out WPF and hardware acceleration? I should have made that point in my original post - sorry. Perhaps it's possible to use two GPUs... but that's another question altogether...
The team doesn't have any significant C# experience and I'm no expert myself, but I think the overall long term benefits of a managed environment probably outweigh the time it'll take to get up to speed.
Looks like Winforms and C# have it for now.

Were you to look at moving to C# and therefore .NET, I would consider Windows Presentation Foundation rather than WinForms. WPF is the future of smart clients in .NET, and the skills you pick up you'll be able to reuse if you want to make browser-hosted Silverlight applications.

I concur with the WPF sentiment. Tag/XML based UI would seem to be a bit more portable than WinForms.
I guess too you have to consider your team, if there is not a lot of current C# skills, then that is a factor, but going forward the market for MFC developers is diminishing and C# is growing.
Maybe some kind of piecemeal approach would be possible? I have been involved with recoding legacy applications to C# quite a bit, and it always takes a lot longer than you would estimate, especially if you are keeping some legacy code, or your team isn't that conversant with C#.