DirectX SDK October

Thanks for the heads up.

I think they have changed the acronym of XACT to now meana "Cross-platform audio creation tool" or something like that. Nice and convenient way to change it, eh? :)

Quote:

Original post by technic Thanks for the heads up. I think they have changed the acronym of XACT to now meana "Cross-platform audio creation tool" or something like that. Nice and convenient way to change it, eh? :)

But then it would be CPACT, and that's just not 1337!!`!!1~ [wink]

It's funny how PIX is actually called "Performance Investigator for XBox for Windows". At least I think it's "Performance Investigator" - they don't make any references to the actual wording of the acronym hehe

Quote:

Original post by Anonymous Poster They should really bittorrent these files, it's not fun to see a 15kb download speed.

Perhaps it's your connection, I am getting 200kb/s

So let me get this right!!!! Now you can code the XBOX360 controller to work with your applications???

I havent seen the xbox360 controller but how does it plug in to the computer or do u hook your 360 up to your computer?

That is some tight shananigans! :)

Quote:

Original post by chaoticseedx So let me get this right!!!! Now you can code the XBOX360 controller to work with your applications??? I havent seen the xbox360 controller but how does it plug in to the computer or do u hook your 360 up to your computer? That is some tight shananigans! :)

Well, it has been publicly announced that the Xbox360 controllers are interoperable with the PC. They are just USB devices. It's not really just an "XBox360 controller" anymore...more of a "Microsoft controller".

An entire API dedicated to one controller? Isn't that kind of taking a step backwards?

Matt Hughson

Quote:

Original post by Anonymous Poster After having a look at XACT, I won't be leaving Fmod anytime soon.

How so? Are you telling me you fully analyzed and evaluated XACT in a period of 2 hours? Personally, I like the API because it is easy to take all of your sounds, export them to one package, and import and play them. The studio for it is a little confusing, but you can do some cool things with it like linking it to variables in your engine.

How come you keep doing "updates" to the SDK without bumping at least the minor version number?

Sigh, this is just a useless update. I mean, am I missing something, or is there abosolutly no reason to download this update?

I mean, one 170 meg download is enough for one day (BF2 patch, sheesh, 170 megs!)

Quote:

After having a look at XACT, I won't be leaving Fmod anytime soon.

Having recently seen a demo of XACT (I assume it is the one that was in the Oct'05 package) I'm at least curious to check it out. It did look pretty sweet.

W.R.T. to FMOD though - don't you have to cough up for a (potentially pricey) licence if you ever want to publish commercially? It's been a while since I last checked, but that could be a point in XACT's favour [wink].

Quote:

How come you keep doing "updates" to the SDK without bumping at least the minor version number?

The runtime (the "9.0c" part) hasn't been changed since Summer 2003 (or was it 2004?), so there is no reason to change the version number there. Everything else (i.e. the SDK) is for us developers.

I've had at least 3 versions of the PSDK in the last couple of years, they didn't have anything other than the date to distinguish them - not a version number as such.

Quote:

Sigh, this is just a useless update. I mean, am I missing something, or is there abosolutly no reason to download this update?

It's not going to offer everyone something in every release. I stuck with the Dec04 SDK for quite a while - part of the reason was that I saw no compelling reason to upgrade. No one is forcing you to upgrade!

For those developers not on the XB360 developer program, the XInput stuff could be very interesting.

hth
Jack

LOL MATTHUGHSON! ROFL! Yeah it seems like it huh, but probably it lets you access specific things within the 360 controller instead of the generic, normal features with DInput

Anyone know where I get get the MeshViewer app? I thought it was a handy tool...

Quote:

Original post by Moe Anyone know where I get get the MeshViewer app? I thought it was a handy tool...

If you really want it, you could always download the August SDK (it is still up on the MS site), and just unzip it (without installing). You can find it in there, the structure of the installer mirrors that of the final installation.

I guess I should have put the MeshViewer warning up at the top of my post hehe

Quote:

Original post by Moe Anyone know where I get get the MeshViewer app? I thought it was a handy tool...

DxViewer and DxOps are the suggested replacements for the functionality of mview and effectedit.

DxViewer has a number of advantages over mview and EffectEdit:
* Sas 1.0.1 compliant for D3DX Effects
* Allows more control over optimization, includes, etc...
* Adds normals, binormals and tangents if necessary
* More robust skinning
* Automatically reloads files on changes
* Uses "only" the programmable pipeline.
* Considerably more maintainable code (uses DXUT, simpler loading, etc...)

The major things missing from DxViewer are the "modifier" actions (weld, optimize, etc...) and the mesh navigation features (walking edges, triangles, verts, etc...). We think dxops is a more full featured replacement for the modifiers and we hope to get to the complex navigation in a future release of DxViewer.

DxOps is a command-line scriptable tool that exposes a large number of the D3DX APIs in a simple fashion. Additionally, DxOps has some advanced functionality such as the 'shade' command that provides the ability to run HLSL shaders on texture surfaces including the ability to read multiple source textures. DxOps is pretty modular and it should be easy to add custom commands if you find something lacking or let us know if you think there is something we should add.

Please give these two new tools a try and let us know what you find lacking.

Paul Bleisch [MS]

Well, the DxViewer just can't compete with good ol' Mesh Viewer :) The Mesh Viewer feels more like a tool and in addition to the "modifier" actions it just supports more things, like animations, PMeshes and much more elaborate render options.

I'm using these tools to check exported X meshes and this is much easier in the Mesh Viewer. DxViewer seems to have some lighting issues (see screenshot below) and when I quicly want to check a mesh, I don't want to load an effect needed to make it actually viewable. As a final complaint, loading an effect resets the selected mesh. I guess this is useful for effects editing, but other than that it just is annoying.

So Mesh Viewer will stay in my toolkit for a while longer.

Quote:

It's not going to offer everyone something in every release. I stuck with the Dec04 SDK for quite a while - part of the reason was that I saw no compelling reason to upgrade. No one is forcing you to upgrade!

For Managed DirectX I'm not too sure this is true, so I'd appreciate some feedback on this. After switching from the June to August 2005 releases, some of my code and that of the DXUT didn't compile anymore because of some API changes.

With the October release it seems I will have the same issues, obivously if I want to use generics, but they also renamed the GraphicsStream to GraphicsBuffer for example. Nice and dandy, but I can't simply reuse my code built against the August release. Since I dislike working with an outdated API (otherwise I'd have stuck with Java ;), I'll probably end up with translating the incompatibilities, yet again...

My primary concern is: will I have to do this every two months from now on? And should I finally get a decent product together, how can I distribute it properly? Maybe I am doing something wrong, but last time I checked my projects compiled against August 2005 didn't run on a June 2005 redist. I'm not too sure the other way around, but I'd imagine this won't work either. As I said, I may be on the wrong track with this, but it seems our Cpp fellows are better off with the unchanged 9.0c runtime.

While we're on the subject of Cpp-ers being better off, to me it seems there have been very few additons to the Managed code samples. For non-cubemap reflections, shadow volumes etc I have had to translate (non-SDK) tutorials and samples. It's not too hard once you get used to it, but for beginners -like me- it's quite daunting.

Other than the few minor complaints above, Managed DirectX is great! Thank you :)

Quote:

Original post by remigius Quote: It's not going to offer everyone something in every release. I stuck with the Dec04 SDK for quite a while - part of the reason was that I saw no compelling reason to upgrade. No one is forcing you to upgrade! For Managed DirectX I'm not too sure this is true, so I'd appreciate some feedback on this. After switching from the June to August 2005 releases, some of my code and that of the DXUT didn't compile anymore because of some API changes.

The same does happen with the native DX code. I managed to explode one of my older samples recently because it was using an older version of DXUT. Luckily though a simple cut-n-paste operation and swapping the included files around solved it pretty quickly.

Quote:

Original post by remigius With the October release it seems I will have the same issues, obivously if I want to use generics, but they also renamed the GraphicsStream to GraphicsBuffer for example. Nice and dandy, but I can't simply reuse my code built against the August release.

I don't think it has ever been stated that, from a source-code level, that each 2-month update is automagically backwards compatable with all previously written code. I've had similar things happen when I've changed platform SDK's.

Quote:

Original post by remigius will I have to do this every two months from now on?

If you keep changing your SDK, quite possibly.

Quote:

Original post by remigius And should I finally get a decent product together, how can I distribute it properly? Maybe I am doing something wrong, but last time I checked my projects compiled against August 2005 didn't run on a June 2005 redist. I'm not too sure the other way around, but I'd imagine this won't work either. As I said, I may be on the wrong track with this, but it seems our Cpp fellows are better off with the unchanged 9.0c runtime.

It is designed such that, upon release, you bundle your application with the necessary setup files that match the binary you're distributing. This should be handled fairly easily with DirectSetup - but I'm not an MDX programmer, so I can't say for sure [smile]

Quote:

Original post by remigius While we're on the subject of Cpp-ers being better off, to me it seems there have been very few additons to the Managed code samples. For non-cubemap reflections, shadow volumes etc I have had to translate (non-SDK) tutorials and samples. It's not too hard once you get used to it, but for beginners -like me- it's quite daunting.

That is a valid point, one that has been mentioned before (I think!)... The wider community seems to be filling in a lot of gaps, but you may well see more in the future.


One general thing to note... and something that I've seen stressed a lot of times by the more experience (and often professional) developers is that you DONT swap development tools mid project unless there is a very big reason (Major new feature, important bug fix). The idea is that you, at the time the project starts, pick which PSDK, which DXSDK, which compiler etc..etc..

Speaking for myself only, I've always caused myself at least a 2-day setback by swapping new tools mid project.

hth
Jack

Thanks for the feedback Jack.

As for the automagical backward compatibility, coming from Java I thought this was pretty much warranted. The C#/CLR libraries haven't broken backward compatibility either so far, so I assumed Managed DirectX wouldn't do this either, especially with the bimonthly updates.

Quote:

One general thing to note... and something that I've seen stressed a lot of times by the more experience (and often professional) developers is that you DONT swap development tools mid project unless there is a very big reason (Major new feature, important bug fix). The idea is that you, at the time the project starts, pick which PSDK, which DXSDK, which compiler etc..etc..

Special thanks for pointing this out. I don't know how I'm gonna cope with this, but it probably is a very good idea indeed. The only problem is that MDX API seems to be quite volatile, changing major classes with the latest update (GraphicsStream -> GraphicsBuffer) and a lot of smaller adjustments in past updates, like methods converted to properties etc. Though under the hood there haven't been any major changes I know of, to me it seems generally unwise to stick with an old version of any API, so I guess I'll just have to live with updating my code once in while.

Quote:

That is a valid point, one that has been mentioned before (I think!)...

I know, just thought I'd beat the horse some more ;) MDX is still quite new, but in the past few months I've been working with it, more and more community tutorials and samples are becoming available. Additional samples and turorials in the SDK however would stress Microsoft's support and endorsement for MDX, which would bring the API's reputation as a mature, professional platform up to par with the Cpp API's rep.

Quote:

Original post by remigius As for the automagical backward compatibility, coming from Java I thought this was pretty much warranted. The C#/CLR libraries haven't broken backward compatibility either so far, so I assumed Managed DirectX wouldn't do this either, especially with the bimonthly updates.

So from what you're saying, MDX is the only .Net component that has been breaking backwards compatabilities?

As for Java, I seem to remember finding quite a few things that were "deprecated" and then removed a couple of releases later. Sure, it gives you a bit of time to get it sorted - but I'd be careful relying on it [smile]

Quote:

Original post by remigius Special thanks for pointing this out. I don't know how I'm gonna cope with this, but it probably is a very good idea indeed.

It's born from the basic reasoning that, in a professional project, you have plenty of other "real problems" to spend time on without having your development tools changing and breaking the problems you solved last week!

Quote:

Original post by remigius The only problem is that MDX API seems to be quite volatile

It's for exactly this reason that you want to stick with one release for the whole development cycle. Pick your syntax/API and stay with it.

As previously mentioned, if you found that GraphicsBuffer fixed a bug you had with GraphicsStream or it offered some super-cool new feature you couldn't live without, then you might give serious thought to upgrading your development tools mid-project...

Quote:

Original post by remigius Additional samples and turorials in the SDK however would stress Microsoft's support and endorsement for MDX, which would bring the API's reputation as a mature, professional platform up to par with the Cpp API's rep.

I agree... more support from the "official side" would bolster it's reputation a lot. Problem I see with this is that the DX team are primarily aiming their tools at the commercial market (where they can make money) and from everything I've seen, native DX still has substantially higher market share. Thus it makes sense for the DX team to invest their budget more in favour of the tools that are actually being used.

Bit of a catch-22 though... more people use Native-DX so they produce more samples/docs for it. People choose not to use MDX because of the lack of samples/docs so use Native-DX, which gives even more incentive for more samples/docs for Native-DX [lol]

Jack

Quote:

Original post by Anonymous Poster Heck, just declaring a variable of type CreateFlags or calling Manager.GetDeviceCapabilities(...) causes a System.IO.FileNotFoundException to be thrown! They couldn't have even TESTED this internally ONCE if they didn't catch this.

What's the file that wasn't found? I'd say that 99% you're doing something wrong. They do test before releasing.

Quote:

Not only that, but significant functionality has completely disappeared. Where's MatrixStack? Add that to the above poster's list... Oh, and some of the API's have even been OBFUSCATED instead of simplified. There's just so many unnecessary changes that do absolutely nothing to improve the state of Managed DirectX. Geez, they even removed the PresentParameters.DeviceWindow property! Now you have to initialize it with an IntPtr HANDLE to the window -- Win32 creeping back up to the managed layer -- STUPID! Tell me who made this change and I'll slap some sense into them.

Email your concerns to directx@microsoft.com