Vincehood Posted April 6, 2021 Share Posted April 6, 2021 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 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted April 6, 2021 Share Posted April 6, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
carlsson Posted April 6, 2021 Share Posted April 6, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted April 6, 2021 Share Posted April 6, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 6, 2021 Share Posted April 6, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Vincehood Posted April 6, 2021 Author Share Posted April 6, 2021 Thanks everyone for the great guidance as usual, will try to digest all of that! 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.