Ich habe das mal versucht, das größte Problem ist eigentlich, dass sich die niedrige Auflösung dann mit den höher aufgelösten Textboxen / Menüs beißt.
Ich habe das mal versucht, das größte Problem ist eigentlich, dass sich die niedrige Auflösung dann mit den höher aufgelösten Textboxen / Menüs beißt.
Kann man doch auch verändern, glaub ich? Pixelige Schrift verwenden und pixeliges Systemset verwenden.
https://rpgmaker.net/games/9093/ -> Erstellt mit dem RPG-Maker Mv
Glaube fast, die meisten die gegen die neueren RPG-Maker wettern, wollen einfach nur kein Geld ausgeben, um sich die Software zu kaufen und lieber mit den gecrackten 2000er Makern weiterarbeiten.![]()
--Ein sehr symphatischer und überaus aktiver RPG Maker Benutzer
Der Ansatz ist da, aber als Pixelpurist finde ich das Gesamtbild da doch wieder doof. Pixelfont mit Antialiasing und nicht auf nativer Größe; Grafiken, die mit Filter zusammengestaucht wurden; Grafiken, die außerhalb des simulierten Pixelrasters platziert wurden. Zumal sich das in Bewegung dann auch außer diesem Rasters gerade zu flüssig abläuft.
Besser als der Brei von den neueren RTPs, aber auch nix Ganzes.
Gibt's bei der ganzen Skripterei noch nichts was wirklich auf niedrigerer Auflösung rendern lässt?
Antialiasing kannst du im RPG Mv deaktiveren.
Man kann die Grafiken auch gleich in der richtigen Größe erstellen oder Pixelgrafiken kaufen oder kommissionieren, die nicht skaliert werden müssen.
https://store.steampowered.com/app/4...City/?l=german
Und es gibt auch viele freie Packs.
Versteh ich nicht.
https://forums.rpgmakerweb.com/index...nt-blur.75294/
https://forums.rpgmakerweb.com/index...g-mode.141354/
Man muss halt wirklich nur mal ein bisschen nachschauen.
--Ein sehr symphatischer und überaus aktiver RPG Maker Benutzer
Ich schon, manche moderne Indiegames im "Retrolook" stoßen Retroliebhabern und Pixelartpuristen sauer auf, wenn sie beim skalieren und rotieren von den Grafiken die volle Bildschirmauflösung nutzen, sodass aus einem um 45° rotiertem quadratischen Pixel ein scharfer DIamant wird. Gibt auch viele Spiele die es beim platzieren von Dekoobjekten/NPCs nicht so genau nehmen und dann ein NPC oder Baum, dessen Grafik 4x skaliert wurde um 1px versetzt zum Hintergrund platzieren. Und beim Bewegen wird sich dann nicht im Pixelraster bewegt, sondern flüssiger in der höheren Bildschirmauflösung.
https://teleshock-p.itch.io/buddys-bone
https://rpgmaker.net/games/12235/images/101921/
https://rpgmaker.net/games/12241/
https://rpgmaker.net/games/11285/
https://rpgmaker.net/games/8582/
Kann ich ja nicht wissen, welchen Maker du benutzt, aber deine Frage hab ich damit doch hoffentlich beantwortet, oder nicht?
Ok, verstanden. Danke.
Sind das nicht aber alles "Fehler", die dir mit jedem RPG-Maker "passieren" können? Das schließt doch zum Beispiel den MV nicht als geeignete Engine für Pixelspiele aus.
Wenn klar ist, dass der 2000er RPG-Maker eine Tilegröße von 16x16 hat und der MV eine Tilegröße von 48x48... warum vergrößert ihr eure Pixel nicht einfach um den Faktor 3? Und damit meine ich kein Skalieren mit Photoshop - "Pixelpuristen" pixeln wahrscheinlich ohnehin lieber selbst?
Zum Beispiel gibt es diese Grafiken hier sogar für den MZ:
https://store.steampowered.com/app/1...P_Horror_City/
Und die sind nicht einfach x3-Skaliert. Sondern haben eben entsprechend große Pixel, um das auch mit einer höheren Auflösung passend darzustellen.
Ich verstehe den Punkt aktuell nicht.
--Ein sehr symphatischer und überaus aktiver RPG Maker Benutzer
Wenn die Grafiken nur hochskaliert sind, nimmt jeder Pixel der Ursprungsgrafik 3 Pixel der Renderauflösung ein. Bewegt sich die Grafik (z.B. weil das Charset der Heldin nach rechts geht) jetzt bewegt sie sich nicht in 3px Schritten (1px Quellauflösung) sondern trotzdem in 1px Schritten. Das führt dazu, dass die Animationen nicht mehr auf das Pixelgitter alignen:
1x
2x mit korrekt alignter animation
2x wie es mit upscaled grafiken aussieht -> der wandernde Pixel "gleitet" durch den Hintergrund
Je höher die Auflösung desto drastischer der Effekte (ein einzelner Pixel gleitet 4, 8, 16... Pixel pro Frame durch einen einzelnen Hintergrundpixel)
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.
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.
Geändert von TrunX (03.07.2022 um 01:33 Uhr)
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.
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.
Geändert von schmoggi (04.07.2022 um 09:59 Uhr)