Selecting an Object On Screen, any tips?

Started by
1 comment, last by Butabah 12 years, 9 months ago
I have squares just littered around my screen, and would like to be able to use my mouse to click on a certain one.

My plan was to iterate through a list of all currently visible objects (done in C++) and match the X and Y coordinates (can't click on one behind another)

Does anyone have a better way that they do this, or point me in the direction of some reading that I may do?
Advertisement
Yeah, loop through the squares and see if the mouse overlaps. Keep track of the nearest one. At the end of the loop, you know what was clicked on. Sounds good.

You have to define what 'better' means. There's lots of opposing ways to make something 'better', and making it better in one direction almost always means making it worse in some other direction.

If you want it "better" in terms of minimizing the number of squares you have to test against the mouse, there's several things you can do. One way is to split the screen into a coarse grid and have a list of squares per tile. Then you get the tile the mouse overlaps and only loop over those squares.

You could organize the squares into more complicated structures like quadtrees, etc. to minimize the number of intersection tests.

There's other ways you could want it to be 'better'. Maybe you want the algorithm to be more paralellizable so you can run the algorithm across multiple cpu cores. In that case I would split the squares into batches, and hand each batch off to a core. Each core will find the 'best' match out of their set. Then take that reduced number of squares and find the best out of that.

Maybe you want it 'better' in terms of memory usage (minimized). Maybe that means you store the rectangles in a compressed format in memory. That may end up having a profound impact on the speed at which you can iterate over and do the intersection tests, but it will take up less memory.

Yeah, loop through the squares and see if the mouse overlaps. Keep track of the nearest one. At the end of the loop, you know what was clicked on. Sounds good.

You have to define what 'better' means. There's lots of opposing ways to make something 'better', and making it better in one direction almost always means making it worse in some other direction.

If you want it "better" in terms of minimizing the number of squares you have to test against the mouse, there's several things you can do. One way is to split the screen into a coarse grid and have a list of squares per tile. Then you get the tile the mouse overlaps and only loop over those squares.

You could organize the squares into more complicated structures like quadtrees, etc. to minimize the number of intersection tests.

There's other ways you could want it to be 'better'. Maybe you want the algorithm to be more paralellizable so you can run the algorithm across multiple cpu cores. In that case I would split the squares into batches, and hand each batch off to a core. Each core will find the 'best' match out of their set. Then take that reduced number of squares and find the best out of that.

Maybe you want it 'better' in terms of memory usage (minimized). Maybe that means you store the rectangles in a compressed format in memory. That may end up having a profound impact on the speed at which you can iterate over and do the intersection tests, but it will take up less memory.


Thanks for your input!

I'll be doing some research and see which methods suit my needs the best, right now the iteration works, but I'm afraid of memory drops once there's alot of items on screen.


This topic is closed to new replies.

Advertisement