Jump to content
Banner by ~ Ice Princess Silky

Rikifive

Support
  • Posts

    3,436
  • Joined

  • Last visited

About Rikifive

  • Birthday August 20

Title

  • Title
    Pixie Pink Pony

Contact Methods

Profile Information

  • Gender
    Male
  • Location
    Poland
  • Interests
    Game Development
    Games
    Digital Art
    Pixel Art
    Music Composing
    MLP (apparently)

MLP Forums

  • Role
    Support For All Your Needs
  • Favorite Forum Section
    Site Questions & Tech Support

My Little Pony

  • Best Pony
    Rainbow Dash
  • Best Anthropomorphic FiM Race
    No Preference
  • Best Mane Character
    Rainbow Dash
  • Best Episode
    Winter Wrap Up // where it started :')
  • Best Song
    Winter Wrap Up // ah memories... c:

Recent Profile Visitors

116,232 profile views

Rikifive's Achievements

Bat Pony

Bat Pony (19/23)

  • 12th Birthday of MLPForums
  • Testing 1
  • Friendship Week 2023
  • Friendship Melody - Winter Wrap Up
  • Greeter

Recent Badges

23.4k

Brohooves Received

8

Community Answers

Single Status Update

See all updates by Rikifive

  1. Welp, I've been struggling with this the whole weekend...

    CHSMW1t.png

    While things were working fine all the time, I've implemented .. let's say, "limitations", to make it more accurate to the pixel environment and stuff.

    So, first things first, Twilight's position (x and y coordinates) are no longer float numbers. They always are integers now, so Twilight won't be able to stand between pixels anymore. These integers are used for collision calculations, so that should be pixel perfect now as well (and maybe make stuff easier for the engine? idk).

    For that I had to make the code a bit more messy by adding more variables and calculations (because just flooring/rounding her coords would be asking for troubles)... There are variables that store fractions and once they'll gather 1 or more, the integers are deducted and added to the distance the character is about to move.

    Soooo, if you'll press a key for a liiiiiiiiittle moment, Twilight won't move, but that tiny speed will bump the fraction. If you'll keep doing this, the fraction will eventually gather an integer, passing it into the distance variable, making Twilight move by that one pixel, if there won't be a wall, that is.

    Making her pixel perfect wasn't hard. What I had problem with is the camera movement. If I'd stick the camera to her (like in Terraria, for example), everything looks perfect even when she moves that 1-2-1-2-1-2-1-2-1-2 pixels per frame. However, the camera in my game moves smoothly (but its position is also all in integers ofc), following Twi and the direction she is facing. The longer the distance, the faster the camera moves (like in Cave Story, for example). That generates problems in such tiny pixel environment, because 1 pixel is rather big, so when Twilight moves between pixels and the camera follows her with a bit of delay and not fully static speed, then at certain speeds the camera isn't synced well with her, making Twilight shake between frames, if I could name it that way.

    Camera doesn't have collisions, so I was just flooring/rounding the coordinates to full pixels, but that made its movement less accurate, so I decided to do the same thing as I did with Twi. The camera also has separate variables for fractions, so that its movement is pixel based, thus more accurate to the one Twi has. This... Partially solved the issue, at least she's not shattering at full speed anymore and that was the worst case, so that's kinda a win. When she's just starting to move and her speed changes, there may be occasional desyncs, but I think it's acceptable and I guess that's something I'll have to deal with if I want that camera to be smoother. I recall Cave Story being a bit choppy as well.

    Welp, that's what I could do for now I guess. I wonder if there's a trick to sync that camera to her, but I was trying and trying and every approach resulted in the same thing. That smooth following is what clashes with the pixel environment, but at this very moment with what I have it's not that bad.

    In the end things work, so that'll do for now. :P 

    1. Show previous comments  4 more
    2. Rikifive

      Rikifive

      @Treeglow Flicker Oh I'm not a fan of it either. :P Depending on what kind of movement and collision you have, it tends to get really, really tricky, I know that feel. It took me a while to setup that properly, imagining behavior, drawing on paper - boxes and walls simulating movement frame by frame to get the idea of what to expect - when and where's collision and what to do to handle that. At first I had some funny things, like teleporting, getting stuck in a wall or the worst - getting the game stuck in a loop, freezing it. EDQ7xNk.png It's a bit confusing yeah, but I think I got it now, haven't bumped into any issues. :P

      @Bas But that's the opposite - Twilight in my game doesn't move fast, but slow - just 1.5 pixels / frame. And if I recall correctly, Ponyvania handles the camera in a different way - it's sorta centered to the character, it is dragged by the character at the same speed, where in my game it smoothly follows the player, introducing tiny fractions.

      (the gif is a bit choppy, 'coz it has a limited framerate, otherwise it would be too large; It's already pretty big as it is)

      JvXInW4.gif

      Ponyvania pretty much does what I've mentioned earlier:

      Quote

      If I'd stick the camera to her (like in Terraria, for example), everything looks perfect even when she moves that 1-2-1-2-1-2-1-2-1-2 pixels per frame.

      The problem is the smooth approach I have, where the camera has its own dynamic speed depending on the distance to target, rather than being dragged by the character at the same speed. In short, what I have is something Ponyvania doesn't have.

      Besides, I'm a member of that server already, I've been invited by someone earlier, don't remember by who though.

       

      @HereComesTom Yeah, your game has a simple system, where the character either moves at static speed or doesn't move, so no sliding, friction and that stuff. Moves and suddenly stops. :P There's nothing wrong with that of course, it all depends on what you want to have in your game and such static speed is a totally viable option used in many games. So, this decision is entirely up to you. :P 

      Though one thing I could suggest considering is to smoother the vertical speed a bit. The character is going up at static speed for a specified amount of time and then suddenly sharply goes down at the same speed without slowing down in the middle. So basically jumps are "V" shaped, which is a little bit odd in my opinion. With horizontal movement it's totally fine, but vertical speed is usually smoothed a bit to a "U" shape. MamJ89C.png

      A perfect example would be "Contra" from NES. If you hold a key, the rambo-guy moves at static speed, when you release the key, he suddenly stops (unless in midair, where he continues to move at that speed), so it's similarly to your game. However, the jumps are smoothed a bit, where the character slows down before reaching the top and starting to fall. :P

      So yeah, that's the one thing I could suggest, but it isn't an issue of course, that's mostly a matter of the style you want to have.

      As for camera, there's the same thing, it's a matter of preference and the style you want to go with, so I'm unable to give an accurate answer. :P 

    3. Splashee

      Splashee

      @Rikifive While I watch your gameplay, I don't sense the camera the way you intend it to do. So let's think simple...

       

      Twilight's position is key here. Take Twilight's integer position only (the stage coords), and the state she is in, such as walking in a direction, ducking, jumping, her speed, anything that the camera should interact to, and now you have all the data you need, but the camera will act on them in reverse. The camera doesn't follow Twilight. The camera is relative to her stage coordinates. The relative value must be integer and fraction away from Twilight's integer position only (for pixel perfect drawing).

       

      The camera is placed on its own defined x and y axis relative to Twilight, so many integer and fraction needed to get what you want, as far as camera movement goes. But the position is always relative from Twilight's integer position, when her frame movement and collision has been calculated (her final position for the frame). Lastly, you clamp the camera to the outer parts of the map as a visual step (you don't modify the distance from Twilight).

       

      Example: Camera starts dead center to Twilight (same position), such as local_cam_x and local_cam_y are both 0 (biased to center of screen). As soon as Twilight does anything, like ducking, the camera will starts changing the local_cam_y in such a way that she is looking downwards. If Twilight walks forward, the local_cam_x is increased in the opposite direction, making it look like the camera is pushed backwards, but now, believe the camera moved outside the stage boundaries? The final camera position is clamped to the edges of the stage.

       

      When the camera has been calculated, all the sprites including Twilight herself, should be displayed on the screen relative to the camera. Result is the same as you have now, only you have more control over custom movement, and you don't have to think about those nasty jumping between pixels trying to target an odd coordinate.

       

      I recommend scrapping the fraction and going back to floating point. Always round to floor (that's what integer does, and also that's what all your favorite games did in the past), and round at the last possible moment (when the sprites are being shown). Trust me, just do it. you save yourself headache later. You will get the same result as you do now, same errors as you do now. The issue is in GML, using floating point as default anyways. When you do integer + integer, you fail and lose more pixels than if you let floating point add up the fractions. (this is a floating point problem, not an integer problem. Floating point will always lose precision if you start modifying anything beyond the decimal point, as floating point values are stored as exponent and mantissa, not as an integer plus a fraction!!!).

    4. Rikifive

      Rikifive

      Yeah, that's one of the approaches I was thinking of giving a try, but it was really late when I was working on it (that status update was created at almost 5AM), so I kind of couldn't think straight lol. I tried that, overcomplicating things and it didn't work hah. I'm still not exactly sure if it will work well in the way I want it to behave, but that's something I'll have to test.

      The camera is already basing on Twi's target position (her coords + direction offset) specified in integers and follows that point on its own. ... in a very simple system at the moment. Welp, currently the camera does its job and allows me to easily switch target it should follow, so it will be fine for now. This is something, that can be adjusted anytime, so I'll get to it later.

      Quote

      believe the camera moved outside the stage boundaries?

      Clamping is one of the first things I did - implemented, not added at the beginning of the calculation process, that is.

       

×
×
  • Create New...