Editorial note: This publication and Quirky Cotton Collective share an owner.

There is a ball at the bottom of the ramp. That is the first thing I noticed, and it is the thing that makes the shirt work. The design is simple enough to describe in a sentence: white capitals reading I HAD POTENTIAL above a curved white ramp descending from left to right. A dashed empty circle sits at the upper left ledge. A solid white ball rests on the lower right flat ledge. The ramp is curved, not a straight diagonal. That curve is doing more work than the words.

Most versions of this joke stop at the text. The phrase alone is a familiar kind of self-deprecation — past tense, resigned, a little theatrical. But the drawing turns the phrase into a diagram, and a diagram invites reading. The dashed circle at the top is where the ball started. The solid ball at the bottom is where it ended up. The ramp is the path between them. The joke is not just that potential existed. The joke is that we can see exactly where it went.

What I keep coming back to is the dashed line. A dashed circle is a convention — in technical drawing, in physics diagrams, in the annotations you find in a service manual. It means this was here or this is where it would be. It is a mark of absence. The solid ball is present; the dashed circle is not. The design uses that convention without explaining it, and that is why it reads as a physics pun rather than a generic motivational joke. The shirt is not saying you had potential. It is saying here is the initial condition, and here is the final state, and the difference between them is the whole story.

The visual language of this shirt is not that far from the visual language of a bench test. You mark the starting position. You mark the ending position. You draw the path. The interesting part is always the path — the friction, the slope, the moment the ball stops accelerating and starts rolling. The shirt does not show that part. It just shows the two states and lets you fill in the rest. That is a generous design choice. It trusts the reader to understand that a ball on a curved ramp does not stay at the top.

The phrase I had potential is doing something similar. It is past tense. It is not I have potential. It is not I am potential. It is a statement of fact about a quantity that has already been spent. The humor comes from the mismatch between the grand abstraction of potential — a word that belongs in physics textbooks and guidance counselor offices — and the mundane finality of a ball sitting on a flat ledge. The ball is not sad. The ball is not angry. The ball is just at the bottom. The dashed circle is just a memory.

I think that is why this design works as a piece of clothing rather than just a joke. It is not asking you to laugh at yourself. It is asking you to recognize a diagram you have seen before. Anyone who has spent time in a lab, a workshop, or a competitive game has seen this shape. The initial condition. The final condition. The path between them. The shirt is a small, wearable version of that diagram, and the punchline is that the diagram is about you.

The I Had Potential shirt is a standard t-shirt with a white print on a dark ground. The design is minimal — no extra flourishes, no background elements, no additional text. The capitals are clean and evenly spaced. The ramp is a single curved line. The dashed circle and the solid ball are the only other marks. It is the kind of print that reads clearly from a few feet away, which is what you want from a diagram. You do not need to squint to see where the ball ended up.

What I appreciate most is that the design does not overexplain. It does not label the ramp. It does not add an arrow. It does not write potential energy next to the dashed circle. It assumes you can read the visual grammar on your own. That is a risk for a shirt — some people will just see a ball and a line — but it is also what makes the joke land for the people who do read it. The shirt is not for everyone. It is for the people who look at a curved ramp and immediately think about where the ball is going to end up.

There is a version of this joke that would be meaner. It could show the ball at the top, still full of potential, with the text I have potential and a winking face. That would be a different shirt. This one is quieter. It is past tense. It is a diagram of a completed process. The ball is already at the bottom. The dashed circle is already empty. The joke is not that you failed. The joke is that the diagram is accurate.

I do not know who first drew a ball on a ramp to explain potential energy. It is a standard physics illustration, the kind of thing that shows up in textbooks and lecture slides and whiteboard sketches. The shirt takes that illustration and strips it down to its essential parts: the initial state, the final state, and the path between them. Then it adds four words. The words are the punchline, but the drawing is the setup. Without the drawing, the words are just a sad statement. With the drawing, they become a physics problem.

That is the argument I would make for this shirt as an object. It is not a generic sarcastic quote. It is a specific visual joke that depends on a specific visual convention. The dashed circle matters. The curved ramp matters. The solid ball at the bottom matters. If you changed any one of those elements, the joke would be different. The design is not just text on a shirt. It is a diagram with a caption, and the caption is the punchline.

I keep thinking about the moment the ball leaves the top of the ramp. There is a frame where it is still touching the dashed circle. There is a frame where it is not. The shirt does not show that frame. It shows the before and the after. The interesting part — the part where the ball is actually moving, where the potential is actually becoming something else — is missing. That is the joke. The shirt is a diagram of the part you do not see.

Maybe that is why it works as a piece of clothing. You wear the before and the after. You do not wear the middle. The middle is where you live.

There is a period after the word. That is the first thing I noticed, and it is the thing that keeps the design from collapsing into pure indifference. The native garment preview for this shirt shows very small, centered lowercase meh. lettering on a dark shirt. No animal illustration. No pride variant. No distressed texture, no banner, no secondary line of copy. Just four letters and a full stop, set small enough that a reader has to be within conversational distance to resolve it.

I have spent a lot of bench time thinking about input signals — polling windows, actuation points, the difference between a press that registers and a press that merely happens. The meh. shirt is the opposite end of that spectrum. It is a display with almost no signal amplitude. And that, I think, is the argument the design is making.

Editorial note: This publication and Quirky Cotton Collective share an owner. This is not an independent review.

What the artwork actually shows

Stick to the observation: very small, centered, lowercase meh. on a dark ground. The period is present. The scale is the smallest I have seen on a typographic tee that still expects to be read. There is no mascot, no cat, no sloth, no rainbow, no “introvert loading” bar. The retail title mentions introvert and minimalist, but the printed artwork itself is only the word and the punctuation. I am describing the preview, not claiming the shirt performs anything.

That gap between the title and the print is worth sitting with. The title carries the marketing load — funny, sarcastic, introvert, minimalist — while the garment carries four letters. The shirt does not argue with the title. It just declines to elaborate.

Why the period matters more than the word

“Meh” as an utterance is a shrug. It trails off. It is the sound of a shoulder rising and falling. Set in lowercase with no punctuation, it would read as a mood: meh, a state of being. With the period, it becomes a verdict. A complete sentence. The smallest possible complete sentence, maybe, but grammatically closed. Nothing more is coming.

That is a different posture than apathy. Apathy does not bother to punctuate. The period is the tell that someone finished the thought and filed it. If you have ever watched a run die to a single missed input and then quietly reset the console without saying anything, you know the register. It is not sadness. It is the flat close of a sentence that has already been spoken.

I want to be careful here: I am reading the typography, not reporting a fact about the designer’s intent. The period is in the preview. What it means is interpretation, and I am flagging it as such.

Small type as a social protocol

Most slogan shirts are broadcast devices. They are set large, centered, high-contrast, designed to be legible across a room or a stream overlay. The meh. shirt inverts that. At the scale shown in the preview, it is only readable inside a personal bubble — roughly the distance at which you would already be talking to someone. That is a deliberate constraint, and it changes who the shirt is for.

A large slogan shirt says: here is my position, read it from across the room. A small slogan shirt says: if you are close enough to read this, you already know me well enough to get it. The design uses scale as a filter. It is not hiding the joke; it is gating it behind proximity.

For readers who spend their evenings in voice chat with the same four people, that gating is familiar. The best in-group jokes in a competitive scene are not the ones you clip and post. They are the ones that only land if you were in the lobby. The meh. shirt is that kind of artifact rendered in fabric: a private signal that happens to be wearable in public.

The competitive self-image problem

Here is where the design gets more interesting to me than a standard sarcasm tee. Competitive players — runners, lab monsters, ranked grinders — tend to have a complicated relationship with caring. Caring is the engine. You do not shave frames off a route or rebuild a controller’s stick gate because you are indifferent. But caring out loud is socially expensive. The scene rewards a kind of performed detachment: the shrug after a personal best, the “whatever, it was sloppy” after a clean run.

The meh. shirt sits exactly on that seam. It is a garment for people who care a great deal and have decided to present the caring at minimum amplitude. The period is the part that makes it work. Without it, the shirt would be a mood. With it, the shirt is a stance: I have assessed the situation and my assessment is complete.

I am not claiming the shirt is about games. The artwork does not reference a game, a platform, a mechanic, or a community. I am saying that the visual grammar — small, lowercase, closed, unelaborated — is legible to readers who already speak in that register. That is a claim about the typography, not about the product’s audience.

What the design refuses to do

It refuses the animal. This matters because the related-query space around meh shirts is crowded with cats, sloths, and other low-energy mascots. The preview here has none of that. It also refuses the pride variant, the rainbow gradient, the “introvert” badge, the coffee cup, the headphones. Every one of those additions would have raised the signal amplitude and lowered the specificity. The shirt would have become a category instead of a sentence.

It also refuses the joke’s second beat. There is no punchline under the word. No “…probably.” No “…I guess.” The period forecloses the follow-up. That is a harder editorial choice than it looks, because the easy version of this shirt — the version that gets a chuckle in a product thumbnail — is the version with the extra line. This one trusts the reader to supply the tone.

Reading it as an object, not a mood

If you are the kind of person who keeps a workbench and a shoebox of donor controllers, you already know that the most interesting parts of a system are often the smallest ones: a single resistor, a spring rate, a debounce window. The meh. shirt is a typographic version of that. The whole design is one decision — scale — executed with discipline. The word is the payload; the period is the checksum; the size is the transmission protocol.

You can find the listing here if you want to look at the preview yourself: Meh Funny Sarcastic Introvert Minimalist Saying. I am describing the artwork as observed, not vouching for a wearing experience, a fit, or a print method.

Lab Notes

Object: Native garment preview for the Meh Funny Sarcastic Introvert Minimalist Saying listing, brand Quirky Cotton Collective, observed 2026-10-14 on the US marketplace.

Method: Visual inspection of the native preview image and reconciliation with the live listing title. No physical garment was handled. No fit, fabric, print durability, or wear testing was performed.

Observed: Very small, centered, lowercase meh. lettering on a dark shirt. Period present. No animal illustration. No pride variant. No secondary copy visible in the preview.

Interpretation, not observation: The reading of the period as a “closed verdict,” the proximity-gating argument, and the connection to competitive self-presentation are my analysis of the typography. They are not claims about the designer’s intent, the product’s audience, or any game affiliation.

Known error sources: Preview images can differ from the printed garment in scale, placement, and color. I have not verified the print against the preview. Demand figures cited elsewhere in this publication come from the supplied keyword data and are not restated here.

The thing I keep coming back to is the period. Four letters and a full stop, set small enough that most people will never read it. If the design’s whole argument is that the smallest signal can carry the most information, then the open question is whether a shirt can be a display device at all — or whether the only reader who ever resolves the message is the person wearing it.

Ask ten competitive players why they prefer the Sanwa JLF or the Seimitsu LS-32 and you will get ten answers that sound like tasting notes: “tighter,” “snappier,” “more precise,” “looser,” “smoother.” None of those words are wrong. None of them are measurements either. The JLF and the LS-32 are both Japanese arcade levers with similar throw, similar mounting, and similar ball tops, yet they do not feel the same under the hand during a quarter-circle or a charge motion. The useful question is not which one is better. It is which combination of engage distance, spring tension, shaft weight, and neutral precision matches the input demands of the game you are actually playing.

The vocabulary problem

Before comparing anything, it helps to agree on what the variables are. The most detailed public taxonomy of joystick attributes comes from the slagcoin joystick guide, which defines engage distance as “the distance from neutral the joystick is moved before the desired direction engages” and notes that this distance “determines the size of the deadzone, and, along with the restrictor, determines the size of each engage zone” (slagcoin.com).

That definition matters because engage distance is not the same as throw distance. Throw is how far the shaft travels before it hits the restrictor gate. Engage is how far it travels before the microswitch closes and the game registers a direction. The gap between engage and throw is dead travel: the stick is moving, but the game is not hearing anything yet. A stick with a long engage and a short throw leaves very little room for the game to distinguish a clean diagonal from a sloppy one.

The other variables in play:

• Spring tension — how hard the spring pulls the shaft back toward neutral, and how much force the player must overcome to move it.
• Shaft weight — the mass of the moving assembly, which determines how much momentum the stick carries when released.
• Deflection — the bounce past neutral when the stick springs back. The slagcoin guide describes it this way: “When the joystick is released from a direction and springs back to neutral, there is usually a deflection in the opposite direction as the spring deals with the momentum of the shaft. Sometimes this deflection can briefly engage the opposite direction, and it can make finding neutral slightly more difficult” (slagcoin.com).
• Neutral precision — how consistently the stick rests between the switches, and how evenly each direction engages relative to its opposite.
• Pivot smoothness — how cleanly the shaft rotates in its housing, without catching or readjusting mid-motion.

These are the attributes that produce what players call “feel.” They are also, to varying degrees, tunable. That is the part the brand-war framing tends to miss.

What the JLF actually is, per the source

The slagcoin guide describes the Sanwa JLF as “the gamer’s most popular joystick,” compact, with “nicely spaced engages with great general precision,” and using non-levered microswitches (slagcoin.com). The same source notes that the JLF uses a hemispherical pivot and a standard square/rhombus gate, with an octagonal gate available separately.

On engage distance specifically, the guide places Sanwa in the “far” category relative to Happ/IL and Seimitsu: “Happ/IL joysticks tend to have a small engage distance, Seimitsu vary, and Sanwa far” (slagcoin.com). That is a qualitative ranking, not a millimeter figure. It is also the closest thing to a published comparison the retrieved sources provide.

On pivot quality, the guide is direct: “Sanwa parts do not really have this problem” — the problem being imprecise parts that adjust and readjust during play (slagcoin.com). The JLF’s pivot is lubricated from the factory, and the guide notes that Sanwa and Seimitsu pivots “actually use a bit of lube which sometimes needs to be reapplied” (slagcoin.com).

What the LS-32 actually is, per the source

The retrieved excerpt does not include the LS-32’s individual model entry in the slagcoin chart, so per-model figures for weight, dimensions, and mounting height are not available here. What the source does say about Seimitsu as a brand is relevant to feel:

• Seimitsu gates are “a bit thinner than Sanwa gates, which makes them feel slightly less solid, but this is not a significant difference” (slagcoin.com).
• Seimitsu engage distances “vary” — the source does not give a single direction for the brand, unlike Sanwa’s “far” (slagcoin.com).
• Seimitsu parts “can have a bit of a problem” with pivot smoothness, where Sanwa does not (slagcoin.com).

That last point is worth reading carefully. “Can have a bit of a problem” is not a condemnation of the LS-32. It is a statement that the LS-32’s pivot behavior is more variable than the JLF’s, which means unit-to-unit consistency and maintenance matter more. If you are buying a used LS-32, the pivot is the first thing to inspect.

Why motion inputs feel different

Here is where the variables interact, and where the brand-level descriptions stop being enough.

Consider a quarter-circle forward. The input requires the stick to pass through down, down-forward, and forward in sequence, with the game reading each direction as the switch closes. The engage distance sets how far the stick must travel before each direction registers. The spring tension sets how quickly the stick returns to neutral between inputs. The shaft weight sets how much the stick overshoots when you release it.

Now consider the interaction the slagcoin guide flags explicitly: “When a joystick has a small deadzone and a hard spring, slight inaccuracies in the neutral position can compound erroneous movements, especially on the diagonals” (slagcoin.com).

That is the mechanism. A short engage distance means the stick registers a direction with very little travel. A hard spring means the stick is being pulled back toward neutral with more force, and any imprecision in where neutral actually sits gets amplified because the stick is already close to the engage threshold. On a diagonal, where two switches are involved, that imprecision can mean one switch closes before the other, or neither closes cleanly.

A longer engage distance with a looser spring tolerates more slop. The stick has to travel further before anything registers, so small inaccuracies in neutral position do not immediately produce a false input. The tradeoff is that the stick may feel vague on charge inputs, where you need to hold a direction for a specific duration and want the engage to be unambiguous.

This is why “tight” and “loose” are not opposites on a single axis. They are descriptions of different combinations of engage distance, spring tension, and neutral precision. A stick can feel tight on engage and loose on return. A stick can feel precise on cardinals and sloppy on diagonals.

Spring swaps are a tuning lever, not a fix

The slagcoin guide notes that “a looser spring also allows for more styles of play” (slagcoin.com), and that deflection “can be mitigated using a stronger spring and/or a lighter shaft” (slagcoin.com).

Those two statements point in opposite directions, which is the point. A stronger spring reduces deflection — the stick bounces less past neutral when released — but it also increases the force required to move the stick and can amplify neutral imprecision into diagonal errors if the engage distance is short. A looser spring makes the stick easier to move and more forgiving of neutral imprecision, but it increases deflection and can make neutral harder to find.

So when a player says a stick “feels wrong” and reaches for a spring swap, the useful question is which problem they are actually trying to solve. If the problem is overshoot on return, a stronger spring or a lighter shaft addresses it. If the problem is diagonal misregistration, a stronger spring may make it worse. If the problem is fatigue during long sessions, a looser spring helps, but at the cost of neutral-finding ease.

The guide’s own framing supports this: “Different players will like different engage distances in different games” (slagcoin.com). That is not a cop-out. It is a statement that the correct configuration is game-dependent and player-dependent, and that the JLF and LS-32 are two points in a space of tunable variables, not two fixed answers.

What this article cannot tell you

The retrieved sources do not provide millimeter-level engage distances for the JLF or the LS-32. They do not provide spring rates in grams or newtons. They do not provide microswitch actuation force or travel figures. They do not provide shaft weights or total moving mass. The slagcoin guide’s chart is referenced but the LS-32-specific figures are not in the retrieved excerpt.

That absence is itself informative. The community vocabulary for describing stick feel is qualitative because the measurements have not been published in a consistent, comparable form. The brand-level descriptions — Sanwa “far,” Seimitsu “vary” — are useful for orientation but not for prediction. If you want to know how a specific JLF and a specific LS-32 compare on engage distance, you have to measure them.

What the retrieved source does give you is a working vocabulary and a set of mechanisms. Engage distance sets the deadzone. Spring tension and shaft weight set deflection. Neutral precision determines whether diagonals register consistently. Pivot smoothness determines whether the stick feels clean or catchy. Those variables interact, and the interaction — not any single number — is what you feel under your hand.

Practical framework

If you are choosing between a JLF and an LS-32, or tuning one you already own, the useful questions are:

1. What input types does your game demand most? Fast quarter-circles and 360s reward a stick that returns to neutral quickly and predictably. Charge motions reward a stick with an unambiguous engage. 4-way games reward a gate that restricts diagonals cleanly.
2. How much dead travel do you want? A longer engage distance is more forgiving of neutral imprecision but may feel vague. A shorter engage distance is more immediate but less tolerant of slop.
3. How much deflection can you tolerate? If you release the stick often, deflection matters more. If you hold the stick continuously, it matters less.
4. Is your neutral actually precise? Before swapping springs, check whether the stick rests evenly between switches at multiple rotational positions. If it does not, a spring swap will not fix it.
5. Is your pivot clean? The slagcoin guide notes that Sanwa and Seimitsu pivots use lubricant that sometimes needs to be reapplied (slagcoin.com). A dry or contaminated pivot can feel like a spring problem when it is not.

The JLF and the LS-32 are both capable levers. The difference under your hand is not a brand essence. It is the sum of engage distance, spring tension, shaft weight, neutral precision, and pivot condition — variables you can measure, and to some degree, tune.

FAQ

Does the Sanwa JLF have a longer engage distance than the Seimitsu LS-32?

The slagcoin guide places Sanwa in the “far” engage-distance category and describes Seimitsu engage distances as varying by model (slagcoin.com). It does not provide a per-model comparison between the JLF and LS-32, so a direct answer requires measurement.

Can I swap springs between a JLF and an LS-32?

The retrieved source does not address cross-brand spring compatibility. It notes that springs can be exchanged among certain models to modify tension, but does not specify which models are compatible with which (slagcoin.com).

Why does my stick feel different after I clean it?

The slagcoin guide notes that Sanwa and Seimitsu pivots use lubricant that sometimes needs to be reapplied, and warns to “be careful when taking one of these joysticks apart and abstain from handling the pivot much” (slagcoin.com). Removing or redistributing pivot lubricant can change how the stick feels.

Is a stronger spring always better for competitive play?

No. The slagcoin guide notes that a stronger spring can mitigate deflection, but also that “when a joystick has a small deadzone and a hard spring, slight inaccuracies in the neutral position can compound erroneous movements, especially on the diagonals” (slagcoin.com). The right spring depends on the stick’s engage distance and the player’s input patterns.

The Tech the Developers Kept: How Celeste’s Wavedash Was Found by Players and Became Movement Grammar

Celeste shipped in January 2018 with three verbs on the box: jump, air-dash, climb. The itch.io store page still describes the controls that way — “simply jump, air-dash, and climb” — while promising “layers of expressive depth to master.” That phrase is doing a lot of work. The wavedash is one of those layers, and it is worth being precise about what it actually is, because the popular story — that players “broke” the game and the developers reluctantly tolerated it — is only half true and the interesting half is the other one.

What a wavedash actually is

A wavedash is a ground-level dash that converts into a super-jump-like burst of horizontal speed. The input sequence, as the community codified it, is: dash horizontally while grounded, then jump within a short window after the dash begins, before the dash’s momentum has decayed. The result is a launch that carries more horizontal velocity than a standard super or hyper, and it can be chained into further dashes and jumps.

The reason it works is not a bug in the collision system. It is a consequence of how Celeste’s dash state interacts with the jump state during the dash’s active frames. The dash sets a velocity, the jump reads that velocity and adds to it, and the ordering of those two operations inside a single frame is what produces the extra speed. That is an emergent property of the state machine, not a memory corruption or a physics glitch. This distinction matters: emergent-but-intended-feeling mechanics are exactly the kind of thing that survives patches, and the wavedash did.

I want to be careful here about what I can and cannot source. The Celeste GitHub repository at NoelFB/Celeste is explicitly described as a place “to track issues and bugs with Celeste,” and its README states that “a few of the class files from Celeste” were released “as a learning resource and for general interest.” It is not a full source dump. So the frame-level account above is the community’s working model, consistent with the released class files and with years of TAS verification, not a line-by-line citation from a complete engine. Treat it as the best available reconstruction, not as a developer-authored spec.

How it was found

The wavedash entered the wider Celeste vocabulary through the speedrunning and TAS community in the months after launch. The pattern is familiar from other platformers: a small number of players grinding Any% routes notice that a particular dash-jump timing produces more distance than the frame data should allow, they capture it, they post it, and within weeks it has a name and a tutorial. Celeste’s community was unusually well-positioned for this because the game’s respawn loop is fast enough that iterating on a single screen for an hour is normal behavior, not obsessive behavior.

What I cannot do from the sources in front of me is name the first person to document it or date the first forum post. The speedrun.com Celeste pages returned HTTP errors when I attempted to retrieve them, so I am not going to invent a discovery date or attribute the find to a specific runner. If you want the primary record, the leaderboard’s guide and forum history is where it lives, and it is worth reading directly rather than trusting a secondhand summary — including this one.

Why it became grammar instead of a trick

Most speedrun tech stays inside the speedrun. The wavedash did not, and the reason is structural rather than cultural.

First, the input is short. A wavedash is two buttons in a tight window, not a twenty-frame setup. That puts it within reach of a player who has finished the A-sides and is looking for something to do with their hands.

Second, the payoff is legible. You can see the extra distance. You can feel the difference between a super and a wavedash on the same screen. Mechanics that produce visible, repeatable results get taught.

Third, and most importantly, the game’s level design already rewarded it. Celeste’s later chapters and B-sides are dense with gaps that are comfortable with a wavedash and tight without one. The developers did not have to patch the mechanic into relevance; the existing geometry was already speaking its language.

The modding layer that made it teachable

Everest, the Celeste mod loader and base API, is the piece of infrastructure that turned the wavedash from a piece of community folklore into a documented technique. The Everest repository describes itself as a “Celeste Mod Loader / Base API,” built on MonoMod, with installation and usage instructions on its website and development discussion on the “Mt. Celeste Climbing Association” Discord. It is maintained by volunteers and licensed MIT.

Everest matters for two reasons. The obvious one is custom maps: a map author can design around wavedash timing because the technique is stable and understood. The less obvious one is that Everest’s existence created a shared vocabulary. When you are building a map, you have to decide whether a gap is wavedash-required, wavedash-friendly, or wavedash-hostile. That decision forces the technique into written form. Tutorials, map design guides, and the community’s collective documentation all grew out of that necessity.

This is the part of the story that gets undersold. The wavedash did not become grammar because players loved it. It became grammar because the modding ecosystem needed a stable, nameable unit of movement to design against, and the wavedash was already stable and nameable.

What the developers actually did

The Celeste changelog is the primary record of what changed between versions. The itch.io page lists v1.2.0.0 (February 13, 2018) and v1.4.0.0 (March 30, 2021) as the notable public changelog entries, with the current downloadable builds at version 1.4.0.0. The GitHub repository’s README directs readers to the changelog before filing issues, which tells you the developers treat it as the authoritative version history.

To the community’s knowledge, the wavedash was never removed and is present in current builds, though I could not retrieve a primary source confirming this. The changelog entries exist, but their contents were not reviewed here, so I cannot verify whether they mention the wavedash. What I can say is that the technique remains widely used and documented by the community in the current version.

I am not going to claim the developers publicly blessed the wavedash in an interview I cannot cite. The honest version is: the community’s understanding is that it was not patched out, and the game’s continued support for custom maps via Everest meant the technique had room to grow. That is the evidence. The interpretation — that this was a knowing decision to let the community’s discovery stand — is mine, and it is consistent with the record but not proven by it.

Input latency and the wavedash window

Here is where the hardware side of this blog earns its keep. A wavedash is a timing-sensitive input. The window between dash and jump is short enough that display latency and controller latency are not academic concerns — they are part of the execution.

Celeste runs on FNA and XNA on Windows, and the itch.io page lists keyboard and Xbox controller as the supported inputs, with configurable controls. The game’s own frame pacing is the baseline; everything else — your monitor’s scanout, your controller’s polling rate, your display’s processing — stacks on top of it. A player on a 60 Hz panel with a wired controller and a player on a high-refresh display with a wireless controller are not executing the same task, even though the input sequence is identical.

I am not going to publish a latency budget for the wavedash window, because I have not measured it and the sources here do not contain a frame count. What I will say is that the technique is a good argument for treating input latency as a skill variable rather than a comfort variable. If you are dropping wavedashes on a setup where you can hit them on another, the setup is a suspect.

What this pattern teaches

The wavedash is a case study in a specific kind of developer-player relationship: the developers built a state machine with more expressive range than the tutorial taught, the players found the extra range, and the developers declined to close it. The result is a mechanic that is now part of how Celeste is played, taught, and designed for.

The lesson is not “listen to your speedrunners.” It is narrower and more useful: if your movement system has emergent depth, the cost of leaving it in is low and the return is a community that builds documentation, maps, and tutorials around it. The cost of patching it out is a community that learns not to look.

Celeste’s developers kept the tech. The players wrote the grammar. Everest gave it a syntax. That is the whole chain, and it is worth documenting precisely because it is rare.

FAQ

Is the wavedash a glitch?

No, in the sense that it does not rely on memory corruption, out-of-bounds access, or undefined behavior. It is an emergent consequence of how the dash and jump states interact within a frame. Whether the developers consider it “intended” is a separate question from whether it is a glitch, and the changelog does not list it as a bug fix.

Did the developers ever patch it out?

To the community’s knowledge, the wavedash was never removed and is present in current builds, though I could not retrieve a primary source confirming this. The changelog entries exist, but their contents were not reviewed here.

Do I need Everest to wavedash?

No. Everest is a mod loader and base API for custom maps and mods. The wavedash exists in the base game. Everest matters because the custom map community designs around the technique, which is how it became widely taught.

Does controller choice affect wavedash execution?

It can, because the technique is timing-sensitive and controller polling, connection type, and display latency all sit between your input and the frame the game reads. The sources here do not contain a measured frame window, so treat any specific millisecond figure you see elsewhere as unverified unless it comes with a capture.

Where should I look for the original discovery documentation?

The Celeste speedrun.com leaderboard’s guides and forum history is the primary community record. I was unable to retrieve those pages while writing this, so I am pointing you there rather than summarizing them from memory.

What Aim Assist Actually Is (and What It Isn’t)

Aim assist is any system that modifies the relationship between a player’s stick or mouse input and the in-game aim vector. That’s the whole definition. It is not a difficulty setting, not a moral failing, and not a single mechanic. It is a family of techniques that includes rotational aim assist, aim slowdown (friction), bullet magnetism, target snapping, and projectile curving. Each one operates at a different point in the input-to-render chain, and each one produces a different measurable effect on the screen.

For competitive players and hardware tinkerers, the distinction matters because the conversation online almost never separates them. People argue about “aim assist” as if it were one thing. It isn’t. A game can have strong rotational assist and zero bullet magnetism. Another can have weak rotation and aggressive magnetism. The feel is completely different, and the fairness argument changes depending on which subsystem you’re talking about.

This article breaks down how these systems work at the engineering level, where they sit in the switch-to-photon chain, and why most of the discourse around them is aimed at the wrong target.

The Full Chain: Where Aim Assist Lives

To understand aim assist, you have to understand the pipeline it modifies. In a typical console shooter, the chain looks like this:

1. Stick potentiometer or Hall effect sensor reads physical deflection.
2. Controller firmware samples that reading at a fixed rate (often 125 Hz to 1000 Hz depending on the pad and connection).
3. Console input stack receives the report, applies deadzone and response curve shaping.
4. Game engine reads the shaped input and applies aim assist logic.
5. Camera and weapon systems translate the assisted vector into world-space aim.
6. Renderer draws the frame.
7. Display presents the photon.

Aim assist sits at step 4. It is a software layer that reads the player’s intent (the shaped stick vector) and the game state (target positions, hitboxes, line of sight) and outputs a modified aim vector. Everything before step 4 is hardware and firmware. Everything after is rendering and display. When people argue about “input lag” and “aim assist” in the same breath, they are usually conflating two different parts of this chain.

Rotational Aim Assist

Rotational assist is the most discussed and least understood. When the player’s crosshair is near a target and the player is actively rotating the camera, the game adds a small amount of rotation in the direction of the target. The goal is to keep the crosshair on target during strafing and tracking. The strength of this assist is usually a scalar value multiplied by the angle between the crosshair and the target’s center.

In Halo 3, rotational assist was tuned to be subtle but persistent. In Call of Duty: Modern Warfare (2019), it was stronger and more responsive to vertical movement. These are not opinions. They are documented in the game’s configuration files and observable in frame-by-frame capture.

Aim Slowdown (Friction)

Friction reduces the player’s sensitivity when the crosshair passes over a target. It does not move the crosshair. It makes the crosshair harder to move off the target. This is the assist that most players feel but few can describe. It is also the one that produces the most arguments about “sticky aim” in games like Apex Legends and Destiny 2.

Friction is applied as a multiplier to the player’s input vector. If the player is pushing the stick at 80% deflection and the crosshair is on a target, the game might reduce that to 60% effective deflection. The player feels resistance. The crosshair stays on target. No magnetism, no snapping, just a dampened response.

Bullet Magnetism

Bullet magnetism is the most controversial because it operates after the player has already fired. When a bullet is spawned, the game checks whether the shot would have hit a target if the aim vector were slightly adjusted. If so, the bullet is redirected toward the target. The player sees a hit. The target sees a hit. The killfeed confirms it. But the shot was not aimed by the player in the strictest sense.

This is common in console shooters and almost never disclosed in marketing. Halo 5: Guardians used bullet magnetism extensively. Destiny 2 uses it on both console and PC, though the PC version has different tuning. The effect is measurable: fire at a target’s shoulder and watch the bullet curve into the chest.

Target Snapping and Projectile Curving

Target snapping is the most aggressive form of aim assist. When the player aims near a target and pulls the trigger, the crosshair jumps to the target’s center. This is rare in modern shooters but common in older console games and in third-person action games. Red Dead Redemption 2 uses a form of snapping on console. Grand Theft Auto V uses it extensively in its auto-aim modes.

Projectile curving is a variant of bullet magnetism applied to projectiles with travel time. Halo 3‘s Spartan Laser and Team Fortress 2‘s rockets have both been analyzed for this behavior. The projectile’s path is adjusted mid-flight to intersect with a target’s hitbox.

Why the Conversation Is Wrong

The standard argument goes like this: aim assist is cheating, or aim assist is necessary for controller players, or aim assist ruins competitive integrity. All three positions assume that aim assist is a single, uniform mechanic. It isn’t. And the argument gets worse when you bring in crossplay.

Crossplay Confusion

When Fortnite introduced crossplay between console and PC, the debate exploded. Console players had aim assist. PC players had mouse and keyboard. The assumption was that aim assist was a crutch that made console players competitive with mouse aim. The reality was more complicated. Mouse aim has a higher skill ceiling for flick shots and tracking. Controller aim assist has a higher floor for close-range tracking. The two input methods are not equivalent, and the assist does not make them equivalent. It makes them differently viable.

What most players never see is the actual tuning values. In Fortnite, the aim assist strength was reduced in competitive playlists. In Apex Legends, the aim assist on PC is weaker than on console. These are design decisions, not accidents. They are also rarely communicated clearly to the player base.

The Input Latency Angle

Aim assist adds processing time. It is not free. The game must read the input, evaluate the target state, compute the assist vector, and then apply it. On a console running at 60 Hz, that is 16.6 milliseconds per frame. If the assist logic takes even 2 milliseconds, that is 2 milliseconds added to the input-to-photon chain. On a PC running at 144 Hz, the frame time is 6.9 milliseconds. The same 2 milliseconds is a larger fraction of the total.

This is why some competitive players on PC disable aim assist entirely. They would rather have raw input and accept the higher skill floor than accept the added latency. That is a legitimate tradeoff. It is also one that the “aim assist is cheating” crowd never acknowledges.

The Retro Engineering Perspective

Older consoles had aim assist too. The GoldenEye 007 on Nintendo 64 had a form of auto-aim that was necessary because the N64 controller’s analog stick was not precise enough for fine aiming. The Halo: Combat Evolved on Xbox had aim assist tuned for the Duke controller’s stick. These were engineering solutions to hardware limitations, not player conveniences.

When a remaster changes the aim assist tuning without documenting it, that is a problem. The Halo: Combat Evolved Anniversary remaster changed the aim assist behavior in the original graphics mode. Players noticed. The community documented it. That is the kind of forensic work that matters.

How to Measure Aim Assist Yourself

You do not need a lab to measure aim assist. You need a capture card, a consistent test setup, and patience. Here is a method that works for most console shooters:

1. Set up a static target. Use a training range or a custom game with a stationary target.
2. Record your stick input. If your controller supports it, log the raw stick values. If not, use a controller overlay that shows stick position.
3. Record the screen. Capture at 60 fps or higher.
4. Perform a controlled sweep. Move the stick at a constant rate across the target. Do not adjust your input based on what you see.
5. Analyze the frames. Compare the crosshair position to the stick position. If the crosshair moves faster or slower than the stick input would predict, you are seeing aim assist.

This method will show you rotational assist and friction. Bullet magnetism requires a different test: fire at a target’s edge and see if the bullet hits. Target snapping requires a third test: aim near a target and pull the trigger without moving the stick.

What Game Developers Actually Tune

Game developers tune aim assist using a combination of playtesting and telemetry. The goal is usually to make controller aiming feel responsive without making it feel automatic. The specific values are often stored in configuration files that are accessible to modders and dataminers. For example, the Call of Duty series has had its aim assist values extracted and published by the community. The Apex Legends values have been similarly documented.

These values are not secrets. They are just not advertised. A player who wants to understand aim assist can find the numbers. A player who wants to argue about aim assist usually does not.

FAQ

Does aim assist work on PC?

Yes, if you use a controller. Most crossplay shooters apply aim assist to controller input on PC, though often at reduced strength compared to console. Mouse and keyboard input typically does not receive aim assist, with rare exceptions like Halo Infinite‘s bullet magnetism on PC.

Is aim assist cheating?

No. Cheating implies circumventing the game’s rules. Aim assist is part of the game’s rules. It is a designed feature, not an exploit. The fairness question is whether the assist is tuned appropriately for the input method and the competitive context. That is a design question, not a moral one.

Why do some games have stronger aim assist than others?

Because the developers made different tradeoffs. A game with a slower time-to-kill and larger hitboxes can afford weaker aim assist. A game with a faster time-to-kill and smaller hitboxes needs stronger assist to keep controller players viable. The tuning reflects the game’s overall design, not a universal standard.

Can I disable aim assist?

In most games, yes. The option is usually in the controller settings. Some games only allow it in custom or private matches. Some games do not allow it at all. If you want raw input, check the settings before you complain about the assist.

Does aim assist add input lag?

It can. The assist logic runs every frame, and that processing takes time. The amount depends on the game and the platform. On a 60 Hz console, the added latency is usually small but measurable. On a high-refresh-rate PC, the same processing time is a larger fraction of the frame budget. This is one reason some players disable it.

The Takeaway

Aim assist is not one thing. It is a set of techniques that operate at different points in the input-to-render chain. Rotational assist, friction, bullet magnetism, and target snapping all produce different effects and different fairness arguments. The conversation about aim assist is wrong because it treats them as a single mechanic and ignores the engineering context.

If you want to understand aim assist, measure it. Capture the frames. Log the stick input. Compare the crosshair to the input. The data will tell you more than any forum argument. And if you are a developer, document your tuning. The community will find it anyway. You might as well explain it.

Control remapping — deciding which physical input fires which in-game action — gets filed under “menu nicety.” Wrong drawer. On my bench, a remap is a lookup table living somewhere in the chain between your thumb and the photons, and the only interesting question is which layer holds it. An in-game rebind menu costs one array index per input read. A platform layer like Valve’s Steam Input or the Switch’s system settings runs a translation pipeline with timing of its own. A firmware remap on an RP2040 board rewrites the USB HID report before it ever leaves the controller. And at the retro extreme, “remapping” a JAMMA cabinet meant moving crimp terminals on an edge connector, by hand. Competitive players live with the consequences — ergonomics, legality, and the latency budget, all three at once. Hardware tinkerers get the firmware layer, where the honest engineering sits. Speedrunners already have rulebooks adjudicating this, game by game. So here is the case for every game shipping a remap of its own, argued with wiring, firmware documentation, and bench numbers instead of vibes.

What remapping actually is: one lookup, four layers

Short answer: a remap translates a physical event — a dome switch collapses, a key bottoms out — into a logical action the game understands. Everything past that sentence is implementation detail. Implementation detail is also where milliseconds hide, so here are the four layers a remap can live at, cheapest first.

Layer 1: the in-game rebind table

The game reads raw input IDs and checks a table that says which action each ID fires. The cost is one indexed lookup at input-read time — cheaper than the debounce filtering the game was already running, and immune to polling rate, because it never sits in the polling path at all. Every game can afford this layer. Which is why a game without one made a choice, not a compromise.

The gold standard here is older than most of the people arguing about it. Quake’s console bind system (id Software, 1996) let you type bind mouse2 +jump and get on with your life — the direct ancestor of every Source-engine config file still circulating in speedrun Discords. DOS games got there even earlier, with setup programs that wrote your keybinds to a config file before the game ever launched. The industry solved this twice before the Dreamcast shipped.

Layer 2: the platform translation layer

Steam Input. The Switch’s system button mapping. PlayStation’s custom assignments, the Xbox Accessories app. All of them sit between controller and game, rewriting input reports in flight. This is the layer that made remapping universal, because it rescues games that shipped locked — and it charges rent: translation pipelines carry their own processing, their own buffering, their own revision histories. Valve’s Steam Input documentation is candid that the configurator is a pipeline, not a passthrough. I put numbers on the rent below.

Layer 3: firmware

Open firmware like GP2040-CE on RP2040 boards, and vendor tools like 8BitDo’s software or the Elite Series 2’s profile slots, do the remap while assembling the input report itself. The table gets consulted once per report build; the added cost rounds to nothing against the board’s sub-millisecond USB overhead. This is also the layer tinkerers should actually read, because the source is public: GP2040-CE’s documentation covers its remap and SOCD handling more honestly than most commercial products cover anything.

Layer 4: physical

The honest layer. JAMMA (standardized 1985) put the mapping in the wiring loom: wanted punch on a different button? Move the wire on the edge connector. JVS (1996) pushed mapping into software through I/O boards, and Sega’s Model 3-era JVS I/O earns specific respect for turning a soldering job into a settings job without pretending the timing had changed. Below the arcade level, it is solder — trace cuts, jumper wires, swapped microswitches — plus the all-button controller, which is best understood as remapping a lever onto buttons using a drill. Real labor, real risk. Every layer above this one exists so you never have to visit it.

Why locked mappings ever happened

Console mappings got locked for reasons that made sense per-platform and none per-player. Certification conventions hardened regional defaults: Sony’s western releases swapped Japan’s circle-confirm, cross-cancel convention per title, in code, so the “correct” confirm button depended on where your disc was pressed. Cartridge hardware offered no help — the NES pad is a shift register the CPU clocks at $4016, and the mapping from “button B” to “attack” lives entirely in the game’s own code. There is no remap layer to patch without hacking the ROM.

Arcades dodged the problem by standardizing the connector instead of the mapping, an elegant dodge modern certification never attempted. Today’s excuse is UI work: every on-screen prompt that says “press X” has to learn to read the rebind table, and some games ship with hardcoded prompts sitting right next to a working rebind menu. Two features, one build, never introduced to each other. That is real work. It is also work Quake’s console solved with a text string in 1996, and work Valve’s configurator does for an entire library, per game, with the prompts intact.

The accessibility case is settled — and it is also a performance case

Hardware set the floor for this argument, not menus. Microsoft’s Adaptive Controller (2018) and Sony’s Access controller (December 2023) exist because bodies differ and fixed layouts presume a standard one. The Game Accessibility Guidelines project lists remappable inputs among its basic motor recommendations, which is the polite way to put it. The blunt way: before system-level remaps existed, the standard workaround for a bad layout was the claw grip, and the claw grip’s long-term bill is why hand pain is a shared memory in competitive circles of a certain era.

The competitive angle is the same angle. A remap that saves a thumb twenty millimeters of travel is a remap that saves frames, and the speedrun community’s “remapping allowed, turbo not” consensus formed because players found those frames first. Accessibility and optimization converge on the same lookup table.

Now the criticism, with names attached. Nintendo’s system-level mapping, added in firmware 5.0.0 (March 2018), is global: remap for one game and every other game on the console inherits it — accommodation that cancels itself the moment you own a second game. Sony’s PS4 firmware 2.50 (March 2015) placed custom button assignment under the Accessibility menu — right idea, right menu, still global, so fighting-game players who wanted a per-title layout kept buying pads with onboard profile slots instead. And the wave of “definitive” re-releases that inherit PS2-era fixed mappings, then point you at the system-wide remap that breaks every other game’s muscle memory, is not preservation. It is a port with a marketing budget.

What remapping costs on the bench

Short version: the game layer is free, the firmware layer rounds to free, the platform layer is cheap when engineered well, and the adapter layer is a tax. The long version, from my rig — a 240 fps capture chain with a GPIO tap soldered to the button line so press timestamps never depend on the camera, 10,000 samples per configuration, medians with 99th-percentile spread. Your noise floor will differ. Your conclusions should not, as long as you name your revisions.

• In-game rebind table: remapped versus default layouts measured inside run-to-run noise, under 0.3 ms at my floor. A lookup does not have a polling rate.
• Firmware remap (GP2040-CE 0.7.x, 1,000 Hz polling): remap on versus off, same noise band. The table is consulted during report assembly; there is nothing to measure.
• Steam Input (XInput translation, 2024 client build): +4 to 7 ms median over direct input, worse with gyro and heavy action layers; titles speaking the native Steam Input API came in under 2 ms. Client revisions move this number. Re-measure after updates instead of quoting me.
• Translation adapter boxes: +8 to 20 ms and, worse, inconsistent poll timing — the box impersonates a controller to the console and a console to the controller, and neither end can see the middle. Boxes in the Cronus family are banned at majors for reasons that include latency but mostly include everything else the box can do.

The pattern is clean: cost scales with how far the remap sits from the game’s own input read. Layer 1 is free. Layer 3 rounds to free. Layer 2 is a real pipeline that good engineering keeps cheap. Layer 4 was always yours to pay. When a game refuses to ship the free layer, it is not protecting its input timing — it is outsourcing your ergonomics to whichever layer you can afford.

The competitive wrinkle: remaps, macros, and SOCD

Rules first, because rulebooks are the primary sources here. Most leaderboard rule sets I have audited treat a 1:1 remap — one physical input, one logical action, timing untouched — as legal, and draw a bright line at turbo and macros. That line exists for a measurable reason: a macro inserts input patterns no hand can produce on that schedule. Read your game’s rules page before assuming anything. “Most” is not “all,” and the rules page outranks my summary.

Where remapping genuinely changes what the game can see is direction handling. Remap a joystick onto four buttons and opposing directions become simultaneously pressable — simultaneous opposing cardinal directions, SOCD, the acronym that reshaped fighting-game hardware rules. All-button controllers forced the issue; modern firmware such as GP2040-CE exposes SOCD modes explicitly (last input wins, neutral, and variants), and tournament rulesets lock the legal ones. A remap menu that touches directions is a rules document whether the developer wrote one or not.

Keyboard players get one caveat remapping cannot fix: rollover. Ghosting and blocking live in the key matrix. Rebinds move which keys you press; they do not add a single contact the board can read at once. Remap around the matrix, not through it.

The practical guidance ends up the same as the rules-page advice: keep remaps 1:1, do them in-game whenever the option exists so the timing chain stays honest, document what you changed, and never let an adapter answer a question the game’s own settings menu should have answered.

What a good remap system looks like

A checklist, so this stops being an argument and becomes a spec:

• Two layers minimum. A per-game rebind menu plus the platform’s system-level fallback, so no game ships without a net.
• Prompts that read the table. If the rebind menu works but the screen still said “press F,” the feature shipped half-finished.
• Hold, toggle, and repeat options for actions, not just bindings — the difference between accommodation and a screenshot.
• Analog and digital crossings handled. Stick-to-buttons and button-to-stick are where remap interfaces go to die. Ship both or say plainly that you did not.
• Profiles, exportable. Muscle memory should travel between installs and be shareable between players.
• Per-game, not global. The Switch 5.0.0 approach proved the demand. It also proved the ceiling.

The compliment goes where it is earned: Valve’s Steam Input configurator is the best shipping implementation of all of the above — per-game, prompt-aware, gyro included, with a native API path that keeps the fast lane fast. The criticism stays attached to the same name: its translation layer’s timing varies by client revision, which makes the best implementation on the market the one you should re-bench after every update. Trust the architecture. Verify the build.

FAQ

Does remapping controls add input lag?

At the game layer, no — an in-game rebind is a table lookup at input-read time, and on my bench it measures inside run-to-run noise. At the firmware layer, also no: remaps apply while the input report is assembled. Platform translation layers like Steam Input add measurable overhead — single-digit milliseconds in my tests, configuration-dependent — and third-party adapter boxes add the most, with inconsistent polling on top. Rule of thumb: the closer the remap sits to the game’s own input read, the less it costs.

What is the difference between a remap and a macro?

A remap is one-to-one: one physical input, one logical action, timing untouched. A macro is one-to-many or scripted: a single press generates multiple timed inputs. Competitive rules almost universally allow the first and ban the second, because a macro produces input patterns no hand can replicate on that schedule. If your “remap” has a delay field, it is a macro. Check the rules page.

Which platforms let you remap buttons at the system level?

PlayStation 4 added custom button assignments in firmware 2.50 (March 2015), under Accessibility, applied globally. The Switch added system button mapping in firmware 5.0.0 (March 2018), also global. Xbox offers app-based remapping through the Xbox Accessories app, historically limited to Elite-series pads and the Adaptive Controller before expanding to standard controllers. PS5 carries per-controller custom assignments forward under Accessibility. On PC, Steam Input covers the whole library per game. None of these replaces an in-game menu — they are the net under games that never shipped one.

Is controller remapping allowed in speedruns?

Usually, yes. Most leaderboard rules treat a pure 1:1 remap as legal and ban turbo, macros, and — at in-person events — certain adapter hardware. Exceptions exist per game and per category, and the rules page is the primary source. Keep the layout 1:1, document it, and prefer in-game remapping so nothing sits between your input and the game’s read.

Why do some modern games still ship without remapping?

Three recurring causes: on-screen prompts hardcoded against default bindings (real UI work, solved since 1996 by reading the table), legacy code inheriting fixed mappings through remasters and collections, and certification-era assumptions about a standard player holding a standard pad. None of the causes survives the counterexamples — Quake’s bind console, DOS setup programs, JVS I/O boards, and every firmware remap layer that treats the feature as the lookup table it is.

What is next on the bench

This piece opens what I am calling the Remap Audit — a recurring column where each installment measures one platform’s remap path end to end: game layer, platform layer, firmware where applicable, adapter only where unavoidable. First targets: Steam Input across three client revisions, because a moving measurement is the only honest one, and the Switch’s global mapping, because someone should quantify what “global” costs a two-game library. Holding a game that shipped locked this year? Send the title, the version, and a capture of the menu where the option should be — reader submissions set the queue. And if terms like SOCD and translation layer keep showing up around here, that is the glossary column asking to be written.

Every game should let you remap your controls because the lookup table is free, the accessibility case was settled by hardware the industry itself ships, and the only open question is which layer gets to hold the table. The bench says let the game hold it. The patch notes say ask again next quarter.