Ich schreibe einen Client für ein Multiplayer-Kachel-basiertes Spiel in libGDX (für Android und Desktop). Die Spielwelt besteht aus tausenden kleinen 32x32 Png-Bildern, die in einen großen rechteckigen Ansichtsbereich gezeichnet werden. Die Bilder werden bei Bedarf über die Socket-Verbindung (Netzwerk) heruntergeladen.libGDX: Beste Möglichkeit, viele kleine Bilder in LibGDX für schnelles Zeichnen zu speichern
Was ist die beste (schnellste und ressourcenschonendste) Möglichkeit, diese Bilder im "Speicher" zu speichern, damit sie bei Bedarf sehr schnell auf den Bildschirm gezeichnet werden können?
Bis jetzt habe ich einen sehr naiven Algorithmus implementiert, der jedes 32x32-Bild in eine Texture lädt und diese unbestimmt im Speicher hält. (Rein zufällig haben meine Bilder eine Größe, die eine Zweierpotenz ist.) Es scheint zu funktionieren, aber ich bin besorgt, dass dies sehr ineffizient ist und möglicherweise GPU-Ressourcen auf älteren Geräten oder etwas übersteigt.
Ich kenne den TextureAtlas, aber das scheint nur für statische Bilder zu funktionieren, die in der kompilierten Android App gepackt und gespeichert werden. Da ich meine Bilder dynamisch über das Netzwerk erhalte, glaube ich, dass dies für mich nicht funktionieren wird.
Ich habe diese libgdx SpriteBatch render to texture Post gefunden, die vorschlagen, viele kleine Bilder in einen FrameBuffer zu rendern, dann verwenden Sie dies als eine Quelle von TextureRegions. Das erscheint mir vielversprechend. Ist das eine gute Lösung? Gibt es einen besseren Weg?
Ich frage mich auch, ob das Zeichnen und Speichern meiner kleinen Bilder in einer großen Pixmap hilfreich sein könnte. Ist dies möglicherweise ein besserer Ansatz als das Zeichnen in einen FrameBuffer, wie oben beschrieben? Wie ich es aus der Dokumentation verstehe, sind Pixmaps rein speicherbasiert. Das kann ein Vorteil sein, da es wahrscheinlich keine Grafik-Ressourcen benötigt, auf der anderen Seite könnte es langsamer sein, da das Laden in eine Textur eine teure Operation ist. Gedanken dazu?
Danke, dass Sie darauf hingewiesen haben. Die Verwendung von FrameBuffers scheint einigermaßen gut zu funktionieren (dies wurde bereits getestet), dies sieht jedoch nach einer einfacheren Lösung aus. –
Nachdem ich mir den Quelltext von TextureAtlas angeschaut habe, glaube ich, dass er nichts anderes tut als meine tausenden kleinen Texturen in einem Array zu speichern.Das ist nur meine naive Implementierung, die hinter einer schönen Fassade versteckt ist :-) Ich werde weiterhin meine FrameBuffer-Implementierung verwenden, weil dadurch die Anzahl der Texturobjekte drastisch reduziert wird. –
Eigentlich ist es nicht :) der Grund für die Verwendung von Texturatlas ist, nur eine große Textur zu verwenden - wenn Sie Dinge rendern, ist das erste, was Sie tun müssen, Grafik an GPU zu senden, was sich auf die Leistung auswirkt. Mit Texturatlas senden Sie die Textur nur einmal. Google für SpriteBatchs "render calls" –