Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Feb 2007
Offline Last Active Apr 16 2012 01:30 PM

Posts I've Made

In Topic: [SlimDX] D3D11 From D3D9

30 October 2011 - 12:44 AM

Regarding camera controls: You apply matrices to your shader with code along the lines of DXEffect.GetVariableByName(name).AsMatrix().SetMatrix(someMatrix); . In your shader code, you have a matrix defined with a certain name, and that applies the value you want to it. I can't really go into a lot more detail, it sounds as if you really need to look up some tutorials. Shaders are somewhat complicated to get into at first, but god, I love them. The fine degree of control they give over everything is amazing.

Regarding your comment about Device.ImmediateContext.Rasterizer.State, I haven't used Direct3D11 yet so can't help you with that one. The API of Direct3D10 and 11 are pretty much identical, but 11 lacks some high level features I don't feel like implementing, and I don't have a directx 11 capable video card anyways.

Here's my recommendation: check out XNA if you haven't already. It sounds right up your alley. It has the simpler .net-esque api you want and is a LOT quicker to get into. It still requires that you use shaders, but it provides a basic one with lighting effects and such, so you won't need to worry about learning much about them right away. I avoid XNA nowadays because I always feel it's forcing me into a particular design paradigm and I prefer having a finer degree of control, but these are personal preferences and I otherwise highly recommend it.

In Topic: [SlimDX] D3D11 From D3D9

29 October 2011 - 02:18 AM

1) The most important difference to know is that Direct3D 10 and 11 lack the fixed function pipeline. That means that many things that were previously done for you have to be done in shaders. You've encountered the first example of this: you have to pass the matrices to your shaders.

2) Another difference is that states are now set in bunches. So for example, you set all of the rasterizer states at once with Device.Rasterizer.State. Lighting is another fixed function pipeline feature that you need to implement in shaders

3) Look up InputElement.

I'm working with Direc3D 10 for the first time, and I love it. However, you're going to find SlimDX documentation and samples for it limited. Fortunately, it's not so bad because the SlimDX api is deliberately close to the native API, so it's trivial to look at c++ code.

In Topic: SlimDX, DirectX 10 sprite woes.

06 July 2011 - 10:31 PM

Thanks, I can't believe I didn't think to try that.

Interestingly enough, the sprite is visible if I use Matrix.OrthoLH instead of OrthoOffCenterLH. Why, I'm not sure. And even though the sprite is visible, the behavior doesn't match what I read in tutorials (specifically the sprite section of Beginning DirectX 10 Game Programming). For example, with the projection matrix set to OrthoLH(800, 600, -1, 1), the viewport set to (0,0,800,600, 0,1) and the transformation matrix set to (Matrix.Scaling(100, 100, 1) * Matrix.Translation(400, 300, 0)), the sprite should appear in the middle of the screen, but appears at the extreme upper right. The size of the sprite seems correct, while the position is not.

Time for further experimentation.

edit: using Matrix.OrthoOffCenterLH(0, 800, -600, 0, -10, 10); produces working results. The origin is the upper left, and the sprite moves down by decreasing Y in the world transformation, and moves left by increasing X. This works fine, but doesn't match the behavior I expected from my readings. Oh well, it works.

In Topic: SlimDX, DirectX 10 sprite woes.

04 July 2011 - 07:43 PM

Bumped for going onto the second page without even getting a view...

In Topic: C++ C# interop

19 February 2011 - 04:09 AM


Is there any SIMPLE way to use my c++ engine in c# (winforms)?
I don't wanna rewrite my engine. Instead of lots of c++ work, i rewrite it in c#... So I'm looking for the simplest solution. Now, i use lib, but if it is necessery, i can use dll, like this:

class __declspec(dllexport) Sprite : public GameComponent


No, there isn't a simple way to do it.

If you're working with windows alone, c++/clr is probably the easiest way to go.

If you're working with linux, you need to wrap it in a c glue library and create bindings to it in c#.

Both of these are time consuming, but that's the price you pay when trying to interop radically different languages.

There are utilities to create a glue library, though I'm a bit behind the times and couldn't recommend a current one (I haven't used anything but c# in a looooong time). Last time I did this. SWIG was the way to go, but it was still tedious and error prone.