(Reale) Ladezeiten in Makerspielen

[Corti]

@Corti:
Als grobe Rechnung klingt da ja schon abschreckend, aber ich gehe jetzt mal von max. 200MB für beide Bilder aus, da sie sich ja pixelgenau ergänzen und nicht mehrfach überlagern sollen. Außerdem strebe ich eine relativ entsättigte Farbpalette an, was vllt den Großteil der Fläche simpler halten könnte. Aber da muss ich gestehen, dass ich kein Fachmann bin. x)

...

Deine entsättigten Farben sind für die Datenmenge völlig egal.
Ob die sich überlagern oder nebeneinander liegen, ist völlig egal.
Ob der Großteil davon Transparenz dargestellt wird, ist völlig egal.
Auf welche Größe die PNG auf der Festplatte runterkomprimiert wurde, ist völlig egal.

Wahrscheinlich werde ich dann aber wirklich den Weg der Stückelung gehen, wobei mich da natürlich interessieren würde, ob 4 kleinere Karten mit derselben Dateninformation mehr RAM und Speicherplatz verbrauchen würden, als eine einzige, unfassende Datei.

...

Durch eine Stückelung erreichst du, dass für eine der Maps dann weniger Daten benötigt werden und somit auch die Ladezeit geringer ist. Dafür muss man dann öfter Laden beim Mapwechsel zwischen den Teilen.

@RAM:
Für moderne PCs und Laptops würde ich mir keine Sorgen machen. Aber man kann MV Spiele auch auf Smartphones und im Web spielen.

[Whiz-zarD]

Deine entsättigten Farben sind für die Datenmenge völlig egal.
Ob die sich überlagern oder nebeneinander liegen, ist völlig egal.
Ob der Großteil davon Transparenz dargestellt wird, ist völlig egal.
Auf welche Größe die PNG auf der Festplatte runterkomprimiert wurde, ist völlig egal.

...

Naja, es ist ja nicht so, als würden Grafikkarten nichts von Kompressionen verstehen.
Auch innerhalb des Grafikspeichers werden Texturen komprimiert. z.B. mit dem S3TC- oder in Smartphones mit dem ETC-Verfahren.

[Corti]

Grafikkarten ja, moderne Grafik-APIs auch. Aus für Nichtprofi-Entwickler pragmatischen Gründen benutzt der Maker PNGs als Datenformat, kommerzielle Spiele haben ihre Texturen bereits in für die Hardware günstigem Format vorliegen, dxt1 bis dxt5, dds etc. sind ja alles S3TC-varianten. Wenn der MV sowas kann, dann könnte man auch den Weg gehen die Bilddaten in einem solchen Format bereit zu stellen.

Der MV benutzt als Grafikausgabe Pixi.js das benutzt WebGL. WebGL -> OpenGL ES. Müsste es also können. Was davon bereits genutzt wird und was man optimieren könnte, kann ich natürlich nicht sagen. Eine Grafik von 10560 * 6864 px wird man auf jeden Fall nicht im PNG Format als eine Textur in die Grafikpileline schieben können. Diese Grafikdaten müssen also noch irgendwie bearbeitet werden.

[Cornix]

PNG ist sowieso kein Format, was eine Grafikpipeline kennt. Die Bilddaten müssen auch nicht im RAM gehalten werden wenn man sie anzeigen will. Man kann die PNG laden; muss sie dann umwandeln in ein Format, welches die Grafikkarte mag; diese Daten dann auf die Grafikkarte übertragen und die Daten im RAM löschen. Das Format, in welchem die Daten auf der Festplatte liegen ist irrelevant für die Grafikausgabe. Was bei dem RPG-Maker jedoch ist, ist dass man (zumindest beim XP und VX) mit dem Ruby Code auf die Farbwerte der einzelnen Pixel zugreifen kann. Damit soetwas möglich ist müssen die Bilddaten natürlich im RAM gehalten werden.

[elvissteinjr]

Komprimierte Texturen auf Mobilsystem sind eh so ne Sache. iirc hat man bei OpenGLES 2.0, worauf WebGL 1 basiert, dort nur eine Garantie auf ETC1, was keinen Alphakanal unterstützt. Alle anderen Formate in der Generation sind herstellerspezifisch und können wahrscheinlich nicht einmal zur Laufzeit generiert werden (zumindest für PVRC gibt's nichts dergleichen).

Zumal sich nebenbei auch die Frage stellt: Verlustbehaftete Texturkompression für 2D Pixelart? Resourcensparen ist schön und selektiv macht das noch Sinn. Automatisch auf jede Grafik wäre es aber wohl eher kontraproduktiv für die Optik, so minimal der Effekt auch sein möge.