0

Hi I am currently using a modified version of spatial hashing algorithm written by Christer Bystrom. This algorithm is OK for collision detection. However when I use it for detecting entities in interested range it has its limits.

I use a huge map. (10000 x 10000 pixels) When I am moving my player, I expect to see what are around my player on the screen. Sometimes some entities are right in front of me or just behind me but I can't see anything on the screen until I get really close.

Here is a visual demo I created for that algorithm. I modified it to work with circle objects. In the demo picture I have already set the powerOfTwo attribute to 9, which is pretty big. The green circle is my mouse position. The red circles are those entities within my player's interested area. But this is not a good solution. The player should be able to see things on all directions around itself and stretch out further to about the same size of the rectangle area holding those red circles.

So I am looking for a better solution out there to implement in my game. I hope it is accurate and fast for detecting entities within interested area, and better not too hard to understand. It can be any other way (quadtree, dynamic tree, RTree or whatever fits the type of game I am making). I have also read about this, but not sure if those methods work well with interests management.

visual demo figure

newguy
  • 255
  • 2
  • 11

2 Answers2

1

Generally with a spatial hash, you will have to grab stuff from more than one cell. This is because even if each cell is larger than a screen width, you could always be close to the edge of your current cell. If each one is larger than a screen width, you could pull the nearest 3x3 cells, and if not, you'll have to loop through "all visible cells" for example like the pseudocode below

for (var x = player.pos.x - screen.width /2; x < player.pos.x + screen.width / 2 - cell.width; x += cell.width) 
    for (var y = player.pos.y - screen.height/2; y < player.pos.y + screen.height/ 2 - cell.height; y += cell.height) 
        // etc etc
Jimmy
  • 9,019
  • 1
  • 30
  • 44
1

The library you're using should do what you want. I tried it — demo here, with the default power of two setting (5):

demo of spatial hash library

You have to specify the “area of interest” in the retrieve function. The library wants retrieve to take a rectangle, so pass in a rectangle centered on the player.

amitp
  • 6,036
  • 3
  • 27
  • 41
  • UPD: I chose this as the answer as it does not only correct my mistaken use of the spatial hashing library, but also gives more insight about the related topic in the blog. So based on your research on the comparison of the two methods on your blog, do you suggest I use a rbush spatial hashing algorithm? – newguy Jul 26 '17 at 14:42
  • Grids are often good and if you have them working I'd stick with them. Run the profiler and see if it's a bottleneck before spending time on other libraries. There's a nice article comparing algorithms that says “it is important to remember that when grids work they are effectively optimal”. The article lists some conditions for grids to be good. If your project does not match those conditions, then yes, consider using the rbush library or some other spatial partitioning system. – amitp Jul 28 '17 at 21:32
  • Thanks I've got rbush working in my game. But RTree is more difficult to understand than simple grid so I just hope there isn't any problem later in case I need to change anything. I expected rbush to have some performance improvement because in theory the area of interest in grid-based approach is bigger than that of RTree approach. But I don't feel very obvious change. I have to admit the RTree approach is much more preciser than grid-based approach and it doesn't have the small issues I have in grid-based approach I used before. – newguy Jul 29 '17 at 02:04