Adventure-style collision detection in INTYBasic

[+atari2600land]

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 November 23, 2017 by atari2600land

[+DZ-Jay]

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.

[+atari2600land]

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
    
 
obeymeplease:
    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


obeymeplease2:    
    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    

    goto obeymeplease

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

Edited November 23, 2017 by atari2600land

[+atari2600land]

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?

[+DZ-Jay]

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.

[intvnut]

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.

[+DZ-Jay]

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?

[intvnut]

 

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.

[+DZ-Jay]

 

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.

[+atari2600land]

I'd like the bounce.

[+DZ-Jay]

I'd like the bounce.

 

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

[intvnut]

 

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.)

 

[+DZ-Jay]

 

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.

[+atari2600land]

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

[Eisengrim]

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?

[Kiwi]

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.

[Eisengrim]

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.