Timeline for Designing Efficient 2D Collision for Topdown Shooter
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 5, 2012 at 23:23 | comment | added | Tristan | As for the migration between buckets in your firing method I'd separate your rendering and physics lists and add all fired bullets to the rendering list but only adding those that pass the larger range check to the physics list. So in further physics updates you iterate through only the items on the physics list. (Of which excluded bullets are not featured but they still appear on the render list so they are visible to the players but not to the physics engine) | |
| Feb 5, 2012 at 23:18 | comment | added | Tristan | Only in the worst case scenario that every bullet is being fired close to the target(s). The way I'm suggesting does the pythagorean calculation on firing and then does two range checks on the return value from the calculation. One to check if it's hitting and then one against a larger value to check if it could hit. If it can't hit then it has no further physics checks performed on it. So that every bullet that is never going to hit something has only has one physics check and if it is visible for say three or four frames, this method saves two or three physics checks. | |
| Feb 5, 2012 at 15:38 | comment | added | Rufei | If I did that, I'd end up making at least a single pythagorean calculation on every bullet per frame. Ideally I would have some type of container to hold bullets in that would indicate as a general rule of thumb if an object needs assessment in the first place, but there is that overhead cost of migrating said objects between buckets. (Of course, let me know if I am understanding your solution incorrectly.) | |
| Feb 5, 2012 at 8:52 | history | answered | Tristan | CC BY-SA 3.0 |