Collision without "Physical Response"?

[Hblade]

Is there a way to make a collision event without using Physical Response?

[Camper1995]

Yes, I was thinking about this too and I must tell you, that is really easy.

First make variable called "collision" or however you want.
Then you just add. When player collide with object > collision=0;

Collision finish>collision = 1;

Ok. Then just put on draw actor: If collision == 1 {speed}

I think this should be work.
________________________________________________________________

CAmPeR

[Hblade]

Cool thanks So simple yet effective + 1 :3

[Camper1995]

Hehe No problem

[Hblade]

This will prevent lots of lag ^.^

[Camper1995]

Sure it will. But I was testing that and if you have too high velocity, you actor go trough the colliding object. :S

Dont know, maybe its just wrong in my script

[Thanx]

No, the reason is GE's collision detection misses collisions, because the actors simply go through eachother from one frame to another. The way the whole thing works, is that the objects are not moving, but teleported every frame. Collision detection makes sure that when an actor is teleported next to, near, or on another one, then it checks to see wether they really met, then does the actions.
At high speeds the teleport takes the actors farther, and the result can be that one of the actors simply get teleported to the other side of the actor... It's GE's collision detection that needs to be corrected...

[Hblade]

That's correct, thankx but if you were to use specify rather then the original, for example:

You won't run into that problem Even if the frame has the actor skip like 40 pixels it'll still collide correctly. Atleast I think thats how it works because one time I did have the perfect collision

[Thanx]

Ok... Well YOU have the codes for GE and not I!!! Maybe you could check out what's the reason for that?

[Hblade]

I think the reason is because the actor's graphic doesn't load if he's being transported like, say if he is here:
[]
[]
[] o.o

And he moves left to the size of the wall, he will be here:
___[]
___[]
o.o[]

But if you use specify, it loads the pathway that he's going I think... Something like that so if he's going to be colliding with the wall, it'll calculate the remaining pixels he is from the wall and then prevent him from moving that far

[DST]

It's GE's collision detection that needs to be corrected...

I wouldn't say that it needs to be corrected, because for most things it works just fine. If ge were to use a predicting method of collisions based on angle and velocity, you'd have two major problems:

1. it would gobble cpu with high actor count. My games 'Monkey Apocalypse' and 'Orbs of Death' would not be possible.

2. it would have just as many errors, because actor speed and velocity can change anytime. If you have four actors bouncing in a cluster, then the first two collide, and their velocities change. So which velocity do we use? The one going into the frame, or the one after the last collision in the frame? In the latter case, collision priority would be a matter of the order in which the objects were rendered, by their position in a. the actor list and b. their cloneindex.

Predicting the outcome would be impossible for you, the user. While order is still determining the current collision method, at least its based upon the actual xy position, rather than predicted position. That means a much more realistic outcome of a cluster of 4 actors than if you used the predicting method. The last actor might not collide with anything at all because the other three are predicted to be somewhere else by now, resulting in a visual collision that you saw happen with your own eyes, yet resulted in no physical response at all.

I believe Ge's method is as good as it gets, and it is based upon methods that are used in games industry wide.

The old saying rings true: Better, Faster, Cheaper. Pick two. Ge is designed to let you make whatever game, not just certain types. And there's no way Mak can predict what you are going to make next.



A side note on previously mentioned issues with "left side of block collision takes precedence over right side collision in platformers". The reason for this is actually quite simple:

When you test for collision, you flip thru the pixels of each actor until you find two pixels that are in the same space and both not transparent. When that collision is found, the script stops, and enacts your collision event, therefore left(min) will be found before right(max).

If it did not dump the script upon finding the first colliding pixel, but instead read through the entire pixel array of both actors, the speed would be reduced exponentially. And with a platform that exports to phones and gp2x, speed is of the essence.