Some questions about collideSprites...
-
Hi!
I am feeling a bit confused about how the collideSprite method works.
First of all, what exactly does it do? The help states that it "Collides two sprites". I do not think that is very clear. Running the example shows two ships that fly by and when they collide they interact with each others movement?
So it seems that the function is supposed to be called repeatedly within the main loop to monitor and handle the interaction between moving sprites? And you need to call it with each tuple of sprites that can possibly interact?
The third and fourth argument seems to make it possible for any sprite to not be moved when the collision happens. I guess the default value for these are true. (By the way, in general, is there a way to see which default values arguments have?)
And now for the resulting return value of the function:
c.exists is true when a collision has occurred. OK, makes sense. Is it true once, and then the next time the function is called in the loop it goes back to false?
According to the help, c.a is the first sprite in the collision and c.b is the second. What does this mean? Why do I need a new reference to the sprites I already used for input to the function? Or is this something else?Then there is *c.resolution_vector representing how sprite A was pushed during the collection, and *c.resolution_vector representing how sprite B was pushed during the collection. This confuses me. The variables are called the same thing? And how do you use them? Are they vectors with the x and y distances?
I wish the example code could show us how to use the return value properly...
One last thing, there is a typo in the example since createSprite() does not take any arguments...
Sorry for asking so many questions! I love Fuze so much and would really like to understand how things work.
-
Hi there. I am also new to Fuze. I have a program where I have started to use collidesprites. I will answer what I can. First, you are right, the function is called repeatedly. In my program I check if bullets collide with a player and decide whether to blow him up. I do:
BulletHitPlayer = collidesprites(player,bullet)
If BulletHitPlayer.exists then
etc....
I do notice that my sprites move a bit when they collide and I suspect thats what the resolution vectors are. One may be from the point of view of the bullet and one from the point of view of the player. What I do for debuging is use the print() function to put the values up on the screen and that way I can understand what is happening. If they pass by to quickly put a sleep() command in. -
Yeah, I did som more experimenting, and it seems like the resulting vectors are actually called c.resolution_a and c.resolution_b. They seems to contain non-zero values as long as the collision is happening, and then go back to zero when the sprites no longer touch. I am not entirely sure how to use them though, but I am thinking maybe to implement some sort of bounce effect?
Because that is another thing that puzzles me a bit: there does not seem to be any way to control how "elastic" the collision is? The sprites sort of scrape along each other's edges, and then continue in the direction they had before. What if you want a more rubber-like behavior where the sprites bounce off each other before continuing? How would you accomplish that?
-
Maybe you could apply some logic based on the speed of the colliding sprites. You could check what the vectors are - I suspect they may have some directional information - then reverse the speed to some degree depending on how fast the sprites are moving at the time.
There is a map collision tutorial in Fuze that I dont remember the name of at the moment that has examples of balls bouncing off the map and bouncing off each other that you might be able to learn from.
-
Thanks! I'll check it out!
Do you have any idea why c.a and c.b are returned from the function? Are they ever anything else than the two sprites supplied when calling the function?
-
@vinicity I think it's more a case of,
The function checks to see if 2 things are colliding. So what it returns is the position of those 2 things. Sprite a and b.. Or piggy one and piggy two if that is preferred. You just need a name to store it within.
That's what I think that is anyway. -
You've actually caught Fuze at a bad time with that particular function page. There are errors on that page which really hurt.
I'll post here what is going to be included in an upcoming update to the help. This is what collideSprites() does:
collideSprites()
Description
Determine if two sprites have collided and optionally resolve the effect of the collision on their movementSyntax
c = collideSprites( spriteA, spriteB ) c = collideSprites( spriteA, spriteB, resolve1, resolve2 )Arguments
spriteA
Handle - Variable which stores the first sprite in the collisionspriteB
Handle - Variable which stores the second sprite in the collisionresolve1
Integer - True (1) if the first sprite can be moved by the collision, false (0) if notresolve2
Integer - True (1) if the second sprite can be moved by the collision, false (0) if notc
Array - List of structures detailing collision data. Properties listed belowc.exists
Integer - True (1) if collision occurred, false (0) if notc.a
Handle - Variable which stores the first sprite in the collisionc.b
Handle - Variable which stores the second sprite in the collisionc.resolution_a
Vector - How sprite A was pushed during the collision { x, y }c.resolution_b
Vector - How sprite B was pushed during the collision { x, y } -
Thanks a lot!
Much more helpful than the current help page... -
And just to confirm, c.a holds the same sprite as spriteA, and same for c.b and spriteB? This is just to make it convenient when processing the results?
-
@vinicity It'll be updated soon. In fact, I can tell you that a lot of big improvements to the help pages formatting and readability will be coming too :)
Until then, the incredible people on this website will put you right, I'm sure!
I'd also be happy to look at your specific case in detail.
-
@vinicity That is correct.
-
Thank you very much! Looking forward to the updated documentation!
-
This post is deleted! -
I did some more experimenting and it turns out that the c.resolution vectors are quite useful for implementing sprite bounce. I just normalized the vector and multiplied it with the desired velocity.
In my main loop I have two nestled for loops in order to monitor each possible collision with any two ships. So the collideSprite method is called 2450 times for each update(). For 50 ships this is pretty smooth, but if I increase the number of ships further, slowdown occurs... Kind of interesting.
Feel free to check out my little demo of 50 bouncing spaceships!
ID: NBYUXMND5C -
@DomDom said in Some questions about collideSprites...:
Collisions have 2 phases. Detection and Response. On first inspection, the collisionsprite function looks like it handles detection and provides the necessary info (in the form of the vectors you're talking about) to enable the programmer to implement the response as he sees fit. This would imply that you need to set the resultant velocities yourself.
Thanks, I gave it a try!
-
This post is deleted! -
@DomDom said in Some questions about collideSprites...:
@vinicity Hope it helped.
By the way, checking collisions between 50 ships would only need 1250 checks if each ship only tests for collisions with the ships that are after it in a list.
Eg. something like
for sA=0 to Len(shipslist)-1
for sB= sA+1 to Len(shipslist)
C= checkcollisions(sA,sB)
Repeat
RepeatSomething else that might speed things up is to do a simple proximity check before the collision check.
Great point! I did not think of that, but in my defence I was kind of tired last night when I did the programming. Thanks!
-
So I made a few changes and optimizations, and cleaned up the code. Fifty bouncing ships makes for a nice screensaver...
-
I just shared a new version of my 50 bouncing ships demo. Cleaned up the code, added some optimizations to make it run smoother. Also made sure that ships that disappears at one edge are moved over to the other.
ID: NBYUXMND5C
-
