How do you make a sprite collide with a bigger sprite?

Ok, so basically I’m trying to make a 2d platformer, and the platforms are bigger than the player, plus I have no idea on how to do collision stuff. Any tips?

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 number

EDIT: 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 bolds

ah, so THATS how that works! Thank you very much! Also sticking to sprites but will ask for help with that if I end up needing it.

Ok so I’m trying to use Sphitsp in a while function, but it freezes the game. Any explanation for why this happens?

WHILE SPHITSP[TILE,PLAYER]
 PLAYERYVOL=0.1
 PLAYERY=PLAYERY+PLAYERYVOL
WEND

That will loop forever since nothing is changing the location of the sprites, so if the SPHITSPis false it stays false. (You might add a SPOFS into the loop, or just use an IF statement.)

Ohhhh ok, now I feel dumb.

Also, don’t hesitate to ask another question if you have one. I know from experience that fixing one issue usually leads to 3 more popping up.

Well, there is one issue, but I have no idea how to describe it. You can’t jump when walking against a wall, or you fall as if you have a wall jump ready when moving at a wall but I have yet to implement wall jumps, I guess?

Hmm 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.

Makes sense. Thanks!

Ok, so there’s a glitch that I can’t fix, so I’ve uploaded the unfinished engine for it, so if any of you wanna fix it, the code is QKX3QDNP.

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 just thought having an array instead of 5 separate variables would be more convenient, considering I was gonna add enemies. And as for the tags instead of numbers for detecting buttons, I didn’t know you might be able to say

if B and #a and #b

or something instead.

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.

Again, I’m not continuing this platformer. You can fix it however you like, but I’ve stopped working on it.

I did just start programming a puyo puyo clone, but I probably won’t be allowed to upload it ever. Yknow, what with puyo puyo Tetris and all that.

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.