How do you make a sprite collide with a bigger sprite?
Root / Programming Questions / [.]
FinnowCreated:
Hmmm it’s been a while since I’ve done something SB related on here...
I’m assuming the platforms for your game are sprites? If so, you should be able to initiate collision-checking between the player and platforms simply by doing
SPCOL player-sprite number SPCOL platform-sprite numberEDIT: you have to type SPCOL a whole two times 😰 Then, to do something (like keeping the player from falling) when the sprites actually collide, you’d write something like
IF SPHITSP(1,0) THEN ...with the two numbers being the two sprites you want to check for collision with. This would be pretty inefficient, however, since you’d have to make sprites for each platform and put them precisely where you want. It would be better to put the platforms directly into your map (if you’re using one) and then figure out collision for the player and platform map tiles. Um anyway this has been going on long enough. Tell me if you’d like to try the slightly more complicated map-tile solution, or stay with the easier-to-understand solution with sprites for the player and platforms
oatmeal
I think I used too many italics and boldsHmm that does sound odd... the only thing I can think of is perhaps your wall collision is counteracting your jumping. Like when you walk into a wall you would do SPOFS X-1, Y or whatever it is. Then your jumping, though I don’t know how you’ve made it work, could be messing with that X-1 somehow. I’m not really sure, though, just a guess.
One thing I'd recommend is to use multiple variables for the player position (PLYRX, PLYRY, etc.) rather than an array (PLYR[4]) since It's easier to understand PLYRX than PLYR[0]
Also, if you want to check if a button is being pressed, you should use B AND (button number) This will detect the button even if other buttons are being pressed.
You can use constants like #A, #B, #LEFT, #RIGHT, etc. to avoid having to memorize the button numbers (so, IF B AND #LEFT THEN ...)
I took a look at your code, and I see a Stack Overflow error. You are losing stack memory on every level change because you use GOSUB without RETURN. Stop using GOTO/GOSUB, it does that way too easily. You only have one call to each and it still bit you. You should practice functions so you can use those instead, they are much better.
Using sprites instead of BG is an interesting design decision. However, you only get 512 or so. If you finish the game you aren't going to have many left over for coins and enemies, etc. However, I think Passocom mini took away the BG system and added more sprites to compensate. Maybe SmileBasic switch will do the same thing. I will consider it a contingency plan. That and I think you want the Sprite collision system to do the work of background collision for you.
Speaking of which, you probably don't want collision turned on for sky sprites (dark blue). Also you seem to be recreating the entire level every frame, move that outside of the main loop. I would suggest calculating the new position and testing it with sphitrc before moving the player.
I tried playing around with it, but I ended up just taking out all the collision code and putting in my own, and still you can slip into a block on a corner if you try. Not very helpful to post it yet because of that.
I was thinking of making a platformer game tutorial series. It would be very long. You wouldn't even get to platforming until episode 3 and may never get to sloped terrain or moving platforms. Would anyone want me to make that? Again long and complex, not a beginner tutorial.
Well OK, be that way, I was only trying to help. Guess I will count that as a no on the tutorial series idea too. Sniff sniff, woe is me.
By the way if you don't take the Puyo Puyo name, story, graphics, music, or sounds and change up the gameplay a small amount, you probably won't have any problems. I mean how many Street Fighter II, Doom, Side Scrolling Beat-em ups, Racing Games, and so on and so on are there.