next »

[MaloEspada]

I think I have an easier solution that I've been using for years:

Code:

//deactivates everything
instance_deactivate_all(true);

//activates some stuff you want to be on all the time
instance_activate_object(player);
..
other instances

//activates stuff on the screen
instance_activate_region(view_xview,view_yview,view_wview,view_hview,true);

it only activates the one on the screen and the ones in the middle of the code (like player)

[JoGribbs]

That seems to work rdein, thank you very much

[Landshark RAWR]

How can I make an object tell whether or not it is overlapping another specific object, like making a collision event turn a bool on while overlapping then off when not.

cuz i duno hao too do dat

[GZ]

How can I make an object tell whether or not it is overlapping another specific object, like making a collision event turn a bool on while overlapping then off when not.

cuz i duno hao too do dat

In GML using the step event (this would be in the object you want to know the overlapping status of):

if (place_meeting(x,y,oWall)) overlapping=1;
else overlapping=0;

OR

Using GM systems:

- Begin Step code

overlapping=0;

- Collision event with object group:

overlapping=1;

- You could then reference the overlapping value in the End Step event (you must use the end step, as collision checks in GM happen after the step event).

The benefit of using the step event code is that you can specify an object ID instead of an entire object group and you get the results instantly. Example using ID:

if (place_meeting(x,y,someObjectId)) overlapping=1;
else overlapping=0;

[Landshark RAWR]

Awesome it works awesomely

Thanks

[sandcrab]

I'm looking for a good way to land a platformer character smoothly on the ground.  I have something reliable going on here, but often times the player "stops" in the air moments before landing on the ground and then falling again (and connecting properly), or he doesn't land consistently at the same y-value (ie, sometimes he's above or below the ground by a pixel), or when jumping up to a platform to the left or right, he ends up inside the tile by one pixel vertically, making him unable to move left or right, but he can jump to get back to the top and then move again.

Currently this is what things look like.

//if (!place_meeting(x,y+vspeed+1,oWall)) && (!climb)
if (place_free(x, y+vspeed+1)) && (!climb)
    {
    if (!hit) jump = true;
    gravity = myGravity;
    if (vspeed > maxFall) vspeed = maxFall;
    }
    else if (!climb)
        {
        jump = false;
        jumpPower = 0;
        gravity = 0;
        //y = oWall.y - 8;
        move_contact_solid(270,2);
        vspeed = 0;
        if (hit)
            {
            hit = false;
            invincibleTimer = invincibleTime;
            }
        }

The commented text is from an experiment--I don't trust that move_contact_solid to do what I think it is doing (or the way I think it should work?), and if I could somehow get the ID of the tile/object he lands on, then I could move him myself to the top of that tile (player origin is at the bottom of his sprite).  I don't know if that's a great method or not though.  Move_Contact_Solid works great where I use it for horizontal collisions.

Something else that I just don't understand in general is needing the +1 in the condition statement (place_free(x, y+vspeed+1))--I know that if I don't have it, he lands embedded into the ground by one pixel, so I can see what it corresponds to, but if I change it to +5, he "hits" 5 pixels higher and then lands on the ground, the same as if it were +1.  

If it would help (in case the problem lies elsewhere) here's a link to my GMK file: http://www.starquail.com/michael/tinyblog/tinybarbarian_OLD.gmk (the code is in the step event of the oBarbarian object).

[xerus]

I highly suggest checking out Matt Thorson's Grandma Engine for platforming.  Trying to use the built in vspeed and hspeed with move_contact_solid stuff is going to drive you insane.

[caiys]

I'd recommend against using solid objects in general since they can be bit buggy in my experience. Here's the landing code I use in Straima when the player collides with a Wall object.

Code:

// Collision with ground
if place_meeting(x,y+3,Wall)
{
  y = yprevious;
  vY = floor(Hero.y);  Hero.y = vY;
  while !place_meeting(x,y+1,Wall) {y += 1;}

  vspeed = 0;
}

What's happening is that if the player collides with the ground then the player is moved to it's previous location and moved down a pixel at a time until it's 1 pixel above the ground. The floor() is in there to prevent the situation you mentioned where the player is at a certain y value but the sprite is drawn a pixel below it.

[GZ]

I'm going to second the idea of taking a look at or using Matt Thorson's platform code. It's very good and can be modified easily, just make sure to credit him.

Expanding on the point that using solid objects is usually a bad idea, and sometimes certain other built-in GM systems like vspeed / hspeed, it's because GM does things behind the scenes that you (and most GM users) don't know about which cause unexpected behaviour. In the case of solid objects and collision events, solid objects set the x and y to the positions prior to collision, which is why something like the code Ant posted makes more sense (just sets the y to the previous).

[Glyph]

I like to get rid of vspeed entirely in my code, favoring a homemade version like in Matt Thorson's engine. Vspeed's a bit nasty because if it's greater than the width of an object you want to land on, you have a potential of passing right through it, among other things. The way I do jumping involves just one variable in its base form:

Code: (Step Event)

//Variable "vs" has been set in the create event
if keyboard_check_pressed(ord('A')) and !place_free(x,y+1) then { //if you press A and there's solid ground below you, perform the next line
vs=-8; } //jump height, alterable
if place_free(x,y+1) then vs+=1; //Gravity, of a sort
if vs!=0 then repeat(abs(vs)) { //if you're moving, perform the next line
if place_free(x,y+sign(vs)) then y+=sign(vs) else vs=0; } //simulates jumping\falling

In my experience, eliminating most GM presets gets rid of the "if"s in platforming.

[sandcrab]

Thanks a lot for the input!  I'm still figuring out what is happening in the Grandma Engine though, even with comments it isn't that easy for me to decipher, but I'm working on it!

That said, Caiys' solution was exactly what I needed at the moment (it even works against ceilings!)  Thanks again, guys

[caiys]

I seem to be having some strange oddities using Chevy's surface scaling. On some random objects it seems to crunch or expand a pixel line. You can see it on the speech bubble below.



Usually I can stop this if I add a 1 pixel transparent border around the outside of the sprite but sometimes that doesn't work either. I can't find any pattern to it either, it's just random, an object can be fine one playthrough and suffer from it the next time. My other two games which use the surface scale look fine, so I'm guessing it might be because I'm using quite a big room for this game (2150x900).

[GZ]

Make sure your objects are at integer locations and not floating point locations. IE:

x=30
y=50

Instead of:

x=30.1
y=50.25

This can happen for any variety of reasons (ie. non-integer movement, bad placement), but a simple way to fix it is by flooring / rounding / ceiling your drawing:

draw_sprite(mySprite,0,floor(x),floor(y));

draw_text(floor(x),floor(y),"mytext");

If you do not use draw commands to draw certain things, you must do so by using a generic drawing script so that they appear correctly. IE:

draw_sprite_ext(sprite_index,image_index,floor(x),floor(y),image_xscale,image_yscale,image_angle,image_blend,image_alpha);

If this does not fix it, it might be because the scaling script is not using surfaces and is instead reverting to GM scaling. GM scaling can have this problem on some video cards.

[caiys]

I'm pretty sure it's not a rounding problem since many of the objects that suffer from it don't move. I can't really test out whether it's a surface problem because I seem to have one of the few comps that correctly scales GM game sprites without them blurring, so to me surface scaling and GM scaling look the same so I guess that could be the problem.

[GZ]

I'm out of ideas based on what I'm seeing. The only real suggestion I have left is isolating the problem and posting it up here (make a copy of the game, delete everything but the problem, upload).