Frame Perfects & Alignment

You have made a few easy levels and now you want to make difficult gameplay, but don’t know how to introduce a high level of difficulty. This guide will discuss how to efficiently apply a mechanic known as frame-perfects into your levels.

Frame-perfects are timings that have a window of one frame to click. These are usually difficult due to the little to no error needed to pass, but there are variations of a frame-perfect.

• Hard Timing: Hard timings are almost frame perfect, having a window of 2-5 frames at N FPS.

• Common Frame-perfect: A common frame perfect is a timing with a window of 1 frame at N fps. Due to changes in the game’s physics, most of these are broken without the use of a physics bypass, as 240fps makes the room for error larger than normal.

• Frame Gate: A step up from the common frame perfect, being possible on only N FPS. These usually include jump height differing with FPS, subframes, or the Rotation hitbox. They’re much harder to build and force the player to play the level at any FPS the creator desires.

• Swift Click Timing: Usually isn’t a frame perfect, but rather a clicking type, requiring the player to click and release within 1 frame. This becomes exponentially harder the higher the FPS. These are commonly used in most modern impossible levels due to the effects caused by the players’ gravity when using a pink dash orb.

• Alignment Frame-perfect: One of the hardest timings, relying on the change of the position of the player and how many units the player moves in a frame. Most of the time these are made accidentally, and technically any frame-perfect is an alignment frame perfect.

Frame-perfects can be made on any FPS or gamemode. Usually ones involving a snapping gravity like the spider or wave tend to be easier than the rest, while modes based on a curve in gravity like the ship are harder due to the floatiness and unpredictability.

This is a more complex method which can be used with macro recording software to build a frame-perfect. The steps to construct one with macrobuffing are shown below.

Everything described here is nerdy stuff about how frame perfects work and some ways to troubleshoot them.

• Despite its many references and its wide use in the GD community, pixel-perfects don’t exist in GD due to how the game calculates positions using units instead of pixels, as well as the size of 1 pixel in units being inconsistent with different monitors and resolutions in windowed mode. The closest thing to a Pixel perfect is a Hitbox perfect, where the hitboxes of the player are mathematically as close as possible to the player.

• While you can make a frame perfect with any gamemode, each mode has a different difficulty of frame perfects. The easiest are usually wave frame-perfects, since it’s easy to predict trajectory. After that comes spider frame-perfects, which are slightly harder to predict due to how tight the hitboxes are. Ball frame-perfects are next, which are slightly easier than the Cube and UFO. The hardest ones are with the robot and ship modes due to them requiring a release at a frame-perfect interval.

• Any frame perfect timing on N FPS will be physically possible on double N fps and above, however these timings can be possible on higher or lower FPS with the help of alignment.

• Decimal-based frame-perfects can exist as well, which can be used to force the player to play at a very specific FPS to complete the jump. For example, you can set it up to make it possible on only 59.69 FPS.

Sometimes you’ll notice your frame-perfect you copied is physically impossible in your level, even though it's possible in the level you copied it from. This is usually Alignment to blame. Alignment is the value in the player’s position, rotation or location of subframes that is smaller than the distance in units the player takes in one step, causing it to persist until another event happens that causes it to change.

Let’s imagine the player is running the game at 60 frames per second, and the X position is changed by 1 unit every frame.

The player’s location will change like this:

1.0 → 2.0 → 3.0 → 4.0 → 5.0 → 6.0 → 7.0 → 8.0 → 9.0 …

Now imagine that a mirror portal offset the player by 0.1 units. 0.1 is smaller than the player’s speed, so it will persist. 

Now our X position will look like this:

1.0 → 2.0 → 3.0 → 4.1 (entered mirror portal) → 5.1 → 6.1 → 7.1 → 8.1 → 9.1 …

0.1 is alignment of each movement after colliding with the mirror portal.

This slight discrepancy can create an Alignment frame-perfect, since with a different alignment the checks for collision with hitboxes will be changed, possibly making the timing physically impossible. You can have an insanely small change in alignment due to the Snap bug which usually doesn’t affect anything unless your timings are very tight.

• X Pos Alignment: Happens with rotated speed portals, mirror portals and Snaps.

• Y Pos Alignment: Happens depending on how the player enters a wave portal, size portal, the ufo click pattern, as well as velocity of the ship. Hitting the ground or a platform will reset this alignment to where the platform was placed vertically.

• Rotation Alignment: Depends on the orb patterns, ball gameplay and ship velocity.

• Subframe Alignment: A difficult alignment that is usually not used in many cases. X and Y positions of the player can affect how subframes can change, due to how the game processes them.