I just ran the little water demo with the debug spew on. Ran much better than the first time I tried it.

However, I did get this message in the debug output:
3024: Direct3D9: (ERROR) :Final Release for a device can only be called from the thread that the device was created from.

I think it might have to do with that auto-release stuff (I only poked around a little, I have no idea if I'm even close). And it's probably harmless, just thought you should be aware of it.

So I've tried today to migrate SlimDX into my Gorgon library. For the most part it's going well. However, I am missing a couple of functions from MDX. The (D3DX)CheckTextureRequirements function, and the TextureLoader.SaveToStream function. I can't seem to find any equivalent in SlimDX. I've found the Texture.From* functions, but nothing to save into a stream or file. Seems odd there'd be loading, but no saving functionality. Are either of these functions in some out of the way class? Or if they don't exist, will they be introduced in a newer version soon? If they don't exist, I can probably put them in myself, but I don't really want to duplicate any one elses effort.

I've also found a couple of instances where a struct is empty. That is, the struct was declared without any access modifier for its members. The structs I've found so far are: Viewport, and SurfaceDescription. Easily fixed by adding 'public:' before the member declarations.

Quote:Original post by Pauluss86
Just grabbed the code, and will try to compile in a moment. Could you place an already built lib in the downloads section on your Google Code site?

The plan is to do a proper binary build when I label a 0.1 release version. That'll happen when I'm fairly content that grievous omissions and mistakes in D3D 9 core and basic D3DX (like the stuff Tape_Worm brought up) is repaired. I also don't want to make massive reorganizations after 0.1, if at all possible. For example, a whole bunch of stuff just got moved around so that D3D 10 can be slid in easily when it's ready. (Yeah, I had a change of heart on the D3D 10 thing. D3D9 Ex might just show up some time too.)

No promises on when that will happen, but I think we're getting fairly close. Delay loading and the D3D(X) version check work now. Try renaming the d3dx9_34.dll to check that out. We moved to June 07 SDK, by the way. There is a wiki page on retargeting it to a different SDK version if you need to.

At this point, notify me if you notice any missing functionality from the stuff that maps to Direct3D 9 core functionality. (Except Resource and BaseTexture. I know they're completely bare, and it will be fixed soon.)

As far as 64 bit, I'm not set up for 64 bit development at all. If someone who is would like to check it out (Washu?) that'd be awesome.

And I almost forgot one last little thing. For various reasons, particularly to support tools better, you now have to explicitly load certain parts of DirectX. Right now that means calling SlimDX.Direct3D9.Direct3D.Initialize and SlimDX.DirectInput.DirectInput.Initialize before you do anything else. This is also where the missing DLL check kicks in, so if you want to handle that, you'll wrap those calls in a try. You'll get exceptions if you forget this bit, so don't. Calling Terminate is optional though, so do or don't as you like. (For the curious, these functions are causing setup and tear down of parent level interfaces, like IDirect3D9.)

[Edited by - Promit on July 2, 2007 3:00:18 AM]

Quote:Original post by Promit
The plan is to do a proper binary build when I label a 0.1 release version. That'll happen when I'm fairly content that grievous omissions and mistakes in D3D 9 core and basic D3DX (like the stuff Tape_Worm brought up) is repaired. I also don't want to make massive reorganizations after 0.1, if at all possible. For example, a whole bunch of stuff just got moved around so that D3D 10 can be slid in easily when it's ready. (Yeah, I had a change of heart on the D3D 10 thing. D3D9 Ex might just show up some time too.)

Something else I've noticed: In the Texture->LockRectangle() functionality, you really need to return the pitch or else you'll have no concrete idea of the byte-width for the texture. Currently there's nothing to facilitate that. I hated the MDX approach of using the [out] parameters to relay this information. And of course that's a personal preference. But I think returning a value type from LockRectangle() that contains both the graphics stream and the pitch would be a more elegant approach. It'd be similar to how LockRect works in the C++ API, by sending back the byte data and pitch in D3DLOCKED_RECT.

It took me a bit to wrap my head around how things work compared to MDX. The SlimDX, while not finished, seems more consistent in design and in how it matches up with the C++ API (the naming is pretty much the same for both, which is really nice). Whereas I find Managed DirectX to be a complete and total mess in many areas.

I wish I were able to continue, but until the display mode enumeration is added I'll have to stop at this point.

Quote:Original post by Tape_Worm
Something else I've noticed: In the Texture->LockRectangle() functionality, you really need to return the pitch or else you'll have no concrete idea of the byte-width for the texture. Currently there's nothing to facilitate that. I hated the MDX approach of using the [out] parameters to relay this information. And of course that's a personal preference. But I think returning a value type from LockRectangle() that contains both the graphics stream and the pitch would be a more elegant approach. It'd be similar to how LockRect works in the C++ API, by sending back the byte data and pitch in D3DLOCKED_RECT.

Done. LockRectangle returns a LockedRect, LockBox returns a LockedBox. The GraphicsStream is inside, along with the pitch info. Works nicely, I think.

Quote:I wish I were able to continue, but until the display mode enumeration is added I'll have to stop at this point.

Also done. I added a bunch of stuff here. The functions from IDirect3D9 are all available, and then that same info is wrapped into collections which you can foreach across. Each AdapterInformation (comes from Direct3D.Adapters) has a GetDisplayModes function that returns a list of display modes for a certain format.

I didn't bother to check what MDX does here, so apologies if I deviate a lot. This is simple and makes sense to me, though.

Quote:Original post by Promit
Done. LockRectangle returns a LockedRect, LockBox returns a LockedBox. The GraphicsStream is inside, along with the pitch info. Works nicely, I think.

Awesome. That's exactly what I envisioned.

Quote:
Also done. I added a bunch of stuff here. The functions from IDirect3D9 are all available, and then that same info is wrapped into collections which you can foreach across. Each AdapterInformation (comes from Direct3D.Adapters) has a GetDisplayModes function that returns a list of display modes for a certain format.

I didn't bother to check what MDX does here, so apologies if I deviate a lot. This is simple and makes sense to me, though.

Awesome again. Doesn't matter how it works, I can easily adjust to whatever you set up and it's much easier when the modes are in a collection so it shouldn't take any effort to change on my end.

I'll get the latest version and continue on once you go through my changes and integrate what you need.

There is another thing I make use of that is not in SlimDX:
The FromStream function should have an overload that has a parameter for size (replacing Width and Height if need be, or not if we wish to resize to that width and height), to indicate the amount of data to read from the stream (in bytes obviously).

Quote:Original post by Tape_Worm
There is another thing I make use of that is not in SlimDX:
The FromStream function should have an overload that has a parameter for size (replacing Width and Height if need be, or not if we wish to resize to that width and height), to indicate the amount of data to read from the stream (in bytes obviously).

Ok, that's in. May I ask what you're using this bit of functionality for? (And on a sidenote, you could have actually written this functionality app-side by reading from the stream manually via Utils.ReadStream and then using Texture.FromMemory.)

Quote:Original post by Promit

Quote:Original post by Tape_Worm
There is another thing I make use of that is not in SlimDX:
The FromStream function should have an overload that has a parameter for size (replacing Width and Height if need be, or not if we wish to resize to that width and height), to indicate the amount of data to read from the stream (in bytes obviously).

Ok, that's in. May I ask what you're using this bit of functionality for? (And on a sidenote, you could have actually written this functionality app-side by reading from the stream manually via Utils.ReadStream and then using Texture.FromMemory.)

Yeah, I realize that now, I hadn't really thought about it hard enough (a result of next to no sleep). If you think it'd be superfluous perhaps it probably doesn't need to be in there, I think I can easily adjust from my end.