Sorry your browser is not supported!

Hi guys, I'm new to DB and I'm currently trying to make a 2D game with sprite collision handling. I've run into a weird problem that I cannot seem to figure out.

First of all, I'm using a file from the DB examples - Sprite example:
09. Sprite Collision

Since you can look that up in your examples menu, I'll only post tiny code snippets to show my problem.

So the main collision handling occurs in this chunk of code:


Very simple and straightforward - if there is a collision, re-set the x and y coordinates to the old x and y coordinates so the sprite cannot move through another sprite.

The problem arises when I thought I could simply remove the two assignment lines and use the oldx and oldy variables directly in the sprite line:


This seems much more efficient to me, as it reduces the code by 2 lines, while accomplishing the same task. But wait; it doesn't work. When I set the code to this, the sprite is allowed to move through the other sprite. I can't figure out why it is important to have the two lines I removed. I even tried to write my own collision detection function and I had the same problem. Can anyone tell me why those two lines are necessary - this would help me understand DB more, and I would be very appreciative.

Thanks!

Hello fish,

While on the surface your supposition seems logical, you have to go back a few more lines in the example code to see what's going on:



The arrow keys are constantly updating the x and y position. The whole purpose of oldx and oldy is to keep the old value of x and y before they are updated by the arrow keys. When you approach the positioning of the sprite in the manner you suggest and use the command SPRITE 1,oldx,oldy,1 you are basically just positioning the sprite at whatever value x or y has been updated to on the last loop repeat.

When the collision code is written as



You are resetting x and y to the old values, so the next pass through the repeat, oldx and oldy have effectively not been changed. Make sense?

Let me try explaining it a different way.

Let's say we repeat the loop 3 times. I'll write some pseudo code of what's happening to the variables:



Now, if we use your logic and never set x=oldx and y=oldy, then those values would never be reset and oldx and oldy would just keep increasing (although they would be one loop behind x and y in value) thus enabling the sprite to continue to overlap the other sprite. The whole point of using oldx and oldy is to ensure that x and y get reset to their old values before they were ever updated by the arrow keys. If the sprites keep colliding, then x and y remain at the values of oldx and oldy.

Hi Latch,
Thanks for your explanation. It makes sense now, although I need a little time for this concept to 'sink in' as it were. Thinking it through, with your help, I see that with the working code, we are ensured that oldx and oldy always contain the last "good" (i.e. non-colliding) coordinates. Whereas, with my faulty code, all oldx and oldy succeed in holding are the last iteration's loop coordinates.

Thanks!