Ergebnis 1 bis 20 von 50

Thema: Grafikstil debatte XXL: Alt gegen Neu

Baum-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #20
    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 13:34 Uhr)

Berechtigungen

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