Da unser neues Projekt nicht ganz so oldschoolig werden soll, haben wir uns überlegt, die Sprites erstmal als comicartige Vektorgrafik zu erstellen und diese dann auf die entsprechende Endgröße zu schrumpfen, mit eingeschalteter Weichzeichnung.
Im Grunde kommen da ja auch ganz brauchbare Sprites dabei raus, aber natürlich ist der schwarze Rand sowohl nach innen als auch nach außen hin weichgezeichnet. Daher wäre es ganz praktisch, wenn alle äußeren "Weichzeichnungs-Pixel" auf einem 50%-Grau münden würden, allerdings mit einem entsprechenden Alpha-Wert, sodaß ich die Dinger dann mit 3D-Sprites auf den Bildschirm bringen kann und der weiche Rand sich einigermaßen nahtlos mit dem Hintergrund verbindet.
Jetzt ist nur die Frage, wie mach ich das am besten? Gibt es da z.B. unter Gimp eine Funktion, die mir dabei behilflich sein könnte? Oder muß ich da selber ran? Also nochmal kurz gesagt, wie sorge ich dafür, daß jeder äußere Pixel aufgrund seiner Helligkeit einen entsprechenden Alpha-Wert zugewiesen bekommt?
weiche Sprite-Ränder erzeugen
weiche Sprite-Ränder erzeugen
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
ja, in Gimp geht das, wenn du es als PNG mit eingeschalteter transparenz behandelst,
dann werden beim verkleinern automatisch die alpha-werte angepasst.
auch in PB selber müsste es funktionieren, wenn du es von dem größeren PNG lädtst,
und per ZoomSprite3D verkleinerst.
ich hab gelesen, dass PNGs als textures für 3Dsprites den Alpha-channel unterstützen,
aber selber ausprobiert hab ichs noch nicht.
normale 2D-sprites unterstützen (laut meinen bisherigen informationen)
noch keinen Alpha-channel bei PNGs.
dann werden beim verkleinern automatisch die alpha-werte angepasst.
auch in PB selber müsste es funktionieren, wenn du es von dem größeren PNG lädtst,
und per ZoomSprite3D verkleinerst.
ich hab gelesen, dass PNGs als textures für 3Dsprites den Alpha-channel unterstützen,
aber selber ausprobiert hab ichs noch nicht.
normale 2D-sprites unterstützen (laut meinen bisherigen informationen)
noch keinen Alpha-channel bei PNGs.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Ja also mit 3D-Sprites hab ich's schon ausprobiert, das funktioniert. Sie müssen mit #PB_Sprite_Texture | #PB_Sprite_AlphaBlending geladen werden, dann braucht man das 3D-Sprite nur anzeigen und voila 
Also zum Verkleinern, Du meinst, ich brauch nur bei der großen Version (die scharfkantig ist) die Hintergrundfarbe entfernen (bei aktivierter Transparenz) und das dann entsprechend verkleinern? Na daß das so einfach ist hätte ich gar nicht gedacht werd's gleich mal ausprobieren.
Das mit dem Zoomsprite direkt in PB will ich eigentlich nicht machen, das ist mir irgendwie nicht "definiert" genug.
Das einzige was mich noch stört ist daß es kein richtiges ClipSprite3D gibt, weil bisher hab ich so immer die aktuell anzuzeigende Animations-Phase errechnet. Da müßte ich mir dann ein neues System ausdenken...
EDIT: Übrigens hätte ich Dir eigentlich direkt 'ne PM schicken können, weil irgendwie dachte ich mir schon daß Du als erster antwortest
Also zum Verkleinern, Du meinst, ich brauch nur bei der großen Version (die scharfkantig ist) die Hintergrundfarbe entfernen (bei aktivierter Transparenz) und das dann entsprechend verkleinern? Na daß das so einfach ist hätte ich gar nicht gedacht
werd's gleich mal ausprobieren.Das mit dem Zoomsprite direkt in PB will ich eigentlich nicht machen, das ist mir irgendwie nicht "definiert" genug.
Das einzige was mich noch stört ist daß es kein richtiges ClipSprite3D gibt, weil bisher hab ich so immer die aktuell anzuzeigende Animations-Phase errechnet. Da müßte ich mir dann ein neues System ausdenken...
EDIT: Übrigens hätte ich Dir eigentlich direkt 'ne PM schicken können, weil irgendwie dachte ich mir schon daß Du als erster antwortest
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
> Das einzige was mich noch stört ist daß es kein richtiges ClipSprite3D gibt, weil bisher hab ich so immer die aktuell anzuzeigende Animations-Phase errechnet. Da müßte ich mir dann ein neues System ausdenken...
ja ne is kla, weils eben ne komplett-texture ist.
du wirst wohl nicht drumrumkommen, jeden frame einzeln zu speichern...
> Übrigens hätte ich Dir eigentlich direkt 'ne PM schicken können, weil irgendwie dachte ich mir schon daß Du als erster antwortest
wie sollte es auch anders sein...
aber da es bestimmt auch andere interessiert, schadet es nix, dass es im forum steht.
ja ne is kla, weils eben ne komplett-texture ist.
du wirst wohl nicht drumrumkommen, jeden frame einzeln zu speichern...
> Übrigens hätte ich Dir eigentlich direkt 'ne PM schicken können, weil irgendwie dachte ich mir schon daß Du als erster antwortest
wie sollte es auch anders sein...aber da es bestimmt auch andere interessiert, schadet es nix, dass es im forum steht.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Jo schon klar 
Naja das mit den einzelnen Frames SPEICHERN könnte man ja zumindest umgehen, indem man alles wie gehabt macht, also alle Animationsphasen in eine einzige Datei. Dann muß halt beim Laden erstmal geschnippelt und hin- und herkopiert werden, sodaß es dann halt jede Phase als einzelnes 3D-Sprite gibt. Andererseits könnte das wieder Rechenzeit benötigen, und das will man dem User ja auch nicht unbedingt zumuten.
Was mir aber noch mehr Sorgen macht, ist eine übersichtliche Numerierung. Irgendwann blickt man dann vor lauter Konstanten gar nicht mehr durch. Und eine "variable Animationsphasen-Anzahl" gibt es dann auch nicht mehr, also z.B. errechne ich momentan die Anzahl der Animationsphasen anhand der Sprite-Breite. Da habe ich natürlich unbegrenzt Platz und kann das alles vollständig automatisieren. Wenn ich nun für jede Phase auch eigene Sprite-Nummern brauch, muß ich sowas halt limitieren auf z.B. maximal 16 Phasen oder sowas.
Evtl werd ich das halt irgendwie einteilen müssen, z.B. mit Hex-Codes:
#A000 = Klasse A (z.B. Gegner), Figur 0, Laufrichtung / Animationsart 0, Animationsphase 0.
Dann habe ich halt nur 16 Klassen, 16 Figuren, 16 Arten der Animation (z.B. 4 für die 4 Himmelsrichtungen, eine fürs Sterben etc) und maximal 16 Phasen. Da ist die Aufteilung jetzt nicht ganz optimal, weil man vielleicht mehr als 16 Figuren haben will aber nicht unbedingt 16 Arten oder 16 Phasen der Animation benötigt.
Naja ich werd ein wenig weiterforschen... vielleicht fällt mir ja noch eine andere Art der Numerierung ein. Habe ich eigentlich volle 32 Bit für die Sprite-Nummer? Ich glaube bei irgendwas habe ich mal eine etwas große ID vergeben wollen und dann meinte der Compiler "do you really want to use such a high number" oder sowas
Naja das mit den einzelnen Frames SPEICHERN könnte man ja zumindest umgehen, indem man alles wie gehabt macht, also alle Animationsphasen in eine einzige Datei. Dann muß halt beim Laden erstmal geschnippelt und hin- und herkopiert werden, sodaß es dann halt jede Phase als einzelnes 3D-Sprite gibt. Andererseits könnte das wieder Rechenzeit benötigen, und das will man dem User ja auch nicht unbedingt zumuten.
Was mir aber noch mehr Sorgen macht, ist eine übersichtliche Numerierung. Irgendwann blickt man dann vor lauter Konstanten gar nicht mehr durch. Und eine "variable Animationsphasen-Anzahl" gibt es dann auch nicht mehr, also z.B. errechne ich momentan die Anzahl der Animationsphasen anhand der Sprite-Breite. Da habe ich natürlich unbegrenzt Platz und kann das alles vollständig automatisieren. Wenn ich nun für jede Phase auch eigene Sprite-Nummern brauch, muß ich sowas halt limitieren auf z.B. maximal 16 Phasen oder sowas.
Evtl werd ich das halt irgendwie einteilen müssen, z.B. mit Hex-Codes:
#A000 = Klasse A (z.B. Gegner), Figur 0, Laufrichtung / Animationsart 0, Animationsphase 0.
Dann habe ich halt nur 16 Klassen, 16 Figuren, 16 Arten der Animation (z.B. 4 für die 4 Himmelsrichtungen, eine fürs Sterben etc) und maximal 16 Phasen. Da ist die Aufteilung jetzt nicht ganz optimal, weil man vielleicht mehr als 16 Figuren haben will aber nicht unbedingt 16 Arten oder 16 Phasen der Animation benötigt.
Naja ich werd ein wenig weiterforschen... vielleicht fällt mir ja noch eine andere Art der Numerierung ein. Habe ich eigentlich volle 32 Bit für die Sprite-Nummer? Ich glaube bei irgendwas habe ich mal eine etwas große ID vergeben wollen und dann meinte der Compiler "do you really want to use such a high number" oder sowas
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
grundsätzlich gibts ne compiler-warning ab Nr. 10.000
aber wenn du nen sprechenden nummerncode brauchst, wärs eh vielleicht praktischer,
das per #PB_ANY zu laden/createn, und sie zugewiesene nummer in
nem array zu speichern, das dann nummerkreis-mäßig organisiert ist...
oder eben gleich in ner structure für das objekt...
sooo uuungefähr in diese richtung...
( weiß nich, ob das richtig geschrieben is.., aber weißt was ich mein, gell? )
PS:
das splitten würde ja nur einmal stattfinden müssen, nämlich zu beginn des games bzw. des levels,
je nachdem wann du laden würdest und wann du FREEn würdest...
aber wenn du nen sprechenden nummerncode brauchst, wärs eh vielleicht praktischer,
das per #PB_ANY zu laden/createn, und sie zugewiesene nummer in
nem array zu speichern, das dann nummerkreis-mäßig organisiert ist...
oder eben gleich in ner structure für das objekt...
Code: Alles auswählen
Structure Object
X.l
Y.l
AnimFrame.l
MaxFrame.l
FrameSprites.l[16]
EndStructure( weiß nich, ob das richtig geschrieben is.., aber weißt was ich mein, gell? )
PS:
das splitten würde ja nur einmal stattfinden müssen, nämlich zu beginn des games bzw. des levels,
je nachdem wann du laden würdest und wann du FREEn würdest...
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Jo klar, ich weiß wie Du meinst. Ich bräuchte dann allerdings ein 2dimensionales Array, weil ich ja auch für jede Himmelsrichtung usw. ein eigenes "Frame-Set" habe.
Das mit dem Array werd ich mir auch mal durchdenken... aber ich frag mich auch, warum ClipSprite3D noch nicht implementiert worden ist. Da ein Sprite3D ja im Grunde nur ein 2D-Sprite als Textur benutzt, dachte ich eigentlich auch, es reicht, dann immer das 2D-Sprite zu clippen, aber Fehlanzeige...
Naja mal schauen, irgendeine Möglichkeit wird's schon geben
Das mit dem Array werd ich mir auch mal durchdenken... aber ich frag mich auch, warum ClipSprite3D noch nicht implementiert worden ist. Da ein Sprite3D ja im Grunde nur ein 2D-Sprite als Textur benutzt, dachte ich eigentlich auch, es reicht, dann immer das 2D-Sprite zu clippen, aber Fehlanzeige...
Naja mal schauen, irgendeine Möglichkeit wird's schon geben
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
nicht ganz, weil eben die sprite3D-routinen von DX direkt auf die textur zugreifen,
das clipping jedoch eine reine anzeige-funktion der 2D-routinen ist.
auch z.b. copysprite greift auf das komplette sprite zu und ignoriert das clipping.
ein direktes clippen und kopieren in jedem frame wäre garantiert massig zu langsam,
deshalb wirst du mit vorab-splitten und auf kleine sprites verteilen bestimmt am besten fahren.
wenn du platz sparen willst: lade das FrameSet-sprite in den hauptspeicher,
dann hast du mehr platz für die kleinen texturen die ja in der graka liegen müssen. (#PB_Sprite_Texture)
und denk dran, dass die kleinen ne kantenlänge von 2^n haben müssen und quadratisch sein.. aber is kla, gell?
das clipping jedoch eine reine anzeige-funktion der 2D-routinen ist.
auch z.b. copysprite greift auf das komplette sprite zu und ignoriert das clipping.
ein direktes clippen und kopieren in jedem frame wäre garantiert massig zu langsam,
deshalb wirst du mit vorab-splitten und auf kleine sprites verteilen bestimmt am besten fahren.
wenn du platz sparen willst: lade das FrameSet-sprite in den hauptspeicher,
dann hast du mehr platz für die kleinen texturen die ja in der graka liegen müssen. (#PB_Sprite_Texture)
und denk dran, dass die kleinen ne kantenlänge von 2^n haben müssen und quadratisch sein.. aber is kla, gell?
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Jo vor allem das quadratische stört mich gegen das 2^n hab ich überhaupt nix, aber mein momentaner Main Character hat eine Größe von 32x64, und jetzt auch noch alles quadratisch machen, arghhhhh
Wäre auch mal interessant zu wissen, wie viel % aller heutigen PC-User tatsächlich noch Grafikkarten haben, die da Probleme machen. Hat nicht irgendwann mal einer was gesagt, daß NUR das Power-of-2 wichtig ist, und das Quadratisch-Oder-Nicht eigentlich ziemlich wurscht ist?
gegen das 2^n hab ich überhaupt nix, aber mein momentaner Main Character hat eine Größe von 32x64, und jetzt auch noch alles quadratisch machen, arghhhhh Wäre auch mal interessant zu wissen, wie viel % aller heutigen PC-User tatsächlich noch Grafikkarten haben, die da Probleme machen. Hat nicht irgendwann mal einer was gesagt, daß NUR das Power-of-2 wichtig ist, und das Quadratisch-Oder-Nicht eigentlich ziemlich wurscht ist?
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
das war in nem thread wo ich mit Zaphod drüber diskutiert hatte,
da war zumindest die idee dazu gefallen, aber ich meine mich zu erinnern,
dass 2^x*2^y nur wenig mehr kompatibilitätssicherheit bietet, als egalewieformat...
dein einwand ist natürlich berechtigt, so langsam sind bestimmt
ne menge karten weg vom fenster, die quadratische 2^n benötigen.
aber sicherheit gibt es da eben nicht, zumal die graka anscheinend auch keinen fehlercode zurückgibt....
> aber mein momentaner Main Character hat eine Größe von 32x64, und jetzt auch noch alles quadratisch machen
musst du doch garnicht.
quadratisch muss nur das sprite vom CreateSprite sein, auf das du den frame zur einladezeit projizierst.
du kannst sowieso nicht Clip&Copy machen, weil Copy eben nicht das clipping beachtet,
also wäre es am praktischsten (denke ich) wenn du nach dem create ein UseBuffer machst,
und dann den frame drauf Displayst. ob du vor diesem Display noch clippst,
um nur einen 32x64 bereich auf ein 64x64 sprite zu displayn, macht den kohl nich fett...
da war zumindest die idee dazu gefallen, aber ich meine mich zu erinnern,
dass 2^x*2^y nur wenig mehr kompatibilitätssicherheit bietet, als egalewieformat...
dein einwand ist natürlich berechtigt, so langsam sind bestimmt
ne menge karten weg vom fenster, die quadratische 2^n benötigen.
aber sicherheit gibt es da eben nicht, zumal die graka anscheinend auch keinen fehlercode zurückgibt....
> aber mein momentaner Main Character hat eine Größe von 32x64, und jetzt auch noch alles quadratisch machen
musst du doch garnicht.
quadratisch muss nur das sprite vom CreateSprite sein, auf das du den frame zur einladezeit projizierst.
du kannst sowieso nicht Clip&Copy machen, weil Copy eben nicht das clipping beachtet,
also wäre es am praktischsten (denke ich) wenn du nach dem create ein UseBuffer machst,
und dann den frame drauf Displayst. ob du vor diesem Display noch clippst,
um nur einen 32x64 bereich auf ein 64x64 sprite zu displayn, macht den kohl nich fett...
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.