sprite detection issue

[Brian's Man Cave]

Hey,

 

For my venture game I seem to be having an issue with the collision detection. I am using a similar method to the example IntyPak game where it tries to look ahead to see if the path does not contain a graphic.

 

The approach I am using seems to work sometimes. 

 

Here is a video showing what is happening, the monster sprite at the bottom goes through the wall : 

 

My code is as follows (Showing the going up check)

 

if #r_mon_3 = 0 then 'Going up
  #col_chk6 = #backtab((X5-3)/8+((y5 % 256)-1)/8*20 - 20)
   if #col_chk6 = 0 then #mon_mov3 = 1

end if

 

 if #mon_mov3 = 1 then
   if #r_mon_3 = 0 then y5 = y5 - 1:#mon_mov3 = 0:if y5 <= 10 then y5 = 11

 end if

 

If anyone can assist, that would be great
 

Thanks,

Brian

[artrag]

Why this?

y5 % 256

 

y5 is already a byte

[Brian's Man Cave]

1 hour ago, artrag said:

Why this?

y5 % 256

 

y5 is already a byte

I am not sure... this was code that I repurposed. Not even sure what that means.   

[artrag]

Use this for testing up

#backtab(X5/8+y5 /8*20 - 20)

Use this for testing down 

#backtab(X5/8+y5 /8*20 + 20)

Use this for testing right 

#backtab(X5/8+y5 /8*20 + 1)

Use this fir testing left

#backtab(X5/8+y5 /8*20 - 1)

[Brian's Man Cave]

51 minutes ago, artrag said:

Use this for testing up

#backtab(X5/8+y5 /8*20 - 20)

Use this for testing down 

#backtab(X5/8+y5 /8*20 + 20)

Use this for testing right 

#backtab(X5/8+y5 /8*20 + 1)

Use this fir testing left

#backtab(X5/8+y5 /8*20 - 1)

Thanks!

 

I think I found the root of my problem, being so close to the edge of the screen. I changed my code around to see if there is a collision of the background or border, then bounce the sprite back if it does.

 

I was looking at the original Venture game, and it appears to do that

 

[Brian's Man Cave]

Tried using Background collision and still getting same problem 🥴

[+DZ-Jay]

1 hour ago, Brian's Man Cave said:

Tried using Background collision and still getting same problem 🥴

From the video, it looks like it's jumping back two cards.  I have a feeling that the problem lies in the code that handles collision with the border, and not the one for moving up.

 

    dZ.

Edited December 23, 2022 by DZ-Jay

[Brian's Man Cave]

50 minutes ago, DZ-Jay said:

From the video, it looks like it's jumping back two cards.  I have a feeling that the problem lies in the code that handles collision with the border, and not the one for moving up.

 

    dZ.

Your are right, I removed the code that dealt with the border.  I was using if y6 >= 86 then y6 = 85 to prevent the sprite from leaving the screen. I think changing the values should solve this... if y6 > 98 then y6 = 98

[+DZ-Jay]

2 hours ago, Brian&#x27;s Man Cave said:

Your are right, I removed the code that dealt with the border.  I was using if y6 >= 86 then y6 = 85 to prevent the sprite from leaving the screen. I think changing the values should solve this... if y6 > 98 then y6 = 98

First, consider the following:

• The "y" position of a sprite corresponds to the top edge of the sprite.
• The sprite plane starts 8 pixels above the background plane.
• The background plane is 12 cards of 8 pixels high, or 96 pixels.

So, if you want to test if the sprite touched the bottom border of the screen, you need to compare its "y" position against:

 

   screen-offset + (screen-rows * card-height) - sprite-height

 

If the vertical delay is zero (no scrolling), the "screen-offset" is 8.  If the sprite is of standard size, the "sprite-height" is 8.  Therefore,

 

     8 + ( 12 * 8 ) - 8 = 96

 

    dZ.

[Brian's Man Cave]

I think I have it working now. But still not the best method, as the sprite never touches the borders of an object. I assume because I am doing a card check that looks 8 pixels up and if there is a graphic, then it won't go up.

 

I tried using Collision detection with the Background that once the sprite hits a background object, then move it the opposite by 2. This worked a bit but created odd results, like sticking to the object or going through it. 

[+DZ-Jay]

6 minutes ago, Brian&#x27;s Man Cave said:

I think I have it working now. But still not the best method, as the sprite never touches the borders of an object. I assume because I am doing a card check that looks 8 pixels up and if there is a graphic, then it won't go up.

 

I tried using Collision detection with the Background that once the sprite hits a background object, then move it the opposite by 2. This worked a bit but created odd results, like sticking to the object or going through it. 

 

In my own game, what I do is to test the center of the sprite instead of its origin.  In other words, I use the center of the sprite (spritex+4; spritey+4) as the reference point to check collisions.  I use that position to check the background card.

 

Also, I do not "look ahead."  I do the boundary collision check as part of the sprite movement.  Essentially, I compute the new position in a temporary variable, check if it is out of bounds, and adjust it if necessary prior to assigning the new value to the sprite object.

 

    -dZ.

[Brian's Man Cave]

5 minutes ago, DZ-Jay said:

 

In my own game, what I do is to test the center of the sprite instead of its origin.  In other words, I use the center of the sprite (spritex+4; spritey+4) as the reference point to check collisions.  I use that position to check the background card.

 

Also, I do not "look ahead."  I do the boundary collision check as part of the sprite movement.  Essentially, I compute the new position in a temporary variable, check if it is out of bounds, and adjust it if necessary prior to assigning the new value to the sprite object.

 

    -dZ.

by boundary collision are you only looking for a x and y, or are you able to look if the card contains a graphic?

[+DZ-Jay]

1 hour ago, Brian&#x27;s Man Cave said:

by boundary collision are you only looking for a x and y, or are you able to look if the card contains a graphic?

 

Both:  by boundary I mean to keep the sprite in the "path," as it were.  My algorithm goes something like this.  Note that this is off the top of my head.

' Get current position
x = sprite_posx
y = sprite_posy

' Update position based on speed
x = x + speedx
y = y + speedy

' Check screen boundaries
If (x > max_x) Then x = max_x
If (y > max_y) Then y = max_y

' Check path boundaries
screen_x = (x / 8) + 1
screen_y = (y / 8) + 1

card = BACKTAB(screen_x + (screen_y * 20))

' Check if card under sprite is empty (not a wall)
' if so, assign new position to sprite,
' otherwise, discard it.
If (card AND CS_CARD_DATA_MASK) = 0) Then
   sprite_posx = x
   sprite_posy = y
End If

 

[Brian's Man Cave]

On 12/25/2022 at 5:22 PM, DZ-Jay said:

 

Both:  by boundary I mean to keep the sprite in the "path," as it were.  My algorithm goes something like this.  Note that this is off the top of my head.

' Get current position
x = sprite_posx
y = sprite_posy

' Update position based on speed
x = x + speedx
y = y + speedy

' Check screen boundaries
If (x > max_x) Then x = max_x
If (y > max_y) Then y = max_y

' Check path boundaries
screen_x = (x / 8) + 1
screen_y = (y / 8) + 1

card = BACKTAB(screen_x + (screen_y * 20))

' Check if card under sprite is empty (not a wall)
' if so, assign new position to sprite,
' otherwise, discard it.
If (card AND CS_CARD_DATA_MASK) = 0) Then
   sprite_posx = x
   sprite_posy = y
End If

 

Thanks for clarifying!

 

I assume then if I wanted the sprite to be able to hit the wall but not go through it, I would need to do a sprite collision?

[+DZ-Jay]

28 minutes ago, Brian&#x27;s Man Cave said:

Thanks for clarifying!

 

I assume then if I wanted the sprite to be able to hit the wall but not go through it, I would need to do a sprite collision?

 

Well, to hit a wall and not go through it is quite simple:

• Update the sprite position in a temporary variable
• Test to see if it is inside a wall (by converting the sprite's position into a BACKTAB card and checking the graphic under it)
• If it is inside a wall, adjust the position in the temporary variable to touch the wall -- that is, to be next to the wall rather than inside it
• You update the sprite position from the temporary variable.

 

That's what I do.

 

    -dZ.

[Mik's Arcade]

wow...despite the issues, this looks good.  Hopefully you can work it all out.  I've noticed you are working on MANY projects.....how many games have you completed?

 

I've taken a long break from coding but starting lurking on the formums recently.  I've have a soft start by working on my latest raspberry pi build but I'm getting the itch to start making a game again. I added my one game to the Intellivision catalog so it's cool to see it there with the real games...lol  I still want to go back and further polish it up but have a list of other game I want to try..

 

I joined a band a couple months ago and have been focusing on music but if that falls apart (it usually does) , I will use the free time to start coding again.

Edited January 18 by Mik's Arcade

[Brian's Man Cave]

On 1/18/2023 at 7:58 AM, Mik&#x27;s Arcade said:

wow...despite the issues, this looks good.  Hopefully you can work it all out.  I've noticed you are working on MANY projects.....how many games have you completed?

 

I've taken a long break from coding but starting lurking on the formums recently.  I've have a soft start by working on my latest raspberry pi build but I'm getting the itch to start making a game again. I added my one game to the Intellivision catalog so it's cool to see it there with the real games...lol  I still want to go back and further polish it up but have a list of other game I want to try..

 

I joined a band a couple months ago and have been focusing on music but if that falls apart (it usually does) , I will use the free time to start coding again.

@Mik's Arcade I know what you mean... I feel like I piled too many projects on my head and not enough time to do all at once 😁

 

So far I have 2 games that have been released (Keystone Kopps and Fast Food) and a bunch more that are pretty much ready to go and are to be released this year. I also have many that are in production, it's funny but my idea of taking a small break from programming a game is to start another one... although I bet that is more common than I think it is. I think I have about 7 games on the go... most are close to done.

[Mik's Arcade]

6 hours ago, Brian&#x27;s Man Cave said:

@Mik's Arcade I know what you mean... I feel like I piled too many projects on my head and not enough time to do all at once 😁

 

So far I have 2 games that have been released (Keystone Kopps and Fast Food) and a bunch more that are pretty much ready to go and are to be released this year. I also have many that are in production, it's funny but my idea of taking a small break from programming a game is to start another one... although I bet that is more common than I think it is. I think I have about 7 games on the go... most are close to done.

wow.  You are a programming beast!