You need to check:
1 grid... when no overlapping
4 grids... when overlapping occours and dimension of object are smaller than height or width of grid-cell
up to 9 grids.. when the dimension of this object is bigger in height or width.
This may happen if there are really rare but big objects in the scene... instead of making the grid-cells bigger you may compute these objects in a special way. Otherwise the many small objects will produce bigger lists to compare against.
As I also don't really know things about bit-shifting:
---
SHR (from a basic dialect, dunno if its nearly the same - 5 bits - in BMax)
Reallocates bit-by-bit to the right. The least significant bits are lost. The zeros are incorporated subsequently in the most significant bits. Only the 5 least significant bits from <number> are always considered with the values of <number> being located between 0 and 31.
SHR relays an unsigned integer division with powers of two ("X SHR Y" corresponds to "X\(2^Y)").
---
Short example:
81 SHR 3 = 81 / 2^3 = 81 / 8 = 10 (like a ceil(result) used)
87 SHR 3 = 87 / 8 = 10
88 SHR 3 = 88 / 8 = 11
So I assume that the shift does:
The find_sector is a global based on a calculation with the gridcell-size (eg. 32) - in this case the variable is 5.0000 .
If object.X is 103 and your gridcell-size is 32 then: Objext.x SHR find_sector
This is the same as: 103 SHR 5 ( ceil(103 / 2^5) = ceil(103 / 32))
Result will be 3 ... the coordinate x=103 lies in grid[3,y]
Remember that grid[0,0] exists (zero based start).
Assuming this, you can say that bitshifting is a shortcut to ceil a variable ... It's a useful thing like MOD.
So it may be also possible to calculate the correct grid by:
GridX = ceil(Object.X / gridsizeX)
But when the SHR-command is used, we can nearly be sure that it's done for the thought of speed improvement.
Hope I'm not totally wrong... if it's correct, I learnt something ;D.
bye
MB
1 grid... when no overlapping
4 grids... when overlapping occours and dimension of object are smaller than height or width of grid-cell
up to 9 grids.. when the dimension of this object is bigger in height or width.
This may happen if there are really rare but big objects in the scene... instead of making the grid-cells bigger you may compute these objects in a special way. Otherwise the many small objects will produce bigger lists to compare against.
As I also don't really know things about bit-shifting:
---
SHR (from a basic dialect, dunno if its nearly the same - 5 bits - in BMax)
Reallocates bit-by-bit to the right. The least significant bits are lost. The zeros are incorporated subsequently in the most significant bits. Only the 5 least significant bits from <number> are always considered with the values of <number> being located between 0 and 31.
SHR relays an unsigned integer division with powers of two ("X SHR Y" corresponds to "X\(2^Y)").
---
Short example:
81 SHR 3 = 81 / 2^3 = 81 / 8 = 10 (like a ceil(result) used)
87 SHR 3 = 87 / 8 = 10
88 SHR 3 = 88 / 8 = 11
So I assume that the shift does:
The find_sector is a global based on a calculation with the gridcell-size (eg. 32) - in this case the variable is 5.0000 .
If object.X is 103 and your gridcell-size is 32 then: Objext.x SHR find_sector
This is the same as: 103 SHR 5 ( ceil(103 / 2^5) = ceil(103 / 32))
Result will be 3 ... the coordinate x=103 lies in grid[3,y]
Remember that grid[0,0] exists (zero based start).
Assuming this, you can say that bitshifting is a shortcut to ceil a variable ... It's a useful thing like MOD.
So it may be also possible to calculate the correct grid by:
GridX = ceil(Object.X / gridsizeX)
But when the SHR-command is used, we can nearly be sure that it's done for the thought of speed improvement.
Hope I'm not totally wrong... if it's correct, I learnt something ;D.
bye
MB