   [SlimDX]Usability questions
  Gentlemen,I need a 64bit DirectX C# layer, so I've been looking at SlimDX. Thank you very much for providing this. I've gotten some sample code to run 64bit thanks to your library. Along the way, there were numerous lines of code that needed changing, and I wondered what reasons you had for choosing explicit Get/Set functions over properties:Managed DX:device.RenderState.CullMode = Cull.None;device.RenderState.Lighting = false;device.RenderState.ZBufferEnable = true;SlimDX:device.SetRenderState(RenderState.CullMode, Cull.None);device.SetRenderState(RenderState.Lighting, false);device.SetRenderState(RenderState.ZEnable, true);Is the former something you'd object to having in your tree if I added it?Jamie   
  I've not used SlimDX yet, but from what I've read on here it's meant to act as a *very* thin layer between managed code and DirectX.  Looking at it from that angle, I'd say they're aiming to keep all functions/constants/etc as similar as possible to the DirectX equivalents.  This has a couple of advantages:1) Someone new to SlimDX but familiar with DirectX should be able to pick it up and run with it without touching the documentation.2) They can be lazy and point everyone at the DirectX documentation [smile];  Yes, we would reject the incorporation of that patch, for three reasons.First, we consider the property method inferior to the function-and-constant method, as the latter is more flexible in terms of more abstracted state management systems, which typically set large quantities of render states programmatically. The method we've chosen to implement allows this kind of programmatic acccess to be reduced to loops, whereas the property method involves either extensive reflection hacks or careful branching. In the degenerate case where no higher-level abstraction is built on top of SlimDX, our method is only slightly more involved in terms of typing than the property method, which we do not consider important.Second, and more critically, our conventions stipulate that we will never allow properties to fail and that properties should be relatively "trivial" operations. Since the unmanaged methods backing most of the things we could make properties are "get/set" functions returning HRESULTs, they might fail or be costly. Properties also cause some pain when the property has to return some more involved object that isn't just a state enumeration, as we have atypical rules for object ownership and disposal.Finally, prefering methods to properties keeps our interface aligned more closely and comfortably with the native interface.   ;  Ok, good answers :-) Thanks.;  Question about direction/purpose. SlimDX seems to be about providing a slim layer on top of DirectX for managed applications. However, the work in Math (Ray, BoundingVolume etc), indicates that SlimDX is growing beyond this.I'm aware that one of our options is just forking the whole thing. Is there the possibility of splitting SlimDX into SlimDX and FatDX, with the non-essential stuff in FatDX?Jamie   ;  My understanding is far from the official word, but I believe that the math stuff is simply meant to be the rough equivalent of the DirectX utility library D3DX. Its stuff practically everyone needs, and for those few who don't need it, there's little harm in it being there.Only bad things will come from forking two distinct versions of SlimDX. Perhaps the math utilities could be separated, that might make more sense, but I don't know if the maintainers would feel that it makes enough sense to be worthwhile.What would be the point/benefit to forking in your mind?   ;Quote:What would be the point/benefit to forking in your mind?A few reasons:1. Our code is currently all MDX. An MDX-like wrapper would ease porting for us.2. Our design philosophy is quite different. We do Test Driven Development. You will have difficulty finding a single "static" in our entire codebase. Everything is interface based.3. We are a commercial entity, and we'd like to reduce risk.4. Not having to merge stuff that we don't need. 5. We aren't a games company...That being said, I liked Josh's arguments for not exposing certain features as properties. I do not wish to suggest that our design philosophy is *better*, only that it is different, and what we are used to. We are also willing to sacrifice a little speed, to gain a lot of design flexibility, hence our use of interfaces everywhere. For example, an ITextureLoader interface can be implemented using mock objects for test, while the real thing takes, what, 5 extra cycles to redirect, when the actual load takes 8ms just to move the drive heads...;  At this point we are hard-pressed enough as it is to keep up with bugs/feature requests and still have time to add in new stuff. Adding an extra layer just to parallel MDX would not only be wasting a large amount of that time, it would also be detrimental to the library itself, as the design of MDX was not that great.Personally I don't think the porting differences between the two are huge, but I will grant you that the code probably needs to be rewritten line-by-line. While it would be nice to make it an easy port, doing so cripples the library for future development, and turns out products like C++.;  Indeed; while we intend to fulfil a goal similar to that of MDX, we aren't trying to be the same API. We don't have the resources or, I'd bet, the inclination to make an official fork and maintain that -- although there is no reason you couldn't do something similar internally to wrap our function-based methods with your custom interface that allowed property-based access, which may allow you to use SlimDX with less effort for the intial port, depending on what your code actually looks like.   