Map Collision Eject

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Map Collision Eject
by on (#159875)
Hi tokumaru
As the topic states eject from tile position can you go into detail i'm aware when logical (lda _ObjectY,x..and %00000111) my object the low bits are how any pixels i'm into the block.How do I add these back is my question.Sorry if this is a newbie question but i'm also new to game coding.
Re: Map Collision Eject
by on (#159901)
I'm assuming a no on my question then,Tepples wanna help?i'm assuming add the low bits+1 back to the object postion.I apologise for my english, i'm Canadian and english is my third language .

Also sorry for the edits i had to look up French,German to English a few times
Re: Map Collision Eject
by on (#159903)
Could I see a bit of context, such as how you are computing this value whose low 3 bits are the penetration distance?

(Also run-ons.)
Re: Map Collision Eject
by on (#159906)
Yes of course this is checking the right side of my aabb


Code:
blobfeetchkloop:
     lda _objectlinkedlist,x       ;<-- my Yposition
   clc
   adc #21
   tay
   ldx _XObjectTmp
   jsr do_tilemapcollision
   bcs blobfeetcollision
   lda _XObjectTmp
   clc
   adc #7
   sta _XObjectTmp   
   dec _tmploop
   bne blobfeetchkloop
blobfeetexit:
   rts      


My collisionRam Map is 16x16
do_tilemapcollision:
 lda _XObjectTmp                            ;<-- Xposition
 lsr
 lsr
 lsr
 lsr
 and #%00001111    ;Karnov
 sta _XTmp
 tay                                                 ;<-- Yposition
 lsr
 lsr
 lsr
 lsr
 asl
 asl
 asl
 asl
 ora _Xtmp
 tay
 lda _MapCollisiondata,y
 cp #1
 beq Collision
NoCollision:
 clc
 rts

Collision:
 sec
 rts

Re: Map Collision Eject
by on (#159912)
Didn't have time to check this out yet. I'm not home now, will try to take a look later.
Re: Map Collision Eject
by on (#159917)
tokumaru wrote:
Didn't have time to check this out yet. I'm not home now, will try to take a look later.

No worries tokumaru i've Tepples helping me.
Re: Map Collision Eject
by on (#159918)
Also Tepples can you go into deep detail or link me as i understand most of you're explanations and find it difficult to understand other members.(I can understand tokumaru&Tepples can the rest of you guys not add into the conversation until they both reply?)
Re: Map Collision Eject
by on (#159920)
I'm not yet in a position to sit down and understand the entire code snippet. But I did find a few things that if you clarified them I could understand better.

Prime wrote:
Code:
blobfeetchkloop:
     lda _objectlinkedlist,x       ;<-- my Yposition
   clc
   adc #21
   tay
   ldx _XObjectTmp
   jsr do_tilemapcollision
   bcs blobfeetcollision
   lda _XObjectTmp
   clc
   adc #7

What are the 21 and the 7?

Quote:
Code:
 tay                                                 ;<-- Yposition
 lsr
 lsr
 lsr
 lsr
 asl
 asl
 asl
 asl
 ora _Xtmp

Why not just AND #$F0?
Re: Map Collision Eject
by on (#159921)
Prime wrote:
Hi tokumaru

Very unusual way to start a topic, since not all members read everything... luckily I read almost everything that isn't SNES, music, repros or mods! :lol:

When in doubt... DRAW! Here's a character (blue rectangle) running right into a wall, inside a tiny 3x3 metatile area:

Attachment:
collision-right.png
collision-right.png [ 4.91 KiB | Viewed 3589 times ]

Since the object moved left (something we know because the horizontal displacement was positive), we have to check all the blocks from the top right corner ($24, $04) to the bottom right corner ($24, $1F), to know whether they're solid or not. Dividing by 16, we have to look at all blocks between (2, 0) and (2, 1). If any of those blocks are solid, you'll know the object has hit a wall, which is the case here.

Now we have to figure out how many pixels to push the object back. Regardless of where the object's hospot is, and how you calculated the rightmost horizontal coordinate, you can easily tell just from looking that this coordinate is 5 pixels into the wall. Math confirms this: $24 AND $0f = $04, the fifth pixel of the metatile. You can now simply subtract 4 + 1 (since we count pixels from 0) from the object's coordinate and you can be sure that its right side will not be inside the wall anymore.

The math is a bit different for the left side, since objects enter the wall from the opposite side (column $0f):

Attachment:
collision-left.png
collision-left.png [ 4.9 KiB | Viewed 3589 times ]

Now we're looking at the corners ($0B, $04) and ($0B, $1F). $0B AND $0F = $0B, which is the 12th column of the metatile, but since the object is entering from the right, that doesn't mean it's 12 pixels in. The actual value you're looking for is 16 - 12 = 4, which is the same we'd get if the object was moving right, like in the previous example. In assembly, you can use a shortcut to find this number: just EOR it with $0F. $0B EOR $0F = $04, which is the number you're looking for. Now you can add that (plus 1) to eject the object from the wall.

Does this help?
Re: Map Collision Eject
by on (#159922)
I noticed now that you mentioned the mask %00000111, which makes me believe you're using 8x8-pixel blocks, not metatiles as in my example, right? If so, that's not a problem, the logic is always the same, you just have to keep the block size in mind when dividing and masking/negating bits.
Re: Map Collision Eject
by on (#159923)
[quote="tepples"]I'm not yet in a position to sit down and understand the entire code snippet. But I did find a few things that if you clarified them I could understand better.

[/code]
What are the 21 and the 7?
21 is my yposition AABB [i add 7 pixels for my xposition]
Sorry Tepples i want help but i wasen't clear





Code:
 tay                                                 ;<-- Yposition
 lsr
 lsr
 lsr
 lsr
 asl
 asl
 asl
 asl
 ora _Xtmp

Why not just AND #$F0
I didn't think of this
I'm new to 6502
Re: Map Collision Eject
by on (#159924)
Thanks tokumaru & Tepples i need to read what tokumaru posted.
Now i get it thanks guys...I was having a problem with my object gravity he was to many pixels into the block.
Re: Map Collision Eject
by on (#159925)
tokumaru wrote:
I noticed now that you mentioned the mask %00000111, which makes me believe you're using 8x8-pixel blocks, not metatiles as in my example, right? If so, that's not a problem, the logic is always the same, you just have to keep the block size in mind when dividing and masking/negating bits.

I'm coding in z80 brother but the same rules apply
Re: Map Collision Eject
by on (#159926)
Tepples I'm used to this


ld b,(ix+constantYInt)
ld c,(ix+ContantYFraction)
ld l,(ix+objectYFraction)
ld h(ix+ObjectYInt)
add hl,bc
ld (ix+objectYFraction),l
ld h(ix+ObjectYInt),h
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Is this the equivalent to as 6502 has direct memory access
charlievelocitycont:
lda _blobgravityf
sec
sbc _blobconstgravityf
sta _blobgravityf
lda _blobvelocity
sbc #0
sta _blobvelocity
Re: Map Collision Eject
by on (#159928)
Yes, that's how you typically subtract 16-bit values on 6502.
Re: Map Collision Eject
by on (#159930)
tepples wrote:
Yes, that's how you typically subtract 16-bit values on 6502.

Do you have a structure i could look at?A typical nes program?I know i am asking a lot tepples but I'm new and that would help.
Re: Map Collision Eject
by on (#159932)
Prime wrote:
I was having a problem with my object gravity he was to many pixels into the block.

My examples were for horizontal motion, but it's exactly the same for vertical: moving down works the same as moving right, moving up works the same as moving left.