DirectX - is there any light in the tunnel?..
by Funky Diver · 03/08/2006 (9:08 pm) · 9 comments
Tom Miller - you suck :)
Guys, Do not update your DirectX SDK to December 2005 or Febrary 2006!
All the API was changed...
It seems like Tom Miller does his work without giving a serious though to software architecture practices.
I spend 4 hours trying to port our development code from April 2005 to February 2006 SDK, then I just gave up... I'm gonna talk to our Director of Research and Development Department to move all the code to OpenGL!
I fed up!
Cheers.
Guys, Do not update your DirectX SDK to December 2005 or Febrary 2006!
All the API was changed...
It seems like Tom Miller does his work without giving a serious though to software architecture practices.
I spend 4 hours trying to port our development code from April 2005 to February 2006 SDK, then I just gave up... I'm gonna talk to our Director of Research and Development Department to move all the code to OpenGL!
I fed up!
Cheers.
#2
Seems when I updated the SDK it changed the name of some functions and the vars some take and the order of vars soemtimes... It was just messy. There were some functions that I just couldnt find a replacement for. THey randoml;y dissapeared.
I would probably advise people against updating the SDK unless they NEED a function in the new one or they want the experience of fixing broken code.
03/09/2006 (3:48 am)
When I was coding my own engine I updated the SDK once and it took me a good 6 hours to figure out why all my .x file loading code and animation code was borked. Seems when I updated the SDK it changed the name of some functions and the vars some take and the order of vars soemtimes... It was just messy. There were some functions that I just couldnt find a replacement for. THey randoml;y dissapeared.
I would probably advise people against updating the SDK unless they NEED a function in the new one or they want the experience of fixing broken code.
#3
03/09/2006 (4:08 am)
I never had a problem with updating the DX SDK. First thing I do it read the changelist anyway.
#4
We are porting our software from Framework.NET 1.1 to Framework.NET 2.0. Feb 2006 SDK has all necessary libs for the new framework, so we are forced to move from version 1.1 to 2.0. The code DOES compile, but all the old DirectX code takes 100% CPU idling (it's known issue with previous SDK compiled under Framework.NET 2.0)! I'm really pissed off with the DirectX team "masterpiece" :(
What a bunch of loosers...
Consider this code used to scale a mesh (C#):
Now, this code will even not compile at all:
*) GraphicsStream was changed to GraphicsBuffer
*) All the concept of working with vertex array has been changed - and there is NO documentation at all how to use new GraphicsBuffer class
Westy, maybe you can tell me HOW can I port this piece of code to Framework 2.0, if you never ever had problems with DirectX SDK?
While compiling our project, we have about 300 errors because the DirectX team changed almost all the properties and function names of API... :[
And this is a post from Tom Miller's blog:
03/09/2006 (7:32 am)
@Westy: I have tons of examples of Feb 2006 SDK incompatibility with DirectX 9c. Did you check new SDK dated Dec 2005/Feb 2006?! We are porting our software from Framework.NET 1.1 to Framework.NET 2.0. Feb 2006 SDK has all necessary libs for the new framework, so we are forced to move from version 1.1 to 2.0. The code DOES compile, but all the old DirectX code takes 100% CPU idling (it's known issue with previous SDK compiled under Framework.NET 2.0)! I'm really pissed off with the DirectX team "masterpiece" :(
What a bunch of loosers...
Consider this code used to scale a mesh (C#):
using(VertexBuffer vb = loadingMesh.VertexBuffer)
{
Array stm_copy = null;
using (GraphicsStream stm = vb.Lock(0, 0, LockFlags.NoSystemLock))
{
try
{
objectRadius = Geometry.ComputeBoundingSphere(stm, loadingMesh.NumberVertices, loadingMesh.VertexFormat, out objectCenter);
//Check the mesh size and scale it if it's big or small
worldScale = 1.0f;
if (objectRadius < 1.0f || objectRadius > 8.0f)
worldScale = 8.0f / objectRadius;
if (worldScale != 1.0f)
{
switch (loadingMesh.VertexFormat)
{
case Direct3D.VertexFormats.Position:
{
Direct3D.CustomVertex.PositionOnly v3 = new Direct3D.CustomVertex.PositionOnly();
stm.Seek(0, System.IO.SeekOrigin.Begin);
stm_copy = stm.Read(typeof(Microsoft.DirectX.Direct3D.CustomVertex.PositionOnly), new int[] {loadingMesh.NumberVertices});
for(int i=0; i < loadingMesh.NumberVertices; i++)
{
v3 = (Direct3D.CustomVertex.PositionOnly)stm_copy.GetValue(i);
v3.X *= worldScale;
v3.Y *= worldScale;
v3.Z *= worldScale;
stm_copy.SetValue(v3,i);
}
}
break;
case Direct3D.VertexFormats.PositionNormal:
{
Direct3D.CustomVertex.PositionNormal v3 = new Direct3D.CustomVertex.PositionNormal();
stm.Seek(0, System.IO.SeekOrigin.Begin);
stm_copy = stm.Read(typeof(Microsoft.DirectX.Direct3D.CustomVertex.PositionNormal), new int[] {loadingMesh.NumberVertices});
// stm.Seek(0, System.IO.SeekOrigin.Begin);
for(int i=0; i < loadingMesh.NumberVertices; i++)
{
v3 = (Direct3D.CustomVertex.PositionNormal)stm_copy.GetValue(i);
v3.X *= worldScale;
v3.Y *= worldScale;
v3.Z *= worldScale;
stm_copy.SetValue(v3,i);
}
}
break;
default:
{
Direct3D.CustomVertex.PositionNormalTextured v3 = new Direct3D.CustomVertex.PositionNormalTextured();
stm.Seek(0, System.IO.SeekOrigin.Begin);
stm_copy = stm.Read(typeof(Microsoft.DirectX.Direct3D.CustomVertex.PositionNormalTextured), new int[] {loadingMesh.NumberVertices});
for(int i=0; i < loadingMesh.NumberVertices; i++)
{
v3 = (Direct3D.CustomVertex.PositionNormalTextured)stm_copy.GetValue(i);
v3.X *= worldScale;
v3.Y *= worldScale;
v3.Z *= worldScale;
stm_copy.SetValue(v3,i);
}
}
break;
}
loadingMesh.SetVertexBufferData(stm_copy, LockFlags.None);
objectRadius = Geometry.ComputeBoundingSphere(stm_copy, loadingMesh.VertexFormat, out objectCenter);
}
worldCenter = Matrix.Translation(-objectCenter);
}
catch
{
}
finally
{
vb.Unlock();
stm_copy = null;
}
}
}Now, this code will even not compile at all:
*) GraphicsStream was changed to GraphicsBuffer
*) All the concept of working with vertex array has been changed - and there is NO documentation at all how to use new GraphicsBuffer class
Westy, maybe you can tell me HOW can I port this piece of code to Framework 2.0, if you never ever had problems with DirectX SDK?
While compiling our project, we have about 300 errors because the DirectX team changed almost all the properties and function names of API... :[
And this is a post from Tom Miller's blog:
WHAT WERE YOU THINKING!!!! I just looked a little deeper in the changes you made from MDX1 to MDX2...You have change WAY too many calls, parameters and other "little" things.... Of course you will say "its much better readable now" BUT WHO CARES!!!!! You just messed up cross-platform Development with all you .NET Compact Framework ISVs! MD3DM (Managed D3D Mobile) is shipping with VS2005 and you bomb them one month before Release with a totally incompatible verison of MDX! Are you not talking to these guys? Are you not looking outside your office that there is another world out there? No wonder nobody has shipped MDX games yet...first the mess with the sample frameworks (changing them in every release with no backwards compatilibity) and than "fixing" the APIs to be more "Whidbey Conform". Well, so much for some christmas games...back to the drawing board and figure out how to manage the two codepath...and looking forward to DX10 I see another path coming...and no help from your side. I still love MDX but its time you learn that you cannot mess with the interfaces if you want ISVs to ship apps/games at some point in time Chris Muench MVP ************************ Saturday, October 22, 2005 5:37 PM by Derek I agree fully with Chris Muench. You're making our company have horrible transitions from our previous code to the newest versions. Our next meeting is discussing the use of OpenGL for our next project. The truth is simple: we like Microsoft, but we can't keep up with them.
#5
03/09/2006 (8:34 am)
Ah sorry, dont use MDX, thats prob why I never came across a problem. Seems you have issues with .NET 2.0 rather than DX.
#6
03/09/2006 (8:38 am)
No, we have exactly problems with DX :) They just change every two month (new SDK release) very important API parts. :(
#7
03/09/2006 (9:18 am)
I loaded all of DX's functions (Well, all the ones I use) to my own in my lib/dll files so it only took me a short amount of time to get everything back on track, but it's still ignorant of them.
#9
MDX 2.0 is a beta. It is clearly marked as a beta. Betas have problems. Betas change. Things break in betas. If you want a static API that isn't in flux don't use a beta.
03/10/2006 (4:34 pm)
Just to point it out here too:MDX 2.0 is a beta. It is clearly marked as a beta. Betas have problems. Betas change. Things break in betas. If you want a static API that isn't in flux don't use a beta.

Torque Owner Westy
What sort of problems are you talking about?