# EZ Collisions

0

was8bit 2020-11-29 06:01

Demonstrates....

1) Cell based placement

2) Cell based movement

3) Cell based collsion check

4) Cell based item pickup

2020-11-29 06:04
2020-11-29 06:01

i always use cells rather then sprites

there much easier for me

was8bit 2020-12-10 15:32

Sprites can be easy too, but only when you do ONLY sprite collisions with SPRITE HIT(checksprite#) then use spritehit=HIT..

Its when you try to see if a sprite hits a piece of background that it can get complicated... but one way to make that easier is to force a small sprite to move 8 pixels at a time, that way when the pixel stops it is just like a character moving cell by cell, and the check is the same - just divide then sprite x,y by 8 to convert sprite coordinates to cell coordinates..

Interesting

was8bit 2020-12-11 19:05 (Edited)

If ever you need any help with the various collision dectection methods, don't hesitate to post any questions... :)

... you might find these interesting :)

Touch/mouse version... https://lowresnx.inutilis.com/topic.php?id=726

... just remember, the x,y position of any sprite, regardless of it's size, is the pixel location of the sprite's upper left corner... making it abit tricky...

The x,y position of any cell is of course it's x,y position on the bg cell grid... making it EZ ...

Cool thanks

That x,y stuff is the primary reason i use cells

was8bit 2020-12-11 22:12 (Edited)

Yep, i agree :)

The only advantage for sprites is SPRITE HIT doesnt calculate whole blocks, but actually takes into account each pixel inside each cell, so any blank spaces are not used towards calulating contact... so if your collisions are ALL sprites, it actually works great as you dont even really need the X,Y for the SPRITE HIT to work...

I started out using only one sprite, my player, and tried using math to calculate contact with different cells... at first everything was OK, but upon intensive testing i found issues...

... sometimes my player did not precisely line up to activate contacts.. so i fell down holes even though i was clearly 2 pixels away, would go up ladders and my player would look like his head was half going thru the dirt... when swinging facing left my player wasnt even touching the rope but floating in mid air... :/

SO, i converted ALL contact points to sprites... this was NOT easy to set up, as this game has TONS of contact points, but in the end I was able to get pixel perfect contact detection like i wanted...

When your player is a sprite, it s very easy to create smooth movents, running, jumping, swinging,,etc. and it looks really good... so i decided to commit to all sprites to get that perfect look for all collisions...

My background, and even some of the animated cells, are ALL traditional cells, as long as contact detection isnt needed with them, i did these as regular cells....

Interesting... How would i go about checking sprite-cell collisions? Im working on a game that uses sprites and cells and i think it would be too hard to use all sprites

was8bit 2020-12-11 23:42

Timo has the BEST code for that.. although it also includes scrolling... here is his example...

https://lowresnx.inutilis.com/topic.php?id=318

was8bit 2020-12-11 23:45

At it's core, Timo checks all sides/corners of the sprite... the math assumes though a sprite of size 1x1 single cell only...

CALL CHECKCELL(X/8,Y/8,R)
CALL CHECKCELL((X+7)/8,Y/8,R)
CALL CHECKCELL(X/8,(Y+7)/8,R)
CALL CHECKCELL((X+7)/8,(Y+7)/8,R)

was8bit 2020-12-11 23:49

If ALL checks return as no collision, then the move takes place... if ANY of the checks return as a collision, then the move is denied...

The X and Y here includes a +-1 for direction.. it isnt evident, but if you trace the code from SUB to SUB, thats what this math effectively does..

Ah cool i will try that
Thanks :)

was8bit 2020-12-13 19:28

Glad to help... if you run into any troubles, you can ATTACH your program HERE so i can look at it and see if i can help :)