The wall sliding doesn't cancel the velocity along the normal of the contact. The result is the walls can seem sticky and make the object jump around corners.
I don't have a login to the bug tracker or idea platform but here is how I've done it with event based wall sliding. As long as you get the collision normal you can calculate the normal velocity(vn) with a dot product. We only need to cancel the velocity going into the solid so min is used to get rid of the velocity going away.
vn=min(0, vx*cos(normal)+vn*sin(normal));
vx-=vn*cos(normal);
vy-=vn*sin(normal);
Maybe I’ll read it more closely later then.
Regardless I’ve found events to run significantly slower than the same logic in js, especially with loops. I just thought there is likely a lot of room for improvement.
That’s talking about how JavaScript is faster than gml, it’s not talking about events. No matter, carry on.
Nice. All we need now is the speed of events to catch up since we will be limited by cpu way before gpu at this point. Although I guess JavaScript was given more priority to solve that problem.
The camera tilt is a nice touch.
Is there any plans to narrow the gap between the speed of event blocks and JavaScript?
The reason gml exists is likely the same reason event blocks exists. It’s a simple way to code a game without all the complexity of programming languages like c/c++/c#/java/javascript/etc. there are pros and cons to using an existing language or a custom one.
No language isn’t without its quirks. JavaScript has many. Even the event blocks have some quirks with picking. Although I will say events are what keeps me using construct. The editor is nice too but really, there are many many other options if I want to code in JavaScript.
Member since 15 Jun, 2009