NightMarez:

If you have a DX10 card and Vista, you probably know what i mean, if you dont have, you are missing out on something awesome :).

Honestly, I have yet to play a D3D10 game that has impressed me over the D3D9 version.

NightMarez:

I dont see what being a hobby dev have ANYTHING to do with you having access to DX10 or not, people say its more clean and easier to program with then DX9 in the first place.

As has been stated several times already in this thread, there is nothing stopping you from having full access to D3D10.  No one is saying hobbyists have to use .NET.  And even if you want to use .NET, you still have full access to the entire D3D10 API using C++/CLI.  You can do that with all Microsoft tools and libraries, no third-party software.  Or are you just wanting Microsoft to abstract away all of the details of D3D10 and give you a whole other API that is more ".NET-esque?"

One of the advantages of MDX back when it first came out was ease of integration between managed languages and the native DX API.  Managed C++ was a horrible mess and mixing managed and native code caused great pain, so it made sense to allow Microsoft to just release an easy-to-use wrapper.  But now with C++/CLI, it's very easy to write your rendering code in C++ and have full interop with your C# game code.

ShawMishrak:

NightMarez:

If you have a DX10 card and Vista, you probably know what i mean, if you dont have, you are missing out on something awesome :).

Honestly, I have yet to play a D3D10 game that has impressed me over the D3D9 version.

 

So now your basicly saying Vista/DX10 is a fake promise and not useful in any way ?

Since you obviously think DX9 is just as good as DX10, its a scam by microsoft ?

Just checking (i know it sounds hostile, but no hostility intended).

That's not what he said at all. He said that, contrary to your statement that people without D3D10 are "missing out on something awesome", he has yet to see any D3D10 game that has impressed him over the D3D9 version of the same game. He never made any claims that D3D9 is just as good or that D3D10 is a scam; merely that at the current time there is nothing made with D3D10 that, to him, is more impressive than the D3D9 version.

Nick Gravelyn:

That's not what he said at all. He said that, contrary to your statement that people without D3D10 are "missing out on something awesome", he has yet to see any D3D10 game that has impressed him over the D3D9 version of the same game. He never made any claims that D3D9 is just as good or that D3D10 is a scam; merely that at the current time there is nothing made with D3D10 that, to him, is more impressive than the D3D9 version.

 

I understand, but me and him have a very different oppinion there, so i had to ask. :)

Sure, no game has "yet" to give max out on DX10's features, but the difference is there.

 

Anyways, this is getting out of hand it seems :P dont think this startet out as a DX9 vs DX10 bashing contest :P

And even if we continue this for the next 1000 pages, i doubt it will have much to say anyways :)

Edit : will just post quick links

http://windowsvistablog.com/blogs/windowsvista/articles/447226.aspx wich is about directx10 on vista

http://www.dxten.com/wiki/Main_Page dx10 wiki and info

NightMarez:

So now your basicly saying Vista/DX10 is a fake promise and not useful in any way ?

Since you obviously think DX9 is just as good as DX10, its a scam by microsoft ?

Just checking (i know it sounds hostile, but no hostility intended).

As Nick pointed out, that's not what I said at all.  The currently released D3D10 games do not offer much over the D3D9 counterparts.  As I mentioned several posts back, the main reason here is that their core rendering engines are still D3D9-based.  The D3D10 API is a completely re-designed API (unlike D3D8 -> D3D9) that requires a new way of thinking about the graphics pipeline.  That said, there are technical advantages to D3D10.  That was the whole point of the new API.  Even D3D9 is still designed for the legacy fixed-function graphics hardware of the Quake-era.  D3D10 aimed to change that by developing a new API that was designed to modern and future hardware.  The problem lies in the implementation.  When code using your API can only be executed on a small percentage of gaming machines, you're not going to sell a lot of copies.

On a technical level, I believe D3D10 is a good, clean API and is a step in the right direction.  On a marketing level, I think it's a borderline failure.  In order to properly support D3D10, you need to re-design your graphics code from the ground up and drop D3D9 support.  But to do that, you need to alienate the vast majority of your customers.  Do you see where I'm going with this?  If Vista was a huge success and everyone started to use it, the story may be a bit different.  But as it is now, Vista market penetration is poor, let alone D3D10 hardware.

I've used D3D10 before;  XNA GS development is only a small part of what I do.  I like the API.  But if I were to write a game that I intend to distribute, I would not use it.  The potential audience for the game would just be too small.

NightMarez:

Anyways, this is getting out of hand it seems :P dont think this startet out as a DX9 vs DX10 bashing contest :P

What bashing contest?  I'm not saying D3D10 is an inferior product, it's just a poor choice if you want to distribute/sell a lot of copies of your game.

NightMarez:

Edit : will just post quick links

http://windowsvistablog.com/blogs/windowsvista/articles/447226.aspx wich is about directx10 on vista

http://www.dxten.com/wiki/Main_Page dx10 wiki and info

To be fair, the first link is just marketing junk to hype the release of Vista and D3D10.

ShawMishrak:

NightMarez:

Anyways, this is getting out of hand it seems :P dont think this startet out as a DX9 vs DX10 bashing contest :P

What bashing contest?  I'm not saying D3D10 is an inferior product, it's just a poor choice if you want to distribute/sell a lot of copies of your game.

NightMarez:

Edit : will just post quick links

http://windowsvistablog.com/blogs/windowsvista/articles/447226.aspx wich is about directx10 on vista

http://www.dxten.com/wiki/Main_Page dx10 wiki and info

To be fair, the first link is just marketing junk to hype the release of Vista and D3D10.

I get ya :)

Im aware the first link is marketing, but i was more into the "whats new" part (lower part of the post).

Im also aware of the part where the majority of players still use winxp/dx9, but if that should change, it requires some reason for them to change, DX10 games would be a reason for them to change.

Thats why (in my oppinion) we need DX10 (and yeah, i know, we can get it like "that", but i would like to have seen it in XNA GS to be honest).

NightMarez:

ShawMishrak:

NightMarez:

Anyways, this is getting out of hand it seems :P dont think this startet out as a DX9 vs DX10 bashing contest :P

What bashing contest?  I'm not saying D3D10 is an inferior product, it's just a poor choice if you want to distribute/sell a lot of copies of your game.

NightMarez:

Edit : will just post quick links

http://windowsvistablog.com/blogs/windowsvista/articles/447226.aspx wich is about directx10 on vista

http://www.dxten.com/wiki/Main_Page dx10 wiki and info

To be fair, the first link is just marketing junk to hype the release of Vista and D3D10.

I get ya :)

Im aware the first link is marketing, but i was more into the "whats new" part (lower part of the post).

Im also aware of the part where the majority of players still use winxp/dx9, but if that should change, it requires some reason for them to change, DX10 games would be a reason for them to change.

Thats why (in my oppinion) we need DX10 (and yeah, i know, we can get it like "that", but i would like to have seen it in XNA GS to be honest).

DX10 is not going to make me change my OS  - nor will it make that happen for a lot of people.  The problem is that Vista - while shiny, and having some neat stuff, doesn't offer a significant functional advantage over what I already have to invest in it.  Like the majority of people, I'm not a hard core gamer (I probably write game code more than I actually play games), so the extra shiny graphics DX10 offers isn't really a selling point.  Nor do I want to have to update my laptop to play a video game.  Right now DX10 is a just a toy with too many barriers to entry - if they make it availlable for XP then we'll see a larger adoption rate I think - however there may be a technical reason why this is not possible.  

 My guess is that XNA GS and/or tools similar to it will be used increasingly more often for games that don't require hardware pushing as newer generations of programmers come out and the older ones who are experienced with C++/Un-managed languages filter out.  Mind you that's not going to happen anytime in the future - and who knows, C# and XNA GS may not turn out to be the tool of choice if/when it does - maybe someone will invent an awesome Lisp based api that blows everything else out of the water. Someone should work on that...I need to use the parenthesis more often ;) .

 

 

 

 

ShawMishrak:

CarotteJf:

"..use the native API directly (it is trivially easy to do that from managed code.." I'm not sure about this. What about types & structures for parameters/results ?

There are two ways of going about this:  C# P/Invoke and DllImport, or C++/CLI.  With the C# method, you can directly call into any C routine found in any DLL, as long as you know the name and function signature.  Look at this MSDN page for details.  Alternately, you can use C++/CLI to use native APIs just like you would in standard C++.  This allows you to write parts of your game in native C++ and parts in managed C# by wrapping the native code in a managed C++/CLI ref class and calling that code from C#.  It's actually quite trivial to get working, you just have to be careful to not transition between managed and native code too often, as there is an overhead involved with marshalling parameters across native/managed boundaries and verifying native calls are not messing with the runtime stack.

CarotteJf:

We can't rely on using SlimDX or other unsupported stuff.

You still haven't stated why this is so.  Open source projects like SlimDX have the advantage that any new features you want can be added yourself without waiting for the team to add them.  Not to mention a faster release cycle.  The SlimDX team is constantly releasing new versions with bug fixes and features, while the XNA Framework release cycle is anywhere from six months to a year!

"C# P/Invoke and DllImport, or C++/CLI", it's always trivial in academic samples or documentation. When it comes to use them 'for real' that's another story. Each time you need the actual parameters/result type, you need to declare them in the managed code and add marshalling attributes (see Example 3 in the MSDN page you linked). So no it's not that trivial because it involves typing a lot of extra and boring things. Try actually calling some DX9 functions with this method , you'll see what I mean. That's why they ended up doing SlimDX ;) Anyway, if I choose C# to make a game it's because I don't want to deal with C++ and native interop stuff anymore otherwise I'll stick with C++/CLI (and this is why I still haven't switched to C# for game programming).

I can't rely on using SlimDX (or other) because it's unsupported, it lacks samples/tutorials, documentation and support and it's not verified and tested as a MS API would be. "faster release cycle" isn't always good for an API, unless it's only for bug fixes but in pratice too many 'breaking changes' occur with fast cycle, forcing people to change and 'regress' test their code if they want to stay in sync with the latest 'bug free' API version. Such open source projects are worthy only when they're widely adopted because the community around them has a significant 'critical size' we can rely on. AFAIK, SlimDX or any another other 'managed DirectX' API open source project hasn't (yet:)) reached that 'critical size'.

CarotteJf:

"C# P/Invoke and DllImport, or C++/CLI", it's always trivial in academic samples or documentation. When it comes to use them 'for real' that's another story. Each time you need the actual parameters/result type, you need to declare them in the managed code and add marshalling attributes (see Example 3 in the MSDN page you linked). So no it's not that trivial because it involves typing a lot of extra and boring things. Try actually calling some DX9 functions with this method , you'll see what I mean. That's why they ended up doing SlimDX ;) Anyway, if I choose C# to make a game it's because I don't want to deal with C++ and native interop stuff anymore otherwise I'll stick with C++/CLI (and this is why I still haven't switched to C# for game programming).

Having to type extra code (heaven forbid!) does not make a problem non-trivial.  Regardless, the trick is to write the renderer (or whatever other component that needs access to a native API) in C++/CLI and not expose the native data types.  The component should communicate with the rest of the game on a higher level, and only go low-level when working with the API.  And yes, I do use this approach;  it's not just an "academic exercise" for me.  I have a C# game that interops with a C++/CLI physics component that uses Ageia/nVidia PhysX.  It works very well.  All game code interacts with the physics component on a high level, and the physics code simply translates these high-level primitives to low-level PhysX-specific API calls.  It's better integrated than a PhysX wrapper would be and I have complete control over it.

For your D3D9 example, you're taking the harder approach.  The renderer should only take a handle to your game window (if the renderer doesn't create the window itself), and not expose any part of D3D9 to the rest of the game code.  Use abstract renderables or render queue commands to tell the renderer what to do.  Your game code should not have to create D3D9 device resources.  Instead, just request texture, geometry, etc. containers from the renderer, and have the renderer return abstract objects that are handled by the renderer.

I understand that you do not want to have to deal with non-C# languages, but sometimes programmers just need to get their hands dirty!  If everything was already laid out for you, bug-free, where would the challenge be?

CarotteJf:

it's not verified and tested as a MS API would be.

Haha, sorry but that's funny!  Since when have all Microsoft API's been verified?  I'll give credit to Microsoft for creating some nice software, but I'd hardly favor it because "I know it's guaranteed to work."

So far what I got out of this thread is:

1) It's 2008 and hobbyists want to use C# or managed languages to write games.  XNA does this, but it isn't Windows only, and the Windows subset of it doesn't fully take advantage of all the latest and greatest DirectX.  Since it doesn't do this, it's not what they want.

2) The XNA line should be split into Windows and Xbox/Zune, and keep a subset for compatibility.  The XNA framework already does this.  The documentation already talks about programming considerations for all three environments.  Some APIs and features only work in some platforms.  But really the posters want the latest Windows support in XNA now, so it's not what they want.

3) There should be a networking framework that isn't tied to Xbox Live.  There is System.Net in the framework, but since it isn't a high level framework like DirectPlay was for DirectX, it's not what they want.  And didn't DirectPlay get deprecated over on the DirectX side as game companies were writing their own code anyways?

4) If MSFT doesn't do this, we'll just go open source... that old threat.

5) It's just a hack marketing tool for Xbox and Zune, and you are just a lemming if you embrace it.

XNA has a clear mission, provide managed development for games on top of DirectX for multiple platforms.  The multiple platforms mission has been in from the first announcement.  It accomplishes that mission... very well, I might add.  Considering that in just two years you have support for Xbox 360, Zune, and Xbox Live... that's an amazing accomplishment.  It seems to be living up to its mission very well.  All APIs should have specific use cases they are trying to resolve.  For example, the Win32 GDI has the ability to render bitmaps and Win32 APIs can produce sounds, so you have all you need to make games, right?  Well, it wasn't really designed for games' special needs, so it doesn't work very well for it (even though for many years people used it anyways!

This seems like very circular arguing.  This is what XNA does, here are the other options <--> It doesn't do what I want... so it should do it.  Not much room left for negotiation in there.

I suppose it would be reasonable to defend the work I've done, since this thread does cut at the heart of some of the issues here.

SlimDX is the product of a year and a half of careful and dedicated work by four developers, all of whom are professional programmers in their day jobs. It's undergone a number of architectural revisions in this timeframe, while continuing to expand its feature set at a breakneck pace. A fairly decent number of people are already using it, writing applications and reporting bugs. There's at least one substantial application built on top of it. I personally don't think it would be reasonable to start your own C++/CLI wrapper from scratch instead of using our code or forking it. SlimDX isn't small anymore. There's nearly 52K lines of actual code, and something in the vicinity of 30K lines of doc comments. Yes, there's docs. We've learned what works and what doesn't from a design standpoint, and the growing pains are essentially over at this point.

Our releases are on the same schedule as DX, four times a year. We release with the SDKs. Now if you want to follow our Subversion repository, and some people do, naturally that's far more volatile. But all of our code is open, and every time we make a release, we create a tag for it as well. That means that if you need to make changes based on the release you're using, without absorbing all of our post-release changes, you can do that too. There are Release Notes that call out all of the changes, breaking or not. We have a page to report bugs, and most of them are fixed within a day or two.

SlimDX isn't perfect, there's still a long way to go. But we're about to make our June release, and we're claiming complete support for all of:

• Direct3D 9
• DXGI/Direct3D 10
• DirectInput
• XInput
• Raw input
• XAudio2/X3DAudio

At the end of the day, yes, we're still subject to the problems inherent in community driven open source software projects. We don't have a large userbase. (Optimistically, a few hundred people.) We don't have people whose job it is to sit around and kick our code in the shins until something breaks. On the other hand, we have the advantages of being an active open source project too. If something breaks, you can fix it. If you don't want to fix it, we'll fix it and drop you a new build in no time. I like to think that what we lack in community, we make up for in providing a direct line to the developers and the code. If you go out and talk to people, they are universally (as far as I'm aware) happier with SlimDX than MDX, and MDX was the official Microsoft tried-and-true wrapper for years. I have yet to meet anyone who tried SlimDX and didn't like it. (Although I really would like to meet some of these people, as it's quite important to me to understand their point of view.)

I have a question, though. XNA is supported by MS. What exactly does this mean to you? What do you consider to be the significance of that particular detail? Is it their commitment that there will be another release, and that they will fix bugs in that next release? Is is that they provide a community site for people working with it to discuss and assist one another? In short, what do you consider fundamental to that commitment of support which is missing from MDX or SlimDX?

And lastly, if you do have specific complaints about SlimDX, rather than the hand wavy stuff, please mention them to me. Stuff like "3) SlimDX is good, but its not THAT good, seriously." isn't helpful. What do you want from us? We're an MDX replacement, not an XNA competitor. XNA seeks to make game creation readily accessible across platforms. SlimDX just makes DirectX available to managed code in a structure that makes sense in a managed context.

You have a couple of options (talking to people wanting more out of the XNA FRAMEWORK...not XNA for Windows purposes)

 1. Use the XNA Framework to create games. (Hurray Beer!)

 2. Don't use the XNA Framework and use some other Framework (SlimDX etc...)

 3. Create a wrapper of the dlls you want to use and make your own Framework using those

 4. Create your own Framework from scratch

 5. Keep complaining and get nowhere.

These are your choices for development regarding this situation.  To answer your question (the topic), no. There is no hope for a Windows only "XNA" in the matter that you are looking for.  Shawn already answered that question. You can make these so called AAA games without the help of Microsoft. No one is stopping you. Yes, they could make it easier for you by doing what you want but they had another idea. They decided to make the way of making games for hobbyists easier. Their focus? GAMES. Good  Approachable  Multiplatform Encoding Software  (yea, I just made up some stupid stuff that kinda make sense but still stupid). Now, if you want to make AAA games with the latest and greatest technology, then this is not the software for you to use. Now no one said that you can use this software with other software to make that game. That is up to you. It is just not the XNA Framework team's focus. So that is the end of that.

 Oh and people please stay on topic. This thread had 5 different topics in it already.

 

 

 

Promit:

I have yet to meet anyone who tried SlimDX and didn't like it. (Although I really would like to meet some of these people, as it's quite important to me to understand their point of view.)

Well I'm just currently evaluating SlimDX more deeply because it seems it's the only good option left we have :)

The first look I had at it, couple weeks ago, wasn't good mainly because I couldn't find any 3D examples except for the SimpleTriangle one (or MiniTri). And when I looked at this sample, 1st thing I saw when studying it was the marshaling attribute in the Vertex class and this worried me a lot. I thought 'Ohh do I have to deal with marshalling annotations everywhere when using that API, ouch that's gonna be a pain'. That was my 1st impression of SlimDX and 1st impressions are always important. Then I read about the 'water' sample in the Wiki but couldn't find till I SVNed  the whole source. Another bad impression. Then I opened the complete VS2008 solution and finally found the water sample. I tried to build that thing, got 21 errors in the SlimDX project and I gave up at this point :)

But like I said just before, I'm now back to evaluating  it more deeply so I'll eventually post more about SlimDX but here isn't the place, I'll use the link provided in the Wiki. I will also try porting one of my old MDX project to it then I'll make my final decision (which is due around mid june).

Promit:

I have a question, though. XNA is supported by MS. What exactly does this mean to you? What do you consider to be the significance of that particular detail? Is it their commitment that there will be another release, and that they will fix bugs in that next release? Is is that they provide a community site for people working with it to discuss and assist one another? In short, what do you consider fundamental to that commitment of support which is missing from MDX or SlimDX?

It's all about the potential 'audience' and communities that form around MS products. Unless the product is very bad, usually there are a lot of people that start to adopt it. Whether or not MS commitment will be high as we can except is just a 'bet' but it's usually a lower risk than betting on something built by a bunch of individuals.That's just it :)

Promit:

And lastly, if you do have specific complaints about SlimDX, rather than the hand wavy stuff, please mention them to me. Stuff like "3) SlimDX is good, but its not THAT good, seriously." isn't helpful. What do you want from us? We're an MDX replacement, not an XNA competitor. XNA seeks to make game creation readily accessible across platforms. SlimDX just makes DirectX available to managed code in a structure that makes sense in a managed context.

I've no specific complaints about SlimDX, at least yet :), except that bad 1st impression I had. When I mentioned SlimDX it was more in the general context of not being a MS supported product, nothing else. The fact that you replied here and eargely defended SlimDX is a very good point :)

 

The Zedox:

You have a couple of options (talking to people wanting more out of the XNA FRAMEWORK...not XNA for Windows purposes)

 1. Use the XNA Framework to create games. (Hurray Beer!)

 2. Don't use the XNA Framework and use some other Framework (SlimDX etc...)

 3. Create a wrapper of the dlls you want to use and make your own Framework using those

 4. Create your own Framework from scratch

 5. Keep complaining and get nowhere.

These are your choices for development regarding this situation.  To answer your question (the topic), no. There is no hope for a Windows only "XNA" in the matter that you are looking for.  Shawn already answered that question. You can make these so called AAA games without the help of Microsoft. No one is stopping you. Yes, they could make it easier for you by doing what you want but they had another idea. They decided to make the way of making games for hobbyists easier. Their focus? GAMES. Good  Approachable  Multiplatform Encoding Software  (yea, I just made up some stupid stuff that kinda make sense but still stupid). Now, if you want to make AAA games with the latest and greatest technology, then this is not the software for you to use. Now no one said that you can use this software with other software to make that game. That is up to you. It is just not the XNA Framework team's focus. So that is the end of that.

 Oh and people please stay on topic. This thread had 5 different topics in it already.

 

That's is what I'm doing. I've created this topic because I've currently evaluating all the options I have for this game and I wanted to know about XNA future. I'm not *really* complaining, I was just trying to be sure about that future (although with MS, one can never be sure of the future:)). Will it stay 'low' and aimed at XBox/Zune, will it go 'higher' and provide a full API for the Windows platform, will it stay aimed at selling Live subscriptions ?. Like you said, they responded and I got my answers now.

My options are narrowed to 2 & 3 and out of subject for these forums now. I  thank everyone in there for participating, even the DX9/DX10 'fighters' who spammed a bit:)

Our samples are pretty thin, I know...but the water sample is in the samples zip that you download from the site. And our SVN is of course a somewhat volatile medium...I think you had the amazing luck of pulling the source down on the very day someone broke the freaking build >=(

NightMarez:

First of all, im not saying i wanna make a AAA title, im saying i cant as it is,

Of course you can. A AAA title is not defined by the SDK it uses. How many AAA titles out there use DX9? (all of the 360 titles, right?)

NightMarez:

In DX10 you can move alot of the CPU stuff to the GPU, its more clean, and the effects you can make is amazing.

If you wantet to do those in DX9 (some you just cant do), but those you "could" move into DX9, it would eat up your CPU.

If you have a DX10 card and Vista, you probably know what i mean, if you dont have, you are missing out on something awesome :).

Could you be more specific and provide examples/screenshots/etc to show what you mean?