# Adventure-style collision detection in INTYBasic

## Recommended Posts

I spent literally all day trying to do this and came up empty handed. What I want to have is collision detection with the bg in a way like Adventure for the 2600 does AND NOT HAVE IT GO INTO THE BACKGROUND WHEN THE OPPOSITE WAY IS PRESSED. Is this even possible? I have tried multiple things and all of them don't do the thing I capitalized. It's not fair. I'm beginning to think it's not possible.

EDIT: I think I figured it out.

Edited by atari2600land

##### Share on other sites

I spent literally all day trying to do this and came up empty handed. What I want to have is collision detection with the bg in a way like Adventure for the 2600 does AND NOT HAVE IT GO INTO THE BACKGROUND WHEN THE OPPOSITE WAY IS PRESSED. Is this even possible? I have tried multiple things and all of them don't do the thing I capitalized. It's not fair. I'm beginning to think it's not possible.

EDIT: I think I figured it out.

So... have you figured it out? Post your code (not the whole thing! just the relevant bits) and perhaps someone can help.

-dZ.

##### Share on other sites

I've done it, but it involves two waits instead of just one. I think I need the second one in order for it to work.

```    if COL2 and HIT_BACKGROUND then goto opposite

x=0 : y=0

if CONT.RIGHT then #flip=0 : x=1
if CONT.LEFT then #flip=\$400 : x=2

if x=2 then manx=manx-2 : mandirx=2 : mandiry=0
if x=1 then manx=manx+2 : mandirx=1 : mandiry=0

if CONT.DOWN then y=1
if CONT.UP then y=2

if y=2 then many=many-2 : mandiry=2 : mandirx=0
if y=1 then many=many+2    : mandiry=1 : mandirx=0

if f=2 then  mandirx=1 : mandiry=0 : #flip=0
if f=8 then  mandirx=2 : mandiry=0 : #flip=\$400

if f=4 then mandiry=2 : mandirx=0
if f=1 then mandiry=1 : mandirx=0

rem I NEED THIS TO SHOOT DIAGONAL. \/

rem up/right
if f=\$16 then mandirx=1 : mandiry=2 : #flip=\$0

rem up/left
if f=\$1C then mandirx=2 : mandiry=2 :  #flip=\$400

rem down/left
if f=\$19 then mandirx=2 : mandiry=1 :  #flip=\$400

rem down/right
if f=\$13 then  mandirx=1 : mandiry=1 : #flip=0

if shooting<3 then SPRITE 2,manx+\$300,many+\$100+#flip, SPR02 + BEHIND + \$1002
if shooting>2 and shooting<6 then SPRITE 2,manx+\$300,many+\$100+#flip, BEHIND + SPR01 + \$1002
if shooting>5 and shooting<9 then SPRITE 2,manx+\$300,many+\$100+#flip, BEHIND + SPR00 + \$1002

if overallson=1 then SPRITE 0,manx+\$300,many+\$100+#flip,SPR09 + BEHIND + 1

wait
```
```opposite:
if x=1 then manx=manx-2
if x=2 then manx=manx+2

if y=2 then many=many+2
if y=1 then many=many-2

```

The first wait is at the beginning of the loop. f=cont.

Edited by atari2600land

##### Share on other sites

I broke my fixed code by switching from MODE 0 to MODE 1. I put it back to MODE 0 and it works again. Why?

##### Share on other sites

I've done it, but it involves two waits instead of just one. I think I need the second one in order for it to work.

The nature of hardware-based collisions in the Intellivision is that for it to trigger, the sprites must have been moved and rendered in a frame. In other words, by the time you get a collision event, the sprite is actually overlapping the background (or other sprite) by at least one pixel.

If at that moment you wish to "move it back" so that it doesn't go through, you'll now have to wait until the next frame is drawn for the correction to manifest.

An alternative is not to use hardware collisions and do it in software. In such a case, you move the sprite, test its new position and see if it collided, and adjust its position as necessary -- all in the same frame. So by the time it renders the frame, the sprite is where you wish it to be.

I broke my fixed code by switching from MODE 0 to MODE 1. I put it back to MODE 0 and it works again. Why?

Are you asking why switching graphics mode displays screwy? The modes support different data formats and different colour information. That means that one data word for a background card in MODE 0 is incompatible with MODE1 and will not render properly; and vice versa.

##### Share on other sites

If you really want something dirt simple that still relies on hardware collision detection, why not just remember your "last good position"?

```WAIT
IF HIT_BACKGROUND THEN
manx = lastok2_x
many = lastok2_y
ELSE
lastok2_x = lastok1_x
lastok2_y = lastok1_y
lastok1_x = manx
lastok1_y = many
END IF
```

Then, the only other thing you need to remember is to set both "manx"/"many" and the lastok variables whenever you reposition the player through some mechanism other than controller movement.

The reason for 2 sets of "lastok" variables is to account for the 1 frame delay on the collision registers. This will rewind the player back to the last frame that had no collision, regardless of what they're doing on the controller.

##### Share on other sites

If you really want something dirt simple that still relies on hardware collision detection, why not just remember your "last good position"?

```WAIT
IF HIT_BACKGROUND THEN
manx = lastok2_x
many = lastok2_y
ELSE
lastok2_x = lastok1_x
lastok2_y = lastok1_y
lastok1_x = manx
lastok1_y = many
END IF
```

Then, the only other thing you need to remember is to set both "manx"/"many" and the lastok variables whenever you reposition the player through some mechanism other than controller movement.

The reason for 2 sets of "lastok" variables is to account for the 1 frame delay on the collision registers. This will rewind the player back to the last frame that had no collision, regardless of what they're doing on the controller.

Wouldn't that still rewind them after one frame, i.e., the sprite will slightly "bounce" back?

##### Share on other sites

Wouldn't that still rewind them after one frame, i.e., the sprite will slightly "bounce" back?

Yep, it sure would. If you want to use hardware collision to detect collision with the background, you actually have to collide with the background.

##### Share on other sites

Yep, it sure would. If you want to use hardware collision to detect collision with the background, you actually have to collide with the background.

That's what I thought. I don't recall how "Adventure" works, but perhaps he wanted to see how to avoid that little bounce. If so, the only way is to do software collisions.

-dZ.

##### Share on other sites

I'd like the bounce.

##### Share on other sites

I'd like the bounce.

Aha! Good. Then it's quite easy, as intvnut suggested.

##### Share on other sites

That's what I thought. I don't recall how "Adventure" works, but perhaps he wanted to see how to avoid that little bounce. If so, the only way is to do software collisions.

Judging by the collisions in the maze in this video at about 1:00-1:01 and 1:16-1:18, there's a slight bounce. (Slow down to 0.25x to really see it.)

##### Share on other sites

Judging by the collisions in the maze in this video at about 1:00-1:01 and 1:16-1:18, there's a slight bounce. (Slow down to 0.25x to really see it.)

atari2600land had posted on YouTube a sample of his game and it had a very jerky bounce when touching walls, but I wasn't sure that he wanted it that way (I wouldn't). As per his last post, that's how he wanted it, so it's all good.

-dZ.

##### Share on other sites

I tried the wall collision code intvnut suggested and it works great. Thank you!

##### Share on other sites

I'm working on something similar so I'm glad I found this topic. I used IntyColor to draw a maze, gray foreground on dark blue background. I have some rudimentary collision detection on maze walls (where gray meets blue) thanks to intvnut's suggestion, but it's inconsistent. Sometimes my player MOB bumps up against a wall and can go no further, and in other places he cruises right through it. For some reason I get no collision detection when I use COL0 AND HIT_BACKGROUND, but I do with COLO AND \$0100 (the background bit #9). I have some circular rooms in the maze, and it's the borders of those that I think are registering the collisions. In FGBG mode, what really counts as background?

##### Share on other sites
1 hour ago, Eisengrim said:

I used IntyColor to draw a maze, gray foreground on dark blue background.

If you're using color number 8 gray and not tan which is color number 3.  Then dark blue is the foreground color and gray is background color.  Gray can't be use as foreground color in FG/BG mode.  Only the first 8 color can be foreground colors.  Background color can be use with all 16 colors.

##### Share on other sites

Thanks for the suggestion. I changed the maze to tan, but after running it through IntyColor it comes out bright yellow. I also removed all the blue to just leave the background empty; it renders in black. The collision problem I saw before remains. I can bump up against the circular rooms I've built, but full-card borders where yellow meets black have no collision detection.

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.