   [SlimDX] 2 Suggestions
  I'm new in SlimDX, so I looked up in the samples and the docs.As you can guess, I moved from XNA(LOL) after the big disappointment that XNA 4 support only on mobile phones after I've waited for it(I guess they won't even support XP in the future. Yeh it took me alot of time to get that). Anyway, I have suggestions that I always hoped it will be in XNA:1.A vertex format as ColoredVertex in your samples, should be as interface for saving unnecessary operations:Today:Context9.Device.SetStreamSource( 0, vertexBuffer, 0, Marshal.SizeOf( typeof( ColoredVertex ) ) );Context9.Device.VertexFormat = VertexFormat.Position | VertexFormat.Diffuse;Context9.Device.DrawPrimitives( PrimitiveType.TriangleList, 0, 1 );Maybe in the future :-) :Context9.Device.SetStreamSource<ColoredVertex>(0, vertexBuffer, 0);Context9.Device.DrawPrimitives( PrimitiveType.TriangleList, 0, 1 );This will be allowed by the special new interface:public interface IVertexFormat{    VertexFormat VertexFormat    {   get;    }    int SizeInByte    {   get;    }}I'll start with the second property: You always use the SizeOf method in unsafe code, so instead, use this property as well.And the first one: Context9.Device.VertexFormat will be set from internal source instead of unnecessery exterenal source.2.Support using joystick vibration in Joistick class. You can see how to do in in C++(I didn't understoond a word there):http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.win32.programmer.directx.input&tid=2c6bed15-6328-4f2a-82a0-e10e94b76b5c&cat=〈=&cr=&sloc=&p=1I would like to hear your opinion about it.[Edited by - talhadad on April 18, 2010 9:34:50 AM]
  Personally, I'm not particularly interested in trying to clean up functionality that is archaic to begin with. You shouldn't even be using vertex formats. As for the Joystick stuff, I think we do have force feedback in there, but I have to double check.   ;  The fundamental design guideline behind SlimDX's interface is to reproduce the native API as faithfully as possible (while still maintaining appropriate managed semantics). This means we aren't generally in the business of adding additional abstraction to that API.Quote:A vertex format as ColoredVertex in your samples, should be as interface for saving unnecessary operations:Your example does not require ColoredVertex to be an interface, it requires SetStreamSource to take a generic parameter. This would also imply that VertexBuffers become strongly typed (via a generic parameter) and thus, so does DataStream and all the other related interfaces. All to enforce a less-flexible and unnecessary paradigm of using structures for vertex representation. The way the API is implemented now, you can trivially build an abstraction like the one you're describing in a few lines of code. This is not a change we'd make, certainly not for v1 (due to it being a serious API break) and not for v2, either.Quote:This will be allowed by the special new interface:ColoredVertex is part of the sample framework, not the core API. The same framework is designed to be very minimalistic and not necessarily representative of general best-practices. The idea is to have a minimal framework to illustrate a particular sample or concept from as close to first-principles as possible. Having a complex vertex format interface like this just adds noise. It also is D3D9 specific, whereas the current vertex structures are not. I see no benefit to adding this proposed IVertexFormat to the sample framework.I can't comment on our joystick/feedback support as I'm unfamiliar with it. I'll leave that to somebody like Mike who's built most of it.   ;Quote:Original post by PromitPersonally, I'm not particularly interested in trying to clean up functionality that is archaic to begin with. You shouldn't even be using vertex formats. As for the Joystick stuff, I think we do have force feedback in there, but I have to double check.I can understand what you are saying, and I know that DX don't have that interface, and it doesn't mean they shouldn't have. What I was offering, is just for make a common interface for all the vertex formats, for flexibility and for OOP(don't forget why interface was invited). The IVertexFormat, is needed for know the VertexFormat without the user intervention.A one interface won't interrupt the all code...As you mention, both of ways are easy and works. It isn't critical, but it's against the OOP. Altough I don't perfectly understand you, I will understand if you will fear it will make SlimDX more complicated.And for the joystick - I already saw the Joystick class, but I noticed(as mention) that there is no control of vibration. As you said, you can get the currect vibration by the Joystick class(via JoystickState), but you can't set the vibration by this. This is why I gave you the link for setting vibration in c++.Tanks for your answaring and sorry about my english.   ;Quote:Original post by talhadadI can understand what you are saying, and I know that DX don't have that interface, and it doesn't mean they shouldn't have. What I was offering, is just for make a common interface for all the vertex formats, for flexibility and for OOP(don't forget why interface was invited). The IVertexFormat, is needed for know the VertexFormat without the user intervention.Your "interface" is exposing a portion of the API that is not recommended for use in modern applications. It is an archaic remnant of the fixed function pipeline.Furthermore, vertex structures are supposed to be POD types to make them easily convertible to a binary blob to feed to the GPU. Interfaces tend to complicate that in ways that are difficult to predict.Quote:A one interface won't interrupt the all code...And it unnecessary. We expose the DirectX API. It is up to the user to determine how they can best benefit from that API, and provide their own abstractions.Quote:As you mention, both of ways are easy and works. It isn't critical, but it's against the OOP. Altough I don't perfectly understand you, I will understand if you will fear it will make SlimDX more complicated.OOP has nothing to do with this. This is a question of what our API should do, and as already has been mentioned: we're a thin layer wrapped around DirectX to expose it to managed code. We do not change how the API functions, and we really don't provide additional functionality that falls outside of the purview of making it easier to use in a managed context.   ;Quote:hat I was offering, is just for make a common interface for all the vertex formats, for flexibility and for OOP(don't forget why interface was invited)... It isn't critical, but it's against the OOP...The IVertexFormat, is needed for know the VertexFormat without the user intervention. A one interface won't interrupt the all code...As I said, the change you are proposing would require you to use such an interface (and thus decrease flexibility) -- unless we maintained both the generic and non-generic versions, which would just be error prone and counterintuitive. Also, it is a incorrect to assume that interfaces equate to be OO design. That's simply not true. The concept of interfaces are not, in fact, a strictly OO concept. They are an abstractive concept that apply across multiple programming paradigms. Forcing users to build structures that implement rigid interfaces provides no additional OO benefit (putting thing in classes/structs doesn't equate to "OO" design either) does not improve the design of the API at all.   ;Quote:Original post by jpetrieQuote:hat I was offering, is just for make a common interface for all the vertex formats, for flexibility and for OOP(don't forget why interface was invited)... It isn't critical, but it's against the OOP...The IVertexFormat, is needed for know the VertexFormat without the user intervention. A one interface won't interrupt the all code...As I said, the change you are proposing would require you to use such an interface (and thus decrease flexibility) -- unless we maintained both the generic and non-generic versions, which would just be error prone and counterintuitive. Also, it is a incorrect to assume that interfaces equate to be OO design. That's simply not true. The concept of interfaces are not, in fact, a strictly OO concept. They are an abstractive concept that apply across multiple programming paradigms. Forcing users to build structures that implement rigid interfaces provides no additional OO benefit (putting thing in classes/structs doesn't equate to "OO" design either) does not improve the design of the API at all.Quote:hat I was offering, is just for make a common interface for all the vertex formats, for flexibility and for OOP(don't forget why interface was invited)... It isn't critical, but it's against the OOP...The IVertexFormat, is needed for know the VertexFormat without the user intervention. A one interface won't interrupt the all code...I'm starting to understand what you said- programmers don't like to work with many classes and interface(maybe I'm an exception :-) ), so thanks for answering.And for last, did you understand what I said about the joystick vibration and would it be in the future?;Quote:I'm starting to understand what you said- programmers don't like to work with many classes and interface(maybe I'm an exception :-) ), so thanks for answering.No, that's not it -- it's just that your assertions re: what constitutes "better OO" are off-base.Quote:And for last, did you understand what I said about the joystick vibration and would it be in the future?As I said, I'm very unfamiliar with the joystick APIs and can't comment on them.   ;Quote:Original post by talhadadAs you can guess, I moved from XNA(LOL) after the big disappointment that XNA 4 support only on mobile phones after I've waited for it(I guess they won't even support XP in the future. Yeh it took me alot of time to get that).Just as a point of note, XNA 4.0 supports all current platforms (PC, Xbox 360, Zune) and in addition supports Windows Phone 7.XNA 4.0 also seems to be providing functionality similar to what you're after, check out Shawn Hargreaves latest blog post.