Handling walls with collision detection

[Vincehood]

Hello,

I am trying to understand how to get a game character to stop when colliding a wall (background or border).

Thanks to the SDK game2 example, I learned a bit about collision detection using SPRITE (with HIT) as well as COLx and HIT_BACKGROUND / HIT_BORDER).

Can one get in any way information about the direction where the collision occurs (left, right, down, up) or does it need to be handled by the program itself? Is there an example around?

Thanks

/Vincent

[+DZ-Jay]

Hi, Vincent,

 

It looks like you are progressing through a full game in your project. I can't wait to see the results!

 

To answer your question, unfortunately there is no additional information available about a collision, other than that it occurred and what was involved (objects and/or background).

 

This is because the "HIT" facility in IntyBASIC utilizes the built-in collision detection mechanism of the STIC (video) chip, which is a plane-Jane "AND" between the pixels of one object against another or the background. That is, any "on" pixels that overlap trigger a collision.

 

In Christmas Carol, I forwent the use of this mechanism because since it only triggers on screen refresh, I would have to wait for the next frame after updating the sprites to know if any collisions occurred. I used a trick similar to Pac-Man in which I computed the logical position of each sprite within a virtual-tile map of 4x4 tiles and compared their positions. Overlapping virtual-tiles resulted in a collision. It's just another alternative.

 

As for the direction, I kept track myself of the current direction of travel for each of the sprites (which was used to determine which graphic to display in order to reflect their orientation), and included that in my handling of the collision event. You may want to do the same.

 

I did not use IntyBASIC in Christmas Carol, but the principles remain the same on any language.

dZ.

[Kiwi]

Let's say you press left. if cont.left then charx=charx-1:lastdirection=1 , then the your character hit a wall. Save the direction value, like lastdirection=1 because collision will occur as the frame is being drawn by the hardware(If I understand it correctly). Then you do if COL7 AND $1 (whatever sprite number[if COL7 is background pixel collision{I need to confirm with the manual when I'm not too lazy}], or the magic number in the constant is[i think HIT1{Kinda lazy to open constant.bas to confirm, sorry }]) then if lastdirection=1 then charx=charx+1.

[Vincehood]

Hello!

thanks to you both. I think you confirm a pattern that I was suspecting. Now I know more or less what to do!

 

DZ-Jay: yes my idea would be to do a full game. I don't want to create too much hype though . I hope I will be able to allocate the time it requires. I am quite happy with the result so far and that's really thanks to a great SDK and a fantastic community.

I used to own an Intellivision with the computer extension module when I was a kid. This was my first programming experience and it was great fun to access the sprites from the cardrige games. I did not have any media to save my programs then so I was writing them on paper and re-typing them to run them. I feel I have some unfinished work to do...

 

/V

[Vincehood]

btw I have a related question.

I read about priority between sprite and background objects (how to decide which one is in the front).

How is it between sprites? Do I need to handle that in some way through collision handling or is there a better way?

In my case, one sprite should always be behind the other one.

/V

[GroovyBee]

Sprite 0 has the highest priority, followed by sprites 1 down to 7 (with 7 being the lowest). If there are two sprites with the same X and Y position, then the one with the lowest index number will be displayed on top/first, followed by the others. This effect can be used to make multicoloured sprites because if there are any unset unset pixels in a sprite's definition then either the BACKTAB card or another sprite of lower priority behind it, will show through.

To make a sprite go behind an on screen BACKTAB card just add "+BEHIND" (without the quotes) to the sprite command's attribute field.

[Vincehood]

Great, very handy!

Thanks

/V

[Vincehood]

Hello again,

after a number of attempts, I gave up the idea of using COLx + HIT_BORDER. I got the impression that when it comes to keeping the character visible on the screen, it seems to be easier to simply keep the coordinates within the screen boundaries.

I ended-up taking also a similar approach for the disc thrown by the character. I am trying to get the disc to bounce over the walls.

As in Tron deadly disc, buttons 1,2,3,4,6,7,8 and 9 are used to throw the disc. I am using button 5 to take back the disc.

Unfortunately, there are situations in which the disc anyway leaves the screen and I am really scratching my head over this.

I don't know if anyone feels for looking at my code. I am wondering if I have made some mistake in the logic or if I am simply not using the right design pattern.

Thanks

/Vincent

Tron3.bas

[catsfolly]

You need to change your collision checks to use >= (greater than or equal to) or <= (less than or equal to).

 

Currently, the disc moves 2 pixels at a time. So, if the player x position is 99 and he throws the disc EAST, the disc will be positioned at

 

99,101, 103, 105, 107, etc.

 

Xmax = SCREEN_WIDTH - BORDER_WIDTH = 156

 

So the check "IF Xd1=Xmax THEN " will fail - the disc positions will be 153,155,157,159 etc.

You need to change it to "IF Xd1>=Xmax THEN ".

 

And you need to do the same for all of your other collision checks - use >= or <= for the checks.

 

Does this make sense?

 

Catsfolly

Edited January 20, 2017 by catsfolly

[Vincehood]

Thanks a lot yes it does make a lot of sense!!

By the way, is there a way to use the debugging mode and to trace some specific variable without being an assembler expert? I guess it would help for this kind of things.

V