Texturgenerierung verhindern

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Texturgenerierung verhindern

    Seit Studio (kann mich nicht erinnern, dass das vorher der Fall war) konvertiert GM Grafiken in Texturen, standardmäßig in 2048*2048 Bilder. Das Problem daran ist u.A., dass Optimierungen an PNG Bildern dadurch hinfällig werden und man recht große Dateien enthält. Mir ist das leider erst eben aufgefallen, da ein Projekt mit einigen Full-HD Bildern zu einer 27MB EXE führt. Da ich grundsätzlich PNG und nicht JPG verwende, bin ich hier auf entsprechende Optimierungen angewiesen, was eigentlich auch ganz ordentlich funktioniert aber nicht, wenn GM diese Optimierungen zunichte macht.

    Früher war das nicht der Fall, da konnte man wunderbar seine externen Ressourcen optimieren und GM hat das eingelesen und in den Grafikkartenspeicher eingeladen.

    Lange Rede, kurze Frage: Kennt jemand in GM eine Option, mit der man das Konvertieren in eine Textur verbieten kann? GM optimiert ohnehin nichts und lässt bei einem 1920*1080 Bild den Rest frei, statt die Bilder zu zerschneiden und somit Speicherplatz in der Grafikkarte zu sparen. Bei kleineren Texturen reduziert GM sogar die Auflösungen, was besonders ärgerlich ist.

    Ich wäre hier über Erfahrungsaustausch echt sehr dankbar.
    Byte GameMaker Magazin - Online Zeitschrift für Spieleentwickler

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von the_black_wall ()

  • Du musst bedenken dass Grafikkarten die Texturen nicht auf dieselbe weise (komprimiert als jpeg oder png) im Grafikspeicher speicher.
    Die GPU speichert texturen unkomprimiert, egal was das ursprüngliche format auf der Festplatte ist. (Weshalb ich generell nicht empfehle jpegs zu verwenden.)
    Die Textur wird von der HDD in den RAM gelesen, dort dekomprimiert und an die GPU in unkomprimierten format gesendet.

    Du kannst dir einfach ausrechnen wieviel Speicher ein 1024*1024 pixel bild verbraucht:
    Jedes pixel hat 4 Kanäle (r,g,b und alpha) welcher jeweils 1 byte (8 bit) besitzt.
    Somit wäre das:

    1024*1024*4 = 4194304 bytes.
    4194304/1024 = 4096 KB = 4 MB

    Du wirst also mit einer einfachen 1024*1024 großen textur 4MB Grafikspeicher verbrauchen. (und das steigt mit höherer Auflösung exponentiell an. Eine 2K textur, also 2048*2048 pixel würde schon 16MB verbrauchen.)

    Der Grund dafür ist das GPUs schnell arbeiten müssen. Das komprimieren/dekomprimieren von Texturen im Grafikspeicher würde in realtime applicationen zu enormen performanceeinbußen führen.
    Es gab bereits versuche hardware basierte Texturkomprimierung einzuführen (ich glaub Nvidia hat da mal was gemacht) das hat aber meines Wissens nach auch leichte Qualitätseinbußen mit sich gezogen und sich damit auch nicht durchgesetzt.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von LEWA ()

  • Das ist mir schon klar, LEWA, ich rede primär davon, dass die Methode von GM unnötig viel Festplattenspeicher braucht (große EXE). Das geht auch anders, selbst wenn man es nicht so macht wie früher. Mit einfachen PNG Optimierungen kann man die EXE viel kleiner bekommen, doch das ist mit GM nicht möglich, da GM die Sachen noch einmal anfasst und sich somit alle Optimierungen erübrigen.

    Was GM macht ist doppelt ärgerlich. Es ignoriert nicht nur die Optimierungen des Entwicklers, sondern wandelt die Texturen sehr ungeschickt in PO2 um und verbraucht damit auch noch unnötig Grafikkartenspeicher. Vor allem wenn man sehr viele Einzelbilder hat, erweist sich das als Käse. Man könnte die Bilder so aufstückeln, dass die leeren Flächen gefüllt werden und die Bilder dann wieder zusammenfügen. Ich hatte das mal vor vielen Jahren bei einem Projekt, aber einerseits wurde das in C++ mit einer eigenen Engine erstellt und andererseits war ich dort kein Programmierer. Wie auch immer, ich schweife ab.

    Für mich zeigt sich leider erneut, dass GM in so gut wie allen Belangen enge Grenzen hat, sobald man auch nur ein wenig anspruchsvoller wird. :(
    Byte GameMaker Magazin - Online Zeitschrift für Spieleentwickler
  • Du kannst backgrounds/sprites/texturen auch als "included files" ins Spiel laden. Diese Ressourcen werden vom GM nicht konvertiert (oder sonst irgendwie verändert.)
    Dann musst du aber viele Sachen die der GM für dich übernehmen würde (wie z.B: die Texturepage optimierungen) selbst implementieren.

    Ist es suboptimal? Womöglich. Dass hast du aber heutzutage bei vielen Engines (Game Maker ist bei weitem nicht ein einzelfall). Entweder passt man sich daran an oder (wozu ich immer tendiere da ich selbst auch kein fan von solchen etwaigen eigenheiten von Engines bin) man implementiert diese funktionalität selbst um solche "limitationen" zu umgehen.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von LEWA ()

  • Das gute an so einer "fertigen Engine" wie der GM:S Engine ist doch, das sie dir die Arbeit abnehmen, dir über solche Sachen einen Kopf machen zu müssen :)

    Klar, mag vll nicht optimal gelöst sein, aber dafür müssen wir "Hobbyentwickler" uns nicht damit rumärgern und uns sowas erst selbst schreiben etc.
  • @LEWA: Ja, dass muss ich mir mal anschauen. Vor Studio habe ich das immer so gemacht, also externes includet. Studio lagert die Sachen von sich aus schon aus, was ich durchaus gut finde. Nur was es damit macht, ist etwas befremdlich. Ebenso, dass ich keine (offensichtliche) Möglichkeit habe, dieses Verhalten mit einem Schalter in den Einstellungen zu ändern.

    @Atomicmaster: Ich bin ja durchaus ein Fan von GM und sogar von GMS. Man kann damit relativ einfach viele, sehr individuelle Sachen machen. Ich mochte die Grundlogik in GM schon immer und finde es angenehmer als in anderen Entwicklungsumgebungen die ich so kenne. Aber manchmal, wenn ich über solche Probleme stolpere, ärgert es mich. Ich will vor allem kleinere Dateien am Ende haben. Mein Projekt soll hochauflösende Bilder zeigen, aber die EXE (und ich will eigentlich alles in einer EXE haben) sollte möglichst klein sein. Genau hier versagt GM leider.

    Nun ja, wenn ich mal wieder etwas mehr Zeit dafür habe, werde ich die Möglichkeiten ausloten. Danke dafür. Hätte nicht mehr damit gerechnet, dass jemand auf die Frage anspringt. :D
    Byte GameMaker Magazin - Online Zeitschrift für Spieleentwickler