2016-04-03 12 views
1

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?

Antwort

1

Eigentlich ist TextureAtlas der beste Weg, um viele Bilder zu speichern (klein oder nicht) und zum Glück muss die TextureAtlas-Instanz nicht auf eine statische Weise erstellt werden.

Werfen Sie einen Blick auf

addRegion(java.lang.String name, Texture texture, int x, int y, int width, int height) 

TextureAtlas'es Methode. Es ermöglicht den Atlas dynamisch zu erstellen.

Also, was Sie tun sollen, ist leer Atlas erstellen

TextureAtlas atlas = new TextureAtlas(); 

dann Ihre Bilder in einer Art Schleife

for(Texture texture : yourTexturesCollection) 
     atlas.addRegion(...); 
hinzufügen

dann können Sie Ihren Atlas verwenden, indem findRegion oder andere Methode verwendet (Werfen Sie einen Blick auf Referenz)


Beachten Sie, dass für Android-Geräte Es wird empfohlen, nicht größeren Atlas als 2048 x 2048px zu verwenden.

Für eine andere Art von Geräten (wie Dekstop) kann dieser Wert ein anderer sein (normalerweise größer). Es ist nicht LibGDX Limit, sondern OpenGL!

+0

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. –

+0

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. –

+0

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" –