I am using the AnalogOnScreenControl to move my sprite around the screen. I would like to restrict the sprite so it can not move outside the screen boundaries.

I have tried putting a line at the top of the screen and checking collisions between the sprite and the line, but the effect is that the sprite sticks to the top line. It does not move at that point. So I tried the onAccelerometerChanged() method as an alternative, but that also doesn't work.

How do I detect the screen boundary and prevent the sprite from going beyond it?

  • 2
    \$\begingroup\$ Why not simply test if your sprite bounds go outside your world boundaries? It doesn't have to be done with OpenGL. \$\endgroup\$ – Sidar Feb 26 '13 at 11:09
  • 1
    \$\begingroup\$ @Sidar question didn't really call for world boundaries, called for screen boundaries, and he didn't say anything about OpenGL. Am I missing something? \$\endgroup\$ – Cameron Fredman Feb 26 '13 at 22:23
  • \$\begingroup\$ @CameronFredman GLES = OpenGL ES. The question implies it was OpenGL ES bound. It's not much relevant to anything GLES1. He simply needs to check boundaries of whatever he is keeping track of. Screen/world all included. It was a case of semantics here. Nothing more nothing less. My point still stands regardless of the space he is in. \$\endgroup\$ – Sidar Feb 27 '13 at 5:49
  • \$\begingroup\$ @Sidar his original question referred to "AndEngine gles1". AndEngine named their versions GLES1 and GLES2. Run a google search for "AnalogOnScreenControl" and you'll see the entries take you straight into AndEngine code, plus he had the andengine tag on the original post. Don't think he was asking an opengl question, except to the extent andengine happens to use opengl. \$\endgroup\$ – Cameron Fredman Feb 27 '13 at 5:55
  • \$\begingroup\$ @CameronFredman If andengine is tagged then it shouldn't be in the title. Obviously it confused me since I don't work with AndEngine nor do I know of the 2 different builds. But that's just me. \$\endgroup\$ – Sidar Feb 27 '13 at 5:58

What you're asking for is a subset of collision handling. Essentially, when you've moved the player outside of the scene, you want to move the player back into the scene, and you want to do that in the same update as you've moved the player, immediately after moving the player, so the out-of-scene location never gets rendered.

Lets assume you do something like this to move the sprite:

physicsHandler.setVelocity(pValueX*100, pValueY*100);

Now you want to move them back into the scene if they're outside it. So we're going to need a new method. Lets throw in a method call right after moving the sprite (we'll call it "adjustToSceneBinding()" so you have this:

physicsHandler.setVelocity(pValueX*100, pValueY*100);

Sidenote, you can do the adjustToSceneBinding() method from inside or outside the Sprite. Doing it from inside (i.e., have sprite be a class that extends sprite) is probably more proper, but for our purposes doesn't matter. Now the adjustToSceneBinding code:

public boolean adjustToSceneBinding(Sprite player) {

    // Correct the X Boundaries.
    if (player.getX() < 0) {
    } else if (player.getX() + player.getWidth() > CAMERA_WIDTH) {
        player.setX(CAMERA_WIDTH - player.getWidth());

If the sprite's X coordinate is less than zero, move them back to zero. If the sprite's X PLUS the player's width is more than the camera width, move them back to the camera width minus the player width. Don't forget the player X coordinate represents the left side of the sprite. That's why I'm taking into account the width in addition to the position for calculating the right side.

The above code only addresses left/right movement, but I'm going to let you extrapolate how to do the same for up down.

  • \$\begingroup\$ Thank you sooo..... much. It's working properly.Very nice logic.And thanks for giving me chance for making up/down code through that i understand that how it works. \$\endgroup\$ – Bin Feb 27 '13 at 6:53
  • \$\begingroup\$ @Bin You got it, buddy. \$\endgroup\$ – Cameron Fredman Feb 27 '13 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.