 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MMBasic and sprites - questions
| Author | Message | ||||
| Decoy Senior Member  Joined: 02/08/2019 Location: DenmarkPosts: 109 |
Hi guys I am trying to understand how sprites work in MMBasic (4.5C). Does it involve having objects (presented by sprites), and then creating instances of those objects on the screen? Also, how are collisions handled? Is it in the vein of "if <instance_1> collide with <instance_2> then something"? Say, if I wanted to create a moving sprite, would I do like this?: c = 200 d = 200 sprite on jumpman, c, d movement: if keypress = 128 then d = d - 1 if keypress = 128 then SPRITE MOVE jumpman, c, d goto movement Ceptimus, you must know something about this :) |
||||
| Decoy Senior Member Joined: 02/08/2019 Location: DenmarkPosts: 109 |
Okay, I just found the collision() under functions in the manual. So, collision(n, SPRITE) where n is the name and the entire sprite is used as detection mask, yes? So, how can I choose different actions for different sprites? Thanks! |
||||
| ceptimus Senior Member Joined: 05/07/2019 Location: United KingdomPosts: 130 |
You can only check any one sprite at once, and you can check if it's collided with the edge of the screen or ANY of the other currently enabled sprites. The collision check can be 'just touching' which is good if you want say balls bouncing off each other, or you can check for 'overlap' when one or more of the non-transparent pixels of a sprite are at the same screen location(s) as those of other sprites - this is better, for example, to check whether one of the guardians has killed Willy - just touching is okay, but overlap is deadly! If you only want to check one sprite against some other sprites - one or more but not all of them - then you can't do it directly, but you can temporarily switch off the sprites you don't want to check against. If you switch them off, quickly check and then switch them back on again, you probably won't even see that happening because it's so fast - the worst that might happen is the sprites flicker a bit, but they do that anyway when you're moving them around. The information you get back when you do the collision test tells you if the top, bottom, left, or right sides of the sprite have touched something, and whether it's just touching or overlapping. |
||||
| Decoy Senior Member Joined: 02/08/2019 Location: DenmarkPosts: 109 |
Okay, thanks for the explanation. Do the sprites flicker a lot when moving? Are there any option of measuring distance between sprite? Such as measuring distance from player_sprite to a certain point (x, y) on the screen or to another sprite(s) wherever they may be located. Thanks! |
||||
| ceptimus Senior Member Joined: 05/07/2019 Location: United KingdomPosts: 130 |
Another way to check - say you have ten sprites and you check each one for collision. If only, say, sprite 3 and sprite 7 return 'true' then you know sprite 3 has collided with sprite 7 - you don't have to switch any of them off for that sort of test. Regarding distance, there is no easy way to get an exact pixel-distance separation, but remember it is your program that has to move them around by specifying the coordinates of the top left corner of their bounding boxes - and you can calculate the distance between those top left corners - square root of ((x1 - x2)^2 + (y1 - y2)^2) |
||||
| Decoy Senior Member Joined: 02/08/2019 Location: DenmarkPosts: 109 |
So, it does seem that MMBasic can be used pretty well for games! I just watched your Manic Miner video again, https://youtu.be/yEhipN9reYU, and the sprites doesn't seem to have visual flicker. Actually, the game looks amazing. |
||||
 Print this page |
