man zerteile das bild in 128er blöcke (zb) speichert diese als einzelne tgas ab und benennt sie nach ihrere posisition und zwar net nach pixeln sondern nach dem raster. komplett leere werden weggelassen. dann werden immer nur so viele blöcke gezeichnet wie annähernd sichtbar sind. wobei nicht vorhandene (also leere die garnet erst gespeichert wurden) einfach ignoriert werden.

aber wenn man das zu groß wählt kann das sein, dass eben net so viel wegfällt, ich hatte mir mal so ein algo für interpolationen gebastelt, der hätte sowas glaube ich können. aber das wieder zu laden wäre auch ne arbeit

Genau das wollte ich auch grad schreiben.

Ein Problem haben wir natürlich: wenn wir ein Höhlen-Level haben, sind große Bereiche belegt und nur relativ kleine Bereiche frei, die Einsparung wäre dann nicht so groß wie erwartet, allerdings wäre der Verwaltungsaufwand höher. Ich denke mal, da muss man nochmal gaanz scharf drüber nachdenken.

Das Problem ist ja auch, dass wir zerstörbares Terrain haben. Wenn aber ein "Schaden" mehrere dieser Teile betrifft, artet das in eine sehr komplizierte Rechnerei aus, da man zu jedem Pixel gucken muss, "wo es ist". Also nicht einfach (x,y):= 0, sondern eine Rechnung für jedes Pixel, um die Position in der zusammengefassten Map zu erhalten. Schneller wird das nicht unbedingt

_________________
Gott sei Dank bin ich Atheist!

stimmt darüber hab ich noch garnet nachgedacht, hm das ist wieder ein problem

Das stimmt natürlich der Schaden muss umständlicher auf diese Teile aufgeteilt werden. Aber ich denke mal den Schaden an der Grenze abzubrechen und an einem anderen Teil wieder aufflammen zu lassen sollte durchaus möglich sein. Klar ist es mehr Aufwand. Aber nicht so viel wie du das gerade denknst. Du musst defintiv nicht für jedes Pixel nachsehen! Du hast Blöcke in denen sich nicht willenlose Pixel befinden sondern eine Gruppe von 128x128 (oder was auch immer). Und mehr oder weniger könntest du auch deine Explosion an diese Raster anpassen und entsprechend Blockweise abarbeiten. Also geht bitte nicht davon aus ihr müsstest für jedes Pixel nachrechnen wo sich dieses befinden. Das ist unnötig kompliziert.

Seth: Diese Idee ähnelt meiner ja ziemlich. Nur mit dem Unterschied, dass ich die Teile nicht per Dateiname identifiziere sondern per eigener Definition und ich nicht so extrem viele kleine Texturen bekommen. Dadurch spare ich mir das dauernde Wechseln der Texturen.

Ich persönlich versuche die Dinge aber immer so flexibel wie Möglich zu gestalten. Um später auch einfach noch Einfluss darauf nehmen zu können ohne komplett alles ändern zu müssen. Selbst wenn das bedeuten sollte, dass ich mir mehr Aufwand mache. Das soll nicht bedeuten, dass meine Lösungen immer optimal sind. Und das bedeutet auch nicht, dass die anderen Möglichkeiten nicht funktionieren. Es ist nur mein Stil und so würde ich es machen. Seht als Idee oder und Anregung. Wie ihr das macht ist letzen Endes eure Entscheidung. Und wenn euch die ein oder andere Lösung zu umständlich oder zu kompliziert erscheint, dann macht das auch nicht. Es ist euer Programm und ihr müsst das programmieren.

Und bei den Höhlen. Sobald ihr auch nur 3 Blöcke einsparen könnt ist es doch nicht mehr nutzlos gewesen. Und auch wenn ihr gar keine einspart habt ihr wenigstens die Daten nicht größer gemacht. Also im Vergleich zu einer großen Textur ist doch alles besser?