dt-rush / sameriver

game engine written in go
Other
1 stars 1 forks source link

lazy recalculation of spatial hash #87

Open dt-rush opened 1 year ago

dt-rush commented 1 year ago

Whenever spatial hasher gets a function call to inspect the table cells, it checks if it's dirty. If it is, it recaculates.

All spatial hashers gets set to dirty when an entity Position or Box changes.

But how do we observe the changes? Right now our component data access is with pointers and that's rather nice for the caller...

Ah. Needs some more thought.

dt-rush commented 1 year ago

The motivation for this is that with the runtime sharer/limiter temporal structure, it might not be that the spatial hash is updated at all times, when a logicunit runs, it's only accurate just after its Update() function runs. For the World spatial hasher, which now Update()'s at the start of World.Update() (not runtime logicunit, this is overhead), it records the situation at the start of the frame. Maybe it would be advantageous to just consider that as / implement it as the default for all spatial hashers. And if you want the subframe data you have to do CellRangeOfRect (pos, box) and consider that all the other entities might have moved too (thus, some might even have just left the only cell they appeared in, and be retrieved falsely).

dt-rush commented 1 year ago

in short, if a sub-frame event can cause the position or box of an entity to change, its true spatial hash cells are not known without recalculation at the time a given logic may run, since the spatial hash was only last recalculated at the start of the frame.

This means calculations based on spatial hash data (collision, distance, chunk via distanceapprox) can be inaccurate by 1 frame, unless we rigorously re-calculate the spatial hash whenever it is dirty.

Is it really so bad ot be off by one frame? The human visual system would probably never notice!