Fangames > Engines
I Wanna Be the Engine KS Edition (For GMStudio)
zebbe94:
So there is a problem I'm having with this, saves won't work after closing the game, even after creating an executable. I dunno if others are having this problem too though.
I've also tried the engine out on the early access (aka beta) version of gms, and in that version the 2 block trick doesn't work. This makes me a bit worried things may break when gamemaker gets updated. :/
Also here are a few suggestions:
* It would be nice to have a template room like in the Seph engine that you can duplicate (just an empty room with all the right settings)
* Have a default savepoint that will be there no matter what difficulty you're playing on
* It would be nice to have a d aligns when in debug mode
* I also kinda like the idea of having the old gm icon like some others mentioned
Other than that and aligns being messed up this seems really nice :)
klazen108:
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...
--- Code: ---////////////////////////////////////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!
--- End code ---
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 :Kappa: )
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 :Kappa: 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:
--- Code: ---o = collision_rectangle(x-5.5,y-12,x+5.5,y+8.5,block,1,1);
--- End code ---
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!
kilgour22:
--- Quote from: klazen108 on June 10, 2015, 10:35:46 AM ---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!
--- End quote ---
Personally, my vote would go towards keeping the physics true to GameMaker 8.0/8.1. However, if lots of people would like to give the GMS physics a try, then I would be open to the new physics as well.
pieceofcheese87:
I'm fine with new physics, but i'm sure all the pixologists would not be
infern0man1:
Pixologist here :Kappa:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version