DirectX SDK (Dec 2005/Feb 2006) - do not use, guys

#1 What do you mean, they made use Dec.2005 in school didn't seem to have any problems

#2 If they started to code from that SDK - they will not have any problems, but if they are upgrading from previous SDK version, and if they especially using MDX - they will need to rewrite BIG portions of their code....

#3 Oh thank god. MDX *sucked* in the past. i hope this starts to fix it... though i'm guessing they will just be lazy until the vista and 360 xna stuff is done.....

#4 @Jason: it seems like they are pushing DirectX 10, but in a very ugly way...

#5 *cough Halo cough*

#6 @nibbuls

:)

#7 However if you are using only native DX, go ahead and upgrade.

#8 @Westy: I tried also some native C++ porting - some stuff was changed (vertex buffers), but nor as severe as MDX...

@nibbuls: :)

#9 If nothing had changed, what would be the point of a new SDK??

#10 Well, but it should be compatible with previous SDK inside the same version (DirectX 9), it's a good practice, lot's of companies will spent extra money for porting every 2-4 month -> long production cycles... That's not good...

#11 Honestly, i dont think you should be changing components/technologies midcycle. pick a tech, and only if there is a overwhelming justification do you switch during development.

#12 > lot's of companies will spent extra money for porting every 2-4 month -> long production cycles

No, you shouldn't be upgrading simply because a new version is released. A good company would only upgrade midcycle if the new release offered a fix or feature that was important to them, in which case the effort would make sense. That's why they have release notes, so you can see what has changed.

#13 You are right, guys, but in our case, we are forced to move to Framework.net 2.0 (by some reasons), so we are forced to use new SDK, because they have updated libraries from 2.0... Otherwise, we wouldnt do it.

I tried the old version of SDK (v.1.1), but by some reason, MDX 1.1 takes 100% CPU while running in Framework.NET 2.0... Profiler shows that there are caught hidden exceptions in the MDX layer :/, that's why it consuming that mush CPU even while idling...

#14 >You are right, guys, but in our case, we are forced to move to Framework.net 2.0 (by some reasons), so we >are forced to use new SDK, because they have updated libraries from 2.0... Otherwise, we wouldnt do it.

MDX 2.0 is a *beta*. There will be a lot of churn in those APIs and things will break often. That's why it's a *beta*. And you will find problems with MDX 2.0. It's not done yet and they know there are issues.

#15 I am kind of mixed. I agree with taualex that it's not good to have to deal with api's the churn continuously (and microsoft generally does a very good job about back-compat)

but on the other hand... I tried MDX 12 months ago.. and in my opinion (and most peoples) it is HORIBLE. it needs to be gutted, or at least fleshed out beyond the primitive no-doc skeleton it is before it's usable.

So I guess I prefer the mess it up now.. as long as eventually it becomes usable.

#16 SDK DLL's are debug. When you compile make sure it uses retail dll's.

#17 SDK has debug (with program database files) and release versions of DLLs, you can specify which to use from the DirectX control panel.