Collision effect doesn't fire up above center

[lverona]

Hey guys!

I am making my first game here. Using a CollisionFree method I looked up from Game A Gogo.
I am using a Collision event on Bottom of Player though to fire up sounds and other things when the player lands on a platform.

Problem is - when my player goes above the center position of GE, platforms stop receiving Collision events on Bottom of Player for some reason, although they receive Top events just fine. What could be the problem?

The game is attached.

[skydereign]

That system isn't meant to use collisions at all. The reason one would want to use CollisionFree is to avoid having to deal with collisions (which can be very inefficient). You gave the collision event to the platform actor, which means every single clone will have to check if they are colliding. It would be better to have the player own the collision event. But, since you are using CollisionFree, you should just add the sound code into the ball's draw.

[lverona]

Okay, I understand. But how in that design then you deal with things like entering a zone (which can be made with a wire frame region) and having something happening or dealing with specific items?

For example, I have moving platforms. When the player steps on the platform, he should become a child to that platform so that they move together. Should I put that into Draw Actor as well? Wouldn't that make writing the game very difficult?

Also, I would be worried about game speed - so much conditions in Draw Actor which happens every frame!

[lverona]

Oh, by the way, it still does not explain why events stop firing up if the object is above center. I understand using collisions with that method might be wrong methodologically, but shouldn't collision events register above the center? Or there is a principle at work here I do not understand?

[skydereign]

One actor's draw frame won't slow the game down, unless you use loops for very large amounts (or the equivalent in writing out thousands of lines). Now you can still use collision events, there is nothing wrong with that, but that system you put in draw is meant to handle a specific type of collision. It handles the collisions in the actor's movement system. So any similar type of collision should be incorporated into the same system (namely the player sound noise when they land). Of course that CollisionFree method gets messed up by any other actor that has doesn't have their collision state disabled (so it makes it harder to handle collisions of other things).

As for the actual reason it isn't working, I assume it has to do with the fact that that system isn't meant for collisions at all. It is supposed to stop you right above the platform, so the collision event doesn't trigger. I didn't look too much into it, that is just an assumption, because that draw actor is by far one of the hardest to read bits of code in gE I have seen (despite it being very simply structured). I'll take a further look to see if my initial thoughts were correct.

-Edit
And indeed you begin to be floating one pixel above the ground.

[lverona]

Thank you for looking into this, this was my assumption as well, however, it does not explain why object below the center of GE do register the Collision event.

ps: I did incorporate the sounds into the Draw Actor loop, it works very well.

[skydereign]

The problem I believe has to do with casting. C truncates doubles and floats when casting into an integer. CollisionFree uses integer xy values, so we are dealing with some level of truncation. Now take the following two examples (your code to determine landing uses y+yvelocity+1, and your gravity is 0.16).
ball.y=-2;
y+yvelocity+1 = (-2) + (0.16) + (1) = -0.84 = 0
ball.y=-1;
y+yvelocity+1 = (-1) + (0.16) + (1) = 0.16 = 0

Notice how there is no difference between one pixel (along y=0). Because of this truncation, all negative values less than -1 of y will be a pixel offset from the same calculation dealing with positive values of y. This makes sense because truncation removes data, which will always make the number closer to 0.

To avoid this problem, you can force the actor to be a pixel lower, that way you aren't floating above, by switching +1 to -1 (a cheap hack, but one pixel floating above is far more obvious then one pixel lower in the collision).

-Edit
Fixed the example.

[lverona]

Ha! Fantastic! So in "above center" case we are not really touching the platforms and Collision never occurs!

I think this should be taken into account.

I have actually made a small improvement to this ColisionFree Engine by working with the coefficient which stops you from getting stuck in the ceiling if your jump is very fast.
Commented the Draw Actor code here, in case it would be useful to someone:
viewtopic.php?f=6&t=9992&p=84257#p84257

[lverona]

To avoid this problem, you can force the actor to be a pixel lower, that way you aren't floating above, by switching +1 to -1 (a cheap hack, but one pixel floating above is far more obvious then one pixel lower in the collision).

Tried it. Problem here is that some platforms I use in the game are not very flat and have some decoration on it, as if they are dirty. That makes the view jitter. I could make perfectly flat platforms and add decoration above of course...

[skydereign]

I was using your game when testing it out. It should work fine (does for me). Unless said tiles don't already exist in the file you uploaded.

[lverona]

Probably did something wrong yesterday. Works fine now.
Thanks for your help, skydereign!