|
Note: You must be registered in order to post a reply.
|
| cbx |
Posted - Nov 14 2004 : 05:42:36 AM
The problem is far worse then I thought!
So I go and do a fresh install of windows after getting a new computer, and install the new october 2004 DirectX SDK and POOF!, there goes my DX9Tools library! It will not run, and it will not even compile! Why? Because when you install the october dx sdk it does not also install any of the previous managed dx9 libraries. For example my dx9tools library is written to work with ver 9.00.0900 and guess what, the october dx sdk only installs ver 9.02.3900! Do you know what that means! That every one who has written code using DX9 needs to update there code to work with the new libraries! Laaaaame! Note to MS, feel free to install old versions of your managed DX9 SDK libraries next time!
Then I got to thinking...
Worse yet, all of my DirectX 9 example apps on my directx page were written for ver 9.00.0900 of the DX SDK. OMFG! All that work,... All those example apps I wrote, all those websites I posted them to,....
DAM YOU MS DIRECTX TEAM! DAM YOU!!! Now people are going to download my example apps from all over the net and try to compile and run them and they will not be able to! And good luck trying to find a link to the old managed directx libraries on the ms directx website, they only provide links for the newer v9.0c libraries.
And I'm just thinking about myself! What about all the other people out there and the apps those people have written! This is a disaster lying in wait!
What are your thoughts on this! Has anyone had any similar problems? I am looking for the link to the old redistributible package containing the v9.00.0900 managed directx libraries (summer 04 I believe). Has anyone have the link? |
| VBBR |
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  |
| hotrodx |
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. |
| ceefour |
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. |
| Bill_Shtinkwater |
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. |
| ceefour |
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 |
| Matt_Giuca |
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. |
| Knight Chat X |
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!!! |
| cbx |
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!  |
| Lachlan87 |
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. |
| cbx |
Posted - Nov 15 2004 : 6:18:35 PM
quote:
Originally posted by Eric Coleman
To add to the problem, on my own personal computer I apparently have two versions, 9.00.0900 and 9.00.1126.
lol This is turning into an episode of the twilight zone...
BTW I also used to have 9.00.1126 on my system before I did the fresh install of windows. Must have been installed during the original DX9.0 install, when the DX9 was first released to the public ...
|
| Eric Coleman |
Posted - Nov 15 2004 : 6:06:54 PM
quote:
Originally posted by cbx
It was only about a week ago that I did my fresh install of windows and installed the DirectX SDK. So I'm not sure why eric seems to have ver 9.02.2904 on his system. Did you install the new october 2004 release of the full sdk (and install all of the options)?
I installed a clean computer (it did not have Directx 9 installed). Visual Studio was not installed on the test machine either. I used a clean machine to make simulate someone installing Directx 9 for the first time to see if it would install the old managed directx files. The directx install programs that I used were downloaded directly from Microsoft's website today, so I obviously had the latest versions.
To add to the problem, on my own personal computer I apparently have two versions, 9.00.0900 and 9.00.1126.
The versions that I'm reporting are from the folder names from C:\WINNT\Microsoft.NET\Managed DirectX\. The version reported by right-clicking and viewing the properties window reports 5.3.0.900 and 5.3.1.1126 respectively for the Microsoft.DirectX.dll file. |
| cbx |
Posted - Nov 15 2004 : 5:01:44 PM
Don't get me wrond I don't mind the changes, I just wish they would have installed the older managed libraries instead of having to go through all the hassle of tracking down the previous redist containing the old managed libraries, plus on top of that, having to download a 84Mb file just to extract the 1.5Mb worth of files contained within it!
It was only about a week ago that I did my fresh install of windows and installed the DirectX SDK. So I'm not sure why eric seems to have ver 9.02.2904 on his system. Did you install the new october 2004 release of the full sdk (and install all of the options)?
Check this out, the many versions of DX (as they are on my computer) ...
OK Kiddies, are you ready to be confused! Yaaa let get this party started!
After doing a frash install of windows and installing the new october 2004 DX SDK (full install with all options instaled) I have on my system...
C:\WINDOWS\assembly\*all 9.0c Microsoft.DirectX libraries are v1.0.2902.0
C:\WINDOWS\Microsoft.NET\Managed DirectX\v9.02.3900
Right clicking and selecting properties on the dx files found in C:\WINDOWS\Microsoft.NET\Managed DirectX\v9.02.3900 will tell you the version of the file is 5.4.0.2904!
... So after installing the DX9.0b redist I also have ...
C:\WINDOWS\assembly\*all 9.0b Microsoft.DirectX libraries are v1.0.900.0
C:\WINDOWS\Microsoft.NET\Managed DirectX\v1.0.900.0
Right clicking and selecting properties on the dx files found in C:\WINDOWS\Microsoft.NET\Managed DirectX\v1.0.900.0 will tell you the version of the file is 5.3.0.900!
NO WAIT! It gets better!!!
Run the "DirectX Diagnostic Tool" and select the "DirectX Files" tab. You will find that files such as the Microsoft.DirectX.dll is reporting a ver 5.04.0000.2904 or ver 5.03.0000.0900 for the Final Retail and Final Debug versions respectivly.
Phew! Seems every where you look no two versions of DX are the same! Yikes! lol How is this stuff even working the first place!
This is versioning hell! |
| Eric Coleman |
Posted - Nov 15 2004 : 12:30:33 PM
quote:
Originally posted by cbx
Eric's suggestion to install DX9c redist did not work, so I tried the dx9b and that seemed to work.
...
Now does that make any sence to anyone? Essentilly MS is saying that when they release a new version of DX that they are not going to be backwards compatible with previous versions!
I think this is a very big problem if Microsoft wants "Managed DirectX" to be taken seriously.
For the record, there were problems like this with Direct 8 and 8.1. The type libraries were different and incompatible, yet when directx 8.1 was released they did not provide a secperate type library, but instead overwrote the old one. I don't remember what the changes were, but they generally didn't effect simple graphics demonstrations. Anyways, the fact is that they've done stuff like this before, but as far I know the changes in Directx 8 only effect VB programs.
The changes in Managed DirectX wouldn't be an issue if the 9.0c end user installation would install previous versions of DirectX.
Ok, I just installed directx 9.0c on a fresh computer. The computer had the 1.0 .NET framework. I tried 2 different methods. First I tried the redistributable version, directx_9c_redist.exe. This is the version that game companies are supposed to put on their game CDs. I also tried the web setup, which is a smaller download.
Neither of those programs installed Mangaged Directx. I was able to get it installed by using the "/InstallManaged" command line switch that CBX suggested. That worked, but not without some problems.
The full redist package contains a "manageddirectx.cab" file, and that's just odd that it doesn't install it by default. Problem two is that the directxsetup.exe file makes no hint that you are supposed to use "/InstallManaged" to install managed directx. You can't use a /? or a /help, and that sucks.
Third, it installed only one version of Managed Directx, 9.02.2904, which is different from what CBX has installed. CBX mentions version 9.02.3900 in his initial post.
What was Microsoft thinking? .NET and Managed Directx might be great for programmers, but who do they expect to use the programs? First, a hidden command line switch is just stupid and I very seriously doubt that many average computer users would even know where to find the command prompt, and even fewer would know how to use it. And then, even if an average user can accomplish that, what are they supposed to do when it installs the wrong version? I'm not stupid, but I was assuming that I would have 9.02.3900 installed when I installed directx 9.0c (directly downloaded from MS today).
What's the point of using .NET and Managed DirectX if it simply won't work as expected for end-users? |
| VBBR |
Posted - Nov 15 2004 : 04:41:59 AM
The license changed. Now you can use it even for commercial projects, as long as you display a logo for at least 3 seconds with no interruption, and make a reference to R3D in the readme file. |
| Zarneth |
Posted - Nov 14 2004 : 9:01:53 PM
quote:
Revolution3D was always freeware, you just need to display the logo for 3 seconds.
Really? Even for commercial usage? R3D's such an awesome engine. Just gotta figure out all the intricies of the meshbuilder still. :\
I seem to remember noticing on a topic on the old old forums where you used to have to pay a 30% royalty. XP |
|
|
| VBGamer |
© |
 |
|
|
|
