Jump to content
IGNORED

Software collision using card types


Recommended Posts

Hello,

I was reading this older thread & I like the proposed pattern that consists in encoding the card type into the unused bits of a card:

 

However I am not sure how to apply this approach when using DEFINE + SCREEN + WAIT.

Does anyone have an example?

Should one load the data to video with SCREEN first and then POKE the extra bits?

 

Additionally, is the approach possible to use depending where the card is loaded on the screen? For example: let's say I have a card representing a blue sky.

And let's say I want the top sky row to be the limit for the screen while the remaining parts of the sky should not trigger any collision. Is there a way to encode only those top row card instances with the card type?

 

Thanks

/V

 

Link to comment
Share on other sites

1 hour ago, Vincehood said:

However I am not sure how to apply this approach when using DEFINE + SCREEN + WAIT.

Does anyone have an example?

Should one load the data to video with SCREEN first and then POKE the extra bits?

You can add the 14th or 15th bits to the screen data table. So something like a plain blue sky tile would turn from $0201 to $8201(set 15th bit) or $4201(set 14th bit).  Then you can peek at the backtab by doing. #Mcard = peek($200,herox+heroy*20) and then do comparison like if Mcard = $8201 then heroy+1 or I think AND #Mcard with a value(I'm unsure of the value. I'm guessing 0x3FFF) to get the last 1 or 2 bits.

 

  • Thanks 1
Link to comment
Share on other sites

Alternatively you can define multiple GRAM cards that look the same, e.g. all of them are blank to the eye but those have different values so you can check the card as usual. In my very simple slalom game I made in the beginning of 2015, that was the approach I took to determine if the skier was inbetween two  poles, though to the player everything looks the same. It depends on how many cards you have to spend, respectively if the two upper bits would be used for boundary checking of multiple cards.

  • Thanks 1
Link to comment
Share on other sites

4 hours ago, carlsson said:

Alternatively you can define multiple GRAM cards that look the same, e.g. all of them are blank to the eye but those have different values so you can check the card as usual. In my very simple slalom game I made in the beginning of 2015, that was the approach I took to determine if the skier was inbetween two  poles, though to the player everything looks the same. It depends on how many cards you have to spend, respectively if the two upper bits would be used for boundary checking of multiple cards.

That is certainly another option, and a very popular one from what I've seen.  It does, however, consume more of those precious GRAM slots, which could be used to add more details to the scene.  I would only recommend that if the list of card types you need to account for is larger than four, and you can't find another way to track them externally.

 

    -dZ.

  • Thanks 1
Link to comment
Share on other sites

It is easier to consider a certain X or Y coordinate over a threshold to confirmate if your sprite is touching the border.

 

For example if using a fractional movement and an imaginary 4 pixel border around with a 16x16 sprite:

 

IF #x < $0400 THEN ' left border exceeded

    new_room = -1

ELSEIF #x > $9400 THEN ' right border exceeded

    new_room = 1

ELSEIF #y < $0400 THEN ' top border exceeded

    new_room = -10

ELSEIF #y > $5400 THEN 'bottom border exceeded

    new_room = 10

END IF

 

The variable new_room could be zero when the room isn't changing. You need good collision check with walls to avoid passing impossible paths from room to room.

 

Typically the card detection is something like this:

 

    #c = #backtab((#y / 256 + 0 ) / 8 * 20 + (#x / 256 + 0) / 8))    ' For top left, the plus zero expression is to adjust the offset if checking other corners, in this case top left

 

When handling a map with multirooms, you need a table of cards to walls.

 

For example:

 

    IF collision_room(room * 24 + (#c AND $01f8) / 8 ) <> 0 THEN  ' We have a collision

 

Supposing there are only 24 cards per screen. And you'll fill manually the DATA table for collision_room (24 values for each room).

 

The collision handling is highly dependent on the game. For example, if you have speed variables you could make the player to reboot, or simply adjust the X,Y coordinates to be outside the collision.

 

 

 

 

  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

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

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...