Seite 3 von 3 ErsteErste 123
Ergebnis 41 bis 50 von 50

Thema: Grafikstil debatte XXL: Alt gegen Neu

  1. #41
    Zitat Zitat von schmoggi Beitrag anzeigen
    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:

  2. #42
    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.

  3. #43
    @ 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".

  4. #44
    Zitat Zitat von Froschvampir Q Beitrag anzeigen
    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.
    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 Zitat von TrunX Beitrag anzeigen
    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:


    Geändert von schmoggi (10.07.2022 um 14:34 Uhr)

  5. #45
    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.)

    Geändert von Cherry (12.07.2022 um 00:39 Uhr)

  6. #46
    Zitat Zitat von Cherry Beitrag anzeigen
    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.)
    Wie bereits gesagt wurde, Anti Aliasing mag in manchen Augen ein Problem sein, das lässt sich leider zumindest im XP nicht ausschalten. In den neueren Makern wie MV scheint das wohl anders zu sein.
    Ich habe mal kurz in den Code geschaut und es ist mir möglich jedes Wort auf der X Achse pixel aligned darzustellen. Mehr geht leider nicht mit Standard Mitteln. Wenn jemanden beim Text diese Tatsache wirklich stört, gibt
    es immer noch die Möglichkeit eine Font per Bitmap über ein custom Skript anzeigen zu lassen. Aber ganz ehrlich ... wenn man jetzt mit der Lupe nach diesen Dingen sucht, dann ist aus meiner Sicht der Fokus beim Spielen schief.
    Und am Ende sind die eigentlichen Spieler keine Game Devs, das kommt noch hinzu. Gerade auf den Text bezogen ist mir persönlich das stimmige Gesamtbild wichtiger als pixel aligned Buchstaben. Und ich meine nicht, dass man
    mein schnelles Beispiel jetzt objektiv betrachtet als "schlecht" bezeichnen kann.
    Zitat Zitat von Cherry Beitrag anzeigen
    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" ist durch die mal nebenbei schnelle Anpassung entstanden. Ist alles eine Frage von Zahlen, lässt sich einfach lösen. Schau:



    Neben einer Verbesserung der Regen Strahlen sind diese immer pixel aligned.


    Zitat Zitat von Cherry Beitrag anzeigen
    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.
    Wie beim Regen aufgezeigt, eine Frage der Zahlen und Werte. Das sind Dinge, die sich im Code mit einigen Handgriffen anpassen lassen. Bei Zoom und Rotation bin ich mir aus dem Stehgreif nicht sicher, da ich nicht weiß wie offen der Code im Falle von XP da ist. Und Rotation ist mMn eh ein Thema für sich weil auch damals die Regel war, verschiedene Frames der Sprites zu zeichnen, statt ein Sprite rotieren zu lassen was oft eh nach Schmutz ausschaut.
    Zitat Zitat von Cherry Beitrag anzeigen
    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.
    Es wird immer persönliche Präferenzen geben, keine Frage, aber man kann sich auch selber unnötig im Weg stehen. Das Gefühl bekomme ich bei diesen Diskussionen sehr stark. Du hast das Spielgefühl angesprochen. Und darauf kommt es am Ende auch an und nicht auf nicht 100% pixel aligned Dinge, welche man mit der Lupe findet, aber beim eigentlichen Spielen nicht relevant sind bzw. dem Spieler nicht auffallen, weil der Fokus auf das Gesamtbild liegt. Am Ende zählt der Spaß. Selbst moderne und kommerzielle Spiele mit pixel art zeigen nicht immer diese pixel Perfektion auf, vermitteln einem am Ende aber das schöne charmante retro feeling von damals. Und es gibt ja selbst hier im Atelier Beispiele dafür, dass am Ende der Spaß zählt wenn wir an Projekte wie die von realtroll oder Kelven denken, welche mit dem XP umgesetzt sind und die 16 Bit Optik nutzen. Wir sind ja in keinem Wettbewerb wo es darum geht Pixel Purismus vorzuweisen sondern es geht den meisten darum den Spaß und das Spielgefühl von retro pixel games umzusetzen. Und ein Gefühl ist am Ende ja auch subjektiv und ich persönlich z.B. empfinde keinen Unterschied (Movement etc.) wenn ich zwischen meinen Beispielprojekten hin und her switche. Würde ich jemanden daran setzen, der keine Ahnung vom Maker hat, der würde sich höchst wahrscheinlich auch fragen was jetzt anders ist. Und ich gehe sogar so weit und sage, dass selbst viele User hier anhand des Spielgefühls nicht unterscheiden könnten, ob es nun mit 2k(3) oder beispielsweise mit XP erstellt wurde.
    Zitat Zitat von Cherry Beitrag anzeigen
    (Ach ja, btw, 2k/2k3 kann auch Sprites rotieren. Ursprünglich zwar nur kontinuierlich im Kreis, aber es gibt verschiedene Wege das zu ändern.)
    Echt, ich habe da nix gefunden . Aber ich gehe davon aus, dass du von custom patches etc. redest, die u.a. du erstellst hast wenn du verschiedene Wege erwähnst. Dann muss man der Fairness halber auch Ruby / Java für die neueren Maker einwerfen, womit so vieles möglich ist.

    Geändert von schmoggi (12.07.2022 um 15:42 Uhr)

  7. #47
    Zitat Zitat
    Und darauf kommt es am Ende auch an und nicht auf nicht 100% pixel aligned Dinge, welche man mit der Lupe findet, aber beim eigentlichen Spielen nicht relevant sind bzw. dem Spieler nicht auffallen. Am Ende zählt doch der Spaß.
    Das Ding ist halt einfach: Es gibt Dinge, die findet man im Detail zwar nur mit der Lupe, was man aber auch nur braucht wenn einen jemand fragt was genau denn jetzt das Problem ist. Ohne Lupe "spürt" man es aber schon. Keine Ahnung wie ich es beschreiben soll. Wie ein minimal verstimmtes Instrument, was einem dann halt den ganzen Spaß verhaut beim Zuhören der Musik. Oder wenn in einem Film Audio und Video um mehr als ca. 5-10 Millisekunden verschoben sind. Oder wenn jemand den Orangensaft in meinem Blood and Sand nicht frisch gepresst hat. Man merkt dass was nicht passt lang bevor man genau sieht und erklären kann was. Beim Regen war das zum Beispiel so. Bei der Schrift war es auch ohne Lupe offensichtlich dass die Abstände im kleinen "e" z.B. nur einen halben Pixel hoch waren (mir zumindest).

    Drum, ich stimme dir komplett zu, es geht drum dass es Spaß macht und nichts negativ auffällt was den Spaß stört. Aber mir fällt sowas halt auf und es stört dann. CrossCode war ja auch sogar noch ein Beispiel dafür wo das nicht stört sondern sogar hilft, aber das ist halt eben meistens nicht so sondern andersrum. Aus dem Grund war ich zum Beispiel auch von Stardew Valley enttäuscht - es sah zuerst cool aus, und dann bei genauerem Hinschauen ist die Illusion zerfallen als sich Debris in Subpixeln gedreht und herumbewegt hat.

  8. #48
    @real Troll
    Hatte noch überlegt einen Textabschnitt bezüglich handanimierten Rotationen zu schreiben, aber gedacht mein Post ist auch so schon zu lang.^^

    Stimme da voll zu, dass so programmierte (unsauber aussehende) Rotationen eigentlich nur bei schneller und stetiger Bewegung sinvoll sind wie zb. eine Zauberanimation mit einem schnell rotierendem Feuerball der dabei auch noch skaliert und transparenter wird. Auf nem screenshot mögen die Pixel da am Rand ausgefranzt aussehen oder ungleichmäßig skaliert, gerade bei so 150% Zwischenstufen, aber in Bewegung fällt das dann wenig bis garnicht auf. Wichtig ist halt, dass in den Momenten wo die Bewegung zu einem Stillstand kommt es im Falle von Skalierung auf einem Integerwert (Ganzzahl) stehen bleibt oder im Falle von Rotation auf einem 90° Zwischenschritt, sodass man da keine unschönen Verzerrungen dauerhaft sieht. Alternativ muss man wie du vorgeführt hast mindestens diesen Endframe nochmal von Hand überarbeiten.

    Im Falle von meiner präferierten low-fps Schaukelanimation sinds neben dem unrotiertem Ausgangsframe auch nur jeweils 3 frames zur Seite (welche auf der anderen seite zu 99% identisch gespiegelt sind), also kein großer Aufwand das nochmal von Hand aufzuhübschen.
    Hab jetzt mal auf die schnelle nur ein wenig über die unschönen Sprünge an den Armen drüber gepixelt, geht sicher noch besser:



    Zitat Zitat von schmoggi Beitrag anzeigen
    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.
    Ich weiß nicht, ich hab den Ursprung der Diskussion eher als die Frage wieso manche Spieler den rm2k(3) Grafistil dem Stil der neueren Maker vorziehen wahrgenommen. Wobei sich die Diskussion da zweigeteilt hat. Einmal die Fraktion die einfach den 320x240 low-res Pixelartstil dem high-res Pixelartstil der neueren Maker visuell vorziehen. Und auf deinen Einwurf, dass man den 320x240 low-res Stil in den neueren Makern einfach imitieren kann entstand noch eine Nebendiskussion, dass es doch nicht ganz so trivial wie Assets x2 skalieren ist bzw. die allermeisten Spiele die es versuchen es nicht sauber hinbekommen. Das man in der Theorie, wenn man vieles beachtet und manche Skripte extra anpasst bzw. auf die Nutzung von Standardsystemen verzichtet, es hinbekommt ein komplett authentisches low-res Pixelartspiel in den neueren Makern hinzubekommen, hat glaub ich keiner bestritten.

    Nur sind die aller meisten RPG Maker Entwickler Amateure, viele arbeiten sich evtl grad erst in die Grundlagen der Programmierung ein, sind also technisch interessiert/begabt, aber haben evtl. weniger Gespür für Grafik Design Grundlagen. Wenn sie dann mit einem Tool arbeiten das all diese Fehler bei low-res Pixelart erlaubt oder gar standardmäßig forciert kommen entsprechend auch Spiele raus, die all diese Fehler machen und das Spiel auf den ersten Blick als Amateuerprojekt outen.

    Auch bei den modernen (kommerziellen) Indiegames merkt man diesen sofort an ob das ein 1-Mann-Programmierer Projekt war der auch ein wenig Grafiken erstellen kann (dem dann so was wie rotierte scharfe Pixel kackegal sind) oder ob da ein professioneller Pixel Artist mit kreativer Entscheidungsgewalt beteiligt war, der da sofort sein Veto einlegen würde.

    Gibt sicher auch Spiele wo es gameplaytechnisch sinvoll ist sowas wie eine dynamische Kamera zu haben, die das Pixelraster ignorierend flüssig rein und rauszoomt abhängig davon wie schnell sich der Spieler bewegt oder was auf dem Bildschirm los ist. Wenn das bei einem Pixelartspiel passiert mögen sich da ein paar Retroliebhaber drüber aufregen, aber ich habs längst als eigene Subkategorie "Modernes Indiegame" akzeptiert statt mich darüber aufzuregen, dass es nicht authentisch "Retro" oder "16-bit Pixelart" ist. Gibt halt saubere Umsetzungen (Wie zb. Celeste was auch gar nicht auf Retro-Game tut.) und welche wo man direkt merkt, dass sich da einfach nur wenig Gedanken gemacht wurden bei der Umsetzung.

    Ein Negativbeispiel was mir noch einfällt ist der PC-Release von Chrono Trigger. Da wurden einfach die Smartphone Version mit dem Touchinterface (Riesen Buttons) für den PC geported ohne großartige Anpassungen (Es hat sich sogar eine Bildschirmtastatur geöffnet bei der Namenseingabe, die sich mit der Maus bedienen lässt). Zu allem Überfluss wurde dann noch ein nicht ausschaltbarer "Scharfzeichnungsfilter" über das Pixelart gelegt um die Optik auch noch komplett zu verhunzen. Nicht nur, dass die Pixelart Chars dadurch hässlich aussahen, die Tiles die vorher nahtlos aneinander gepasst haben hatten plötzlich scharfe Kanten zwischen einander durch den Filter, es sah also einfach nur hässlich aus. So was passiert, wenn man einen einzelnen Programmierer dran setzt der entweder kein Gespür für Grafik hat oder einfach nur nicht gut genug bezahlt wurde, als dass ihn das großartig jucken würde. Vermutlich wurde ihm gesagt du hast eine Woche die Android Version für PC zum laufen zu kriegen. "Und mach das es schöner aussieht und nicht mehr so pixelig."

    Ein Tweet von Cyangmou dazu.

    Da der Aufschrei groß war und die Rezessionen überwiegend negativ (hat das grandiöse Spiel nicht verdient), wurde ein Großteil der Probleme dann nachträglich immerhin noch gepatched. Pixelart wurde wieder schön pixelig gemacht und selbst der scharfe Arial Font bei den Textboxen wurde durch einen Pixelartfont ersetzt, da auch das viele Spieler gestört hat.

    Nur mal als Beispiel, dass es auch große Studios wie Square Enix ordentlich verkacken können bei einem Pixelart Spiel, wenn sie keinen (erzwungenen) Einschränkungen durch die Engine ausgesetzt sind und kein Artist Supervisor an der Umsetzung beteiligt ist. ^^

    EDIT:
    Zitat Zitat von Cherry Beitrag anzeigen
    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.
    CrossCode befindet sich noch auf meinem Pile of Shame. Würde mich aber interessieren inwiefern es sich nicht ans Pixelraster hält oder Subpixelrendering nutzt. Das einzige was ich auf die schnelle beim betrachten von Screenshots entdeckt habe ist, dass das Spiel weder auf 720p noch 1080p Screenshots scharf dargestellt wird, sondern leicht verwaschen ist. Vermutlich weil die verwendete Auflösung sich nicht integerskalieren lässt auf die gängigen Vollbildauflösungen?

    Geändert von TrunX (12.07.2022 um 20:46 Uhr)

  9. #49
    Zitat Zitat von TrunX Beitrag anzeigen
    Ich weiß nicht, ich hab den Ursprung der Diskussion eher als die Frage wieso manche Spieler den rm2k(3) Grafistil dem Stil der neueren Maker vorziehen wahrgenommen. Wobei sich die Diskussion da zweigeteilt hat. Einmal die Fraktion die einfach den 320x240 low-res Pixelartstil dem high-res Pixelartstil der neueren Maker visuell vorziehen. Und auf deinen Einwurf, dass man den 320x240 low-res Stil in den neueren Makern einfach imitieren kann entstand noch eine Nebendiskussion, dass es doch nicht ganz so trivial wie Assets x2 skalieren ist bzw. die allermeisten Spiele die es versuchen es nicht sauber hinbekommen. Das man in der Theorie, wenn man vieles beachtet und manche Skripte extra anpasst bzw. auf die Nutzung von Standardsystemen verzichtet, es hinbekommt ein komplett authentisches low-res Pixelartspiel in den neueren Makern hinzubekommen, hat glaub ich keiner bestritten.
    Ich glaube, tatsächlich ging es bei der ursprünglichen Frage (wieder mal) um dieses leidliche Thema bzgl. Refmap und andere Assets, welche beim 2k(3) Verwendung finden, und die Nutzung dieser in den neueren Makern.
    Zumindest habe ich das so aufgefasst. Denn, soweit ich mich erinnere, war das immer wieder Thema in den Jahren zuvor ab Release von XP. Es ist schwierig(er) für die neueren Maker Ressourcen zu finden / zu erstellen weil höhere Auflösung etc.
    Und weil ab XP das RTP, welches mit Blick auf die höhere Auflösung erstellt wurde, von Community verstärkt eingesetzt wurde, bekamen die alten Hasen den Eindruck, dass diese Optik mehr oder weniger zwingend ist bzw.
    das vorherige nicht mehr erreicht werden kann. Und das ist schlicht falsch. Denn, rein auf die Assets bezogen ist es ja durch simple Skalierung machbar. Und daraus, wie du gut beschrieben hast, haben sich dann mehrere Dinge hier abgeleitet + das persönliche Empfinden.
    Diese haben ja durchaus Berechtigung und sind zu einem großen Teil auch lösbar / umsetzbar. Dabei helfen sicherlich coding skills und Wissen darüber, was der Maker intern so im Code alles anstellt.

    Und wie du richtig geschrieben hast, sind viele Anfänger. Aber die Community hat auch durchaus Leute mit Talent in verschiedenen Bereichen vorzuweisen, die teils auch den Sprung in den professionellen Bereich schaffen.
    Ich glaube, das Kollektiv hat in den Jahren zuvor einfach die Gelegenheit verpasst sich zusammenzuraufen und eine Art Template oder Sample Projekt zu erstellen, auf welches man zurückgreifen kann
    und gewisse Dinge vorab erledigt hat (Beispiel Regen von oben) + vielleicht Refmap aufbereitet für die fertige Nutzung.
    Das hätte sicherlich geholfen da bisschen mehr Akzeptanz zu schaffen. Stattdessen hat man stark getrennt, XP Community da, Atelier hier usw. Hin und wieder haben sich einige auf der anderen Seite verlaufen aber
    mehr auch nicht. Und witzig auch, dass diese retro Liebhaberei am Ende schnell einem wow usw. weicht und es gar nicht mehr so relevant scheint, wenn dann Vorzeigeprojekte wie London Gothic XP auftauchen.
    Da kann ich mich noch gut an einige Reaktionen bei der Vorstellung erinnern . Vielleicht war es auch das, was fehlte. Ein gutes Projekt, welche die Leute mitzieht und aufzeigt, dass es auch mit den neueren Makern funktioniert

    Zitat Zitat von TrunX Beitrag anzeigen
    Ein Negativbeispiel was mir noch einfällt ist der PC-Release von Chrono Trigger. Da wurden einfach die Smartphone Version mit dem Touchinterface (Riesen Buttons) für den PC geported ohne großartige Anpassungen (Es hat sich sogar eine Bildschirmtastatur geöffnet bei der Namenseingabe, die sich mit der Maus bedienen lässt). Zu allem Überfluss wurde dann noch ein nicht ausschaltbarer "Scharfzeichnungsfilter" über das Pixelart gelegt um die Optik auch noch komplett zu verhunzen. Nicht nur, dass die Pixelart Chars dadurch hässlich aussahen, die Tiles die vorher nahtlos aneinander gepasst haben hatten plötzlich scharfe Kanten zwischen einander durch den Filter, es sah also einfach nur hässlich aus. So was passiert, wenn man einen einzelnen Programmierer dran setzt der entweder kein Gespür für Grafik hat oder einfach nur nicht gut genug bezahlt wurde, als dass ihn das großartig jucken würde. Vermutlich wurde ihm gesagt du hast eine Woche die Android Version für PC zum laufen zu kriegen. "Und mach das es schöner aussieht und nicht mehr so pixelig."

    Ein Tweet von Cyangmou dazu.

    Da der Aufschrei groß war und die Rezessionen überwiegend negativ (hat das grandiöse Spiel nicht verdient), wurde ein Großteil der Probleme dann nachträglich immerhin noch gepatched. Pixelart wurde wieder schön pixelig gemacht und selbst der scharfe Arial Font bei den Textboxen wurde durch einen Pixelartfont ersetzt, da auch das viele Spieler gestört hat.

    Nur mal als Beispiel, dass es auch große Studios wie Square Enix ordentlich verkacken können bei einem Pixelart Spiel, wenn sie keinen (erzwungenen) Einschränkungen durch die Engine ausgesetzt sind und kein Artist Supervisor an der Umsetzung beteiligt ist. ^^
    Ja, Chrono Trigger ist / war übel, das ist aber auch echt ein mega Negativbeispiel, weil 1. Chrono Trigger und 2. der nicht vorhandene Respekt gegenüber dem Spiel und den Fans. Tatsächlich sehe ich das bei größeren Studios / Publishern häufiger als bei Indie Entwicklern.
    War auch am Ende ein Grund, wieso ich es mir dann für den DS geholt habe, auch wenn da einige aufgrund der Änderungen in Dialogen / Charakteren aufschreien und Snes Version rufen .
    Zitat Zitat von TrunX Beitrag anzeigen
    EDIT:
    CrossCode befindet sich noch auf meinem Pile of Shame. Würde mich aber interessieren inwiefern es sich nicht ans Pixelraster hält oder Subpixelrendering nutzt. Das einzige was ich auf die schnelle beim betrachten von Screenshots entdeckt habe ist, dass das Spiel weder auf 720p noch 1080p Screenshots scharf dargestellt wird, sondern leicht verwaschen ist. Vermutlich weil die verwendete Auflösung sich nicht integerskalieren lässt auf die gängigen Vollbildauflösungen?
    Crosscode hat meines Wissens eine 5xx x 320 render Auflösung und man kann das Fenster neben der original Größe 2x größer darstellen lassen oder mit stretch / fit auf dem Display komplett skalieren. Zusätzlich gibt es noch die Option die Größe der Pixel von 1x bis 4x einzustellen, was bei größeren Displays hilft.

    Geändert von schmoggi (13.07.2022 um 12:36 Uhr)

  10. #50
    Zitat Zitat von TrunX Beitrag anzeigen
    Das hier finde ich von deinen gezeigten (Pixel)Beispielen am besten. Kompliment.

    Jedoch sieht die Bewegung weitaus weniger flüssig aus als diese Variante:

    Zitat Zitat von TrunX Beitrag anzeigen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •