Juliean said:
That was something that I was suggesting before, so I'm not sure why you are asking me :D I would absolutely see it as a possibility to solve that “problem” by just measuring the max-peak of a what a cell can have, and then reserve to that.
Wastes more precious cache and memory than anything. I'd guess it's slower than pointer chasing as well on worlds larger than a screen.
Would you proudly show such code? Would you argue this way on some job interview, and still expect to get the job? I doubt you would. It's just for the sake of argue, yes?
Juliean said:
Since they were (i belive) talking about GPU-resources on that slide, I think they did mean actual fixed memory by design. They also did mention the part about making sure by asserting and testing regularily that the game doesn't blow up.
Was it to bin lights to a screen grid? Something like that? In such scenario, you do not know your object count, as it depends on camera. Thus the approach is eventually justified, although a single work group could handle proper compaction in no time.
But in our case the object count is always known. At least we know how many objects are allowed in the whole game, and we use that to use fixed sized memory for the whole system, so it never allocates anything, ideally.
Contrary, if you have to set a max count per grid cell (not per whole game), that's always bad. It causes design limitations, and still wastes memory. For absolutely no reason.
It's inferior, bad, and you can't talk it good, no matter how often you repeat the same bad arguments.
Juliean said:
Yeah, but if you store its own vector, the code would not be as simple anymore, to declare it the “simplest solution”
Imo it dos not increase complexity at all. Same algorithm, same data.
Juliean said:
Using this for other features could be done, but I'm not sure that a range-query would work. Without knowing the first object in the “list”
You do know the pointer to the first object. It's in the grid, your spatial acceleration structure. Which, likely, you keep around, in case you want spatial queries.
I mean, that's literally what a broad phase is doing: Spatial range queries.
Well, maybe that's a good keyword, to get to some other perspective you maybe prefer…
So, in my applet, i have called the objects Object, to keep it simple. But that's not what i personally associate with that data. It's not a game object, a sprite, or whatever.
It is a bounding volume (or area in 2D). In my case a bounding sphere, but could also be a bounding box (or rectangle).
And the collision system as shown is just the broad phase, not knowing about sprites or skeletons, or even the orientation of a rigid body.
It does not know about shapes, only their bounds. And it computes potentially colliding pairs, in other words: pairs of overlapping bounds.
A second, narrow phase collision detection system would then, knowing about actual shapes, calculate precise intersections from those pairs.
E.g. bit mask overlap tests for transparent sprites, or GJK algorithm to see if convex polyhedras intersect, etc.
Maybe you don't need such accuracy for your game and circles or rectangles are good enough, but the concept still makes sense.
And if you use ECS, you could add a collision component to your game objects, which then holds the bounding volume, the pointer, plus some index or ID for the pair mask, if needed.
The broad phase system could then also implement range queries, to find collision components inside a given rectangle range.
Btw, with all that argue we overlooked the true advantage of the vector approach:
If objects go to multiple cells, you can suppurt objects that are larger than a cell.
If objects go only into one cell, this does not work, and you'd need a multi level grid.
Multi level grid is faster anyway, but worth it only if many objects are large.
If you want small cells, and only few objects are larger than a cell, the vector approach becomes indeed more attractive.
