IMprOVE_WRAP solves this by providing a new function, iw_draw_self_wrap(). This new function augments the default draw by drawing the calling instance four additional times, at positions left, right, up, and down from the actual instance, the width or height of the wrap region away from the actual instance. This is not a big deal if the instance crosses the wrap boundary quickly, and has a relatively small sprite but for slower-moving instances, or instances with larger sprites, it creates a jarring “jump” effect, where suddenly the instance appears on the “post-wrap” side of the boundary, with no real warning, rather than gradually entering the room. If the instance is off the edge of the wrap boundary, but hasn’t yet crossed over, the instance draws on the “pre-wrap” side of the room after the instance progresses by margin pixels over the border, then the instance’s position is moved over to the “post-wrap” side of the room, and the instance is drawn there. With move_wrap(), an instance still draws its sprite in the default draw in only one location: at ( x,y). Wrapping instances can (optionally) draw themselves on both sides of the border With move_wrap() the margin argument which determines the margin by which the instance must be outside of the room is the same for both horizontal and vertical travel with iMprOVE_WRAP the horizontal and vertical margins may be set independently of each other. IMprOVE_WRAP allows you to define a “wrap region” - a rectangular area inside the room, which instances wrap around the borders of, rather than the borders of the room. But in many games, the “play field” may not be synonymous with the entire room - the room might have a border, or “dashboard” or “heads up display” which ideally should be considered “out of bounds” with regard to the play field. This means that move_wrap() is only useful when an instance moves outside the room, or encounters the edge of a room. Wrap region no longer limited to room bordersĪnother problem with move_wrap() is that it is intended to work with the Outside Room or Intersect Boundary GML Events. IMprOVE_WRAP eliminates this dependency, so that an instance no longer need to use the GML speed variables in order to wrap wrap behavior in iMprOVE_WRAP is based entirely on an instance’s x,y position. When they do so, they are often confused when they discover that move_wrap() doesn’t do what they expect.
Many GM:S users will implement their own movement systems that eschew these variables, in order to give themselves complete control over the movement engine.
But you can also “move” an instance by changing it’s x and y position in the room, without setting a speed. In standard GML, the variables speed, hspeed, and vspeed are used to move instances. One of the most troublesome limitations of move_wrap() is that it only works for instances that have a speed. iMprOVE_WRAP improvements over move_wrap() Wrap behavior is no longer based on the built-in GML speed variables. iMprOVE_WRAP addresses these limitations, resulting in a more powerful, flexible implementation. GameMaker: Studio has a GML function, move_wrap(), which is intended to provide this feature easily, but it has a few limitations. Many video games have the feature that exiting one side of the screen will “wrap” you around to the opposite side - notable examples of this include the smash hit classics Asteroids and Pac Man.
Today I’ve released a new asset on the YoYoGames Marketplace, called iMprOVE_WRAP. Why arguing about Link’s gender is dumb, and why it’s important.“Null Room” hidden in Superman (Atari, 1979).video games, programming, the internet, and stuff
0 kommentar(er)
