ID:2400561
 Sep 21 2018, 1:13 pm
|
|||||||
| |||||||
The bounds destination of the moving object would be useful to have so if you need it in cross you don't need to recalculate it yourself.
| |||||||
|
Sep 21 2018, 1:30 pm
|
|
Ninjanomnom
 |
I've been trying to think of a decent way the language could support better modification of bump behaviour and this helps but it's certainly not the cleanest way to handle it. At the moment if you have an object 1 pixel in front of another and something steps into it with a large enough step_size it will hit both things even though one is clearly in front of the other.
|
Creating a temporary list for this call is really not a great idea; it would simply slow down movement across the board. Sending the proposed loc and step_x/y coordinates might not be so awful, although it's questionable whether that would be of much use.
I can't actually think of a use case where Cross() would benefit from knowing the potential coordinates of the mover. The call is made whenever the overlap is a possibility, and if the movement is cut short for any reason the call is not repeated. | |
The proposed step_x/y would be fine as well. The use case that triggered this request was in needing to know when 2 things are being crossed at the same time. You don't have much information to go on inside a cross call to figure out the sort of state that the movement is in. Just being able to know how much the moving thing is moving would make things easier.
| |
Remember though, crossing two objects at the same time may not even happen. Cross() is only called once for each object on a yes/no basis. The call asks about a collision that may potentially happen, but doesn't necessarily have to.
| |
It doesn't necessarily have to happen but it's useful to know if it would potentially happen. Also just knowing how far something is moving is useful and we'd not have a good way at the moment of figuring that out. Objects don't only move in step_size amounts after all.
| |