# Midp2.0 Sprite.CollidesWIth(Barrier, true) help

This topic is 4831 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Okay going only by what I have in my learning to program midp2.0 games book, the author uses this method to do collisions:
if(xMove!=0 || yMove!=0) {
layers.setViewWindow(xView+xMove,yView+yMove, getWidth(), getHeight()-infoBar.getHeight());
playerSprite.move(xMove, yMove);

}
...

if(sprite.collidesWith(barrierLayer, true))
{
layers.setViewWindow(xView,yView, getWidth(), getHeight());
playerSprite.move(-xMove, -yMove);
}
else
{
xView+=xMove;
yView+=yMove;
}

this is fine and dandy for his examples where you run around into barriers or wall, but can only move one way at a time. It seems collidesWith falls apart when trying to do something like a platformer. For instance: Suppose you have a player runing to the right. YOu want to have ac onstant x motion right unless he hits a verticle wall, then stop. And you want a constant down motion to keep him on the ground (and fall if any pits appear). So this is my thinking:
in canvas.Update(){

if(xMove!=0 || yMove!=0) {
layers.setViewWindow(xView+xMove,yView+yMove, getWidth(), getHeight()-infoBar.getHeight());
playerSprite.move(xMove, yMove);

}
...
..
..

if(sprite.state == RUN)
{
xMove =4 ;//always run right
//check for collisions while moving right
if(playerSprite.collidesWith(barrierLayer, true))
{
layers.setViewWindow(xView,yView, getWidth(), getHeight());
playerSprite.move(-xMove, 0);
}
else
{
xView+=xMove;
playerSprite.nextFrame(); //animate since we are moving

}

//now force some gravity and test y direction:
yMove=1;
if(playerSprite.collidesWith(barrierLayer, false))
{
layers.setViewWindow(xView,yView, getWidth(), getHeight());
playerSprite.move(0,-yMove);
}
else
{
//we are not hitting a barrier, must be falling
playerSprite.state=FALL;
yMove=4;
}
}
else if(playerSprite.state == FALL)
{
//test xdirection movement collision
xMove=4; //fall the direction we were going
//test that we dont hit a while while falling down right
if(playerSPrite.collidesWith(barrierLayer, true))
{
layers.setViewWindow(xView,yView, getWidth(), getHeight());
playerSprite.move(-xMove,0);
}
else
{
xView+=xMove;
}

//now test the ymovement fallign collision
yMove=4;
if(playerSPrite.collidesWith(barrierLayer, true))
{
layers.setViewWindow(xView,yView, getWidth(), getHeight());
playerSprite.move(0,-yMove);
yMove=0;
playerSprite.changeTo(RUN);
playerSprite.state=RUN;

}
else
{
yView+=yMove;
}
}

this more or less works the way I want but two problems: First I realize the collidesWith could care less about direction so im doing a ton more checks than I need...its split up cause it makes sense in my mind that way... secondly for some reason, and its not apparent in my above code...the player runs at like half the speed... if i take out all the falling yMove crap in my RUN state, then it runs great (of course doesnt "snap" to the floor). So how does one use collidesWith in a platformer like setting, knowing what tiles? I had a thought of creating two barreirs: Verticle, and Horizontal , so depending upon what direction I want to check for for a response to colliding with, I know i can tell it to check against the proper orientation for the right direction (x or y). So anyone got some cool ideas tricks or even have a clue what , even if in general, my dilemma is? thanks, Shane

##### Share on other sites
Quick question:
Is it absolutely 100% manditory that you do sprite collisions?

##### Share on other sites
I guess not, like i said I was just going off what I learned from that one book...and while I can do it several different ways, I figured id pop in here to try to come up with the "ultimate" best solution...

I could build a collision map I suppose of some sort and test that way and write functions like xVel = barrierLayer.CanMoveLeft(xVel); or something that can return the needed velocities after collision is done.

##### Share on other sites
Problem is that midp2.0 is only on the newest of devices. If you are interessted in mobile development you will have to face the fact that the majority of devices still have midp1.0.
Not to mention different screen sizes.

Best thing to do is to sepperate the drawing and the object handling.

BTW what book are you reading? From your example you might want to check out java game programming by brakeen. A very good book that even includes something like which you are doing.
(I think the source code is available on his HP, but get the book as well, it is definetly worth it!)

##### Share on other sites
The book is beginning mobile phone game programming (or something like that), I actually fixed the problem as realized it was the design of his demos that was throwing me off in the way the view and player positions were updated, I changed that and it's more or less working.

Ya I knew midp1.0 is still on other devices, but I wanted to get a solid demo of the game working on one device, and then work on "porting" it to the other devices...

I do think midp2.0 is quite nice thus far...

##### Share on other sites
Porting from MIDP 1.0 to 2.0 is easy (no changes needed, you can just add stuff to make the game better).
Porting from MIDP 2.0 to 1.0 may be a nightmare. In fact, sometimes the MIDP 1.0 port is a whole new project, not just some mere code changes here and there. (It depends on many factors, though.)

Just wanted you to keep that in mind. MIDP 2.0 is way more powerful than MIDP 1.0 (not just the library itself, but also the phones carrying it), so don't expect an easy port at the end if you didn't keep that port in mind throughout the whole MIDP 2.0 development process. If you don't, you might end up redesigning the whole thing for other platforms.

##### Share on other sites
I was looking into this book for java midp1.0 programming:

http://www.amazon.com/exec/obidos/tg/detail/-/1592001181/ref=pd_sim_b_3/104-9221303-6984766?%5Fencoding=UTF8&v=glance

##### Share on other sites
I was looking into this book for java midp1.0 programming:

http://www.amazon.com/exec/obidos/tg/detail/-/1592001181/ref=pd_sim_b_3/104-9221303-6984766?%5Fencoding=UTF8&v=glance

1. 1
Rutin
73
2. 2
3. 3
4. 4
5. 5

• 21
• 10
• 33
• 20
• 9
• ### Forum Statistics

• Total Topics
633427
• Total Posts
3011818
• ### Who's Online (See full list)

There are no registered users currently online

×