Repository navigation
Prep for Rotation Feature in Crosshairs - #38
samtcifihi wants to merge 2 commits into
Conversation
Crosshairs needs altitude numbers to remain upright while their positions follow the rotating planes. Existing glyph nudges follow the glyph's own counter-rotation and therefore stay fixed on screen. Add opt-in nudge.relativeTo = "piece" to translate in enclosing piece/face axes after glyph rotation and flips, retaining scaled offset units. Preserve existing behavior when omitted or set to "glyph". Regenerate schema types and document the option. Validation: 18 new offset tests and 4 existing flip/rotation tests pass; renderer compilation with ES2022 libraries and targeted lint pass. Tested jointly with the Crosshairs change across all 12 angles and 4 display modes. Companion proposal: samtcifihi/ap-gameslib branch crosshairs-board-rotation-30. Release the renderer update before updating gameslib's renderer dependency and integrating that branch.
…s-rotation-chappy-kver8m
|
Here was Claude's step recommendations to me (edited for irrelevant information):
I'm not entirely sure what steps 2 and 3 entail, so I've left them verbatim as Claude put them. Barring more specific instructions, I'll assume that step 2 is complete when you say the renderer change is good to go, and I'll ask Claude to walk me through step 3 and verify whether it's something on my end or not |
|
I am very protective of the renderer. It is the core of everything. AI has routinely gotten things wrong. Please tell me what problem this PR is trying to solve. Yes I will read the code closely, but I'd like to hear from you what the goal is. Thanks! |
|
Makes total sense to be cautious, yeah. Some of the display options in Crosshairs use numbers to indicate height. But rather than being centered in the cell like in many games, or always in a particular corner like Decktet games, they rotate around with the plane to nicely sit in the whitespace next to the plane icon. But they also rotate themselves to stay upright because they're meant to be read. So unless we're missing something, there's currently a tradeoff in whether we want to have numbers sometimes overlap plane glyphs, or have them sometimes sideways and upside down. The intention here is to avoid needing to make that tradeoff When I had Claude review it, I specifically highlighted that I wasn't sure a renderer change was necessary, but you're right that a way to do it without a renderer change could have slipped by him PS: After writing it, I ran this comment by Claude for factual accuracy, and he agreed I was correctly representing what he was trying to do, but acknowledged that he may have missed an alternate approach |
|
I'm at a disadvantage not having played or coded crosshairs. I will take a look at how Fritz builds the render. There may be a simpler solution. If you happen to have a game state that illustrates the problem, that would be great. |
|
And yes, steps 2 and 3 above are about the workflow. Once a new version of the renderer gets published, it propagates through the tool chain, bumping the pinned I'm each of the consumers. It's one reason a full deployment takes as long as it does. |
|
Since Crosshairs doesn't currently allow rotation, everything works, but here's a game state with some planes in various orientations. The "Plane glyphs with two small numeric altitude indicators." is the display option in question. The current code won't let you rotate, but if you rotate anyway, this should illustrate it PS: I've asked Claude to see if he can find an alternate approach that doesn't need a gameslib change. I'll add a comment if he finds something. EDIT: Claude on my end couldn't find any alternate approaches, for what it's worth, and he gave some arguments as to why he thinks the gameslib change is necessary as well as cited a place where he thinks the renderer already includes a similar patch, but he could be wrong. Unless specified otherwise I'll assume that relaying what Claude says beyond generalities would be unhelpful and redundant with what Claude says on your end |
|
It is absolutely true that gameslib does not know anything about user rotation. I'm not against adjusting the renderer, to be clear. I just wanted to make sure I fully understood the problem the PR was trying to solve before diving in to validate it. I just know from experience that AI has routinely blown the renderer up, so I'm just extra cautious. |
|
Totally makes sense; measure twice cut once and all that. Feel free to ask me if you need anything else |
|
So the ultimate goal here is just to be able to rotate the board and keep everything looking correct, including the little numbers? |
|
That is correct |
|
So I'm going with the spirit of the PR but not the PR itself. We're going to add |
3 participants
What
tldr, it adds an option that Crosshairs can use to implement rotation without numbers being either sideways or overlapping plane glyphs sometimes. Chappy made initial branches here and in the gameslib for me, but I wasn't sure if it was right, so I had Claude go over it, and he recommended resolving this PR first and only once it was working, do the PR for the gameslib change, since otherwise the gameslib might ask for a renderer function which didn't exist
What follows was generated by Claude; I've kept it unchanged since it has a lot of specific detail which might be helpful:
Adds
nudge.relativeTo("glyph"|"piece", default"glyph") to the glyph schema.Today a
nudgeoffset is always applied in the glyph's own post-rotation/flip axes. For an upright label (orientation: "vertical") attached to a piece that itself rotates with the board, that means the label's offset is pinned to a fixed screen angle — it does not travel with the piece as the board rotates.relativeTo: "piece"translates in the enclosing piece/face axes instead, so an upright label can stay at a fixed position relative to a rotating piece (e.g. beside its nose, or its tail) at any board rotation.This is needed for the AbstractPlay/gameslib Crosshairs board-rotation feature: Crosshairs' numeric/numeric-abstract display modes put small altitude digits at a fixed angular offset from each plane's heading, and those digits must stay in that same relative position as the user rotates the board in 30° increments.
Why here, not in gameslib
Gameslib has no way to know the user's chosen board rotation at legend-construction time — only the renderer applies it, when it counter-rotates upright glyphs and bakes in the board transform. So the "stay relative to the piece as it rotates" behavior can only be implemented in the renderer.
Compatibility
relativeTois optional and defaults to"glyph", which is exactly the prioruse.dmove(dx, dy)behavior. No existingnudgeusage is affected..d.ts, and docs (docs/glyphs.md) updated together.Testing
test/glyphNudge.render.test.ts(new): for every combination of board rotation (0°–330° in 30° steps) andrelativeTo(undefined/"glyph"/"piece"), renders an upright, flipped, rotated glyph with a nudge and checks the resulting screen-space offset against the expected value for each coordinate system.npm run typecheckandnpm run lintclean._base.tshunk and re-running the downstream gameslib Crosshairs rotation test reproduces 22 failures (digits land at the wrong angle at every rotation except 0°), confirming the change is load-bearing, not decorative.🤖 Generated with Claude Code