You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dennoch hätte ich ein paar allgemeine und teils auch spezielle Anregungen:
Die Editor-Ansicht:
Der Overlay-Mode ist schon recht cool so, allerdings wäre es gut, wenn man das Blending des Underlays abschalten kann. Ich arbeite bei Overlay-Sprites meist NICHT mit einer schwarzen Outline, sondern irgendeiner Zwischenfarbe. Das wird dann etwas unkomfortabel, wenn die anderen Farben zb abgedunkelt oder gegraut erscheinen.
Mich persönlich nervt in allen verfügbaren Grafiktools, mit denen man Overlay-Sprites erstellen kann, dass man ständig zwischen den Layern wechseln muss. Dabei ist in der Regel alleine durch die Farbauswahl eine logische Zuordnung der Sprites bereits vorgegeben.
Das wäre ein enormer Zugewinn, wenn man das jeweilige Underlay mit in der Ansicht bearbeiten könnte. Sprich, die jeweiligen Farben für beide Sprites in der Palette untereinander aufgeführt und das danach der Editor entscheidet, zu welchem Sprite der Pixel gesetzt wurde.
Der Sprite-Container:
Finde ich sehr geil, dass man die Sprites dort sortieren kann. Was ich cool fände, wenn man nicht unbedingt Sprites anlegen müsste, um sie zb vertikal anzuordnen. Denk mal an die großen Monster in Katakis und Co, wenn man nur ein Einzelnes im Format 3x4 Sprites erstellen möchte.
Dateihandling:
Die oberen beiden Beispiele lassen sich in Spritemate soweit schon umsetzen, sind dabei auch ein Beispiel, warum ich das Underlay gerne ohne Blending hilfreicher finde. Das Overlay ist in beiden Fällen dunkelrot, wird also für Details und Antialiasing eingesetzt, aber nicht direkt für Outlines.
Die unteren beiden Objekte verwenden teils gestreckte Sprites, um in diesem Beispiel künstlich Extra-Farben zu erzeugen. Ein weiteres Beispiel wäre die Biene in Comaland, dessen Flüge expanded Hires-Sprites sind. Ich kenne selbst nur den Spriteeditor "MOB-Profi", mit dem man solche Objekte auch direkt darstellen kann. An sich kann man das auch stellvertretend für Riesen-Sprites sehen, welche früher in Paint-Magic vorbereitet wurden, heute es aber nicht einen Crossdev-Editor gibt, der sowas berücksichtigt. Tatsächlich sind das auch alles Fälle, wo ich Dokumentationen schreibe, wie sie zusammengesetzt werden müssen.
Worauf ich hinauswill, geht zugegeben ans Eingemachte...
Preview-Fenster: Vergleichbar mit MOB-Profi müsste das Vorschaufenster sich wie eine Leinwand verhalten. D.h. auch flexible Größe, damit man auch zb zusammengesetzte Sprites dastellen kann. Die entsprechenden Daten kommen aus...
...neues Attribut-Fenster: Praktisch eine Tabelle, bei der jedes Sprite im Container Attribute wie Positions-Koordinaten, Priorität, X-Expansion und Y-Expansion vorgegeben werden kann. Der Vollständigkeit halber zusätzlich mit der Angabe ob HiRes/Multicolour sowie der Farbe. Das wäre auch ein saugeiles Protokoll für Coder... (bzw falls irgendwann mal Animation kommen sollte, wäre das auch ein guter Ort für Objekt-Name und Frame-Nr).
The text was updated successfully, but these errors were encountered:
v3to
Dennoch hätte ich ein paar allgemeine und teils auch spezielle Anregungen:
Die Editor-Ansicht:
Der Overlay-Mode ist schon recht cool so, allerdings wäre es gut, wenn man das Blending des Underlays abschalten kann. Ich arbeite bei Overlay-Sprites meist NICHT mit einer schwarzen Outline, sondern irgendeiner Zwischenfarbe. Das wird dann etwas unkomfortabel, wenn die anderen Farben zb abgedunkelt oder gegraut erscheinen.
Mich persönlich nervt in allen verfügbaren Grafiktools, mit denen man Overlay-Sprites erstellen kann, dass man ständig zwischen den Layern wechseln muss. Dabei ist in der Regel alleine durch die Farbauswahl eine logische Zuordnung der Sprites bereits vorgegeben.
Das wäre ein enormer Zugewinn, wenn man das jeweilige Underlay mit in der Ansicht bearbeiten könnte. Sprich, die jeweiligen Farben für beide Sprites in der Palette untereinander aufgeführt und das danach der Editor entscheidet, zu welchem Sprite der Pixel gesetzt wurde.
Der Sprite-Container:
Finde ich sehr geil, dass man die Sprites dort sortieren kann. Was ich cool fände, wenn man nicht unbedingt Sprites anlegen müsste, um sie zb vertikal anzuordnen. Denk mal an die großen Monster in Katakis und Co, wenn man nur ein Einzelnes im Format 3x4 Sprites erstellen möchte.
Dateihandling:
Die oberen beiden Beispiele lassen sich in Spritemate soweit schon umsetzen, sind dabei auch ein Beispiel, warum ich das Underlay gerne ohne Blending hilfreicher finde. Das Overlay ist in beiden Fällen dunkelrot, wird also für Details und Antialiasing eingesetzt, aber nicht direkt für Outlines.
Die unteren beiden Objekte verwenden teils gestreckte Sprites, um in diesem Beispiel künstlich Extra-Farben zu erzeugen. Ein weiteres Beispiel wäre die Biene in Comaland, dessen Flüge expanded Hires-Sprites sind. Ich kenne selbst nur den Spriteeditor "MOB-Profi", mit dem man solche Objekte auch direkt darstellen kann. An sich kann man das auch stellvertretend für Riesen-Sprites sehen, welche früher in Paint-Magic vorbereitet wurden, heute es aber nicht einen Crossdev-Editor gibt, der sowas berücksichtigt. Tatsächlich sind das auch alles Fälle, wo ich Dokumentationen schreibe, wie sie zusammengesetzt werden müssen.
Worauf ich hinauswill, geht zugegeben ans Eingemachte...
Preview-Fenster: Vergleichbar mit MOB-Profi müsste das Vorschaufenster sich wie eine Leinwand verhalten. D.h. auch flexible Größe, damit man auch zb zusammengesetzte Sprites dastellen kann. Die entsprechenden Daten kommen aus...
...neues Attribut-Fenster: Praktisch eine Tabelle, bei der jedes Sprite im Container Attribute wie Positions-Koordinaten, Priorität, X-Expansion und Y-Expansion vorgegeben werden kann. Der Vollständigkeit halber zusätzlich mit der Angabe ob HiRes/Multicolour sowie der Farbe. Das wäre auch ein saugeiles Protokoll für Coder... (bzw falls irgendwann mal Animation kommen sollte, wäre das auch ein guter Ort für Objekt-Name und Frame-Nr).
The text was updated successfully, but these errors were encountered: