Nine-Slice für Sprites: Rahmen und Knöpfe behalten beim Skalieren ihre Ecken, nur die Mitte und die Kanten werden gestreckt.
Stand: ein Frame wird immer auf die Grösse des Sprites gestreckt (steht auch unter "Not yet" in der README).
Abzuklären: die vier Ränder am Frame/an der Textur festlegen oder am Sprite.
Übernommen aus todo-notes/nine-slice.md beim Umzug auf das Issue-System (2026-09-12).
Angelegt: 2026-09-11 · bf41919 — Add todo notes for the next round of features, gaps and upkeep
Gemeldet von: Claude (Assistent)
Nine-Slice für Sprites: Rahmen und Knöpfe behalten beim Skalieren ihre Ecken, nur die Mitte und die Kanten werden gestreckt.
Stand: ein Frame wird immer auf die Grösse des Sprites gestreckt (steht auch unter "Not yet" in der README).
Abzuklären: die vier Ränder am Frame/an der Textur festlegen oder am Sprite.
---
*Übernommen aus `todo-notes/nine-slice.md` beim Umzug auf das Issue-System (2026-09-12).*
- **Angelegt:** 2026-09-11 · `bf41919` — Add todo notes for the next round of features, gaps and upkeep
- **Gemeldet von:** Claude (Assistent)
Ränder soll natürlich beim Frame in der Texture festgelegt werden können. Außerdem braucht noch ein weiteres Property beim Frame was bestimmt wie die Ränderkanten ausgefüllt werden (wiederholen, strecken)
Ränder soll natürlich beim Frame in der Texture festgelegt werden können. Außerdem braucht noch ein weiteres Property beim Frame was bestimmt wie die Ränderkanten ausgefüllt werden (wiederholen, strecken)
admin
moved this to Next in Development on 2026-09-16 08:27:50 +02:00
Ränder am Frame (wie hier entschieden): TextureFrame trägt border (links/rechts/oben/unten) und fill, beide optional. Ein Dokument ohne sie heißt genau „nicht geslict" — deshalb kein Format-Bump, und setFrameSlice löscht die Schlüssel wieder, wenn sie nichts mehr bedeuten: das Undo eines Randes stellt den schlichten Frame wieder her, statt vier Nullen zu hinterlassen.
fill = stretch | repeat, eine Einstellung für die Kanten und die Mitte. Mein Einwand gegen den Kachel-Modus war, dass repeat-Sampling bei einem Frame aus einem Sheet die Nachbarzelle hereinzieht. Der Ausweg liegt in der Geometrie statt im Sampler: pro Kachel ein Quad mit den echten UVs der Frame-Zelle, die letzte angeschnitten. Damit kachelt auch ein Frame aus einem Sheet sauber. Ab 64 Kacheln je Achse wird gestreckt — ein Schutz gegen einen Puffer, der mit der Sprite-Größe wächst, keine Designaussage.
Zu kleines Sprite: links und rechts werden gemeinsam heruntergerechnet, bis die Mitte genau 0 ist. Die Ecken treffen sich an einer Naht, nie übereinander.
Bedienung: vier ziehbare Linien im Textur-Editor plus dieselben vier Zahlen im Inspector.
Ein Fund, den erst der e2e-Schritt gezeigt hat
Die Randlinien waren zuerst unerreichbar: handleAt meldet im Inneren eines Frames immer 'move', die Reihenfolge „Handles → Linien" war damit wirkungslos, der erste Testdrag verschob den Frame. Richtig ist dreistufig: die acht Größenpunkte, dann die Linien, dann der Frame-Körper.
Zweitens las der neue pixelRow-Hook anfangs einen 120×1-Streifen als ein Extract — der kommt resampled zurück, jede harte Kante war weichgezeichnet. Jetzt sind es N Einzelmessungen wie bei pixelAt; ein Instrument, das Kanten verwischt, taugt nicht zum Messen von Kanten.
Belegt
npm run check → 88 Files, 1124 Tests, grün (vorher 1109)
npm run build → ok
GM_STEPS=37 node tools/e2e.mjs → ALL PASSED – 12 checks
15 neue Unit-Tests (Spans, Geometrie, Cache-Schlüssel, Normalisierung, Kommando samt Undo, Serialisierungs-Rundlauf, Randlinien-Geometrie) und Schritt 37 nine-slice mit dem Pixelbeweis auf echter GPU: der rote Rand misst 7 px bei einem 200er Sprite (erwartet 8), dieselbe Grafik ohne Ränder 66 (8/24 × 200 = 66,7), die Mitte zeigt 23 Kachelstreifen statt 1.
Die Gesamtzahl 955 im Wiki ist eine Rechnung (943 gemessen aus CI-55 + 12); bestätigt erst der CI-Lauf auf be8f233. Sagt der etwas anderes, mache ich das Issue wieder auf.
Umgesetzt in `be8f233`.
**Ränder am Frame** (wie hier entschieden): `TextureFrame` trägt `border` (links/rechts/oben/unten) und `fill`, beide **optional**. Ein Dokument ohne sie heißt genau „nicht geslict" — deshalb kein Format-Bump, und `setFrameSlice` löscht die Schlüssel wieder, wenn sie nichts mehr bedeuten: das Undo eines Randes stellt den schlichten Frame wieder her, statt vier Nullen zu hinterlassen.
**`fill` = `stretch` | `repeat`**, eine Einstellung für die Kanten **und** die Mitte. Mein Einwand gegen den Kachel-Modus war, dass `repeat`-Sampling bei einem Frame aus einem Sheet die Nachbarzelle hereinzieht. Der Ausweg liegt in der **Geometrie statt im Sampler**: pro Kachel ein Quad mit den echten UVs der Frame-Zelle, die letzte angeschnitten. Damit kachelt auch ein Frame aus einem Sheet sauber. Ab 64 Kacheln je Achse wird gestreckt — ein Schutz gegen einen Puffer, der mit der Sprite-Größe wächst, keine Designaussage.
**Zu kleines Sprite:** links und rechts werden gemeinsam heruntergerechnet, bis die Mitte genau 0 ist. Die Ecken treffen sich an einer Naht, nie übereinander.
**Bedienung:** vier ziehbare Linien im Textur-Editor plus dieselben vier Zahlen im Inspector.
### Ein Fund, den erst der e2e-Schritt gezeigt hat
Die Randlinien waren zuerst **unerreichbar**: `handleAt` meldet im Inneren eines Frames immer `'move'`, die Reihenfolge „Handles → Linien" war damit wirkungslos, der erste Testdrag verschob den Frame. Richtig ist dreistufig: die acht Größenpunkte, **dann** die Linien, **dann** der Frame-Körper.
Zweitens las der neue `pixelRow`-Hook anfangs einen 120×1-Streifen als ein Extract — der kommt resampled zurück, jede harte Kante war weichgezeichnet. Jetzt sind es N Einzelmessungen wie bei `pixelAt`; ein Instrument, das Kanten verwischt, taugt nicht zum Messen von Kanten.
### Belegt
```
npm run check → 88 Files, 1124 Tests, grün (vorher 1109)
npm run build → ok
GM_STEPS=37 node tools/e2e.mjs → ALL PASSED – 12 checks
```
15 neue Unit-Tests (Spans, Geometrie, Cache-Schlüssel, Normalisierung, Kommando samt Undo, Serialisierungs-Rundlauf, Randlinien-Geometrie) und **Schritt 37 `nine-slice`** mit dem Pixelbeweis auf echter GPU: der rote Rand misst **7 px bei einem 200er Sprite** (erwartet 8), dieselbe Grafik ohne Ränder **66** (8/24 × 200 = 66,7), die Mitte zeigt **23 Kachelstreifen statt 1**.
Die Gesamtzahl **955** im Wiki ist eine Rechnung (943 gemessen aus CI-55 + 12); bestätigt erst der CI-Lauf auf `be8f233`. Sagt der etwas anderes, mache ich das Issue wieder auf.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Nine-Slice für Sprites: Rahmen und Knöpfe behalten beim Skalieren ihre Ecken, nur die Mitte und die Kanten werden gestreckt.
Stand: ein Frame wird immer auf die Grösse des Sprites gestreckt (steht auch unter "Not yet" in der README).
Abzuklären: die vier Ränder am Frame/an der Textur festlegen oder am Sprite.
Übernommen aus
todo-notes/nine-slice.mdbeim Umzug auf das Issue-System (2026-09-12).bf41919— Add todo notes for the next round of features, gaps and upkeepRänder soll natürlich beim Frame in der Texture festgelegt werden können. Außerdem braucht noch ein weiteres Property beim Frame was bestimmt wie die Ränderkanten ausgefüllt werden (wiederholen, strecken)
Umgesetzt in
be8f233.Ränder am Frame (wie hier entschieden):
TextureFrameträgtborder(links/rechts/oben/unten) undfill, beide optional. Ein Dokument ohne sie heißt genau „nicht geslict" — deshalb kein Format-Bump, undsetFrameSlicelöscht die Schlüssel wieder, wenn sie nichts mehr bedeuten: das Undo eines Randes stellt den schlichten Frame wieder her, statt vier Nullen zu hinterlassen.fill=stretch|repeat, eine Einstellung für die Kanten und die Mitte. Mein Einwand gegen den Kachel-Modus war, dassrepeat-Sampling bei einem Frame aus einem Sheet die Nachbarzelle hereinzieht. Der Ausweg liegt in der Geometrie statt im Sampler: pro Kachel ein Quad mit den echten UVs der Frame-Zelle, die letzte angeschnitten. Damit kachelt auch ein Frame aus einem Sheet sauber. Ab 64 Kacheln je Achse wird gestreckt — ein Schutz gegen einen Puffer, der mit der Sprite-Größe wächst, keine Designaussage.Zu kleines Sprite: links und rechts werden gemeinsam heruntergerechnet, bis die Mitte genau 0 ist. Die Ecken treffen sich an einer Naht, nie übereinander.
Bedienung: vier ziehbare Linien im Textur-Editor plus dieselben vier Zahlen im Inspector.
Ein Fund, den erst der e2e-Schritt gezeigt hat
Die Randlinien waren zuerst unerreichbar:
handleAtmeldet im Inneren eines Frames immer'move', die Reihenfolge „Handles → Linien" war damit wirkungslos, der erste Testdrag verschob den Frame. Richtig ist dreistufig: die acht Größenpunkte, dann die Linien, dann der Frame-Körper.Zweitens las der neue
pixelRow-Hook anfangs einen 120×1-Streifen als ein Extract — der kommt resampled zurück, jede harte Kante war weichgezeichnet. Jetzt sind es N Einzelmessungen wie beipixelAt; ein Instrument, das Kanten verwischt, taugt nicht zum Messen von Kanten.Belegt
15 neue Unit-Tests (Spans, Geometrie, Cache-Schlüssel, Normalisierung, Kommando samt Undo, Serialisierungs-Rundlauf, Randlinien-Geometrie) und Schritt 37
nine-slicemit dem Pixelbeweis auf echter GPU: der rote Rand misst 7 px bei einem 200er Sprite (erwartet 8), dieselbe Grafik ohne Ränder 66 (8/24 × 200 = 66,7), die Mitte zeigt 23 Kachelstreifen statt 1.Die Gesamtzahl 955 im Wiki ist eine Rechnung (943 gemessen aus CI-55 + 12); bestätigt erst der CI-Lauf auf
be8f233. Sagt der etwas anderes, mache ich das Issue wieder auf.