dAND3h

Equally, you can rotate "the object you are moving" 's UP vector until it points in the same direction as the terrains normal. Then do a cross product on the new UP vector and the right vector, which will give you the look vector.

You need to think about how you will lay out your engine. A basic structure can be:

Particle Engine---has many-->Particle Emitters---has many--->particles. You will want to create a method by which you send chunks of the number of particles to the graphics card at once, to save draw calls.

For the actual particles, you need to think about what attributes you would like for the emitter. Max particles speed, colour, and of course texture. etc.

If you want to make an efficient GPU based particle system, you will do world calculations inside the shader. This includes scaling,translation and rotations. For instance, you can create a simple particle trajectory with a start time and velocity.

position = (currentTime - startTime)*constantVelocity

Where startTime is passed into the vertex shader from the application.

You can also manage to pass just the centre position of the starting particle into the shader, and transform each vertex of the quad using that position and the UV coordinates.

As for tutorials, I have yet to see a satisfactory one. Most seem to fly past important topics without discussing them.

Just keep it as simple and practical as possible at the beginning. When I did a simple 3D level editor(simple as in 1 weeks work) I made sure It was a completely separate entity to my game. Therefore, the only thing I needed to do was to decide how I was going to store the data, so I could parse it accordingly when my game loads the level. It did however use alot of the code from my game, most notably the render and input code, with modifications to suit the editor;

Because I had such a short amount of time, I decided to limit the artists abilities to just translate,scale and rotate objects. I also decided to leave out the ability to add textures in the editor. I believe as a starting point, this is what you should aim to do.

You would have to make a decision as to whether or not you want to load the models from within the program dynamically, or to load them before hand. Clearly the dynamic option would be more use to the artist, as they wouldn't need you to dig around the code to load another model, but as a start, the pre-load method is adequate.

For ray-casting, you need to make sure you are only casting inside the "viewport" where your scene is being rendered. Otherwise, you will end up with a bogus cast because of the mouse position taking the entire window into account.

As pointed out above, it seems as though you are rendering and updating for each particle! Think about that and you will see why it will slow down. If you have 10,000 particles, each one has to create a new transformation matrix (10,000+ operations) and each one will render itself separately(10,000+ draw calls).

Most modern particle systems use the GPU for both rendering and calculating positions. And then some sort of particle collision system on the CPU. Using the GPU , you will then batch alot of particles together, in a DynamicVertexBuffer which will be sent to the graphics card at once! Turning 10,000 draw calls into maybe 2 or 3!
You should post both the CreateNewParticle and RenderParticle methods.

I don't get this line: "

With my ultimate goal of being able to implement my

own

game ideas"

Why does that stop you from using C++?

Well, seeing as Unity is the only thing you listed which is actually an Engine, I say go with that!

All seriousness though, Apparently, XNA is on the chopping block to be discontinued, as of Windows 8 there will be no more support for it.
Unity3D(lite) is all the rage at the moment for indie developers anyway, kind of depends on what you want to do.  Unreal is always an awesome engine.

Wow, I doubt I could be more unhelpful to your original question if I tried, sorry!

Ye, it is probably a depth buffer problem. If you do not enable the depth buffer, things will get drawn in the order which they were added to Components, and NOT on their order in 3d space.

Set
GraphicsDevice.DepthStencilState = DepthStencilState.Default; at the start of your draw method.

Normally when you cant see things being drawn, it is to do with the depth buffer. Without the depth buffer enabled, components will be drawn in the order they were added to the component list and not their order in 3d space. I cant say for sure, because I don't know how you coded it, but just try enabling the depth buffer before you draw the primitives.
So, inside the draw method, set :
GraphicsDevice.DepthStencilState = DepthStencilState.Default;

And if your not already, you should draw any 2d sprites AFTER you draw your 3d models/primitives. So put the spriteBatch.Draw() after the call to base.Draw() in your draw method.

Well, first of all, you need the direction you want to turn to.
So, you have a Vector3 Position of the object you want to face.

desiredDirection = ObjectPosition - planePositon ;
//Ok, so you have the direction you want to face, now we need to recalculate our other direction vectors
Right = Vector3.Cross(Up,desiredDirection);
//We need to normalize this
Vector3.Normalize(ref Right, out Right);
//then get the new forward/look Vector
Forwards = Vector3.Cross(Up,Right);
//normalize again
Vector3.Normalize(ref Forwards,out Forwards);
//then we need the new Up vector
Vector3.Cross(Right,Forwards);

//Now comes the fun part. We need an homogenous Matrix to represent this transformation around 3 different axis simultaneously. So it will be a 4d //matrix like so:
Matrix rot = new Matrix(Right.X,Right.Y,Right.Z,0, Up.X, Up.Y, Up.Z, 0, Forwards.X, Forwards.Y, Forwards.Z, 0, 0, 0, 0, 1);

//As you can see, the last dimension has no translation.

//If you then just multiply your world matrix with the matrix you created here, your plane should turn to face your object.

Hey, I am looking to implement some collision detection for my 2d "engine". I came across collision masks while googling. It seems like a really good idea, the problem is, I do not fully understand how to make/implement it. This is what I understand so far:
1. I create my level using paint or whatever.
2. Then what I do is create a new layer, and draw for example, a straight black rectangle over the ground. I then delete the original level layer so I am just left with the black rectangle.
3. Load the map and mask into separate SDL_Surfaces.

But after this is where I do not understand what to do! I have some questions that I would be grateful for an answers:
1. How do I actually test the collision?
2. Do I have to iterate through each pixel in the mask and then check the colour of the pixel?
3. How do I set a different type of collision on a different colour?(I'm guessing I just do some check like: if(pixel is black) COLLISION_TYPE = ground)...but that seems wrong?
4. Do I have to iterate through the entire mask every time through my game loop? Which would mean iterating through each pixel?
5. How would I apply a mask to a moving surface, such as my player character?

I am sorry for being so noob but this is really hard to understand. Please can somebody try to answer these questions. Thanks