Read More...
Read More...
Comments
Thanks. I've been muddling my way through porting the code from several of my DX9 books for the last six months, so I've sort of picked up some knowledge about how to work with C# and SlimDX through trial and error- but the existing tutorials are pretty sparse indeed.
As to your points:
- I may make that change to use Marshal.SizeOf, rather than calculating the size by hand, however, I still like having the constant Stride field, I think it is a little more readable.
- You are completely right, it should be a ref parameter... Although I always get a little confused about whether it is totally necessary, if you are passing objects that are passed by reference vs structs that are passed by value...
- That is definitely a gray area... I dug through the CD as well as the downloaded code, and had trouble finding any license that appeared to apply to the code rather than the book text. I'm making sure to leave the original copyright notices in, and I try to always have at least a couple links back to the book's website in each entry.
You use ref if you need to change the variable on the [i]caller's side[/i]. The original code uses a macro, that's why it can change the value without specifying a C++ reference (&).
Keep up the good work.
Argh, fixing Util.ReleaseCom() has been more troubling than expected... Unfortunately, C# won't allow one to pass a derived type as a ref parameter of the base type (see http://blogs.msdn.com/b/ericlippert/archive/2009/09/21/why-do-ref-and-out-parameters-not-allow-type-variation.aspx), so I have had to implement an override for each SlimDX.ComObject derived type that I use...
One of the legitimate times C-style macros are useful. Is there a more elegant approach that I am missing?
void ReleaseCom<T>(ref T x) where T : class, IDisposable
The automatic type inference will have no problem with that, so one does not need to mention the type explicitly.
Edit: Correction, the type restriction needs [tt]class[/tt] as well, otherwise one can't nullify it.
Ah, thank you very much, that is much better than having a bunch of overloads. I don't get much call to use generics outside of LINQ and the built-in collections in my day job. I'll have to remember that the next time I want a polymorphic ref parameter.
You're welcome. Get used to using them yourself, you will benefit - in your day job, too ;)
For instance: In your latest post you work with a MeshData. Think about how to make that a generic class (with the vertex as a generic type parameter).
Here's a [url="http://www.gamedev.net/topic/645430-texture-drawing-wrong-on-cubes/?view=findpost&p=5077664"]hint[/url].
Though, don't get too distracted about this, rather continue your tutorials. To get used to generics it helps to implement e.g. known classes like a List<T> or Set<T> (which you could test against).
Cheers
I'd like to congratulate you for this nice tutorial series, since there's still a great lack for C#. The biggest I've seen so far is the rastertek transliteration to SharpDX [url="http://sharpdx.org/forum/7-documentation/52-rastertek-tutorials-in-sharpdx"]here[/url], but that's without thorough explanation.
A couple of hints:
- One can get a struct's size with Marshal.SizeOf (you actually use it in your Util class)
- ReleaseCom should use a ref parameter, otherwise the null assignment is useless.
- Make sure you don't violate intellectual property (e.g. you provide the original shaders and model files with your git repository). Ok, one can download them easily from d3dcoder.net, but nonetheless.