Slayn
Level 0
|
 |
« Reply #60 on: November 04, 2010, 09:26:22 AM » |
|
I've kinda hit a hurdle here while studying the code. Noobie question. if (place_meeting(x + sign(h), y, obj_floor)) Just what exactly is the meaning of this code? I've read the GM manual and tried to find an answer on the Game Maker Community but I only know that it's suppose to determine if the player meets the object, and x and y deal with the position of the sprite, but I can't wrap my mind around what is being computed here with the sign(h) added to it. Could someone explain the thought process behind this for me? Same thing when it's (x,y+1,obj_floor) or (x+sign(h),y+2,obj_floor). I guess I just don't understand x and y properly. For reference, this code is in the obj_moveable, end step event. And thanks so much for this engine! This is my first foray into learning GML after the GM tutorials here on TIG.
|
|
|
Logged
|
|
|
|
Xion
|
 |
« Reply #61 on: November 04, 2010, 11:00:05 AM » |
|
sign() returns the sign of a number (positive negative or zero) h is the horizontal speed, I believe.
since the absolute value of h is usually greater than 1, using it directly could result in some inaccurate collisions, especially at high speeds.
so x+sign(h) shrinks h down to a more precise -1, 0, or 1 and checks that place relative to the object's current x position.
so say your character is moving left with an h of -7 x+sign(h) would be whatever the character's x is -1, since -7 is a negative number. if you're moving right with an h of 10, sign(h) = 1 it works with decimals, too, so sign(0.1) still equals 1 because it's a positive number.
and if you're standing completely still sign(0) = 0 because zero is neither positive nor negative.
|
|
|
Logged
|
|
|
|
|
___
Vice President of Marketing, Romeo Pie Software
Level 10
|
 |
« Reply #63 on: November 04, 2010, 01:54:26 PM » |
|
Thanks! I mathematically understand what sign(h) does to x now. I'm still trying to figure why you need to do that in the first place. Why does x and y ever need to be altered? Isn't it checking the characters x and y axis position? Why would adding a number to x or y need to be done? I think I just don't understand the function in general. For most platforming code that I've made and seen, you want to check positions that the player could potentially be in before moving them. So if you're about to move something to the right by one pixel, you first check that new position. Something like: if (I'm not colliding with the wall one pixel to the right of me) then set my x position to one pixel to the right of me. else don't move me because there's a wall where I was about to move. Sometimes you also want to check the position that is one pixel below the character to see if they are standing on a floor.
|
|
|
Logged
|
|
|
|
PlayMeTape
Guest
|
 |
« Reply #64 on: November 04, 2010, 02:16:12 PM » |
|
if (I'm not colliding with the wall one pixel to the right of me) then set my x position to one pixel to the right of me. else snap to edge.
I usually do this too.
|
|
|
Logged
|
|
|
|
Dom2D
|
 |
« Reply #65 on: November 15, 2010, 11:51:13 AM » |
|
Oooh why did I not know about this engine?!
|
|
|
Logged
|
|
|
|
sandcrab
|
 |
« Reply #66 on: November 19, 2010, 01:29:54 PM » |
|
 "Doctor, I fall through the floor whenever I do this."  "Vell, don't do zat!" I'm to proud to use this (great) engine directly, but it's made great improvements in my own platformer logic. I did hit one snag though (you are probably aware of it already.) When you are determining collisions with jump-thru objects, it's based on "if one is below me, and I am not inside of one," and the problem is obvious, what if you are standing on one, and you are also inside of another? Even in your sample program, where the square is only one tile tall, if you set up a level with two jump-thru platforms stacked one tile above each other, you fall right through the lower one when you overlap them both. Is there an easy fix for that? Besides not building them like that, that is!
|
|
|
Logged
|
|
|
|
Matt Thorson
|
 |
« Reply #67 on: November 19, 2010, 04:27:29 PM » |
|
 "Doctor, I fall through the floor whenever I do this."  "Vell, don't do zat!" I'm to proud to use this (great) engine directly, but it's made great improvements in my own platformer logic. I did hit one snag though (you are probably aware of it already.) When you are determining collisions with jump-thru objects, it's based on "if one is below me, and I am not inside of one," and the problem is obvious, what if you are standing on one, and you are also inside of another? Even in your sample program, where the square is only one tile tall, if you set up a level with two jump-thru platforms stacked one tile above each other, you fall right through the lower one when you overlap them both. Is there an easy fix for that? Besides not building them like that, that is! Yeah, the current fix is just don't build them like that. If you want to really fix it you need to loop through all the platforms below the player and all the platforms within the player, then check that there's at least one below that isn't within. This is a pretty expensive thing to do in Game Maker, so I opted for the cheap method that works most of the time.
|
|
|
Logged
|
|
|
|
nachito
|
 |
« Reply #68 on: December 13, 2010, 01:08:45 PM » |
|
Hey, ive been playing with this engine trying to make my first crappy game out of it, but as a profesional noob, i have tons of questions. How can i change the sprite for like, jumping or walking left and right (coding  )? i dont know really where to ask this kind of questions :> ive tried image_index, sprite_index and other functions but i really dont know where or when to use it :< any help will be thankd, even "press f1 u dumb asshole"  .
|
|
|
Logged
|
hi?
|
|
|
GregWS
|
 |
« Reply #69 on: December 13, 2010, 11:24:55 PM » |
|
What I've generally done is handle sprite stuff in its own little separate section, handled in the object's step event. I'll usually have some variables to keep track of what state the player is in (eg. mid-air, running, etc.); these would be updated in the part of the code that handles the object's movement. If I remember correctly Matt's engine already has some variables in it that could be used to figure out what sprite should be displayed at the current moment. So once you know those variables, you can just create a big if/else statement section checking the variables and changing the sprite index accordingly. Sorta like this: if(walking == true){ sprite_index = spr_walking; }else if(in_air == true){ sprite_index = spr_in_air; }else{ sprite_index = spr_idle; } Hope that helps a bit! 
|
|
|
Logged
|
|
|
|
lasttea999
|
 |
« Reply #70 on: December 14, 2010, 09:07:38 PM » |
|
Adding to what GregWS wrote:
Each object has a sprite that it is associated with. Each sprite has a bunch of frames, called subimages. Each object shows exactly one of these subimages at all times.
sprite_index: The number of the object's sprite. Set it to spr_runleft, for example.
image_index: The number of the subimage being displayed. Frames are counted starting with 0. So, if image_index is set to 2, for example, the object will show the 3rd frame of the sprite.
image_speed: The speed with which the object cycles through the subimages of its sprite. 1 means the object will cycle through subimages at the rate of X subimages per second, where X is the room speed. 0 means the object won't cycle through subimages at all, that is, it'll keep showing the current subimage.
Most of this has to do with the basic workings of Game Maker, though, so I'm not sure it's the kind of issue appropriate for this thread. Consider consulting the GM help manual; it's a nice resource!
|
|
« Last Edit: December 14, 2010, 09:13:54 PM by lasttea999 »
|
Logged
|
|
|
|
ink.inc
Guest
|
 |
« Reply #71 on: December 14, 2010, 11:06:49 PM » |
|
Just wanted you to know that without the Grandma Engine, I'd never have gotten anywhere close to where I am today, coding wise. I found it just when I started GM a year ago, and it's helped me tremendously.
Thanks, man. You've done a thing worth doing.
|
|
|
Logged
|
|
|
|
Matt Thorson
|
 |
« Reply #72 on: December 15, 2010, 12:26:32 AM » |
|
Awesome, that's really nice to hear! It's actually weird to think how long ago I released this.
|
|
|
Logged
|
|
|
|
Ant
Guest
|
 |
« Reply #73 on: December 15, 2010, 07:18:46 AM » |
|
Hmm... I can't seem to fathom out how the engine deals with the obj_player colliding with the floor. I can't even seem to find where in the code it's happening.
For my game I'm trying to go down the same collision detection route where you detect a possible collision first before moving the player to the position, but it seems quite buggy. I don't want to just copy->paste Matt's engine since I'd like to first know exactly what the code is doing.
|
|
« Last Edit: December 16, 2010, 02:51:10 AM by caiys »
|
Logged
|
|
|
|
lasttea999
|
 |
« Reply #74 on: December 15, 2010, 12:38:02 PM » |
|
If I'm not mistaken, the engine is built so that you can tell it how to deal with collisions in user-defined events 0 and 1.
I'm a fan of this engine too!
|
|
|
Logged
|
|
|
|
Ant
Guest
|
 |
« Reply #75 on: December 16, 2010, 02:53:03 AM » |
|
Ah I just realised that obj_moveable is the parent of obj_player and deals with collisions. It seems to go down the same route as my own code so it's a bit annoying that my own is so buggy. Oh well, back to the drawing board. 
|
|
|
Logged
|
|
|
|
Matt Thorson
|
 |
« Reply #76 on: December 16, 2010, 01:52:44 PM » |
|
Yeah I just did the inheritance thing so you can have multiple objects which use the movement engine, not just the player.
|
|
|
Logged
|
|
|
|
idoru
|
 |
« Reply #77 on: January 24, 2011, 08:30:29 PM » |
|
Has anyone added moving platforms, specifically vertical, to this engine?
I've made slight modifications to the original engine, including a tweak that allows the player to fall through a jump-through platform by pressing the jump key while pressing the down key. I'd like to use the jump-through as parent to the moving platform so the player can get on from below and get off by falling through.
My failed attempts, so far, have involved checks in the player step event. This has generally resulted in the player repeatedly falling with the platform (i.e. not "standing still" on the platform) while the platform moves downward, and simply falling through when the platform reaches the bottom of its travel and reverses direction upward. I have a feeling I could solve both of these problems by basing the player's movement in the current step on a look-ahead to where the platform will be in the next step. However, this would require specific code for each platform and each movement pattern. I'd rather do something more low level which would then be applicable to any moving platform without case-specific modification.
With that in mind, I assume I'll need to modify the core code of oMovable, in the end step. But that code is relatively foreign to me and I don't know where to begin modifying it. In general, I'm having trouble wrapping my head around how this should be done and any insight would be appreciated.
|
|
|
Logged
|
|
|
|
lasttea999
|
 |
« Reply #78 on: January 25, 2011, 12:04:02 PM » |
|
I made an engine partly based on this one that has moving platforms, but I ended up using what you might call a workaround. Basically, the platforms push the player around without taking into account the mechanics of the engine. If there's a better way to do it that incorporates Grandma Engine's system more, I'd like to know too!
To be more specific, the platforms themselves do use the kind of velocity featured in this engine, but they pretty much ignore the velocity of the player object (so it sorta seems to me like a workaround).
|
|
|
Logged
|
|
|
|
idoru
|
 |
« Reply #79 on: January 28, 2011, 10:02:54 PM » |
|
I made an engine partly based on this one that has moving platforms, but I ended up using what you might call a workaround. Basically, the platforms push the player around without taking into account the mechanics of the engine. If there's a better way to do it that incorporates Grandma Engine's system more, I'd like to know too! I was able to get it working the way I wanted with a similarly "brute force" approach. It's not elegant and I'm not a good coder so it's likely inefficient as well.  But it works for vertical-travel platforms and should be easy to modify for horizontal-travel. The player can fall through by pressing down and jump. If too close to the edge of the platform when hitting a wall, the player will fall off to avoid any stuck-in-wall situations (assuming the player sprite's hitbox is constant between animation frames). And any object can be made a platform by simply setting its parent to the moving platform object. In case anyone is interested in the code: Added an empty parent object oMovingPlatform. Added scrCheckPlatform: if ((place_meeting(x, (y + 1), oMovingPlatform) or place_meeting(x, (y + 2), oMovingPlatform)) and (global.FallThroughPlatform == false)) { if (place_meeting(x, (y - 1), oMovingPlatform)) { return false; } else { return true; } }
In the begin step of oMoveable, added this line: on_platform = scrCheckPlatform();
In the end step of oMoveable, added this after the similar code for scrCheckBelow: else if (scrCheckPlatform()) { collide = true; break; }
In the step code of oPlayer, I added the platform condition to this section: if ((on_ground) or (on_platform)) { accel = S_RUN_ACCEL; fric = S_RUN_FRIC; } else { accel = S_AIR_ACCEL; fric = S_AIR_FRIC; }
Still in the step code of oPlayer, I added this section just before the code for jumping (global.FallThroughPlatform is declared in the create code for oPlayer): if (on_ground) { global.FallThroughPlatform = false; }
if (on_platform) { if (keyboard_check_pressed( key_jump )) { if (keyboard_check( key_down )) { global.FallThroughPlatform = true; } else { vspd = S_JUMP_SPEED; } } }
And then in the user defined event for vertical collision, I added this (the offset is 4 pixels because my player sprite is 8x8 with the origin centered): if (scrCheckPlatform()) { ActivePlatform = instance_nearest(x, y, oMovingPlatform); if ((place_meeting(x, (y - 1), oFloor) == false) and (place_meeting(x, (y + 1), oFloor) == false)) { y = (ActivePlatform.y - 4); } }
|
|
|
Logged
|
|
|
|
|