[McKay (OP)]

If I want to simulate two objects colliding, both moving relative to a virtual background and the monitor, I understand how I can make the objects move, iteration by iteration, at the same time (same canvas refresh), by calculating but not refreshing the canvas until all objects have their next trajectory position iteration calculated, but once the objects get to actually colliding, there is a problem - one object can be analyzed at a time in relation to the other object/s and determined if it has collided with another object (say, the pixels are "touching" ), so:
* if two objects about to collide are separated by 1 pixel and the canvas is analyzed for location, not the  memory in which the next iteration is being built, then, in the next iteration the objects outermost pixels will overlap
*if two object are about to collide and are separated by 1 pixel and the memory is analyzed instead, then the collision will happen only for one object, as for the first object analyzed the other object will be 1 pixel away, but when the other object is analyzed, it will see the first object as already touching - no pixels apart and, thus, in the next iteration the objects (programmed to bounce in collision) will both move in one direction - the direction of which the first analyzed object was moving..
Am I making sense? I am quite confused about this.

Specially complicated for simulating charged particles - then they are basically touching all the time, with various degrees of repulsion and/ or attraction.

[David Cooper]

Not something I've ever done. Are these irregularly shaped 2D objects? If they are, the easiest way to detect collisions may be to draw them in their new positions in an empty area of memory and check to see if a pixel's already been written every time you write one, though you will need to find a way to work out which object it was that caused that pixel to be written. Once you've established that two objects have collided, there's no need to act on that collision for this frame, but just allow them be drawn with a momentary overlap. You can simply do the calculation for how they will both move after the collision and apply that the next time they are drawn.

[evan_au]

If objects are moving quickly, they could move (say) 10 pixels between frames, so a 1 pixel boundary won't detect proximity in time to prevent a hit.
It may be better to detect the colission once they have hit?

[McKay (OP)]

So it is basically collision detection what I am interested in. I couldnt make out what to search for in the first place, for some reason, but now I have a concrete phrase. I guess.

[David Cooper]

Yes, I've just tried googling "collision detection programming" and it seems to return plenty of the right kind of sites to get going. From this one http://katyscode.wordpress.com/2013/01/18/2d-platform-games-collision-detection-for-dummies/ it makes it sound like an interesting thing to study and experiment with:-

Now, let’s not beat about the bush: collision detection is a nightmare when done right.

I wish I had time to get into it, but it looks as if it would take a lot of reading just to find the best approach for any given task, and it would be necessary to do that reading to avoid going down the wrong route, unless of course you can find a forum where experts in this are willing to share knowledge and advice, because then you could spell out what it is you need to program for and they would be able to direct you down the best paths for the task you're taking on. If it's writing games, it's clearly very different from doing a serious physics simulation where processing time is not so important and greater accuracy is required.