Java-Gaming.org Hi !
 Featured games (90) games approved by the League of Dukes Games in Showcase (777) Games in Android Showcase (231) games submitted by our members Games in WIP (856) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: [1]
 ignore  |  Print
 not detecting collision with keybindings?  (Read 4744 times) 0 Members and 1 Guest are viewing this topic.
catsaremyreligion

Senior Newbie

 « Posted 2013-09-26 20:00:47 »

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:

 1  2  3  4  5  6  7  8 ` 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!
wessles
 « Reply #1 - Posted 2013-09-26 20:16:27 »

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

 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 `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:

 1  2  3 `interface Moveable {    public void move(float movex, float movey);}`
Opiop
 « Reply #2 - Posted 2013-09-27 01:20:36 »

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.
wessles
 « Reply #3 - Posted 2013-09-27 02:24:15 »

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...).
Opiop
 « Reply #4 - Posted 2013-09-27 02:29:32 »

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!
catsaremyreligion

Senior Newbie

 « Reply #5 - Posted 2013-09-27 14:55:29 »

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.

 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17 `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

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?
wessles
 « Reply #6 - Posted 2013-09-27 19:55:06 »

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

Senior Newbie

 « Reply #7 - Posted 2013-09-27 20:07:40 »

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

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.
wessles
 « Reply #8 - Posted 2013-09-27 20:26:43 »

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.
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!
Jimmt
« League of Dukes »

JGO Kernel

Medals: 167
Projects: 5
Exp: 6 years

 « Reply #9 - Posted 2013-09-28 21:03:45 »

Moving the player and moving the background provide two different types of games. They are not the same thing.
wessles
 « Reply #10 - Posted 2013-09-29 03:12:00 »

Quote
scroll every object that isn't the player,
He is moving the background and the player.
Jimmt
« League of Dukes »

JGO Kernel

Medals: 167
Projects: 5
Exp: 6 years

 « Reply #11 - Posted 2013-09-29 03:17:49 »

"The player is stationary in my game"
catsaremyreligion

Senior Newbie

 « Reply #12 - Posted 2013-10-03 20:18:08 »

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?
wessles
 « Reply #13 - Posted 2013-10-03 20:29:49 »

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

Senior Newbie

 « Reply #14 - Posted 2013-10-03 20:32:37 »

The player stays at the same screen coordinates.
Opiop
 « Reply #15 - Posted 2013-10-03 20:37:02 »

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!
catsaremyreligion

Senior Newbie

 « Reply #16 - Posted 2013-10-03 20:50:29 »

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?
Opiop
 « Reply #17 - Posted 2013-10-03 21:52:28 »

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!
Pages: [1]
 ignore  |  Print

 hadezbladez (288 views) 2018-11-16 13:46:03 hadezbladez (157 views) 2018-11-16 13:41:33 hadezbladez (289 views) 2018-11-16 13:35:35 hadezbladez (70 views) 2018-11-16 13:32:03 EgonOlsen (2133 views) 2018-06-10 19:43:48 EgonOlsen (2152 views) 2018-06-10 19:43:44 EgonOlsen (1364 views) 2018-06-10 19:43:20 DesertCoockie (1966 views) 2018-05-13 18:23:11 nelsongames (1599 views) 2018-04-24 18:15:36 nelsongames (2247 views) 2018-04-24 18:14:32
 KaiHH 15x LiquidNitrogen 14x Spasi 13x orange451 13x bullen 9x 65K 9x NuclearPixels 7x polinc 7x Zemlaynin 7x VaTTeRGeR 5x hadezbladez 3x ral0r2 3x CommanderKeith 2x SHC 2x berzas 1x Riven 1x
 Deployment and Packagingby mudlee2018-08-22 18:09:50Java Gaming Resourcesby gouessej2018-08-22 08:19:41Deployment and Packagingby gouessej2018-08-22 08:04:08Deployment and Packagingby gouessej2018-08-22 08:03:45Deployment and Packagingby philfrei2018-08-20 02:33:38Deployment and Packagingby philfrei2018-08-20 02:29:55Deployment and Packagingby philfrei2018-08-19 23:56:20Deployment and Packagingby philfrei2018-08-19 23:54:46
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org