Okok today we have another journal entry in the long quest to get an accurate fangame engine in GMS! I was looking into the walk-off align differences today, and comparing them between engines. For the following test, I took a bad align for the walkoff (imagine that the good align for a rightward facing spike is align #3, then I had #1) and then held right until the kid collided with the spike, and recorded the position at the start/end of each frame. Looking at the results from GM8.1 and GMS, it appears that the position is the exact same on every frame! Therefore this is definitely a collision issue. In GM8.1, the kid collides with the spike at (294.00, 439.87), but the kid in GMS survives at this position. Maybe it's because the position for collision is being floored (down) in GMS, where it's being rounded (up or down) in GM8.1? I don't think this would explain the issue with minispike walkoffs though...
////////////////////////////////////GMS Results:
begin of step end of step
(282.00, 439.47) (282.00, 439.47) //start position
(282.00, 439.47) (285.00, 439.47) //first step of movement
(285.00, 439.47) (288.00, 439.47)
(288.00, 439.47) (291.00, 439.47)
(291.00, 439.47) (294.00, 439.87) //should have collided here
(294.00, 439.87) (297.00, 440.67)
(297.00, 440.67) (300.00, 441.87)
(300.00, 441.87) (303.00, 443.47)
(303.00, 443.47) (306.00, 445.47)
(306.00, 445.47) (309.00, 447.87)
(309.00, 447.87) //Collided!
//////////////////////////////////GM8.1 Results:
(282.00,439.47) (282.00,439.47) //start position
(282.00,439.47) (285.00,439.47) //first step of movement
(285.00,439.47) (288.00,439.47)
(288.00,439.47) (291.00,439.47)
(291.00,439.47) (294.00,439.87) //Collided!I wonder if modifying the playerKiller collision detection in end step to round position values would make it behave the same? I'll have to do more testing. (And yes, I did bunny-hop until my v-align was identical in both tests
)
EDIT: Literally 3 minutes after I posted this I changed the
place_meeting(x,y,playerKiller) line in the end step event to
place_meeting(round(x),round(y),playerKiller) and the kid dies when you don't have the correct align! Left-facing minispikes are still acting up, so the root cause there is something else.
EDIT 2: As for the minispike/kid image_xscale issue, I'm trying to separate the block collision and move it into the end step function as well, but I can't seem to get it to work how it should... even if I do the
if (solid) x=xprevious... stuff, the kid gets stuck, stutters in the ground, can't jump, all sorts of nasty things. If we could get a working collision event in the form of
if (place_meeting(x,y,block)) then we could try rounding the coordinates differently and possibly make some progress.
EDIT 3: Ok, I should really shut my mouth and code before I start posting
I managed to get the collision with blocks working perfectly in the step event, turns out you have to do x=xprevious/y=yprevious at the start of the event,
and x+=hspeed/y+=vspeed at the end of the event... go figure. Anyway, after I did that, I changed the collision check like so:
o = collision_rectangle(x-5.5,y-12,x+5.5,y+8.5,block,1,1);where o is a variable holding the id of the block if there is one (like 'other' in the collision event). Adding 0.5 to the coordinates actually seems to work, I can walk off all the minispikes now, and only with the correct align! So the question now becomes, is it really worth switching to this arcane collision system in order to maintain a perfect replica of physics, or should we embrace the new way that GMS suggests? Leave me your comments if you have any!
