# Thread: Determining what the mouse is over

1. ## Determining what the mouse is over

Hello, I'm new to the boards and new to game programming, though not new to programming itself (at least in an amatuer capacity). I and my friends are quite the board game fanatics, but often lack the time or sufficient people to play face to face. I have decided to give a go at programming some board games to help alleviate the addiction

I think the best idea is to develop a generic library of routines to create generic objects common to all board games as well as an engine to control them and handle input from the user, passing this information along to game specific code. I am hitting my head against a brick wall on how to handle determining what object the mouse is over (for mouse-over info) and where the mouse clicked for either activation or placement.

This kind of thing is trivial for something like chess with only 1 item per "area" and all areas are regular polynomials. But for most board games multiple pieces can be in an area, and most of the time the areas are not regular. I just can't figure out a good method for determining where the mouse was clicked in odd shaped territories. The game of risk is a classic example of this. I know this problem is probably trivial one and easily solved since I've seen computer risk games that are 20+ years old.

Any help in the right directions or links would be much appreciated.

Tony

P.S. heh this board group is helping me already just stating the problem and giving the example of chess made me thing of making multiple squares of various sizes that "mostly" fill odd shaped areas (esp since most people won't be clicking on the edge of places to stress test the game ). If this is a common solution ignore this post, if there are better ways I'd be glad to hear them.

2. Well thats a manner of collision detection.
I have two ideas to solve this:

1. Create a *.bmp mask for a strangely shaped field.
Black pixel should be on the place you can click.
And when you get x and y of mouse click, compare the color
of the pixel on location(x + bitmap.x, y + bitmap.y) to black.
so you know if the field is clicked or not.

2. This is more complicated way:
If the field shape is somehow defined with lines, You can test
if the mouse is inside the shape by comparing the mouse x,y
with all the defined lines. This procedure is a bit complicated,
so search it on the web.

3. And by all means don't use polynomials. For the most part take the math you've learned and dumb it down some for the computer. Collision boxes and hit boxes are normally just that - boxes. Either that or you can use spheres. But sphere's suck for this because when a sphere is off, it's way off.

4. Originally Posted by Bubba
And by all means don't use polynomials. For the most part take the math you've learned and dumb it down some for the computer. Collision boxes and hit boxes are normally just that - boxes. Either that or you can use spheres. But sphere's suck for this because when a sphere is off, it's way off.
But what about shapes like country's and stuff, The only solution is masked bitmap!

5. You can use a rectangle bounding box and if the user clicks within the box then go on to do a pixel perfect collision check.

6. Originally Posted by Quantum1024
You can use a rectangle bounding box and if the user clicks within the box then go on to do a pixel perfect collision check.
agree

7. What about defining the objects as polygons and doing a point in polygon test? I learned a clever one a couple days ago where you go up from the point you're testing and you count the number of times you cross an edge. If it's odd, you're inside. If it's even, you're outside.

8. Yeah but to determine if you've crossed an edge you either have to use the screen information or you must mathematically describe the polygon using lines. This comes down to nearest point on a line intersection test and for complex shapes, this would be ultra slow.

9. I don't think it would have to be that slow. You can make a lot of assumptions about the intersection test because one line is vertical. You could roll like this:
Code:
intersectionCount = 0;
for (i = 0; i < poly.numLines; ++i) {
j = (i+1)%poly.numLines;
if ((mouse.x - poly.vert[i].x) * (mouse.x - poly.vert[j].x) < 0) {
slope = (poly.vert[j].y-poly.vert[i].y)/(poly.vert[j].x-poly.vert[i].x);
testy = poly.vert[i].y+slope*(mouse.x-poly.vert[i].x);
if (testy > mouse.y)
++intersectionCount;
}
}
That's linear, and I'm pretty sure it would work.

10. As I said, slow. What if poly.numLines is somewhere in the range of 5000? You going to test against every line even though you might be light years from it? Not good.

11. I still don't think it would be that slow. Unless you're testing polygons that go back and forth across a potential vertical test line lots of times, you won't be running the calculations that many times because the algorithm tests to see that the edge has x-coordinates on both sides of mouse.x before it does most of the math. Also, you're only running this on mouse click events, so it's not like you're losing time on every frame. Finally, you could use something like a bounding box test across all of your polygons first to figure out which ones need to be tested with the good test.

12. That is slow, And is complicated to make and understand!
I mean mask can be just a file with *.txt and contain:
100100101010
001100011001
And is faster.