"Each frame you are going to iterate through each object and perform actions on it such as moving it in the case of bullets (and checking for collisions when the bullets move), or responding to player input (detected earlier) in the case of player controlled objects. So you are already going to be going through their list each frame anyway. When an object moves across a boundary (simple math check detects this) simply reference the appropriate grid square,"
I don't think you understand the method I've outlined. In the method I've outlined, there is no single "appropriate grid square" per object. There can be two. Or four. Or many.
To do what you suggest, each object would need to keep a list of all the link pointers in the grid that point back to it. Then you would iterate through each object, and each item in that object's list, and remove the links those items point to in the grid square lists.
This is a lot more complicated and unlilkely to be significantly faster than simply nulling all the lists on the grid.
As for the data being out of date at the start of the frame, why do you care? If you move a bullet, why do you care if you know where the other bullets are currently, which is to say, where they were last frame, or where they have been moved to this frame before you got to moving this bullet? You can't act on that information. That way leads to madness. :-)
If you want to act on the information from a previous frame, then you should copy that information to a scratch buffer that won't get modified as you iterate through it.
Only in rare cases have I needed to modify a buffer whilst simultaneously reading the data from said buffer. And that wa when doing a box blur on an image. I can't imagine why you would need to do that in this case. I could see why you might want an enemy's prior position, to say, draw a motion blur, but why would you care what squares it occupied when testing for collisionsm, which you finished doing last frame?
In some ways it can be quicker too as you are only modifying the bank when movement occurs rather than refreshing every grid square every frame - a bit of a waste if most of them are empty or if most of the objects are slow moving/stationary.
The amount of data we are talking about here is so small that even a "low end pc" would have no difficulty dealing with it. We're talking about the equivalent of clearing a 64x64 image to black, in software. I drew screens full of sprites with alpha in software at 60fps in Blitplus. And that was slowed down by readpixels.
You're just talking about a miniscule amount of data. It wouldn't make a lick of difference in speed to do it the more complicated way.
The method I outlined is already complicated enough. :-)
I don't think you understand the method I've outlined. In the method I've outlined, there is no single "appropriate grid square" per object. There can be two. Or four. Or many.
To do what you suggest, each object would need to keep a list of all the link pointers in the grid that point back to it. Then you would iterate through each object, and each item in that object's list, and remove the links those items point to in the grid square lists.
This is a lot more complicated and unlilkely to be significantly faster than simply nulling all the lists on the grid.
As for the data being out of date at the start of the frame, why do you care? If you move a bullet, why do you care if you know where the other bullets are currently, which is to say, where they were last frame, or where they have been moved to this frame before you got to moving this bullet? You can't act on that information. That way leads to madness. :-)
If you want to act on the information from a previous frame, then you should copy that information to a scratch buffer that won't get modified as you iterate through it.
Only in rare cases have I needed to modify a buffer whilst simultaneously reading the data from said buffer. And that wa when doing a box blur on an image. I can't imagine why you would need to do that in this case. I could see why you might want an enemy's prior position, to say, draw a motion blur, but why would you care what squares it occupied when testing for collisionsm, which you finished doing last frame?
In some ways it can be quicker too as you are only modifying the bank when movement occurs rather than refreshing every grid square every frame - a bit of a waste if most of them are empty or if most of the objects are slow moving/stationary.
The amount of data we are talking about here is so small that even a "low end pc" would have no difficulty dealing with it. We're talking about the equivalent of clearing a 64x64 image to black, in software. I drew screens full of sprites with alpha in software at 60fps in Blitplus. And that was slowed down by readpixels.
You're just talking about a miniscule amount of data. It wouldn't make a lick of difference in speed to do it the more complicated way.
The method I outlined is already complicated enough. :-)