Develop Reference

Xna keeping player from overlaping parts of map

I had an idea in my game of having 3 layers to the map, the first being the ground, the second being the roads/grass/etc, and the third being impassable objects such as walls/buildings/lakes/rivers/trees. I have it so the player is centered at the middle of the screen and the layers of the map move in the inverse direction that the player wants to go. I was thinking I would have the different layers that way if the playerModel overlaps whereever something is drawn on the impassableLayer, then the playerModel would shift back. However, as I am new to xna, I don't know how to get the game to recognize that the playerModel is overlapping the impassable objects on the impassableLayer. The impassableLayer obviously only has objects drawn on it, and is empty anywhere there isn't an object. Therefore I can't just say:
if (playerModel.X > impassableLayer.X)
{
impassableLayer.X++;
}
As this would always be true.
Is there a way to tell if an object is overlapping a layer?

What you are looking for is collision detection I belive. You want to keep objects from passing through each other. It isnt as simple as the idea you had. True collision detection will take alot of work, but their are tons of tutorials for it.
Youtube tutorial on per pixel collision
Per-pixel collision on MSDN
Bounding Box Collision
You can always to a search here on the site or google, there are lots of resources for this out there.

WPF: Finding 3D-visuals that are partially inside a 2D rectangle

I am making a WPF program with the possibility to modify data graphically in 3D. In order to give the user the option to select multiple graphical objects at the same time, I want to implement a selection rectangle. (Just like the one in windows explorer.) A common functionality in programs like this one is to have 2 different functions for the selection rectangle, and that the user can somehow choose which of the methods should be used.
Any object that is partially or completely inside the rectangle is selected.
Only objects that are completely inside the rectangle are selected.
The 2nd method is straight forward by using the bounding box of each object, and check if it is inside the rectangle. The 1st one on the other hand, seems to be quite some work. All my graphical objects are complicated 3D figures, and can be rotated by the user in any way. At the moment I am unable to find any other way than checking if any of the triangles in the mesh of any of the objects cross my 2D rectangle, and that can be quite time consuming.
I have little experience with WPF 3D, but I have done this before in OpenGL. Then I could tell OpenGL to draw a specific area of the screen, and the collect a list of objects that was visible in the specific area. All I needed to get the functionality I wanted was about 5 lines of code.
I guess my question is this:
Is there a way to do this with WPF 3D, similar to the OpenGL approach?
If not, is there any other smart way to find all objects (Visual3D) in a viewport that is partially behind a 2D rectangle?
I refuse to believe I am the only one with this kind of problem, so I hope a clever mind can point me in the right direction.
Regards,
Sverre
Thank you for your answer!
The 2D-rectangle is just in front of the camera and extending infinitely forward. I want to get any object that is partially or completely inside that frustum.
The camera we are using is an orthographic or perspective projection camera (System.Windows.Media.Media3D.ProjectionCamera). The reason we are not using the matrix camera is that we are using a 3rd party tool that does not support the matrix camera. But I am sure there is a way to get the matrix from a projection camera as well, so that is hopefully not the problem.
In theory your solution sounds like just what we need, but I am not sure how to proceed. Do you have any links to sample-code, or can you give some more hints on how to actually implement this?
Btw: Since we are working with WPF, we do not have direct access to DirectX. At least that’s what we have concluded after some research. You mention use of the z-buffer, which we haven’t been able to access through WPF. If you know a way to access the z-buffer, it’s greatly appreciated! This is of-topic, but we have struggled to disable the z-buffer for some time, but have given up…
Best regards,
Sverre

Is your intersection region a 2d rectangle or a frustrum based at a 2d rectangle and extending infinitely forward (or perhaps to some clipping limit)? If it can be construed as a viewing frustrum, then you can leverage the existing capabilities of the graphics system to render the scene using a Camera View and Projection that corresponds to your originating rectangle, with all lighting and shading disabled and colors chosen specifically to 'tag' the different objects in your scene. This means you can use the graphics hardware to perform the clipping/projection as a 'rendering' operation, then simply enumerate the pixel values as 'tags' to determine the objects present in the rectangular view.
If you need to restrict selection to an actual 2d slice (or a very shallow frustrum), you can use the Z-buffer (if you can get access to it) to exclude tagged pixels that are outside the Z range of your desired selection frustrum.
The nice thing about this approach is that you probably already have the Camera matrix (it's the same matrix used for your window for selection) and only need to change the Projection matrix to be a sub-set of the viewing window.

A 'smart' way would be to transform the rectangle into a box using the Camera's matrix
And then do a intersection of all the objects and the box.

Collision Detection for arbitrarily sized, positioned and rotated rectangles in XNA

I'm working with xna in C# and in my game I will have a variety of space ships flying all over the place. They will each have an arbitrary rotation, size and position in space and I need a method to determine when they collide. Ideally the method would take two Rectangles, two doubles and two Vector2s for size, rotation and position respectively and return a boolean that indicates whether they have intersected or not.

Have a look at these links:
Collision Detection Overview
Collision Detection Matrices
Putting Collision Detection Into Practice
They show you a way to do pixel-based collision detection, which is more accurate than rectangle-based for irregularly shaped objects.
Update 2021-01-17 (Martin Senne)
Links of XNA have moved to
XNA
XNA - Collision

You could also consider just using an out of the box solution for this and integrating something like the Farseer Physics Engine:
http://farseerphysics.codeplex.com/

These rectangles you describe are called OBB (Oriented Bounding Boxes)
The way to do collisions between them is using the 'Separating axis theorem'
A really nice page describing it in detail with lots of pictures can be found here

Animations in a 2D C# XNA game

I want to create a 2d game in C# using XNA. There should be stickmen who can wear different weapons like a pistol, a grenade or a rocket launcher. And those stickman also should be able to do other things, like drink a bottle of beer and stuff.. So how do you create and store these animations (drink a bottle of beer, walk, throw a grenade) and how can you tell them how to hold a weapon (pistol: in the hand, grenade: in the hand, but holding the arm behind them, rocket launcher: on the shoulder)? What's the best (simple and extensible) approach to this?

For stickmen, comes to my mind, skeletal animations with directly rendered bones. Such vector graphics would scale very well compared to sprites. Skeletal animation stores a tree of bones with lengths and angles, and interpolates between predefined keyframes. The advantage of this is that you can easily incorporate some simple physics and inverse kinematics that blend with the animations (take a look at Jakobsen excellent Verlet dynamics paper) for holding weapons, beer cans and mantling ledges, etc. This is fairly advanced stuff, much easier than 3D graphics, but it will still take you a long time to design and implement.

One thing that can help when compositing sprites (giving a hero a sword, etc) using SpriteBatch is the Origin argument on some of the Draw method overloads. It allows you to rotate around something other than the top left corner and can also help when positioning sprites that are of differing sizes. Since the Origin is specified in source texture scale, any calculations will be valid event if the sprites are drawn at a different scale.

What you're asking is a fairly broad question. You might want to have a look at the 2D Platformer sample that comes with XNA Game Studio. That can get you started.

Hiding objects that obscure the player in a 3D scene

I'm designing a 3D game with a camera not entirely unlike that in The Sims and I want to prevent the player character from being hidden behind objects, including walls, pillars and other objects.
One easy way to handle the walls case is to have them face inwards and not have an other side, but that won't cover the other cases at all.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
One probably not so good idea I had in mind is to scan from the camera to the player in a straight line and see if you hit a non-hidden object, continuing until you reach the player. Unfortunately, I am an almost complete newbie on 3D programming.
Demonstration SVG illustration < that wall panel obscures the player, so it must be hidden. Another unrelated and pretty much already solved problem is removing all three wall panels on that side, which is irrelevant to this question and only caused by the mapping system I came up with.

What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
This is a good plan. You'll want to incorporate some kind of bounding volume onto the player, so the entire player (plus a little extra) is visible at all times. Then, simply run the intersection algorithm for each corner of the bounding volume.

Finding which object is at a given point on screen is called picking. Here's an XNA link for you which should direct you to an example. The idea is that you retrieve the 3D point in the game from the 2D point, and then can use standard collision detection methods to work out which object is occupying that space. Then you can elect to render that object differently.
One hack which might suffice if you have trouble with the picking approach is to render the character once as part of the scene, and then render it again at the end at half-alpha on top of everything. That way you can see the whole character and the wall, though you won't see through the wall as such.

One easy way, at least for prototyping, would be to always draw the player after you draw the rest of the scene. This would ensure that the player is rendered on top of anything else in the scene. Crude but effective.

Create a bounding volume from the camera to the extents of the player, determine what objects intersect that volume, and then render them in whatever alternate style you want?
There might be some ultra-clever way to do this, but this seems like the pretty straightforward version, and shouldn't be too much of a perf hit (you're probably doing collision every frame anyway....)

The simplest thing I can think of that should work relatively well is to model all obstacles by a plane perpendicular to your ground (assuming you have a ground.) Roughly assuming everything that is an obstacle is a wall with some height.
Model your player as a point somewhere, and model your camera as another point. The line in 3d that connects these two points lies in a plane that is particularly interesting to you, because if this plane intersects an "obstacle plane" below the height of the obstacle, that means that that obstacle is blocking your view of the player point.
I hope thats somewhat clear. To make this into an algorithm you'd have to implement a general method for determining where two planes intersect (to determine if the obstacle is tall enough to block view.)