|
Lachlan87
Moderator
USA
160 Posts |
 Posted - Nov 15 2004 : 7:18:58 PM
|
That’s what pisses me off too. After you finally get MDX working, it's lots of fun to program with, but it's dang hard to get things set up right. Since you can pretty much guarantee that your end-users are lazy, stupid, and evil, that is unacceptable. People want to be fed pureed stuff with a spoon, and MDX requires way too much chewing.
|
Edited by - Lachlan87 on Nov 15 2004 7:19:50 PM |
 |
|
|
cbx
Swordmaster
Canada
296 Posts |
Posted - Nov 15 2004 : 8:04:27 PM
|
quote:
Originally posted by Lachlan87
That’s what pisses me off too. After you finally get MDX working, it's lots of fun to program with, but it's dang hard to get things set up right. Since you can pretty much guarantee that your end-users are lazy, stupid, and evil, that is unacceptable. People want to be fed pureed stuff with a spoon, and MDX requires way too much chewing.
I think someones got the munchies!  |
Created by: X
http://www.createdbyx.com/ |
|
|
|
Knight Chat X
Squire
USA
24 Posts |
Posted - Nov 17 2004 : 3:57:02 PM
|
It's worse than that, this problem of library/runtime file versions also affecting the .Net Framework itself, upon attempting to install Visual Studio 2003, Visual Basic 2005, and DirectX 9.0c October SDK, and Visual Web Developer noticed each app I tried to install failed to install properly and refused installation, and the reason was?
Each and every release has a totally different version of the runtime files, you must install a paticular version, usually the one that comes on the applications CD in order to install it, but get this as it's even worse, since they change the runtime files like this, it means it would affect all languages under the framework, and what sucks more is that users that use your applications more than likely are forced to not just download the runtime files once, but anytime there is a change in versions on your machine which your software relies on, this would explain why if you create a software title using .Net, and a user needs to download .Net to run your app, if the user download's it today and the framework is 2.0 and your software is in 1.9, they don't match, version 2 is incompatible, thus problems occur, I can easily see this as leading to inquires and numerous online technical support requests.
As for pre-authored game engines, here's another game engine, this seems to be the onlyone I could get to work with with DirectX 9.0c, however, I don't recommend using a pre-authored game engine's because where's the fun and control in having your own, I know I know, there are plenty of up's to it as well, mainly getting game out faster:
http://www.truevision3d.com
For now, CBX's advice works well to get existing app's to go, another thing to remember is Visual Studio will automatically link references to the newest installed version of files, in order to run the 9.0b or previous samples simply remove all DirectX references in the IDE, and re-add each one, but this time navigate to the DirectX Version 9.00.0900 files and the app's should now work, even with DirectX 9.0c installed.
Another tip is something I learned from the big language changes of VB6 to VB.net, when creating your own library, it's best to keep things as light weight and as simple as possible yet functional, because if there's a change somewhere and you've got this massive library that is so deep it takes a day to re-learn something you wrote previously, it probably branches too much will create a big learning curve for others to follow. An example would be let's say you wanted to remove a tree from the ground, if the tree is small and there aren't as many branches, thus, it is easier to remove and you are ready to move to other things you gotta do quickly, now, let's say you try and remove a very huge tree that has many roots and is many years old, it's taller, has many branches, that tree would be a nightmare to remove.
Well, due to all the changes in programming syntax, technologies, security updates which hinder or remove features altogether and force developers to change programming methods, I got one thing left to say, I've spent more time re-writing programs and converting languages because of all these required changes, lack of adequate documentation, simple straight forward examples, it's caused so much time loss and nothing but headaches.
I like Microsoft, and I ain't got a problem with Bill Gates, but these version conflicts are messed up!!! |
The net is getting bigger and bigger. |
|
|
|
Matt_Giuca
Neophyte
Australia
3 Posts |
Posted - Jan 10 2005 : 04:03:35 AM
|
I agree, this version stuff is completely craxy. I don't know how you can expect the enduser to keep up. The best you can do is install the old versions yourself.
I found out that old versions of MDX are actually able to coexist. However I also noticed a very wierd thing - when I reopened my projects in VS.NET they automatically upgraded the version of the DLLs. I havent really tried this out much, but wouldn't that corrupt the code (since some functions have changed)? Anyone know about the auto-upgrading?
Also I found out that each version of MDX has a couple of different version numbers. This is the dumbest thing of all. Heres what I wrote in my analysis document:
All versions are installed by mdxredist.exe.
Each has 3 different versions.
In Windows\Assembly, it displays a version there. (assembly folder version)
If you right click the assembly, and go properties you see another version. (properties version)
In Windows\Microsoft .NET\DirectX Managed you see a different version (.net managed version)
In .NET when you go to the properties of the assembly you see yet another version. (runtime version)
December 2004
Included in: directx_9c_Dec04sdk_redist.exe
mdxredist.msi: 3,877,888 bytes
Installs and uninstalls managed.
assembly folder version: 1.0.2902.0
properties version: 5.4.0.2904
.net managed version: v9.03.91
runtime version: v1.1.4322
SDK Summmer 2003
mdxredist.msi: 5,180,928 bytes
Installs managed, no uninstall, also silent
Install header: "1126"
assembly folder version: 1.0.1901.0
properties version: 5.3.1.1126
.net managed version: v9.00.1126
runtime version: v1.0.3705
Unknown source???
assembly folder version: 1.0.900.0
properties version: 5.3.0.900
.net managed version: v9.00.0900
runtime version: v1.0.3705 (same as above)
---- End of doc ---
By the way the latest version can be found inside directx_9c_Dec04sdk_redist.exe (search msdn) if you extract the files and look for mdxredist.msi.
Also I found the following things in my program had to be changed:
Light.Commit() has become Light.Update()
why?
Another thing which is a very good thing, but annoying to have to change, is that CustomVertex.GetNormal()/GetPosition() and CustomVertex.SetNormal(Vector3)/SetPosition(Vector3) have been replaced with properties CustomVertex.Normal/Position
Anyway this is unacceptable, especially for Microsoft, but I suppose it will straighten out. Hope that document helped someone. |
|
|
|
ceefour
Neophyte
Indonesia
2 Posts |
Posted - Mar 10 2005 : 06:58:21 AM
|
This versioning problem actually also exists in .NET Framework itself. VS.NET 2003 by default targets v1.1 only, so your apps won't run on version 1.0 of the framework. I'm not sure if it can run on newer .NET Framework versions.
However you can change your project properties so your app will run under v1.0 but you need to design your app carefully so it won't use v1.1 features.
I believe the same thing can be done with Managed DX apps. You only need to loose up your assembly dependency so it will use any version of Managed DX available on the system. The same restrictions apply though, and it won't work if the Managed DX API between versions change (as it seems to) and you use the changing API.
About my first MDX app, it's a overlay rotator app. It's like a very simple wallpaper rotator, but it doesn't use your wallpaper but instead uses an overlay to overlay that picture desktop using the white color key. It's great... :-) And I haven't found any other app that provides the same functionality... And the download is only 8 KB. :-P
If you're interested just go to http://dev.gauldong.net/shiningwallpaper/. The source is available but currently not downloadable. It uses C# though... I hate VB :-P |
GaulDong Developer Center - http://dev.gauldong.net/ |
|
|
|
Bill_Shtinkwater
Neophyte
1 Posts |
Posted - Mar 11 2005 : 1:51:03 PM
|
I want to rant too! ;) I am also amongst the many affected by the changes to the latest MDX - even once I get my game to compile (which wasn't that hard, just changing the one call to lights().commit or whatever) but now it seems 1. my bullets no longer get drawn for some reason, and 2. whenever I quit the game I get: "An unhandled exception of type 'System.NullReferenceException' occurred in microsoft.directx.direct3dx.dll
Additional information: Object reference not set to an instance of an object."
Great, thanks M$! Thankfully my project is fairly simple, but how can anyone consider making a commercial game with things like this happening? However I notice that in the release notes for the update it says:
"Starting with this SDK release, D3DX is released as a dynamic-link library (DLL). Updates to D3DX in the future will continue to ship as uniquely named DLLs that exist side-by-side on the system. This allows for continued improvements to the library without imposing regression risk. D3DX9.lib is provided as the import library for the DLL, which your application can statically link against. See documentation for details."'
If I read that right (which is a big "if" ;)) that means that it is now safe to make function calls to the d3dx library because any future changes to those calls will only affect new versions of the d3dx dlls, which can all happily coexist with each other. So, new versions don't break stuff that uses old versions. That would seem like a step in the right direction. :)
Still the thing that kills me is how difficult it is to even get a system properly configured with mdx. As somebody said earlier in the thread, you can count on your end users to be lazy and stupid. That's totally correct - as an end user myself I know all about it. ;) Command line flag required for installation? You gotta be kidding.
So anyway, does anybody know of a place (a forum or mail address) at Microsoft where all this bitching can be directed? Without an MSDN membership, that is. I mean, obviously they have some clue about all the problems but I'd really love to hear an explanation for why MDX could ever be considered a viable platform for real game development. Because as nice as it is for me to work with, I have all but given up hope to ever write something I can feel comfortable distributing, especially commercially.
OK, I think I'm done ranting. At least until the next time MS breaks my game, heheh.
|
VB is dead! Long live VB! |
|
|
|
ceefour
Neophyte
Indonesia
2 Posts |
Posted - Mar 11 2005 : 4:27:58 PM
|
quote:
Originally posted by Bill_Shtinkwater
So anyway, does anybody know of a place (a forum or mail address) at Microsoft where all this bitching can be directed? Without an MSDN membership, that is. I mean, obviously they have some clue about all the problems but I'd really love to hear an explanation for why MDX could ever be considered a viable platform for real game development. Because as nice as it is for me to work with, I have all but given up hope to ever write something I can feel comfortable distributing, especially commercially.
Here's Tom Miller's blog: http://blogs.msdn.com/tmiller/
If you have no idea, he's MDX's architect. Good luck trying to get a reply from him, though. |
GaulDong Developer Center - http://dev.gauldong.net/ |
|
|
|
hotrodx
Squire
43 Posts |
Posted - Mar 27 2005 : 9:38:50 PM
|
Let's hear Microsoft doing an old Britney number...
Oops, I did it again
That DirectDraw part
I'm tossing out again
Ooh baby, baby...
Oops... No more DLL Hell
Deprecation is swell...
I'm not that innocent. |
|
|
|
VBBR
Moderator
Brazil
617 Posts |
Posted - Mar 28 2005 : 11:14:37 AM
|
One must not have anything else to do to come up with this. But that was funny anyway  |
Whatever. Who knows... |
|
|
|
|
DirectX 9.0c Damit they did it again!
