Sign in to follow this  

SlimDX Official Launch -- Binary Builds and a Wiki!

This topic is 3706 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm happy to announce that SlimDX is officially going live. It's been a bit over three months since I originally posted a thread to gauge interest, and the response was clear. People want to see a real successor to Managed DirectX, and we're it. There's a couple announcements to go along with our launch. First, we have a homepage! The Wiki hosted there (courtesy of Rim van Wersch, aka Remigius) will serve as a source of non-reference documentation and status, as well as development and debugging tips, along with anything else useful to people. Second, our development homepage at Google Code is now hosting binary builds, as well as a samples package. There isn't a set release schedule for these right now; they'll be updated as appropriate when significant progress has been made. It's not that we're done. There's still a long way to go. While Direct3D 9 enjoys near-completion, there's plenty of other APIs to be filled in. We're working actively on Direct3D 10, DirectInput, and DirectSound. However, it was time to break out of the "prototype" feel and establish ourselves as a proper project. For those of you that haven't heard, the MDX samples and documentation are being discontinued, and will not be included in the DX SDK starting in November. Our goal is to fill out as a completely usable library for managed game development by then. Over the coming weeks, the wiki will be filled out with summaries of all of the SlimDX classes, including their current status. If you're just working with Direct3D 9, then I believe SlimDX is already ready for you to use. DirectSound should be usable right now, but I'm in the process of authoring a sample in order to make sure, as well as to provide a starting point for people working with it. DirectInput isn't ready yet, and Direct3D 10 is still somewhat volatile, but if people start trying to use those APIs and tell us what needs to be filled in, we will make progress much faster. Current Developers: Promit jpetrie Mike.Popoloski ravyne2001 [Edited by - Promit on September 23, 2007 2:25:11 AM]

Share this post


Link to post
Share on other sites
Congratulations, mate! Glad to see it's moving forward nicely. Once the C# Workshop is completed I'll have some free time available if you're looking for any additional hands.

Cheers!

Share this post


Link to post
Share on other sites
This is great work! Looking forward to upcoming releases.

Here is an initial "wishlist" of missing classes that I will need to recompile using SlimDX. Hopefully, some/all of these will find their way into upcoming releases. Please let me know if there are recommended workarounds not requiring some of these classes. Please also let me know if you do not intend to ever support some of these classes. It might be useful to have a Microsoft.DirectX.* to SlimDX member-by-member mapping table. Perhaps this will find it's way into your MDX migration guide. Thanks again.

Microsoft.DirectX.Diagnostics
--------------------------------------
All

Microsoft.DirectX.DirectInput:
--------------------------------------
EffectObject
Key
JoystickState

Microsoft.DirectX.DirectSound:
----------------------------------------
Buffer3D
Buffer3DSettings
Listener3D
SecondaryBuffer

Microsoft.DirectX:
-----------------------
GraphicsStream (use DataStream)

Microsoft.DirectX.Direct3D:
-----------------------------------
BehaviorFlags
CreateFlags
CustomVertex
DepthFormat
Light
LightType
RenderStateManager
SamplerStateManager
SamplerStateManagerCollection
TextureStateManager
TextureStateManagerCollection
VertexFormats

Microsoft.DirectX.Direct3DX:
-------------------------------------
AllocateHierarchy
AnimationController
AnimationRootFrame
BoneCombination
CompressionQuality
ExtendedMaterial
Frame
IntersectInformation
KeyframedAnimationSet
LoadUserData
MeshContainer
MeshData
PrtCompressedBuffer
PrtEngine
RenderToEnvironmentMap
RenderToSurface
SkinInformation
TechniqueDescription
XFile
XFileData

Share this post


Link to post
Share on other sites
Microsoft.DirectX.Direct3D:
-----------------------------------
BehaviorFlags -- This struct seems pointless, just OR together CreateFlags values.
CreateFlags -- We have this.
CustomVertex -- Gone. Write your own vertex structures as needed.
DepthFormat -- Gone, and folded into Format.
Light -- Known issue, will fix.
LightType -- Known issue, will fix.
RenderStateManager -- Gone. Use SetRenderState().
SamplerStateManager -- Gone. Use SetSamplerState().
SamplerStateManagerCollection -- Gone.
TextureStateManager -- Gone. Use SetTextureStageState().
TextureStateManagerCollection -- Gone.
VertexFormats -- No longer plural, use VertexFormat.

We have TechniqueDescription as well.

The RenderTo* bits will be put in soonish. However, the SH/PRT stuff, as well as the D3DX Mesh animation stuff, could be a long time coming.

Oh, one other thing I wanted to mention. That stupid bug where Dispose doesn't show up in Intellisense which has been affecting most builds for some time is finally fixed. Sometimes C++/CLI really just gets in the way. In any case, Dispose will show up correctly as a member now.

[Edited by - Promit on August 6, 2007 2:20:03 PM]

Share this post


Link to post
Share on other sites
This is great news! I love to see this project progressing and it seems to be doing well :D

One thing I am a little fuzzy on: Why only a sumary of each class in the wiki documentation? Don't we need proper (complete, with ever details and examples) documentation for people that have little or no experience with (M)DX? Especially now that the MDX documentation is disappearing soon, I think it would be very usefull. And since it is a wiki, everyone can participate and make it even better than the original documentation (I would love to see some good examples on several topics that are not documented in any of Microsoft's documentation).

Share this post


Link to post
Share on other sites
I, for one (and I think Promit agrees with me) see no benefit to essentially re-writing documentation that already exists. 90% or more of the SlimDX API-reference-level "documentation" would be identical to the documentation that exists in for the underlying native DirectX libraries. It's consequently signifigantly more efficient for us to simply document the mappings between SlimDX and native DX interface names, and any other variances that exist (for example, I'll probably author a page or two on DataStream and its usages and quirks, especially with respect to the D3D10 interface).

API documentation on a class-by-class, method-by-method basis would simply be a copy-paste job from the native docs, and would consume precious time that I think we'd all rather have spent on implementing functionality.

Share this post


Link to post
Share on other sites
I am not sure I agree with you there. Sure, in the beginning its good to just focus on functionality, but as the library gets bigger and bigger it starts to make more and more sense to publish your own documentation/reference. Microsoft's documentation for native DirectX is very good, but I think it still makes sense to have at least a reference for each function/type/property.

Share this post


Link to post
Share on other sites
I would be nice to at least see some setup code (you know the one that displays a triangle on the screen). Just so the newcomers can see it. I don't see the harm in it. Since it's a wiki, other people can post code and API documentation on what functions and classes do. Correct?

Share this post


Link to post
Share on other sites
Quote:
Original post by Alpha_ProgDes
I would be nice to at least see some setup code (you know the one that displays a triangle on the screen). Just so the newcomers can see it. I don't see the harm in it. Since it's a wiki, other people can post code and API documentation on what functions and classes do. Correct?
One of the sample apps is exactly that, a single coloured triangle, or do you mean have that code also posted on the wiki so users don't have to download it to see it? [smile]

Share this post


Link to post
Share on other sites
I agree with Mike; if you don't feel like maintaining your own documentation, then perhaps you can make links to the MSDN for the methods/properties in your classes.

Share this post


Link to post
Share on other sites
Amongst other things, it's probably worthwhile to have some XML doc comments in there, since those show up in Intellisense. I'm just not sure how extensive those comments ought to be.

Share this post


Link to post
Share on other sites
Quote:
Original post by ViLiO
Quote:
Original post by Alpha_ProgDes
I would be nice to at least see some setup code (you know the one that displays a triangle on the screen). Just so the newcomers can see it. I don't see the harm in it. Since it's a wiki, other people can post code and API documentation on what functions and classes do. Correct?
One of the sample apps is exactly that, a single coloured triangle, or do you mean have that code also posted on the wiki so users don't have to download it to see it? [smile]


Yes that's exactly what I mean [smile] Screenshot too [smile]

Share this post


Link to post
Share on other sites
Quote:

perhaps you can make links to the MSDN for the methods/properties in your classes.

I have toyed with this (or rather, with doing this automatically) -- with limited success. Perhaps a CHM decompiler would help. What I'm against is the manual word-for-word duplicate of interface documentation that isn't any different from the native documentation. I'm certainly not proposing no documentation whatsoever, just that our energy be focused on implementing features and documenting differences or new tech.

Share this post


Link to post
Share on other sites
Two things of note:
1. If we're going to be strong signing our assemblies then the PK must NOT be in the SVN. Ever.

2. The PKs should be generated and shared between the developers, or only on the lead's machine used to build the final assemblies. The latter is more secure.

Share this post


Link to post
Share on other sites
I don't know exactly what I want to do with strong signing. It's a pain and I don't particularly like the idea. SlimDX isn't really meant to be GAC installed either. On the other hand, a couple people do want it signed, as their apps demand all its libraries should be strong signed.

It's fairly akward, all in all. I'm considering simply delay signing it and letting people do the final signature at their leisure.

[Edited by - Promit on August 12, 2007 6:31:46 AM]

Share this post


Link to post
Share on other sites
Ok, we've reached a decision on the signing stuff. All SlimDX binary releases from here on out will be strong signed. However, no strong signature support of any kind will be added to the source repository, because this causes a lot of problems. Those of you who wish to produce a signed assembly from the Subversion repository will need to do it yourself.

It makes things akward for those of you who are bleeding edge but still want strong signatures, but I think it's the best compromise available, given that strong signing is not particularly cooperative with the development model we want to use.

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Ok, we've reached a decision on the signing stuff. All SlimDX binary releases from here on out will be strong signed. However, no strong signature support of any kind will be added to the source repository, because this causes a lot of problems. Those of you who wish to produce a signed assembly from the Subversion repository will need to do it yourself.

It makes things akward for those of you who are bleeding edge but still want strong signatures, but I think it's the best compromise available, given that strong signing is not particularly cooperative with the development model we want to use.


That is exactly how it should be. Basically the signing says "Hey, this is from us." That is how I do my own code, I sign my binaries and leave the source unsigned. It's a fair compromise in my opinion.

Share this post


Link to post
Share on other sites
does SlimDX have the the functionality to be able to compile shader fragments and link them? In particular im interested in doing this from a resource.

If there is a better way of doing this, then I can change since I havn't written the code yet.

Share this post


Link to post
Share on other sites
Quote:
Original post by Override
does SlimDX have the the functionality to be able to compile shader fragments and link them? In particular im interested in doing this from a resource.
Not yet, but it's something that will be added in the near future. Effect was much higher priority, but that's basically finished at this point, so the low level shader stuff can be filled out now.

By the way, I just wanted to point out that there is a frequently updated release notes page. You can use that to keep track of what's going on without having to watch progress on a per-commit basis.

Share this post


Link to post
Share on other sites
Quote:
Original post by Alpha_ProgDes
Quote:
Original post by ViLiO
Quote:
Original post by Alpha_ProgDes
I would be nice to at least see some setup code (you know the one that displays a triangle on the screen). Just so the newcomers can see it. I don't see the harm in it. Since it's a wiki, other people can post code and API documentation on what functions and classes do. Correct?
One of the sample apps is exactly that, a single coloured triangle, or do you mean have that code also posted on the wiki so users don't have to download it to see it? [smile]


Yes that's exactly what I mean [smile] Screenshot too [smile]
I find the idea kind of absurd and not that useful. But I did it anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by tonyoto
SlimDX is great! Just wanted to ask if Vector3.Transform() will find its way in?
I'm surprised we missed it, considering TransformCoordinate and TransformNormal are in there. I'll drop it into the code now, although I'm not sure when the next binary build will be.

Share this post


Link to post
Share on other sites
Maybe I'm dumb and missed it, but are there Plane building functions like D3DXPlaneFromPoints(), or plans to add them?

Fantastic wrapper by the way, thanks for all the hard work.

Share this post


Link to post
Share on other sites

This topic is 3706 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.
Sign in to follow this