Render environment in DirectX - c#

I want to program for DirectX in C# and i have DirectX SDK,
what kind of project should be choose ? Windows form or ....

You should ask yourself first: What's the purpose of my project?
If you intend to building applications with beautiful 2D-3D visuals, then you just need to learn WPF.
On the other hand, if you wanna build games that require a lot of resources, XNA is the way to go.
Building applications on XNA is a lot of pain, since XNA is built for gaming.
The same can be said about building games with WPF.
In both cases, you don't need to communicate natively with DirectX (Which could be done via C++). Unless you're building a low level rendering engine, or a (very) high budget game.

You should use XNA, that is the replacement for Managed DirectX C#
Microsoft XNA ('XNA's Not Acronymed) is a set of tools with a managed runtime environment provided by Microsoft that facilitates computer game development and management. XNA attempts to free game developers from writing "repetitive boilerplate code" and to bring different aspects of game production into a single system.
From Wikipedia XNA Article.
Unless you want to just render windows but WPF might be the best options. See this blog post.

XNA:
XNA is a game oriented framework that allow you to target multiple hardware easily (Windows, the Xbox 360, Zune and now Windows Phone 7 with version 4) using .NET languages like C#.
Note that there's not a 1-1 relation between XNA and the DirectX SDK, for instance, it doesn't expose D3D10 or D3D11 or some interfaces that you can find in D3DX.
.NET Wrappers:
If your are looking for something similar than the native DirectX API, you have 3 options:
Windows® API Code Pack for Microsoft® .NET Framework:
wraps a bunch of Windows native libraries such as DirectX so they can be used from managed code. Note it doesn't expose API's prior to D3D10 such as D3D9.
SlimDX: Same thing but only for DirectX and exposes Direct3D from version 9 to 11 (SlimDX is an aside project that is not related to Microsoft).
C++/CLI and DIY the wrapper: Unless you have special needs, I wouldn't recommend it.
The final choice depends on your needs. If it's just for learning purpose of the DirectX API but in C#, I would say pick the Windows API Code Pack or SlimDX.

Related

What's the deal with Monogame, SharpDX, and XNA?

I've been doing research on good tools to create games with, and I came across Monogame, Sharpx, and XNA. I have some questions regarding each:
When I create a new windows project (which advertises that it uses DirectX 12), the code template looks like this:
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
I understand Monogame is a re-implementation of XNA, but where is the "re" part? This code shows Monogame using Microsoft's XNA, and doesn't even hint at the usage of DirectX 12.
SharpDX has an advantage of using WinRT (so i've heard), but what exactly does that mean to me? I know that SharpDX is a layer that sits on top of DirectX to allow it to be used in C#, and naturally should use WinRT. What excuse does Monogame have not to use WinRT?
I feel I'm confused at something and want clarity. Keep in mind that I'm a total noob at this stuff, anything helps!
MonoGame is indeed a reimplementation of XNA. It uses Microsoft.Xna.Framework.* namespaces to preserve source code compatibility with XNA projects. MonoGame does not currently support DirectX 12 - the desktop version has DirectX 11 and OpenGL backends.
It provides simple, cross-platform classes for common game tasks (loading content, rendering, sound playback, etc.) and a pipeline for building runtime-optimized content files. MonoGame is really powerful for most projects and great for quick development, though not a fully featured game engine like Unity. Since it is modelled after XNA (discontinued a few years ago), most XNA samples/tutorials work just fine.
SharpDX is a low-level wrapper of DirectX types. You should go with it only if you want to get your hands dirty with low-level plumbing, which doesn't appear to be the case.
The DirectX implementation of MonoGame (used for classic Windows, UWP, and Windows 8 apps) internally uses SharpDX for communicating with DirectX. When it comes to WinRT, it is just an implementation detail of "modern" Windows app platform.
Wikipedia has a few pages on the history of XNA. In short it is no longer supported. MonoGame extends it. SlimDX and SharpDX use their own DirectX wrappers and are basically copies of each other. Going by a recent post SlimDX future
It will not be continued. I do not know MonoGame but am strong in SharpDX and it provides current support for DirectX 12. If you also want to use OpenGL, you could try ANX but I do not know it. The SharpDX guy also wrote a Collada class which is on GitHub and there is an Assimp class that is compatible. None of the above have an integrated physics system but PhysX for .Net works fine with SharpDX.
In summary if you only need Direct X for C# then SharpDX would be the most straight forward choice. If you think you might expand to other platforms, you might want to check out MonoGame or ANX but I can't vouch for either. None of the above mentioned are complete Game Engines (such as Unity or UE4) they simply allow the use of features such as DirectX that are not natively supported by Visual Studio C#.

Win CE 7 application development

I have requirement that we need to develop a rich UI application(similar to WPF or silverlight). The target device is having embedded OS Win CE 7. how can i achieve this, after so much R&D i got to know that
1. we have to user Silverlight for GUI and C++ as backend coding
2. we can create the MFC application using some third party SDK we will not be able to get rich UI
Also, i read that we can add components in WIN CE 7 for compact framework.
Is my above understanding correct, can someone throw some light on this?
Just to add my 2 cents to Chris and Paolo's replies, if you are not building the OS image for the target device or, at least, can't control the features it supports, your choice may be limited by the set of components that were included into the OS image provided with the device.
Windows CE is highly componentized and both the badly named "Silverlight for Windows Embedded" (XAML) and .NET Compact Framewor runtimes can be left out of the OS image to save storage space and memory.
The XAML runtime can leverage graphic acceleration (if the HW you are using provides it and the BSP includes drivers to use it, of course) and this may lead to a more responsive system, compared to a full .NET implementation.
I would also try to stay away from MFC for new implementation. The only good reason to use MFC is that you already have an UI framework that fit your needs and is based on it.
Currently on CE you can decide between an easy to design and rich UI with complex to develop and debug code-behind (XAML) or an easy to develop .NET application with an ugly windows 95-like UI that require lot of work to be "beautified". XAML in the hand may merge the best of both worlds (requiring additional cost and two heavvy runtimes on your target, but this may not be an issue if you have a powerful x86 machine or a graphic accelerated ARM Cortex).
To develop application on WEC 7 you need an SDK built from OEM that give you the target board.
If you want to develop on a Virtual PC image you need Platform Builder to use CEPC BSP and create an O.S. image and the corresponding SDK.
After that, you can develop using Silverlight only with C++ but you can use .Net Compact Framework and managed code for Windows Forms development.
Paolo.
It really, really depends on both your definition of "rich" and the graphics capability of the hardware you're targeting.
CE 7 supports the .NET Compact Framework. Many people will say that you can't do "rich" UI in the CF, but that's not really true. You can't do it with the standard controls, but if you do your own custom control drawing, you can do pretty well. Yet, it's a lot of work, but it can be done. The limitations here are in alphablending (not fun to get working) and animation (also not fun), but with dedication you can work around many issues.
CE 7.0 also supports "Silverlight for Windows Embedded" (a.k.a. SWE). First thing to know there is that it's really not Silverlight. It's a XAML rendering engine, but any other Silverlight assets you might have won't work with it.
SWE supports only C++, though since it is COM based, it can be wrapped in CF classes and then used from managed code. I've seen a couple of companies do this, and one even offers it as a product.
MFC is available, but since MFC was crap even 10 years ago, I definitely wouldn't use it today. If you want to use C++ but not SWE, there are better options than MFC. STL and WTL come to mind for windowing apps.

C# Equivalent to java's Graphics2D

I've recently started about thinking about making a 2D game engine in C# from scratch.
Now, I've wondered: In java, I'd use the java.awt.Graphics2d and java.awt.Container classes.
What would you suggest me to use in C#?
Apparently, google couldn't help me with that one.
In .NET you could use Windows Presentation Foundation, it offers a great lot of graphic-manipulation. But if it fits to create a game-engine, I am not sure.
See MSDN for an overview.
Though, if you really want to have power, you should stick with DirectX and C++.
Note: there is FNA and MonoGame (both reimplementations of the now discontinued XNA), but they are both frameworks for creating games, not creating a game engine...
You can easily build games (2D/3D) with FNA or MonoGame (reimplementations of the now discontinued XNA). They aren't engines but they are both a layer architecture for simple DirectX-usage.
If you're looking for image manipulation within Windows Forms (PictureBox, Draw()-method overrides) you should have a look at System.Drawing.

Which Graphics Framework for Windows 8? MonoGame? OpenGL and Xaml/DirectX Mixing?

I would like to develop a game for windows 8, but since Xna isn't supported, i don't really know, if it is good to use something like MonoGame - because i think, it doesn't make any sense to use MonoDevelop with OpenGL while the UI Frontend runs with DirectX. But my searches and on "apptivate.ms", they still force the developers to use MonoDevelop - but why would a corporation like Microsoft even do this?
And i don't like to build my game in C++ with DirectX, because in my case, it's not a big game, and my favorite language (also, my language at work) is C#..
Btw., it would not be a big deal for me to write this game with OpenGL or C++, because I've got a lot of experience in these two for the past four years, but in this case, i like to have a "fast" and "save" solution like C# and a Graphics Framework.
So... maybe someone has the answer to these qustions:
Should i use MonoGame with Xaml / C# and don't worry about the mix of DirectX and OpenGL?
Or is there even another DirectX/Game Framework which i can use?
Or maybe, i'm totally wrong, and Xaml doesn't need DirectX? Or i can force MonoGame to use DirectX?
Or, another point - would something like "System.Drawing" fast enough for a spaceshooter with some nice shading effects (I think, for my case, i need shading and something like bloom, blurring etc.)? Maybe, Microsoft added a new 2D drawing library? (But i think its still gdi+ )
Your question is ambiguous if you are referring to Windows 8 Metro (aka Modern) or Windows 8 Desktop, but I assume it's the Metro version.
If you want to develop a game in C# for Win8 Metro without using a commercial solution, you can use:
SharpDX which is a low level DirectX API for .NET or the up-coming SharpDX.Toolkit (check latest news on the website) which is a high level framework around Direct3D11 (with a XNA like API, but with full Direct3D11 support). SharpDX is the only C# wrapper covering the whole DirectX API that is certified to work under Windows 8.
MonoGame which is using SharpDX for its Metro backend. I haven't heard that you need to use MonoDevelop for it, as it is working with an existing XNA project and VS 2012 should work just fine.
ANX which is also using SharpDX for its Metro backend.
Concerning the previous answer, If Win8 Modern is assumed, you can't use OpenTK, as OpenGL is not a certified API for the Microsoft App Store and SlimDX is not compatible with Windows 8 Metro.
There is an OpenGL to DirectX wrapper in the works that allows use of OpenGL in Windows 8 Modern applications. It's not complete yet but it may be sufficient if you want cross-platform compatibility and are willing to target only the subset of OpenGL that is implemented (or are willing to implement the rest yourself and hopefully contribute back.)
https://gl2dx.codeplex.com
Update: gl2dx seems to be dead as of November 2013, but there is a similar project, ANGLE, which implements most (if not all) of the OpenGL ES 2.0 spec and the EGL spec on top of either DirectX 9 or 11. This is the method by which Firefox and Google Chrome do WebGL on Windows.
http://code.google.com/p/angleproject/
If you want to use OpenGL and c#:
http://www.opentk.com/
For DirectX and c#:
http://www.slimdx.org/
or
http://sharpdx.org/
GDI+ is out bounds of Metro/Modern UI apps, if you're interested there some companies that look to make replacement apis like this one: http://www.moderncomponents.com/products/DrawingLibrary/, it's still in it's early stages, but looks good and may help you to create some simple games.

Best Windows language for multitouch and large bitmaps?

I will be developing an interactive application, involving multitouch, several layers of large bitmaps, and video playback. The screen resolution will be fairly large (1920x1280).
For several years, I have developed interactives in Flash, iOS, and OS X Cocoa. However, this project must run on a Windows box, so iOS & Cocoa are impossible. Also, I'm concerned about performance in Flash, since there may be 3 videos playing simultaneously, and large bitmaps moving around.
I know little about the technologies available on Windows. I'm investigating Silverlight, C#, Unity, Processing, and Java. If anyone can offer advice, it will be greatly appreciated.
You seem to be investigating several technologies on different levels:
C# and Java are programming languages. What you prefer may depend on your existing skills, but C# is from Microsoft so chances are that you will experience less friction using this language if you develop for Windows. Picking the right programming language is an important decision.
Silverlight is a "technology stack" from Microsoft. It enables you to develop XAML based applications that run in the browser. Compared to the native WPF stack it is less powerful. Choosing Silverlight, WPF or another technology stack like Processing.js is an important decision.
Unity is a dependency injection container from Microsoft. You can use this or any other suitable container if you like. Or none at all. You don't really have to think about this until you have made some of the more important decisions about your project.
Personally, I don't have experience with the type of application you describe, but I would go with C# and WPF. WPF has some support for multitouch on Windows, and only if it isn't adequate for your requirements you need to to go native and develop in say C++ which tends to require more work.
Multitouch in Windows 8 has been redesigned but unless you want to develop for a yet to be release operating system this is not an option.
Use Visual C++ if you like to create a LAN based Application, C++ is known for it's power and you could have many resources that could help you in developing this application. If you're going to create this application for web Use ASP.net(C#) C# is known for its flexibility and class libraries dedicated for web and client appilcation i also advice the use of WPF and Silverlight applications.
I suggest you have a look at Windows 8 and Metro Apps. Here is a link to start with this: The Microsoft BUILD conference, Windows 8, and the new UX Challenge. C# (.NET languages in fact), HTML5 and XAML are clearly the direction. Native C++ is back in town with WinRT. Silverlight is now in the gray area :-)
Even if you don't use Windows 8, it will give you a good overview of multitouch future in the Windows space.

Categories