Jump to content
  • Advertisement
Sign in to follow this  
mysigninname

XNA to DirectX

This topic is 2607 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Im curious to hear people's opinions on how much of a leap it is shifting from xna to directx.

I want to get frank de luna's book on x11 when it comes out, but i also value xna's way of allowing you to focus more on the game itself rather than the engine.

How much of an increase in work load would there be moving to direct x ? Are there experienced directx guys/gals out there who would still rather make a game using xna?

~S~

Share this post


Link to post
Share on other sites
Advertisement
XNA 4.0 to D3D10+ isn't that much of a leap since the XNA API has more or less adopted the organization that D3D10 started. Obviously it doesn't have all the newer features of D3D11 or 10, but the basic idea of having a device, buffers, shaders (or effects), and textures is there. You of course gain a finer level of control since XNA does hide a bit of manipulating buffers/textures directly (e.g. the Set/GetData methods would take some work to implement yourself to get the level of functionality XNA has). Or details that XNA no longer provides, such as being able to play with shader fragments (e.g. Vertex/Pixel shader objects went away with XNA 4.0, so using Direct3D allows you to forgo the effects framework, which is not possible in XNA).

Also, you would have to develop your own content pipeline, so yeah XNA is still a player because it helps simplify development and provides tools to process content you author into a binary format quite easily. And it does have some higher level features, such as the Game, Model, and SpriteBatch objects to allow you to easily get an app setup - but that doesn't make it an engine by a long shot. But if you're looking to learn working with the D3D API or want to investigate how all that stuff is put together, then it's an effort that can be beneficial.

Share this post


Link to post
Share on other sites
Some questions you might want to consider:

  • Do you (and your team) feel comfortable in a C++ environment?
  • Will the scope of the game or future games benefit from the switch? Will the game will push your target platform's resources to its limits?
  • How much do you currently rely on XNA's content pipeline?
  • Do you like writing tools and engines? Or more interested in the game development?
  • Do you prefer handling your own memory allocations?
  • Are you targeting XBOX 360 Indie games? I think you have to use XNA for this.I started writing my personal game engine in XNA and eventually made the switch to DX (early on) because I preferred the flexibility/performance over productivity... and over long term, it'll set me on the right track to keep up with the latest technology. I found it more rewarding knowing I don't have the overhead of .NET framework and have complete control over the memory.

Share this post


Link to post
Share on other sites
Switching to D3D doesn't automatically mean forgoing C# and .NET either, e.g. SlimDX is a very good wrapper to stay in the managed world and have full access (more or less) to the DX API's. Of course, Frank's book will be using C++, but it's not that difficult to translate as its more about learning the functionality opposed to syntax.

Share this post


Link to post
Share on other sites
XNA is really more of a framework than an engine, but it still has a lot of things that will be missed/have to pull your own resources for when moving to DirectX.

I think that losing the content pipeline will be one of your biggest setbacks, if not the biggest, to moving from XNA to DirectX. If you rely on it greatly to generate your files to be used in run-time, you'd find the Content Pipeline to be very invaluable and flexible. The runtime content components also make content loading very quick.

As a non-XNA alternative, you'll have to write your own binary file generator, or deal with loading and processing the raw content to the right format every time the program loads, which leads to longer loading times. However, the .xnb file format can still be used in non XNA programs, and there is documentation on the structure of the XNB format to help you write your own file loaders and converters. With this in mind, you can even go hybrid/transitionary with your content handling. That is, you can use a C#/XNA solution just to convert the content into .xnb. This is completely removed from your DirectX programs, which will only deal with loading the content.

Share this post


Link to post
Share on other sites

XNA 4.0 to D3D10+ isn't that much of a leap since the XNA API has more or less adopted the organization that D3D10 started. Obviously it doesn't have all the newer features of D3D11 or 10, but the basic idea of having a device, buffers, shaders (or effects), and textures is there. You of course gain a finer level of control since XNA does hide a bit of manipulating buffers/textures directly (e.g. the Set/GetData methods would take some work to implement yourself to get the level of functionality XNA has). Or details that XNA no longer provides, such as being able to play with shader fragments (e.g. Vertex/Pixel shader objects went away with XNA 4.0, so using Direct3D allows you to forgo the effects framework, which is not possible in XNA).

Also, you would have to develop your own content pipeline, so yeah XNA is still a player because it helps simplify development and provides tools to process content you author into a binary format quite easily. And it does have some higher level features, such as the Game, Model, and SpriteBatch objects to allow you to easily get an app setup - but that doesn't make it an engine by a long shot. But if you're looking to learn working with the D3D API or want to investigate how all that stuff is put together, then it's an effort that can be beneficial.


Just to correct this but XNA4.0 is modeled on the ideas in D3D11 not 10. Thats why non mutable render states made it in as they are far faster to render with. The buffers and textures have always been part of the DirectX model, in the first few versions immediate mode was even extremely bad. Shaders were introduced in DX7 expended in DX8 and finally the SM levels were available since DX9.0.


You will only miss the content pipeline for mesh loading actually, loading of textures, shaders and effects can all be done with D3DX functions and these are more or less as simple as the content stuff.Content.Load<Effect> == D3DXCreateEffectFromFile; and so on.


D3DX adds a similar framework to that of XNA, even including mesh loading for x and sdkmesh formats all other formats you are on your own.

And DXUT gives you a application framework that takes most of the creation of the device and stuff out of your hands.

Share this post


Link to post
Share on other sites

Just to correct this but XNA4.0 is modeled on the ideas in D3D11 not 10. Thats why non mutable render states made it in as they are far faster to render with. The buffers and textures have always been part of the DirectX model, in the first few versions immediate mode was even extremely bad. Shaders were introduced in DX7 expended in DX8 and finally the SM levels were available since DX9.0.



I'm speaking in terms of API organization, which puts D3D10 and 11 to be far more similar to each other than compared to D3D9 and below, not that buffers, textures, or shaders are somehow a new idea... :blink:

Also, validation up front opposed at draw time with constructs like input layouts and render state objects started with D3D10, not 11. Or the idea of not having hardware caps (all features must be supported). This is why I said D3D10+ as I'm talking about both here. It's a baseline, and XNA 4.0 HiDef graphics card requirements are essentially D3D10 or higher (not quite, but you're golden if you have a D3D10 card). For all intensive purposes, it's the D3D10 API without some features like geometry shaders. Compared to 11, quite a few features are missing (not to mention the whole device context business)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!