Pixel Art und Vector Art: Nine Slice und Sort Line #308

Closed
opened 2026-10-03 19:17:20 +02:00 by admin · 2 comments

Bei Pixel Art bzw. Vector Art Assets fehlt die Möglichkeit eine sort line wie bei Texture Frame zu setzen. Auch nine slice properties sind nicht möglich. Wie könnten wir das umsetzen ohne doppelten code zu erzeugen?

Bei Pixel Art bzw. Vector Art Assets fehlt die Möglichkeit eine sort line wie bei Texture Frame zu setzen. Auch nine slice properties sind nicht möglich. Wie könnten wir das umsetzen ohne doppelten code zu erzeugen?
admin added this to the Development project 2026-10-03 19:17:20 +02:00
admin moved this to Next in Development on 2026-10-03 19:17:26 +02:00
admin added the question label 2026-10-03 19:18:11 +02:00
Owner

Plan. Kurz gesagt: Fast alles gibt es schon, es hängt nur am Texture-Frame. Ich würde es von dort lösen, statt es nachzubauen.

Was schon da ist

  • Zeichnen und Sortieren sind schon allgemein. Beide lesen Nine-Slice und Sort Line aus dem TextureRef, den jedes Bild liefert (symbols.ts:77, drawOrder.ts:161). Bei Pixel Art und Vector Art setzt generatedRef dort heute fest slice: null und lässt sortLine weg (texture.ts:109). Mehr fehlt im Bildpfad nicht.
  • Die Regeln brauchen vom Frame nur drei Schlüssel und eine Größe. normalizeBorders, setFrameSlice, frameSortLine usw. lesen border, fill, sortLine und w/h. Das passt genauso auf ein Pixel-Art- oder Vector-Art-Asset.
  • Zerschneiden geht auch bei einem erzeugten Bild. Nine-Slice arbeitet mit UVs von 0 bis 1 des Frames. Pixel-Art-Frames werden aus ihrem Sheet geschnitten, Vector Art ist ein ganzes Bild. Bei beiden braucht es also keinen neuen Zuschnitt.

Vorschlag: aus einem Frame-Feature ein Bild-Feature machen

  1. Modell: Ein gemeinsamer Typ PictureCut mit border?, fill? und sortLine?. TextureFrame erweitert ihn, das Dateiformat der Texturen bleibt dabei gleich. PixelArtAsset und VectorArtAsset bekommen dieselben drei optionalen Schlüssel. Fehlt einer, bleibt alles wie heute, eine Migration braucht es nicht.
  2. Regeln: Die Funktionen in texture.ts nehmen statt TextureFrame einen PictureCut und eine Größe. Die Größe ist der Frame, width/height bei Pixel Art oder die Canvas-Größe bei Vector Art. serialize.ts liest die Schlüssel für alle drei Typen über dieselben Funktionen ein.
  3. Bildpfad: generatedRef füllt slice und sortLine aus dem Asset, mit demselben nineSliceOf wie bei Texturen. Nine-slice scale wird eine gemeinsame Schema-Zeile, die auch Pixel Art und Vector Art bekommen.
  4. Commands: SetFrameSliceCommand und SetFrameSortLineCommand bekommen statt (assetId, frameId) ein Ziel: ein Texture-Frame oder ein ganzes Zeichen-Asset. Es bleibt eine Klasse je Command, und Undo funktioniert wie bisher.
  5. Inspector: Die Blöcke NINE-SLICE und SORTING wandern aus frameSection.ts in eine eigene Datei. Frame-Inspector und Asset-Inspector (Pixel Art, Vector Art) rufen sie mit ihrem Ziel auf, die Zeilen gibt es also nur einmal.
  6. Gefundene Lücke: drawOrder.ts:162 rechnet die Sort Line über rect.h um. Ein ganzes Bild hat rect: null, die Linie würde bei Vector Art also stillschweigend ignoriert. Dort kommt sourceHeight als Rückfall dazu.

Fragen (mit Vorschlag)

  1. Pixel Art: eine Einstellung je Asset oder je Frame? Vorschlag: je Asset. Alle Frames haben dieselbe Canvas-Größe und sind meist Bilder einer Animation, die Füße stehen also in jedem Frame an derselben Stelle. Je Frame bräuchte eine Auswahl einzelner Pixel-Frames im Inspector, die es heute nicht gibt.
  2. Bearbeiten im Tab: Im Texture-Tab zieht man Ränder und Sort Line mit der Maus. Vorschlag: erst nur Inspector-Zeilen, die Linien aber im Pixel-Art- und Vector-Art-Tab einzeichnen (nicht ziehbar), mit der Geometrie aus sheetView.ts. Zum Ziehen müsste die Drag-Logik aus TextureCanvas heraus, und sie käme den Malwerkzeugen beider Tabs in die Quere. Das wäre ein eigenes Issue.
  3. Einheit: Ränder und Sort Line in Canvas-Pixeln, bei Pixel Art wie bei Vector Art. Vector Art rastert zwar überabgetastet, die UVs gelten aber relativ zum Bild. Vorschlag: so lassen.

Nicht dabei

  • Kollisionsumrisse je Frame (#141) für Pixel Art und Vector Art. Danach war nicht gefragt, sie ließen sich aber später auf demselben Weg anhängen.

Tests

  • Unit: die verallgemeinerten Regeln, resolvePicture für Pixel-Art-Frame und Vector Art mit slice/sortLine, der drawOrder-Rückfall und die Commands mit beiden Zielen (je mit Gegenprobe).
  • e2e: ein Check in Modul 48 (Pixel Art), dass ein Sprite mit Rändern in neun Teilen gezeichnet wird. Vector Art läuft über denselben Code, das deckt der Unit-Test ab.
Plan. Kurz gesagt: Fast alles gibt es schon, es hängt nur am Texture-Frame. Ich würde es von dort lösen, statt es nachzubauen. ## Was schon da ist - **Zeichnen und Sortieren sind schon allgemein.** Beide lesen Nine-Slice und Sort Line aus dem `TextureRef`, den jedes Bild liefert (`symbols.ts:77`, `drawOrder.ts:161`). Bei Pixel Art und Vector Art setzt `generatedRef` dort heute fest `slice: null` und lässt `sortLine` weg (`texture.ts:109`). Mehr fehlt im Bildpfad nicht. - **Die Regeln brauchen vom Frame nur drei Schlüssel und eine Größe.** `normalizeBorders`, `setFrameSlice`, `frameSortLine` usw. lesen `border`, `fill`, `sortLine` und `w`/`h`. Das passt genauso auf ein Pixel-Art- oder Vector-Art-Asset. - **Zerschneiden geht auch bei einem erzeugten Bild.** Nine-Slice arbeitet mit UVs von 0 bis 1 des Frames. Pixel-Art-Frames werden aus ihrem Sheet geschnitten, Vector Art ist ein ganzes Bild. Bei beiden braucht es also keinen neuen Zuschnitt. ## Vorschlag: aus einem Frame-Feature ein Bild-Feature machen 1. **Modell:** Ein gemeinsamer Typ `PictureCut` mit `border?`, `fill?` und `sortLine?`. `TextureFrame` erweitert ihn, das Dateiformat der Texturen bleibt dabei gleich. `PixelArtAsset` und `VectorArtAsset` bekommen dieselben drei optionalen Schlüssel. Fehlt einer, bleibt alles wie heute, eine Migration braucht es nicht. 2. **Regeln:** Die Funktionen in `texture.ts` nehmen statt `TextureFrame` einen `PictureCut` und eine Größe. Die Größe ist der Frame, `width`/`height` bei Pixel Art oder die Canvas-Größe bei Vector Art. `serialize.ts` liest die Schlüssel für alle drei Typen über dieselben Funktionen ein. 3. **Bildpfad:** `generatedRef` füllt `slice` und `sortLine` aus dem Asset, mit demselben `nineSliceOf` wie bei Texturen. `Nine-slice scale` wird eine gemeinsame Schema-Zeile, die auch Pixel Art und Vector Art bekommen. 4. **Commands:** `SetFrameSliceCommand` und `SetFrameSortLineCommand` bekommen statt `(assetId, frameId)` ein Ziel: ein Texture-Frame oder ein ganzes Zeichen-Asset. Es bleibt eine Klasse je Command, und Undo funktioniert wie bisher. 5. **Inspector:** Die Blöcke *NINE-SLICE* und *SORTING* wandern aus `frameSection.ts` in eine eigene Datei. Frame-Inspector und Asset-Inspector (Pixel Art, Vector Art) rufen sie mit ihrem Ziel auf, die Zeilen gibt es also nur einmal. 6. **Gefundene Lücke:** `drawOrder.ts:162` rechnet die Sort Line über `rect.h` um. Ein ganzes Bild hat `rect: null`, die Linie würde bei Vector Art also stillschweigend ignoriert. Dort kommt `sourceHeight` als Rückfall dazu. ## Fragen (mit Vorschlag) 1. **Pixel Art: eine Einstellung je Asset oder je Frame?** Vorschlag: **je Asset.** Alle Frames haben dieselbe Canvas-Größe und sind meist Bilder einer Animation, die Füße stehen also in jedem Frame an derselben Stelle. Je Frame bräuchte eine Auswahl einzelner Pixel-Frames im Inspector, die es heute nicht gibt. 2. **Bearbeiten im Tab:** Im Texture-Tab zieht man Ränder und Sort Line mit der Maus. Vorschlag: **erst nur Inspector-Zeilen, die Linien aber im Pixel-Art- und Vector-Art-Tab einzeichnen** (nicht ziehbar), mit der Geometrie aus `sheetView.ts`. Zum Ziehen müsste die Drag-Logik aus `TextureCanvas` heraus, und sie käme den Malwerkzeugen beider Tabs in die Quere. Das wäre ein eigenes Issue. 3. **Einheit:** Ränder und Sort Line in Canvas-Pixeln, bei Pixel Art wie bei Vector Art. Vector Art rastert zwar überabgetastet, die UVs gelten aber relativ zum Bild. Vorschlag: so lassen. ## Nicht dabei - Kollisionsumrisse je Frame (#141) für Pixel Art und Vector Art. Danach war nicht gefragt, sie ließen sich aber später auf demselben Weg anhängen. ## Tests - Unit: die verallgemeinerten Regeln, `resolvePicture` für Pixel-Art-Frame und Vector Art mit `slice`/`sortLine`, der `drawOrder`-Rückfall und die Commands mit beiden Zielen (je mit Gegenprobe). - e2e: ein Check in Modul 48 (Pixel Art), dass ein Sprite mit Rändern in neun Teilen gezeichnet wird. Vector Art läuft über denselben Code, das deckt der Unit-Test ab.
admin removed the question label 2026-10-03 19:43:56 +02:00
Owner

Umgesetzt wie im Plan, mit deinen drei Antworten (je Asset, Linien nur anzeigen, Canvas-Pixel). Commit: 3e05cbb, Wiki: a8a6580 (Textures, Pixel-Art, Vector-Art, Architecture, Development).

Was jetzt geht

  • Pixel Art und Vector Art haben im Inspector dieselben Blöcke NINE-SLICE und SORTING wie ein Texture-Frame, in Canvas-Pixeln, dazu die Zeile Nine-slice scale.
  • Ein Sprite, das so ein Bild trägt, wird in neun Teilen gezeichnet und auf einer nach Y sortierten Ebene an der Sort Line einsortiert.
  • Pixel Art: Eine Einstellung gilt für jeden Frame. Das Asset selbst steht bei mehreren Frames für den Streifen aller Frames nebeneinander. Dieser Streifen wird nicht zerschnitten, nur ein einzelner Frame. Bei einem Frame sind Asset und Frame dasselbe Bild.
  • Im Tab zeichnen beide Editoren die gesetzten Ränder gestrichelt und die Sort Line gelb ein. Ziehen lassen sie sich dort nicht, eingegeben wird im Inspector. Linien auf 0 werden nicht gezeichnet, sie lägen nur auf dem Rand der Zeichnung.

Ohne doppelten Code

  • Ein gemeinsamer Typ PictureCut (border, fill, sortLine). TextureFrame erweitert ihn, Pixel Art und Vector Art tragen ihn als Ganzes.
  • Die Regeln in texture.ts nehmen einen Schnitt und eine Größe (cutSortLine, setCutSlice, …) statt eines Frames. Die alten frame*-Funktionen sind weg, es gibt keine zweite Fassung.
  • SetSliceCommand und SetSortLineCommand bekommen ein Ziel: Texture-Frame oder Zeichen-Asset.
  • Die Inspector-Zeilen stehen einmal in cutSection.ts, die Linien im Tab einmal in SheetCanvas.

Abweichung vom Plan

  • Die Auflösung „Ziel → Schnitt und Größe“ steht in einer eigenen kleinen Datei cutTarget.ts, nicht in texture.ts. Sonst wäre ein Importkreis entstanden: vectorart.ts braucht über vectorPaint.ts selbst texture.ts.

Tests

  • Gate: 232 Files, 3542 Tests (+8). Neu sind Commands, Laden, Bildpfad und die Linien des Tabs für beide Asset-Arten, dazu Vector Art im Sortieren.
    • Drei Gegenproben greifen: kein Schnitt an der Zeichnung, ein Schnitt am ganzen Streifen, kein Rückfall auf die Bildhöhe.
  • e2e 48: 44 Checks (+1, Summe 1732). Der neue Check 48l-ii liest an zwei Stellen eines 128er-Sprites Rot und Blau. Dort landen sie bei 12-Pixel-Rändern mit Scale 2. Ohne Ränder lesen dieselben Stellen Grün.
  • Angesehen: der Pixel-Art-Tab mit den Linien und das zerschnittene Sprite.

Nicht dabei

  • Ziehen der Linien im Pixel-Art- und Vector-Art-Tab (wie besprochen).
  • Kollisionsumrisse (#141) für Pixel Art und Vector Art.
  • Einen e2e-Check für Vector Art gibt es nicht. Sie läuft über denselben Code, das decken die Unit-Tests ab.
Umgesetzt wie im Plan, mit deinen drei Antworten (je Asset, Linien nur anzeigen, Canvas-Pixel). Commit: `3e05cbb`, Wiki: `a8a6580` (*Textures*, *Pixel-Art*, *Vector-Art*, *Architecture*, *Development*). ## Was jetzt geht - **Pixel Art und Vector Art** haben im Inspector dieselben Blöcke *NINE-SLICE* und *SORTING* wie ein Texture-Frame, in Canvas-Pixeln, dazu die Zeile **Nine-slice scale**. - Ein Sprite, das so ein Bild trägt, wird in neun Teilen gezeichnet und auf einer nach Y sortierten Ebene an der Sort Line einsortiert. - **Pixel Art:** Eine Einstellung gilt für jeden Frame. Das Asset selbst steht bei mehreren Frames für den Streifen aller Frames nebeneinander. Dieser Streifen wird nicht zerschnitten, nur ein einzelner Frame. Bei einem Frame sind Asset und Frame dasselbe Bild. - **Im Tab** zeichnen beide Editoren die gesetzten Ränder gestrichelt und die Sort Line gelb ein. Ziehen lassen sie sich dort nicht, eingegeben wird im Inspector. Linien auf 0 werden nicht gezeichnet, sie lägen nur auf dem Rand der Zeichnung. ## Ohne doppelten Code - Ein gemeinsamer Typ `PictureCut` (`border`, `fill`, `sortLine`). `TextureFrame` erweitert ihn, Pixel Art und Vector Art tragen ihn als Ganzes. - Die Regeln in `texture.ts` nehmen einen Schnitt und eine Größe (`cutSortLine`, `setCutSlice`, …) statt eines Frames. Die alten `frame*`-Funktionen sind weg, es gibt keine zweite Fassung. - `SetSliceCommand` und `SetSortLineCommand` bekommen ein Ziel: Texture-Frame oder Zeichen-Asset. - Die Inspector-Zeilen stehen einmal in `cutSection.ts`, die Linien im Tab einmal in `SheetCanvas`. ## Abweichung vom Plan - Die Auflösung „Ziel → Schnitt und Größe“ steht in einer eigenen kleinen Datei `cutTarget.ts`, nicht in `texture.ts`. Sonst wäre ein Importkreis entstanden: `vectorart.ts` braucht über `vectorPaint.ts` selbst `texture.ts`. ## Tests - Gate: 232 Files, 3542 Tests (+8). Neu sind Commands, Laden, Bildpfad und die Linien des Tabs für beide Asset-Arten, dazu Vector Art im Sortieren. - Drei Gegenproben greifen: kein Schnitt an der Zeichnung, ein Schnitt am ganzen Streifen, kein Rückfall auf die Bildhöhe. - e2e 48: 44 Checks (+1, Summe 1732). Der neue Check 48l-ii liest an zwei Stellen eines 128er-Sprites Rot und Blau. Dort landen sie bei 12-Pixel-Rändern mit Scale 2. Ohne Ränder lesen dieselben Stellen Grün. - Angesehen: der Pixel-Art-Tab mit den Linien und das zerschnittene Sprite. ## Nicht dabei - Ziehen der Linien im Pixel-Art- und Vector-Art-Tab (wie besprochen). - Kollisionsumrisse (#141) für Pixel Art und Vector Art. - Einen e2e-Check für Vector Art gibt es nicht. Sie läuft über denselben Code, das decken die Unit-Tests ab.
admin moved this to Done in Development on 2026-10-03 19:54:34 +02:00
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: meleki/feuerwerk#308