not detecting collision with keybindings?

Newbie & Debugging Questions
#1

So in my little side-scroller Java game I’m attempting to make collisions for my character against walls. I am using keybindings instead of key listeners because of the focusing issues it often caused. Here’s the code I’m having trouble with:

 Action moveleft = new AbstractAction(){
      public void actionPerformed(ActionEvent e)
      {
          if (moving==true&&offsetX!=2){
              offsetX=offsetX+2;
          }
      }
    };

The problem is that when a key is held down to make the character move, in the actionperformed method, it doesn’t recheck the conditional statement that determines whether moving is true or false when the key is held down. This results in the character moving indefinitely through all walls until the key is released.

So why is this? What can I do to remedy it? If any more code is required from my program I can provide! Thanks!

#2

I wouldn’t make moving left an abstractualized ‘Action.’ I would just have a method like this:


public void move(float movex, float movey) {
    // Hypothetical positions that you could be in
    Rectangle collisionx = new Rectangle(x+movex, y);
    Rectangle collisiony = new Rectangle(x, y+movey);

    // Check for hypothetical x
    if(/* No Collision by collisionx */)
        x = collisionx.getX();

    // Check for hypothetical y
    if(/* No Collision by collisiony */)
        y = collisiony.getY();

    // So what we did was 'if the new x value will make you collide, don't take x,' and did the same check for y.
}

That is how I handle collision (only I have delta, but you should be able to figure that out ;)). Just methods. You could make an interface if you really want to encapsulate(?) it, like:


interface Moveable {
    public void move(float movex, float movey);
}
#3

I wouldnt use an interface, just stick it in a entity class and let the sub classes inherit the move method. I dont know why, that what I always do. I’ve never used an interface in game programming before, however I have in other stuff.

#4

I like to use them (not often, but) when I want to have some kind of trait for the object. Like it could inherit Textured, Moveable, and Mortal. That way, instead of with extending a class, I could reference it as a Textured, Moveable, or Mortal. I think of it as the class that keeps on extending (minus variables, but getters and setters work…).

#5

Yeah I guess, but I hate having two classes that could be molded into one. I see no huge difference between interfaces and extending when I’m working with a basic entity system, but maybe when I try something a little more advanced, interfaces will come in handy!

#6

Hey thanks a whole lot! This is doing the trick for right now, so I hope it’ll continue to work. I know I’m probably setting up my movement in the least efficient way possible, but I actually have an arraylist of all blocks in the level and a for-loop statement that checks to see if the player’s min x is touching the max y of each block inside the move method you just posted.

public void mover(float movex, float movey) {
        // Hypothetical positions that you could be in
        int collisionx = (int)(offsetX+movex);
        int collisiony = (int)(offsetY+movey);

        for(int i=0;i<level1.Blocks.size();i++){
        	if (Math.abs(p1.minX) < Math.abs(level1.Blocks.get(i).maxX)){
        		moving=false;
        	}
        }
        if (moving==true&&offsetX!=2){
        	offsetX = (int)collisionx;
        }
        if (moving==false){
        	offsetX = 0;
        }
    }

It’s working for my purposes right now, but I’d really appreciate feedback on how to make it more, I don’t know, professional I guess?

#7

Well, could you explain some about your code? Like what the for loop does, what it iterates, what the offset is, etc.

#8

Yeah sure. So I have a text file that has the test level saved into it. The Level class reads the file and adds blocks to an arraylist. Each block contains its own coordinates. The player is stationary in my game, so I use the offsetX to scroll every object that isn’t the player, including the background and everything. So the iteration that I posted goes through the arraylist to check and see if the player is making contact with any block. If it isn’t, then the offset is changed to scroll the objects in whatever direction around the player. I hope this explanation was informative enough.

#9

What? Sorry, but I think that you should know that doing one movement equation is way better than doing one for every object including the background. Seriously, just move the player. I guarantee that it will be more organized and faster.
Then, you could just do pretty much exactly what I gave as an example.

If you are working in java2d, see this for moving a camera (with an entertaining ‘thank you’).

Alternatively, (and IMO easier) lwjgl has a glTranslate function, if you are using lwjgl.

Hope this helps!

EDIT:
Pro-Tip : Use delta!

#10

Moving the player and moving the background provide two different types of games. They are not the same thing.

#11

He is moving the background and the player.

#12

“The player is stationary in my game”

#13

Sorry I don’t know if this was a mis-communication or something, but yeah the player stays at the same coordinates on the screen constantly, while other blocks and the background are moving. Like, I dunno, Super Mario I believe?

#14

Wait, do you mean screen or universal coordinates when you say he doesn’t move?
If it is screen coords, then I stand corrected.

#15

The player stays at the same screen coordinates.

#16

Well, he technically does. You should still be changing his coordinates though. I would recommend using AABBs, HeroesGraveDev posted a good explanation on them here. They basically just check the player position against the position of a axis aligned object. Its really very simple!

#17

Alright thanks a lot. I checked it out and have a few questions because I can be super slow sometimes. So would the AABB in the explanation be like the player and the blocks in my game? Do I find the center and size of them based on the universal coordinates?

#18

Yes, the player and the tiles and whatever else in you game that isn’t rotated at all can use the AABB method. Thats very important, you cant use it if you rotate the object at all, or else you’ll come up with bad results and you’ll want to perform pixel perfect collisions then. And by coordinates for them, do you mean the coordinates of the tile? If thats what you mean, you only need 4 coordinates(2 actually). You’ll need the x and y world coordinates, and then you’ll need the width and height of the tiles. Those are the only coordinates you’ll need. I could help if up posted some code!