Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Pages: [1]   Go Down

Author Topic: GML Problem  (Read 3550 times)

0 Members and 1 Guest are viewing this topic.
GML Problem
« on: August 02, 2010, 01:27:20 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 27
Normally I'd just figure out this simple problem myself, but I'm feeling very lazy.

Code: [Select]
if up=1 and !place_meeting(x+2,y-2,objSolid) and place_meeting(x+sprite_width-2,y-3,objSolid)
{
y-=2
x-=2
moving=1
exit;
}
up is a variable that checks if up is pressed.
objSolid is my solid parent object

This code is supposed to cause link to walk along sloped solid objects. Instead of checking if he should flat out stop moving as if there was solid on the left AND right side of him, it checks if there is solid on the right side of him, but no the left, thus implying the left facing slope. Yet for some reason just treats it like he is running into a normal solid on both sides. I'm sure it's something simple, but I'm lazy...
Logged
Re: GML Problem
« Reply #1 on: August 02, 2010, 01:59:08 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Your code's syntax makes me want to kill myself; and the overall context of the snippet you posted is difficult to determine. Anyway, I did something similar in some of my collision code for the GM Minish Cap Engine. I think that your code could be fixed up by doing:

Code: [Select]
//Logic:
//1. If pressing up, then move up.
//2. If you run into something, look for a way to avoid it if possible.
//3. If there is a way off to the left or right side, go there.
//4. If unable to move to the side, just move back down.
var corn_c;
if (up){
  y -= 2;
  if (place_meeting(x,y,objSolid)){
    for (corn_c = 1; corn_c <= 5; corn_c += 1){
      if (!place_meeting(x - corn_c,y,objSolid)){
        x -= 1;
        break;
      }
      else if (!place_meeting(x + corn_c,y,objSolid)){
        x += 1;
        break;
      }
    }
    if (place_meeting(x,y,objSolid))
      y += 2;
  }
}

The code I use in more recent versions of the the GM Minish Cap Engine uses collision_line and instance_position more though than place_meeting. In your code you used place_meeting and then did something with a sprite_width, that is is like way to the right of where the character would be. Typically you don't have to account for the width of the character when using place_meeting, you mostly use it if you are doing something involving point checks; i.e. place_meeting checks the whole collision mask, position_meeting just uses a the x/y coordinates.

The exit statement you used doesn't make much sense either; as the last statement made in the if-block, if its purpose was for leaving the if-block it would be redundant. Otherwise I think that the exit statement is exiting your whole code block prematurely.
Logged
Re: GML Problem
« Reply #2 on: August 02, 2010, 02:05:09 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 27
Your code's syntax makes me want to kill myself; and the overall context of the snippet you posted is difficult to determine. Anyway, I did something similar in some of my collision code for the GM Minish Cap Engine. I think that your code could be fixed up by doing:

Code: [Select]
//Logic:
//1. If pressing up, then move up.
//2. If you run into something, look for a way to avoid it if possible.
//3. If there is a way off to the left or right side, go there.
//4. If unable to move to the side, just move back down.
var corn_c;
if (up){
  y -= 2;
  if (place_meeting(x,y,objSolid)){
    for (corn_c = 1; corn_c <= 5; corn_c += 1){
      if (!place_meeting(x - corn_c,y,objSolid)){
        x -= 1;
        break;
      }
      else if (!place_meeting(x + corn_c,y,objSolid)){
        x += 1;
        break;
      }
    }
    if (place_meeting(x,y,objSolid))
      y += 2;
  }
}

The code I use in more recent versions of the the GM Minish Cap Engine uses collision_line and instance_position more though than place_meeting. In your code you used place_meeting and then did something with a sprite_width, that is is like way to the right of where the character would be. Typically you don't have to account for the width of the character when using place_meeting, you mostly use it if you are doing something involving point checks; i.e. place_meeting checks the whole collision mask, position_meeting just uses a the x/y coordinates.

The exit statement you used doesn't make much sense either; as the last statement made in the if-block, if its purpose was for leaving the if-block it would be redundant. Otherwise I think that the exit statement is exiting your whole code block prematurely.
The problem is that while I can perform most functions, I can't do them in that clean way, I'm just not expercienced enough. I've used GM for 2 years, and I can make pretty goods games with sloppily done code, but I have no idea where I can learn to do advanced code like that.
Logged
Re: GML Problem
« Reply #3 on: August 02, 2010, 02:21:26 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Ah, sorry about the way my previous post may have sounded. Actually when I first started coding the way I did it looked similar to your code. Transitioning from the code you originally posted to what I then posted isn't so difficult though. Instead of checking a whole bunch as the condition for the if-statement, I started small with just a check to see if the character was pressing the up key. If so, it'll move up and then if running into something will figure out if it can get around it, and if not it will just back up. Rather than seeing if the character is going to run into something at first, instead I have it just proceed forward and then figure something out if it does run into anything.

I could have explained the for-loop better. The reason for the for-loop is because the character is looking for a way to the left and right of where it is to see if it can move there, looking out pixel by pixel for sensitivity. Actually though too, I just realized something. By moving up 2 pixels up, the "corner-cutting" I used might not be as good as I am claiming my code to be - i.e. my original code has set up so that the character was just moving 1 pixel multiple times rather than more than 1 pixels a single time.

And I don't know about being able to make good games with hodge-podge bad code - for example, in the rest of your code, the character probably moves faster diagonally than he does linearly.
Logged
Re: GML Problem
« Reply #4 on: August 02, 2010, 02:27:57 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 27
the character probably moves faster diagonally than he does linearly.
WHY DOES THAT HAPPEN!!!!
It always happens and i can never figure out why. It's really frustrating. I had to add a bunsh more code just to slow him down  :-\
Logged
Re: GML Problem
« Reply #5 on: August 02, 2010, 02:34:35 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
The answer to why it does that can be best explained with a right triangle. If the legs of said triangle are 1 pixel each, the hypotenuse of the triangle is the square root of 2; a2 + b2 = c2, 12 + 12 = c2, 2 = c2, c = square root of 2. The square root of 2 is about 1.44, and 1.44 > 1.
Logged
Re: GML Problem
« Reply #6 on: August 02, 2010, 02:39:09 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 27
The answer to why it does that can be best explained with a right triangle. If the legs of said triangle are 1 pixel each, the hypotenuse of the triangle is the square root of 2; a2 + b2 = c2, 12 + 12 = c2, 2 = c2, c = square root of 2. The square root of 2 is about 1.44, and 1.44 > 1.
I partially understand...

Do you have any perferred method of fixing that?
Logged
Re: GML Problem
« Reply #7 on: August 02, 2010, 02:43:13 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 44
the character probably moves faster diagonally than he does linearly.
WHY DOES THAT HAPPEN!!!!
It always happens and i can never figure out why. It's really frustrating. I had to add a bunsh more code just to slow him down  :-\
Because the player is moving in two directions, thus the speeds "add up". Think of it this way: take a square. Put a dot in the center. Measure from the center to the left or top(which is the same as one of your players four directions). Then measure from the center to a corner. The diagonal is always longer. This equates to the player moving diagonally on a grid, thus why they move faster. Pythagorean theorem, I think?

You can fix this by normalizing the speed. I don't remember exactly how to do that, so maybe someone more math-savvy can help you with that.
Logged
Re: GML Problem
« Reply #8 on: August 02, 2010, 02:52:43 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Yeah, what Dusty said and yeah it is that dude's theorm. A way of making it so the character moves slower diagonally is to make it so the character moves at a certain rate each step, and for that rate to be larger when moving diagonally. It is a little difficult to explain intuitively or to how you've coded what you've got so far; the code in the GM Minish Cap Engine is such that Link's movement is not solely dependent on key-pressing, and I don't know if you have the entire movement in the step event of if it is actually in each of the keys.

I've actually coded Link with correct movement in each of the keys instead of the step event, lol, but the step event stuff is a little more "contained".
Logged
Re: GML Problem
« Reply #9 on: August 02, 2010, 02:57:02 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 44
Yeah, what Dusty said and yeah it is that dude's theorm. A way of making it so the character moves slower diagonally is to make it so the character moves at a certain rate each step, and for that rate to be larger when moving diagonally. It is a little difficult to explain intuitively or to how you've coded what you've got so far; the code in the GM Minish Cap Engine is such that Link's movement is not solely dependent on key-pressing, and I don't know if you have the entire movement in the step event of if it is actually in each of the keys.

I've actually coded Link with correct movement in each of the keys instead of the step event, lol, but the step event stuff is a little more "contained".
if (diagonal) SPEED *= (1/(2^.5));

It's hypothetical code, and I'm not sure how you'd figure out the player was moving diagonally, but I think that'd work...
Logged
Re: GML Problem
« Reply #10 on: August 02, 2010, 03:00:54 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 27
Yeah, what Dusty said and yeah it is that dude's theorm. A way of making it so the character moves slower diagonally is to make it so the character moves at a certain rate each step, and for that rate to be larger when moving diagonally. It is a little difficult to explain intuitively or to how you've coded what you've got so far; the code in the GM Minish Cap Engine is such that Link's movement is not solely dependent on key-pressing, and I don't know if you have the entire movement in the step event of if it is actually in each of the keys.

I've actually coded Link with correct movement in each of the keys instead of the step event, lol, but the step event stuff is a little more "contained".
Most of my code takes place in the step event, including checking keys, and following their actions. My current method is to move two pixels if not moving diagnolly, 1 pixel if you are, however this causes you to move slighlty SLOWER whe moving diagnolly... So frustrating...  
Do you think I should try to learn how to pull of more advanced code or just continue as I am?
@Dusty, I'll try your code right now  
Edit:
@Dusty I don't use the speed variable, I tell the object to move a specific amount of pixels in a specific direction.
« Last Edit: August 02, 2010, 03:02:56 am by LOZMinishRod »
Logged

Mamoruanime

@Mamoruanime
Re: GML Problem
« Reply #11 on: August 02, 2010, 03:20:13 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Using the speed variable probably isn't a bad idea; or at least use the existing xspeed/yspeed variables. Modifying an objects X/Y coordinates directly is usually a bad idea unless you're doing corrections to positions
Logged
Re: GML Problem
« Reply #12 on: August 02, 2010, 03:22:25 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 27
Using the speed variable probably isn't a bad idea; or at least use the existing xspeed/yspeed variables. Modifying an objects X/Y coordinates directly is usually a bad idea unless you're doing corrections to positions
Really? I always found using those built in variables the un-proffesional and worse way to do it. But hey, you've got more experience than me...

Once agian, should I try to learn more advanced GML, or should I stick with what I have?
Logged
Re: GML Problem
« Reply #13 on: August 02, 2010, 03:54:49 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Modifying the x and y directly is fine, relying on speed to much doesn't give you as much control when it comes to what you are colliding with and stuff. If you use the speed variable to do diagonal movement, you will run into issues with how your x/y coordinates can be non-integer numbers. The Game Maker built in functions can account for this, but using speed is kind of like a cop out; working with x and y also makes transitioning to that which is beyond Game Maker easier too.
Logged

Mamoruanime

@Mamoruanime
Re: GML Problem
« Reply #14 on: August 02, 2010, 04:00:00 am »
  • ^Not actually me.
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 9786
Modifying the x and y directly is fine, relying on speed to much doesn't give you as much control when it comes to what you are colliding with and stuff. If you use the speed variable to do diagonal movement, you will run into issues with how your x/y coordinates can be non-integer numbers. The Game Maker built in functions can account for this, but using speed is kind of like a cop out; working with x and y also makes transitioning to that which is beyond Game Maker easier too.

I have complete control relying on speed (well; specifically my own xspeed/yspeed variables). As long as you're using a properly structured finite state machine, you won't ever have any problems with it.

Then again; I don't use GM :P Although; I still don't see how any of the issues you mentioned (non-integer, etc) can be a problem as long as your state structure is correct and you're taking the appropriate steps for position correction.
« Last Edit: August 02, 2010, 04:07:17 am by Mamoruアニメ »
Logged
Re: GML Problem
« Reply #15 on: August 02, 2010, 12:16:36 pm »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 27
Once agian, should I try to learn more advanced GML, or should I stick with what I have?
Logged
Re: GML Problem
« Reply #16 on: August 02, 2010, 12:56:36 pm »
  • d(-_-)b
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 36
You should try to learn more advanced GML, but there's not too much to learn about GML so it's good if you know as much as you can.
Logged
Re: GML Problem
« Reply #17 on: August 02, 2010, 06:44:56 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
Learning some more GML is always good. But what you are trying to do is also done in the Community Project Engine. I suggest you study that as an example. And if Mammy's PureLA engine is still available it is also worth studying. Studying the work of others can teach you a lot.
Logged

Ryuza

That one guy
Re: GML Problem
« Reply #18 on: August 02, 2010, 11:33:24 pm »
  • RyuKage2007
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 290
Here's a link to pureLA if you wanted to give that a look like Niek suggested.

I was just going through it myself a bit ago:
http://www.zfgc.com/forum/index.php?topic=34230.0
Logged
<- Koholint Island - MC Style  <- Link's Awakening Photo Recolors  <- Wind Waker 3D Resources <- Super Mario Bros Crossover
  • RyuKage2007's Youtube
Pages: [1]   Go Up

 


Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved



Page created in 0.102 seconds with 73 queries.

anything