Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  2.5d - approching from top and bottom  (Read 1039 times)
0 Members and 1 Guest are viewing this topic.
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 128
Projects: 4
Exp: 3 years



« Posted 2013-05-28 18:59:26 »

So, I'm using box2d for my 2.5d game (think double dragon, tmnt arcade, castle crashers) where you can move around on the z-axis (faked as y-axis movement). Basically, I have box2d only doing collision if 2 entities have the same z coordinate or a z-coordinate within the depth. All is fine, except when I approach an entity from the top or bottom.
 
So yeah, approaching any box2d entity from the top or bottom within the correct x will make the player bounce back once the z becomes the same as the entity - which makes sense because then it starts detecting collision, and it detects a box inside a box. How could I circumvent this? Thanks.
Offline alaslipknot
« Reply #1 - Posted 2013-05-28 19:24:13 »

maybe you should do some sort of grid or something like that,
look to this picture :

the player is in the "yellow-part" and the entity box is in the "blue-part" which mean they can never collide even if they truly do, i believe the best way to this is to check where is the bottom of your boxes (player and enemies feet) if the bottoms are in the same level, then you could do the rest of the collision detection.
PS :
i never tried to do something similar, i hope i helped  
good luck

"It's not at all important to get it right the first time. It's vitally important to get it right the last time."
Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #2 - Posted 2013-05-28 22:33:47 »

You could also internally handle object movement as a 2d top-down game, and then hack-in vertical movement (jumps, etc).

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 128
Projects: 4
Exp: 3 years



« Reply #3 - Posted 2013-05-28 23:45:18 »

maybe you should do some sort of grid or something like that,
look to this picture :

the player is in the "yellow-part" and the entity box is in the "blue-part" which mean they can never collide even if they truly do, i believe the best way to this is to check where is the bottom of your boxes (player and enemies feet) if the bottoms are in the same level, then you could do the rest of the collision detection.
PS :
i never tried to do something similar, i hope i helped  
good luck
I'm already doing this, however eventually the player z will match the entity z and then 2d physics will be applied and the player bounding box will be inside the entity bounding box, which doesn't work. Someone else on gamedev.stackexchange already suggested only making collision boxes on the feet, which I wanted to try avoiding, but now is probably the only option.
Offline UprightPath
« Reply #4 - Posted 2013-05-29 11:34:42 »

Ah, I don't know enough about box2D to know if this suggestion would work, but why not just get the position/size data from the object and perform your own collision check? Like, get the bounds in 1D across X of the entity that wants to move between Z layers and check if it will collide with any other entity on that Z layer (Only need the 1D across X of each one). It'll at least tell you if a collision will happen from moving between Zs.

Online SHC
« Reply #5 - Posted 2013-05-29 12:11:49 »

Set the bounding box to the bottom part of the object.



To calculate the bounding box use

1  
2  
3  
4  
5  
6  
7  
public void calculateBBox()
{
    bounds.x = object_x;
    bounds.y = object_y + (image_height - image_height/4);
    bounds.width = image_width;
    bounds.height = image_height/4;
}

Offline alaslipknot
« Reply #6 - Posted 2013-05-29 15:31:23 »

Someone else on gamedev.stackexchange already suggested only making collision boxes on the feet, which I wanted to try avoiding, but now is probably the only option.
am afraid that's the only solution, when faking 3D in games you must do something like that, for example in a Top-Down rpg (pokémon) when your player hit the top of a Tree it will not stop moving, cause it's not possible to hit the top of the tree in real life, so the only way for the player to stop is when he hit the bottom of the tree, and i think it's the same for you, if you look in those two pictures, you'll know that the only "simple" way to realize that is by checking the collision in the bottom 1st, then look for the other


another thing , i think you could (or must) check the level of your entities, and i think it's better to do it on the bottom too,
suppose you want to shoot an enemy, you must be in the same level to be able to hit him (unless you can shoot in many direction)

so IMHO, the best solution is to make a grid, if the 2 objects are in the same row then you can check for collision,
Question :
why you want to avoid making collision boxes on the feet ?


"It's not at all important to get it right the first time. It's vitally important to get it right the last time."
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 128
Projects: 4
Exp: 3 years



« Reply #7 - Posted 2013-05-29 17:02:22 »

There are several problems I envisioned with making such a small box - mostly that I'd have to use another body for hit detection and other things.
Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #8 - Posted 2013-05-29 17:17:14 »

Believe me, this is how you do it.
always...

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (35 views)
2014-07-24 01:59:36

Riven (33 views)
2014-07-23 21:16:32

Riven (21 views)
2014-07-23 21:07:15

Riven (24 views)
2014-07-23 20:56:16

ctomni231 (55 views)
2014-07-18 06:55:21

Zero Volt (47 views)
2014-07-17 23:47:54

danieldean (38 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!