Wer die Assets, idealerweise in integer Schritten hochskaliert, sollte natürlich nicht dort aufhören und bei Bedarf, möchte man das ursprüngliche grid movement beibehalten, auch die Engine darauf anpassen. Bleiben wir beim Beispiel 2k < - > XP:
XP hat eine Auflösung von 640 x 480. Der 2k eine Auflösung von 320 x 240. Also eine Skalierung von 2x.
Die Assets werden mit 2x skaliert und behalten so ihren retro pixel look bei. Im 2k bewegen sich Objekte in einem 16 x 16 Raster. Grid movement.
Im XP bewegen sich Objekte standardmäßig in einem 32 x 32 Raster, ebenso grid movement. Das ist auch eine Skalierung von 2x.
Beim Umstieg von 2k auf XP muss man also in diesem Punkt nichts weiter beachten. Es ist identisch und es gibt kein misalignment.
Mir ist der klassische Stil von 2k/2k3 auch am liebsten. Spiele ab XP finde ich am schönsten, wenn sie ebenfalls in diesem Stil sind bzw diesen imitieren. Der Standard-Stil der Maker ab XP trifft so gar nicht meinen Geschmack. Es gibt da zwar auf jeden Fall positive Ausnahmen und hübsch anzusehende Spiele in diesem Stil, aber das Gros davon wirkt auf mich irgendwie visuell wenig ansprechend. Das sind harte Worte und damit tue ich vielen Spielen mit Sicherheit unglaublich unrecht. Aber woran es liegt? Schwer zu sagen. Vielleicht ist das schon eine Form von Uncanny Valley? Vielleicht liegt es aber auch daran, dass ich diesen Grafikstil außerhalb des Maker-Universums nie gesehen habe und er deswegen gewöhnungsbedürftig ist? Ich kenne z.B. kein bekanntes, kommerzielles (nicht-Maker) Spiel, dass diesen Look hat. Und natürlich ist es viel schwieriger, eine Map in höherer Auflösung und dementsprechend mehr erkennbaren Details mit Leben zu füllen. Ich z.B. bin eine absolute Null was Grafiken angeht, aber für 2k/2k3 hab sogar ich es hinbekommen, Posen zu pixeln. Einfach weil man bei der geringen Pixelzahl viel weniger falsch machen kann.
Dies hier ist beispielsweise ein Bild auf Grandys abgebrochenem 1899 - London Gothic, bereits nachdem das Spiel auf den RMXP portiert wurde:
Für mich zeigt sich hier examplarisch, welche Probleme es bei sehr vielen Spielen mit neueren Makern gibt: Viel Leerfläche, repetitive Grafikstrukturen fallen viel eher auf - einfach weil der zu sehende Bildabschnitt viel größer ist. Schaut euch den Boden an. Oder die Mauer.
Hier ein Bild des Spiels auf RM2k-Basis:
Allerdings muss ich sagen, ist es auch oft eine Frage der Gewöhnung. Ich habe soratas Charon - Zhetan Chronicles Betatesten dürfen. Anfangs war ich auch noch skeptisch beim Grafikstil, aber mit steigender Spielzeit hab ich der Grafik durchaus einiges abgewinnen können. Vielleicht braucht man einfach länger, um sich auf diesen Grafikstil einlassen zu können. Und Spiele ab XP+ sehen in Bewegung auch nochmal deutlich attraktiver aus, als als starrer Screenshot.
Beim Umstieg von 2k auf XP muss man also in diesem Punkt nichts weiter beachten. Es ist identisch und es gibt kein misalignment.
...
Ganz so einfach ist es leider nicht, was auch viele XP Spiele im "Pixel Retro Look" beweisen. Nicht alle Entwickler passen da auf, dass die Pixel auch alle im selben Pixelraster liegen und so werden dann x2 skalierte Grafiken auch gerne zwischen zwei Pixeln platziert. Auch bleibt das von WeTa im letzten Post demonstrierte Problem des zwischen den Pixeln flüssig bewegen. Aber vielleicht gibt es da ein Plugin, was das behebt?
Statt Symptome zu bekämpfen (und manche zu übersehen) wärs aber einfacher direkt unskalierte Grafiken zu verwenden und erst das fertig berechnete niedrig aufgelöste Bild auf die Bildschirmauflösung hoch zu skalieren. Ob das mit den neueren Makern geht, weiß ich aber nicht. Soweit ich weiß hat der MV im letzten Update erst die Möglichkeit bekommen das Grid afu 16x16 und Auflösung frei einstellen zu können, aber die Standardmenüs sind 0 auf niedrige Auflösungen angepasst worden und funktionieren da nicht mehr.
Mir ist der klassische Stil von 2k/2k3 auch am liebsten. Spiele ab XP finde ich am schönsten, wenn sie ebenfalls in diesem Stil sind bzw diesen imitieren. Der Standard-Stil der Maker ab XP trifft so gar nicht meinen Geschmack. Es gibt da zwar auf jeden Fall positive Ausnahmen und hübsch anzusehende Spiele in diesem Stil, aber das Gros davon wirkt auf mich irgendwie visuell wenig ansprechend. Das sind harte Worte und damit tue ich vielen Spielen mit Sicherheit unglaublich unrecht. Aber woran es liegt? Schwer zu sagen. Vielleicht ist das schon eine Form von Uncanny Valley? Vielleicht liegt es aber auch daran, dass ich diesen Grafikstil außerhalb des Maker-Universums nie gesehen habe und er deswegen gewöhnungsbedürftig ist? Ich kenne z.B. kein bekanntes, kommerzielles (nicht-Maker) Spiel, dass diesen Look hat. Und natürlich ist es viel schwieriger, eine Map in höherer Auflösung und dementsprechend mehr erkennbaren Details mit Leben zu füllen. Ich z.B. bin eine absolute Null was Grafiken angeht, aber für 2k/2k3 hab sogar ich es hinbekommen, Posen zu pixeln. Einfach weil man bei der geringen Pixelzahl viel weniger falsch machen kann.
Dies hier ist beispielsweise ein Bild auf Grandys abgebrochenem 1899 - London Gothic, bereits nachdem das Spiel auf den RMXP portiert wurde:
Für mich zeigt sich hier examplarisch, welche Probleme es bei sehr vielen Spielen mit neueren Makern gibt: Viel Leerfläche, repetitive Grafikstrukturen fallen viel eher auf - einfach weil der zu sehende Bildabschnitt viel größer ist. Schaut euch den Boden an. Oder die Mauer.
Hier ein Bild des Spiels auf RM2k-Basis:
Allerdings muss ich sagen, ist es auch oft eine Frage der Gewöhnung. Ich habe soratas Charon - Zhetan Chronicles Betatesten dürfen. Anfangs war ich auch noch skeptisch beim Grafikstil, aber mit steigender Spielzeit hab ich der Grafik durchaus einiges abgewinnen können. Vielleicht braucht man einfach länger, um sich auf diesen Grafikstil einlassen zu können. Und Spiele ab XP+ sehen in Bewegung auch nochmal deutlich attraktiver aus, als als starrer Screenshot.
...
Was ist denn der "Stil" von z.B. XP? Du beziehst dich auf das Standard RTP. Was haben denn die darin mitgelieferten Grafiken mit dem eigentlichen Tool zu tun? Zunächst gar nichts. Btw, wie bereits geschrieben, lehnt sich das XP RTP an das beliebte Refmap an . Dadurch, dass ab XP das RTP recht brauchbar wurde und viele Settings abdeckt werden, wird es vermehrt verwendet. Durch die vermehrte Verwendung begehen allerdings viele den Fehler und gehen davon aus, dasss das höher aufgelöste RTP der "Stil" der neueren Maker ist (was auch immer das heißt) und was anderes nicht geht. Ist schade, schon sehr oft gesehen.
Deine Beispiele von London Gothic finde ich übrigens unglücklich. Die dort gezeigten Umgebungen weichen in Ihrem Aufbau voneinander ziemlich ab, der XP Screen z.B. hat größtenteils leere Fläche, der 2k Screen viel mehr Gebäudeausschnitte.
Repetitive Tilestrukturen liegen mehr and den erstellten Grafiken, leere und langweilige Flächen hängen vom Mapping und den eingesetzten Grafiken ab. Ich sehe hier kein Beispiel, wo der 2k seine Vorteile gegenüber dem XP ausspielt.
Da müsste man schon mehr oder weniger identische Screens nehmen. Aber ja, stimmt, höhere Auflösung = mehr Aufwand beim Erstellen der Grafiken wenn man denn die volle Auflösung nutzt, was nicht zwingend ist!
Wie gesagt, man kann weiterhin die Assets in geringerer Auflösung erstellen / nutzen und skaliert diese dann hoch.
Zitat von TrunX
Ganz so einfach ist es leider nicht, was auch viele XP Spiele im "Pixel Retro Look" beweisen. Nicht alle Entwickler passen da auf, dass die Pixel auch alle im selben Pixelraster liegen und so werden dann x2 skalierte Grafiken auch gerne zwischen zwei Pixeln platziert. Auch bleibt das von WeTa im letzten Post demonstrierte Problem des zwischen den Pixeln flüssig bewegen. Aber vielleicht gibt es da ein Plugin, was das behebt?
Statt Symptome zu bekämpfen (und manche zu übersehen) wärs aber einfacher direkt unskalierte Grafiken zu verwenden und erst das fertig berechnete niedrig aufgelöste Bild auf die Bildschirmauflösung hoch zu skalieren. Ob das mit den neueren Makern geht, weiß ich aber nicht. Soweit ich weiß hat der MV im letzten Update erst die Möglichkeit bekommen das Grid afu 16x16 und Auflösung frei einstellen zu können, aber die Standardmenüs sind 0 auf niedrige Auflösungen angepasst worden und funktionieren da nicht mehr.
...
Mmh, also das sind Fehler / Schlampigkeiten (die können passieren) auf Seiten des Entwicklers. Das hat zunächst nichts mit dem eingesetzten Tool zu tun. Das kann dir auch bei dem 2k passieren.
Und ich glaube, man sieht hier den Wald vor lauter Bäumen nicht. Ich werde die Tage ein Test Projekt im XP mit 2x skaliertem Refmap erstellen um aufzuzeigen, dass es da keine Probleme beim pixel retro look oder flüssigem pixel bewegen gibt.
Ich gebe dir allerdigns dahingehenden Recht, dass der ideale Weg eine integrierte Skalierung in der Engine ist. Fun fact: das ist heute mit den gängigen Grafikkarten Treiberseitig möglich. Die Treiber bieten alle mittlerweile Integerskalierung an.
Die Einführung der Grid Anpassung im MZ ist eine sehr schöne Idee (schon lange von der Community gewünscht), aber leider auf den ersten Blick miserabel umgesetzt.
Ich finde nicht, dass der Screen von London Gothic in XP-Auflösung Leere ausstrahlt. So ist es genau richtig, sonst wäre er schon zu überladen. Pixelgrafik verbinde ich nicht mit den realitätsnahen Texturen moderner 3D-Spiele, sondern mit Einfachheit.
Es hat mich noch nie gestört, wenn bei skalierten Grafiken die angesprochenen Probleme auftreten oder anders gesagt, ich hab sie noch nie wahrgenommen. Wobei die Charsets im XP meine ich sowieso in Halbschritten springen, sie bewegen sich nicht Pixel für Pixel.
Ich persönlich empfand die RTP-XP-Charsets immer ansprechender als die VX-Charsets. Aber das ist Geschmacksache. Als Hauptproblem heute sehe ich, dass z.B. beim MV die Möglichkeit besteht auf Charset-Generatoren zurückzugreifen, die meistens im RTP-Stil gehalten sind. Das ist sehr gut für die Entwickler, da dadurch nicht viel Zeit für das Pixeln investiert werden muss. Vor allem, wenn der Entwickler sich primär auf die Handlung oder Gameplay konzentrieren möchte. Der Beigeschmack ist dann natürlich, dass viele Spiele den gleichen Stil haben. Und: So besser ein RTP, desto häufiger wird es benutzt - und so schneller hat man sich satt daran gesehen.
Das zweite große Problem wo ich sehe (am Beispiel XP): Doppelte Auflösung bedeutet 4-Facher Zeitaufwand beim Pixeln. Da der Anteil an Makerspielen auf dem 2k/2k3, die aus selbst erstellten oder überwiegend editierten Assets besehen schon recht gering war, nimmt dieser bei einer höheren Auflösung dann natürlich weiter ab.
Was mir aufgefallen ist: Anders als noch bei 2k/2k3 sind Charset-Templates nicht mehr so verbreitet. Damals, als ich bei dem Makern angefangen hatte (in den frühen 2000er) gab es für jeden verbreiteten Charset-Stil eine Auswahl an Templates. Das hatte damals viel geholfen.
Zitat
Mmh, also das sind Fehler / Schlampigkeiten (die können passieren) auf Seiten des Entwicklers.
...
Ich sehe das Problem eher in der Auflösung. Um ein Detail dazustellen war es beim 2k/2k3 notwendig das komplette "Grid" von 16x16 auszufüllen. Bei den späteren Makern mit 32x32 war das nicht notwendig. Man konnte Objekte und andere Details gut erkennbar machen und ein paar Pixel Abstand zur Gitterlinie lassen. Dadurch sieht die komplette Map immer leerer aus. Das macht sich auch bei der Kontur bemerkbar, die bei 16x16 einen viel höheren Anteil einnimmt.
Mmh, also das sind Fehler / Schlampigkeiten (die können passieren) auf Seiten des Entwicklers. Das hat zunächst nichts mit dem eingesetzten Tool zu tun. Das kann dir auch bei dem 2k passieren.
...
Ne beim 2k(3) konnte das nicht passieren, da die Spiele direkt in 320x240 gerendert werden, das genutzte Pixelgrid entspricht also der Renderauflösung, unmöglich da etwas versehentlich zwischen zwei Pixeln zu platzieren oder die Figuren im Subpixelbereich flüssiger "als erlaubt" umherzubewegen. Zumal die alten Maker auch keine Floating Point Zahlen unterstützt haben was Bildschirmkoordinaten angeht, anders als die moderneren Maker. (VD3 hat zb. den Battlern falsche Kommazahlen als Ancherpoint gegeben, was dazu führt dass sie zwischen zwei Pixeln der höher aufgelösten Bildschirmauflösung gerendert werden und somit unscharf dargestellt werden. Das die Battler nicht auf dem Pixelraster der Hintergrundgrafik platziert sind, ist da also noch das kleinere Problem.)
Es mag sein, dass man mit den moderneren Makern mit extra Aufwand und Einsatz von Plugins authentische Pixelartspiele im 16-bit Stil erstellen kann, aber ich würde jetzt mal behaupten >90% der Maker User sind Hobbyisten, waren evtl noch gar nicht geboren als 16bit Spiele aktuell waren. Diesen Nutzern fallen all die Macken gar nicht auf wenn sie sich bewusst für den "Retro Look" entscheiden oder es stört sie einfach nur nicht, evtl. kennen sie es gar nicht anders und nehmen es einfach als gegeben hin.
Ich denke die Einschränkungen des rm2k(3) hätten Marlex (um beim VD3 Beispiel zu bleiben) vor vielen Kardinalfehlern die er aus Grafikdesign Perspektive begangen hat, weil der RM MV diese zugelassen hat, geschützt und wir hätten ein optisch in sich viel stimmigeres Spiel erhalten, was sich optisch vor den ganzen hochkarätigen SNES Klassikern nicht hätte verstecken brauchen. Final raus gekommen ist (leider) ein Produkt das auf den ersten Blick nach Amateur-Hobby-Projekt ohne beteiligten (professionellem) Grafik Artist mit Kontrollfunktion schreit.
Hier noch mal ein anderer Screen von London Gothic XP, der aus meiner Sicht besser für einen Vergleich geeignet ist da ähnlicher Aufbau. Ich sehe hier jetzt nicht unbedingt "Leere".
Zitat von Kelven
Ich finde nicht, dass der Screen von London Gothic in XP-Auflösung Leere ausstrahlt. So ist es genau richtig, sonst wäre er schon zu überladen. Pixelgrafik verbinde ich nicht mit den realitätsnahen Texturen moderner 3D-Spiele, sondern mit Einfachheit.
Es hat mich noch nie gestört, wenn bei skalierten Grafiken die angesprochenen Probleme auftreten oder anders gesagt, ich hab sie noch nie wahrgenommen. Wobei die Charsets im XP meine ich sowieso in Halbschritten springen, sie bewegen sich nicht Pixel für Pixel.
...
Genau genommen wird alles, unabhängig welcher Maker nun genutzt wird, in gewissen Pixel Abständen bewegt bzw. verschoben. Nehmen wir mal das Beispiel XP:
Der standard move speed von 4 lässt die Figur um 16 (2^move_speed) "Einheiten" pro update bewegen (intern im Maker als Distanz bezeichnet).
Die Map Koordinaten werden intern im Maker mit 128 multipliziert. 128 / 16 = 8. Es braucht also 8 Frames um die Figur von Tile 0 auf Tile 1 auf der X Achse zu bewegen.
1 Tile = 32 Pixel. 32 / 8 = 4. Die Figur springt also pro Frame 4 Pixel weiter. Wir haben 40 FPS. 40 / 8 = 5. In einer realen Sekunden bewegt sich die Figur also 5 Tiles bzw. 160 Pixel weit.
Zitat von TrunX
Ne beim 2k(3) konnte das nicht passieren, da die Spiele direkt in 320x240 gerendert werden, das genutzte Pixelgrid entspricht also der Renderauflösung, unmöglich da etwas versehentlich zwischen zwei Pixeln zu platzieren oder die Figuren im Subpixelbereich flüssiger "als erlaubt" umherzubewegen. Zumal die alten Maker auch keine Floating Point Zahlen unterstützt haben was Bildschirmkoordinaten angeht, anders als die moderneren Maker. (VD3 hat zb. den Battlern falsche Kommazahlen als Ancherpoint gegeben, was dazu führt dass sie zwischen zwei Pixeln der höher aufgelösten Bildschirmauflösung gerendert werden und somit unscharf dargestellt werden. Das die Battler nicht auf dem Pixelraster der Hintergrundgrafik platziert sind, ist da also noch das kleinere Problem.)
Es mag sein, dass man mit den moderneren Makern mit extra Aufwand und Einsatz von Plugins authentische Pixelartspiele im 16-bit Stil erstellen kann, aber ich würde jetzt mal behaupten >90% der Maker User sind Hobbyisten, waren evtl noch gar nicht geboren als 16bit Spiele aktuell waren. Diesen Nutzern fallen all die Macken gar nicht auf wenn sie sich bewusst für den "Retro Look" entscheiden oder es stört sie einfach nur nicht, evtl. kennen sie es gar nicht anders und nehmen es einfach als gegeben hin.
Ich denke die Einschränkungen des rm2k(3) hätten Marlex (um beim VD3 Beispiel zu bleiben) vor vielen Kardinalfehlern die er aus Grafikdesign Perspektive begangen hat, weil der RM MV diese zugelassen hat, geschützt und wir hätten ein optisch in sich viel stimmigeres Spiel erhalten, was sich optisch vor den ganzen hochkarätigen SNES Klassikern nicht hätte verstecken brauchen. Final raus gekommen ist (leider) ein Produkt das auf den ersten Blick nach Amateur-Hobby-Projekt ohne beteiligten (professionellem) Grafik Artist mit Kontrollfunktion schreit.
...
Klar kann dir das passieren. Es geht doch um die Nutzung von skalierten Grafiken. Ich habe jetzt tolle Grafiken erstellt die für ein 8x8 Grid ausgelegt sind weil total retro. Diese muss ich nun auch 2x skalieren um dem 16x16 Grid des 2k zu entsprechen, weil ich damit ein Projekt bauen möchte. Da kann mir der gleiche Mist passieren wie bei 16 auf 32.
Wie gesagt, ich drope hier die Tage Refmap 2x skaliert in einem XP Projekt ohne großen Aufwand und dann schauen wir mal.
Wie gesagt, ich drope hier die Tage Refmap 2x skaliert in einem XP Projekt ohne großen Aufwand und dann schauen wir mal.
...
Habe ich heute selber mal probiert:
Mit etwas Aufwand machbar, aber wenn ich für jeden Text nicht eine Extra-Grafik anfertigen und auch auf die XP-internen Wettereffekte usw. verzichten möchte, ist es mit der Pixel-Authentizität schwierig -- und selbst dann gibt es ja noch die ganzen Probleme mit pixeltreuer Bewegung, die hier wunderbar aufgeführt wurden. So detailversessen bin ich dann nicht, aber als jemand, der sowieso nicht mit Ruby (oder irgend einer anderen Programmiersprache) umgehen kann und auch keine eigenen Grafiken erstellen möchte, gibt es im Endeffekt einfach keinen echten Mehrwert.
Was ich auch etwas seltsam finde, ist, daß der RMXP immer zu den "neuen" Makern gerechnet wird, obwohl er gerade einmal anderthalb Jahre nach dem 2k3 erschienen ist. Und jener in der von Cherry und Co. polierten und gewarteten Fassung ist für einen Hobby-Ersteller wie mich dann einfach alternativlos.
Zumindest das mit dem Text ließe sich lösen, indem man in den Rubyskripten rumgräbt. Die Textboxen werden, soweit ich mich erinnere, ohnehin erst in ein Sprite gerendert. Da könnte man problemlos die Auflösung reduzieren und dann beim Anzeigen wieder hochskalieren.
Klar kann dir das passieren. Es geht doch um die Nutzung von skalierten Grafiken.
...
Ne, mir ging es eben nicht um die Nutzung von skalierten Grafiken, sondern um die Möglichkeit im rm2k(3) die native 240p Auflösung nutzen zu können für authentische 8- oder 16-bit Optik. Alles von Amiga, C64, Mastersystem, NES, Megadrive, PC Engine, Neo Geo über SNES hat eine Auflösung um die 224p-240p genutzt. Aber ja, wenn man theoretisch ein 160x120 Spiel im RM2k machen wollen würde, hätte man das selbe Problem wie mit 320x240 im XP.
Weils mir real Trolls Endzeit (positiv!) angetan hat, hab ich mal eine Szene daraus in einer anderen Engine (GameMaker) nachgestellt, da ich da die Auflösung und die Art und Weise wie gerendert wird frei kontrollieren kann, um die Rotation von Pixelart anhand eines animierten Beispiels zu besprechen:
Hier wird das 240p Spiel auf 960p (x4) hochskaliert, bei der Rotation aber die volle Auflösung genutzt.
Dies lässt die rotierte Grafik ein wenig wie ein Fremdkörper wirken, da es mit dem Pixelraster bricht und die groben Pixel der Grafik wie ausgeschnitten auf einer gesonderten Ebene einfach mit gedreht werden. Je mehr andere (von Hand) animierte und bewegte Elemente es im Bild gibt, die sich an das Pixelraster halten, umso stärker sticht dann das eine Element was ausbricht als Fremdkörper hervor.
Hier hab ich die Skalierung angepasst, sodass die Szene erst vollständig gerendert wird, bevor das fertige 240p Bild dann auf 960p hochskaliert wird, wodurch sich die programmierte Rotation nun an das Pixelgrid hält. (Farbverfälschung durch die GIF-Aufnahme mal ignorieren^^)
Man könnte sagen es sieht nicht ganz so "hübsch" aus, aber es wirkt nun mehr als Teil der Spielwelt. Da andere animierte Elemente ggf. von Hand animiert sind und nicht so super flüssig wären, könnte es trotzdem noch als klar programmiert statt von Hand animiert hervorstechen.
Das kann man lösen, indem man den Winkel der Rotation nicht jeden Frame, sondern zb. nur alle 10 Frames aktualisiert (Bei einem 60fps Spiel):
Das wäre dann vermutlich meine präferierte Lösung.
Wobei flüssige Skalierungs- und Rotationseffekte die programmiert statt von Hand animiert sind überhaupt nicht gegen authentisches 16-bit Pixelart sprechen. Yoshis Island auf dem SNES hat zb. den SuperFX Chip genutzt um solche grafischen Effekte (Skalieren und Rotieren von Sprites) in Echtzeit flüssig darzustellen). Auch wenn da noch ein extra Chip in der Cardridge notwendig war, spätestens bei den PS1 Pixelart Games und dem GBA wars dann auch ohne Zusatzchip möglich (und wurde auch Gebrauch von gemacht).
Der Vollständigkeit halber noch wie es (vermutlich) im XP aussieht mit doppelter Renderauflösung bei Rotationen:
Ich finde die erste gezeigte Lösung bei Weitem am besten. Aber ich bin auch kein "Pixelpurist", also kann ich hier nicht handwerklich, sondern nur ganz subjektiv nach meiner persönlichen Vorliebe für Ästhetik urteilen.
--
Ein sehr symphatischer und überaus aktiver RPG Maker Benutzer
@ TrunX
Erstmal vielen Dank für das konkrete Beispiel und vor allem für die anschauliche Bebilderung. Das macht sicherlich etwas mehr Arbeit, aber dafür lese und gucke ich den Beitrag auch mit einem höheren Gewinn. Gerade wenn ich mir die vorgeschlagenen Animationsmöglichkeiten ansehe, gefallen mir die Zwischenlösungen, in denen rein über Rotationsberechnungen eine handgepixelte Animation simuliert werden soll, allerdings gar nicht
Die Armlinie der erhängten Kreatur wird beständig aufgebrochen, springt hin und her und erzeugt große Unruhe. Die Schleife auf dem Kopf wiederum wird so stark deformiert, dass sie in den meisten Bildern gar nicht zu identifizieren ist. Weder in den Details noch der Geometrie ist das überzeugend. Erst wenn die Pendelbewegung mit wesentlich mehr Zwischenschritten berechnet wird, kann die animierte Figur gestaltwahrend dargestellt werden.
Das liegt gar nicht an dir, es liegt am momentanen Unvermögen der Grafikprogramme, Pixelgrafiken ästhetisch überzeugend zu rotieren. Man muss per Hand ran. Ich will mich gern von dir inspirieren lassen und trage selbst ein Anschauungsbild bei.
Hier soll der Held den Kopf heben. Wenn ich das per Rotationsbefehl lösen möchte, bleibt das Ergebnis hinter der handgepixelten Pose deutlich zurück:
Es ist wie beim Pendel. Die berechnete Objektneigung verhässlicht die Pixelgrafik. In meinen Augen pixelt man wohlgestaltete Rotationen auf dem Pixelraster entweder in allen nötigen Einzelgrafiken selbst oder man löst die Animation vom Raster ab, damit die notwendig zahlreichen Einzelbilder für eine gelungene Rotationsberechnung erreicht werden können. Die Zwischenlösungen sitzen zwischen den Stühlen Einzelbildästhetik und Animationsfluss - jedenfalls bis zur Erfindung eines "Pixelästhetikfilters".
Mit etwas Aufwand machbar, aber wenn ich für jeden Text nicht eine Extra-Grafik anfertigen und auch auf die XP-internen Wettereffekte usw. verzichten möchte, ist es mit der Pixel-Authentizität schwierig -- und selbst dann gibt es ja noch die ganzen Probleme mit pixeltreuer Bewegung, die hier wunderbar aufgeführt wurden. So detailversessen bin ich dann nicht, aber als jemand, der sowieso nicht mit Ruby (oder irgend einer anderen Programmiersprache) umgehen kann und auch keine eigenen Grafiken erstellen möchte, gibt es im Endeffekt einfach keinen echten Mehrwert.
Was ich auch etwas seltsam finde, ist, daß der RMXP immer zu den "neuen" Makern gerechnet wird, obwohl er gerade einmal anderthalb Jahre nach dem 2k3 erschienen ist. Und jener in der von Cherry und Co. polierten und gewarteten Fassung ist für einen Hobby-Ersteller wie mich dann einfach alternativlos.
...
Wieso Extra-Grafik für jeden Text? Retro Text geht mit den neueren Makern auch, siehe Beispiel unten. Und das ist nicht mal mit einem Skript, wie zuvor angesprochen, welches
den Font über ein Bitmap realisiert sondern Standard Message System vom XP. Zusätzlich habe ich dem Text innerhalb 2 Minuten einen drop shadow mit einer Anpassung des Standard Skripts hinzugefügt.
Und wieso auf XP-interne Wettereffekte verzichten? Wettereffekte lassen sich im Code ändern. Exemplarisch den Standard Regen verändert und etwas dem 2k3 angelehnt, 5 Minuten Arbeit:
ps. mit "neuere" Maker sind die Maker gemeint, welche die Möglichkeit für Ruby / Java besitzen.
Zitat von TrunX
Ne, mir ging es eben nicht um die Nutzung von skalierten Grafiken, sondern um die Möglichkeit im rm2k(3) die native 240p Auflösung nutzen zu können für authentische 8- oder 16-bit Optik. Alles von Amiga, C64, Mastersystem, NES, Megadrive, PC Engine, Neo Geo über SNES hat eine Auflösung um die 224p-240p genutzt. Aber ja, wenn man theoretisch ein 160x120 Spiel im RM2k machen wollen würde, hätte man das selbe Problem wie mit 320x240 im XP.
Weils mir real Trolls Endzeit (positiv!) angetan hat, hab ich mal eine Szene daraus in einer anderen Engine (GameMaker) nachgestellt, da ich da die Auflösung und die Art und Weise wie gerendert wird frei kontrollieren kann, um die Rotation von Pixelart anhand eines animierten Beispiels zu besprechen:
Hier wird das 240p Spiel auf 960p (x4) hochskaliert, bei der Rotation aber die volle Auflösung genutzt.
Dies lässt die rotierte Grafik ein wenig wie ein Fremdkörper wirken, da es mit dem Pixelraster bricht und die groben Pixel der Grafik wie ausgeschnitten auf einer gesonderten Ebene einfach mit gedreht werden. Je mehr andere (von Hand) animierte und bewegte Elemente es im Bild gibt, die sich an das Pixelraster halten, umso stärker sticht dann das eine Element was ausbricht als Fremdkörper hervor.
Hier hab ich die Skalierung angepasst, sodass die Szene erst vollständig gerendert wird, bevor das fertige 240p Bild dann auf 960p hochskaliert wird, wodurch sich die programmierte Rotation nun an das Pixelgrid hält. (Farbverfälschung durch die GIF-Aufnahme mal ignorieren^^)
Man könnte sagen es sieht nicht ganz so "hübsch" aus, aber es wirkt nun mehr als Teil der Spielwelt. Da andere animierte Elemente ggf. von Hand animiert sind und nicht so super flüssig wären, könnte es trotzdem noch als klar programmiert statt von Hand animiert hervorstechen.
Das kann man lösen, indem man den Winkel der Rotation nicht jeden Frame, sondern zb. nur alle 10 Frames aktualisiert (Bei einem 60fps Spiel):
Das wäre dann vermutlich meine präferierte Lösung.
Wobei flüssige Skalierungs- und Rotationseffekte die programmiert statt von Hand animiert sind überhaupt nicht gegen authentisches 16-bit Pixelart sprechen. Yoshis Island auf dem SNES hat zb. den SuperFX Chip genutzt um solche grafischen Effekte (Skalieren und Rotieren von Sprites) in Echtzeit flüssig darzustellen). Auch wenn da noch ein extra Chip in der Cardridge notwendig war, spätestens bei den PS1 Pixelart Games und dem GBA wars dann auch ohne Zusatzchip möglich (und wurde auch Gebrauch von gemacht).
Der Vollständigkeit halber noch wie es (vermutlich) im XP aussieht mit doppelter Renderauflösung bei Rotationen:
...
Also wir entfernen uns gerade ewas von dem eigentlichen Kern der Diskussion. Bislang wurde, zumindest ich habe das so, die Thematik mit Fokus auf RPG Maker betrachtet.
Deine Beispiele sind an sich korrekt, ja, das Phänomen tritt bei z.B. Rotation von Sprites auf. Letztendlich ist das aber am Ende Geschmackssache, wie man auch anhand der Reaktionen sieht.
Und das ist, wenn man Game Dev allgemein betrachtet, sicher ein Thema worüber man sich Gedanken machen kann. Aber:
Du zeigst eine "Problematik" auf, die aus Sicht eines Nutzers und Umsteigers von 2k / 2k(3) auf z.B. XP gar nicht relevant ist.
Denn 2k / 2k(3) können gar keine Sprites rotieren. Die Möglichkeit gab es erst ab XP. Heißt, für Rotationen wird der User so oder so
die Grafiken in verschiednee Frames gepackt haben. Genau so, wie das damals in der Regel in kommerziellen Spielen auch gemacht wurde.
Natürlich gab es Ausnahmen wie dein Beispiel mit SuperFX und Yoshi auf dem Snes. Der Punkt ist also:
Rotationen kann der User also weiterhin in verschiedene Frames packen, die Arbeitsweise ändert sich nicht und das "retro feeling" ist wie gehabt vorhanden.
Es braucht keine Rotationsfunktion. Zumal eine Rotationsfunktion meist mehr schlecht als gut ist, wenn kein guter Algorithmus verwendet wird, was bei den Makern nicht der Fall ist, aber mit Scripting theoretisch umgesetzt werden könnte.
Glücklicherweise kann man heutzutage auch auf tolle Tools zurückgreifen wie Rotsprite oder Aseprite, das RotSprite integriert hat.
Worauf ich letztendlich hinaus will ist, dass das gewohnte "retro feeling" mit neueren Makern sehr wohl und im gleichen Umfang und mit überschaubaren sowie zumutbaren Aufwand umsetzbar ist.
Ich habe hier und auch in der Vergangenheit bislang keine Argumente gesehen, die überzeugend das Gegenteil aufzeigen. Dennoch wurde / wird hier bis aufs Brechen an den alten Makern festgehalten.
An sich alles kein Ding, wenn man die classic Maker nutzen möchte. Aber wenn das, im schlimmsten Fall nur, deswegen gemacht wird weil mit den neueren kein "retro feeling" möglich ist und das auch so
verbreitet wird, dann ...
Und hier noch ne kleine Umsetzung von 2k3 mit Refmap auf XP:
Leider hat dein Beispiel aber eben genau die Probleme, die auch TrunX angesprochen hat:
Wie man hier sieht, sind an zig Stellen Dinge auf halbe Pixel aligned bzw. haben halbe Pixel als Breite/Höhe/Abstand, darüber hinaus sind an einigen Stellen Anti-Alias-Artefakte, die da nichts zu suchen haben. (Das ist noch an mehr Stellen, wie ich im Nachhinein sehe, aber die, die ich markiert habe, reichen schon.)
Dein Regen hat dasselbe Problem. In diesem Fall bringt es nicht so viel, was einzukreisen, weil einfach der gesamte Regen-"Strahl" auf halbe Pixel platziert ist und auch selber "Treppen" aus halben Pixeln hat. Ich habe deswegen einfach einmal zum Vergleich rechts daneben eine Variante gestellt, die korrekt dargestellt ist:
-
Das Problem hast du auch, wenn du z.B. ein Picture (oder auch Events, oder auch die Kamera selber, ...) ganz normal bewegst, die entsprechenden Elemente können dann auf halben Pixeln landen dazwischen weil der Maker ja nicht weiß, dass du eigentlich ein größeres Raster haben möchtest. Wie schon von TrunX demonstriert, wird das Problem mit Zoomen und Rotieren noch mal um ein Vielfaches schlimmer.
Das macht einfach das Spielgefühl kaputt. Ich seh das leider immer häufiger: Spiele, wo jemand wohl dachte, Retro und Pixelart bedeutet einfach nur dass Sprites sichtbare Pixel haben. Man sieht dann aber halt schon gleich auf den ersten Blick, dass da was nicht stimmt (oder schlimmer - man beginnt das Spiel zu spielen und entdeckt es danach erst, und fühlt sich dann veräppelt und frustriert). Es ist ungefähr so wie wenn man ein handgemaltes Bild kauft nur um dann zu bemerken, es ist ein Druck. Hat einfach Bootleg-Vibes im negativen Sinne.
Ich weiß dass es Leute gibt, die das nicht stört oder die es nicht mal bemerken. Ist vielleicht eine neuere Generation, die Fake-Pixel einfach schon gewöhnt ist und denkt das gehört so, keine Ahnung. Aber für manche, inklusive mir, ist das halt ein Dealbreaker.
In ganz wenigen Fällen schaffen es Spiele, trotz Pixel-Look dann Subpixel-Rendering bewusst und überlegt so einzusetzen, dass es nicht negativ auffällt sondern tatsächlich das Spielerlebnis verbessert. CrossCode gehört da dazu (was aber kein Makerspiel ist sondern seine eigene Engine verwendet) - da hätte ich es von mir aus nicht mal bemerkt, wenn nicht Lachsen mich drauf aufmerksam gemacht hätte. Hut ab dafür! Aber in den meisten anderen Fällen sieht es einfach nur fake aus.
(Ach ja, btw, 2k/2k3 kann auch Sprites rotieren. Ursprünglich zwar nur kontinuierlich im Kreis, aber es gibt verschiedene Wege das zu ändern.)
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!
Zitieren
. Dadurch, dass ab XP das RTP recht brauchbar wurde und viele Settings abdeckt werden, wird es vermehrt verwendet. Durch die vermehrte Verwendung begehen allerdings viele den Fehler und gehen davon aus, dasss das höher aufgelöste RTP der "Stil" der neueren Maker ist (was auch immer das heißt) und was anderes nicht geht. Ist schade, schon sehr oft gesehen.
"Wolfenhain" fertig. "Endzeit": fertig. Neues Projekt: "Nachbarlicht" 
CherryShare
