Hallo,
meine Frage ist mal ne ganz kurze: ist es möglich, herauszufinden, wieviel VRAM belegt/frei ist?

Danke,
Martok

_________________
Gott sei Dank bin ich Atheist!

Darauf gibt es eine einfache Antwort.

Nein.

Das ist leider nicht möglich. Wozu brauchst du es denn?

Für das Lemmings-Projekt im Delphi-Forum. Es gab dort Diskussionen, ob man die komplette Map in den Ram kriegt, und ich würde gerne ein paar Zahlen haben. Aber eigentlich sollte mit Texturkompression einiges machbar sein, oder? Also große freie Flächen sollten doch einigermaßen "wegfallen"?
Meine Rechnung ist z.b. 4096*4096*4byte=67MB, -x% Kompression. Nun wüsste ich gerne, wei groß denn das Ergebnis ist. Es würde also eigentlich reichen, wenn ich wüsste, wie groß eine Textur gepackt im VRam ist.

Kannst du mir da vielleicht helfen?

_________________
Gott sei Dank bin ich Atheist!

Hört sich vielleicht abstrus an, aber könnte man nicht versuchen, so viele VBOs im VRAM zu erzeugen, bis kein Platz mehr ist und dadurch den verbrauchten Platz zu bestimmen. Aber wahrscheinlich wird dann einfach in den Haupttspeicher gespeichert...

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

La_boda: Ja mit deiner Vermutung wirst du recht haben. Er benutzt dann einfach den Hauptspeicher. Nvidia unterstützt VBOs auch schon auf einer TNT2. Dort ist es aber eher nur ein Wrapper für VertexArrays, da die Karte nicht mal in der Lage ist Vertexdaten im Speicher abzulegen.

Martok: Aha. da kommen wir der Sache doch schon näher. Also um heraus zu finden ob eine Textur so erstellt werden konnte gibt es sogenannte Proxy objekte. Das ist ein spezielles Target mit welche du ganz normal deine Textur erstellen kannst und wenn alles geklappt hat, dann bekommst du das mit. Weiß aber gerade nicht mehr so genau wie. Aber ich würde sowieso empfehlen, dass du darauf einige kleineren Texturen machst. Bei Bergen alleine schon mal deswegen um Lücken (Himmel) zwischen Hügeln aussparen zu können.

Zur Kompression. Die Kompression bei OpenGL (s3tc) ist immer fix. Diese benutzt also immer ein und den selben Speicher. DXT1 mit Alpha ist das Verhältniss 8:1. Ohne 6:1. Und bei DXT3 und DXT5 ist es jeweils 4:1. Also sparst du bei DXT5 ein Viertel. Allerdings solltest du dabei auch bedenken, dass durch die Kompression deine Farben verändert werden. Also wenn du detailierte Informationen in deinem Alphakanal unterbringen möchtest, dann würde das so nicht funktionieren. Der Unterschied bei den 3 Verfahren liegt jeweils im Alphakanal. DXT3 finde ich irgendwie absolut schwachsinnig.

Bedenke dabei aber auch, dass das Hochladen einer Textur so um ein vielfaches Länger dauert, da diese Komprimiert werden muss. Je nach System ist das ein nicht zu unterschätzender Faktor.

Link zu DXT1.
http://www.3dcenter.org/artikel/3dc/index5.php

Danke dir für die interessanten Infos. Jetzt bin ich zwar ratloser als vorher, aber naja...

Mal sehen, was man da machen kann.

_________________
Gott sei Dank bin ich Atheist!

Mit anderen Worten. Ich denke nicht dass du die Kompression benutzen kannst, da diese immer fix ist. Also werden auch leere bereiche mit einer festen Größe komprimiert. Außerdem dürfte dies zur Laufzeit ein bisschen länger dauern. Also das Komprimieren. Und es ist eine verlustbehaftete Kompression. Es kann sein, dass du harte Artefakte sehen wirst. Je nach Stelle im Bild.

Von daher denke ich, dass du selber ein bisschen reichlich arbeit da rein stecken musst. Und zwar in dem du deine Map in kleinere Blöck zerlegst.

Ich würde es so gestalten. Ich mache mir ein Programm in welchem ich ein Bild laden kann. Primär könnte ich darauf gleich einen Leveleditor aufbauen.
Dieses Bild würde ich dann in einzelne kleine Teilbereiche zerlegen. Der Algorithmus für so etwas ist nicht unbedingt das Einfachste aber auch nicht unbedingt schwer. Die einfachste Möglichkeit keit wäre du unterteilst das Bild in 32x32 Pixel große virtuelle Blöcke und die die gefüllt sind kopierst du immer Stück für Stück in eine Textur. Und zwar eine 512x512 große. Damit bekommst du 256 Blöcke in eine Textur. Du musst dir dann nur noch ablegen wo sich dieser Block auf deiner Map und wo er sich in den Texturen befunden hat und damit würdest du dann nur noch bereiche als texturen haben die auch tatsächlich gefüllt wären. Als Optimierung könnte man die einzelnen Blöcke zu Größeren zusammenfassen. Wenn du jetzt Daten verändern wolltest müsstest du das Mittels des Managers die unterschiedlichen Texturen verändern. Also am sinnvollsten wäre es, wenn dieser Manager die Texturen verändern würde. Dann müsstest du dich außerhalb nicht mit den einzelnen Teilen rumplagen.

Mit den entsprechenden Informationen wäre es dann auch ein leichtes die Karte dann noch zu rendern.

Und so hätte man dann nur noch die Texturteile die auch tatsächlich benutz würden. Und kann aus dem eigentlich Programm sich ganz aufs Texturen laden beschränken. Man muss dann keinen großen Aufwand mehr betreiben. Das ist etwas wie ich es lösen würde. Programmiere aber schon ein paar Jahre beruflich. Das sollte man dabei aber auch nicht unterschätzen.

ich hab das net so janz verstanden ^^ aber ich versuche mal wiederzugeben, wie ich das machen würde:

die textur liegt sagen wir im format 2048*1024 vor, jetzt wird diese in 32er blöcke unterteilt (denke das sollte gehen Oo)
die textur kann dann ja so vom editor abgespeichert werden. ich würde dann die koordinaten in den dateinamen setzen, zB:

x0y0 wäre dann der block oben links.

blöcke deren alpha kanal vollständig $00 schwarz ist werden einfach nicht gespeichert.

beim laden der map werden dann die dateien ausgelesen und in ein 2d array abgelegt, wobei der dateiname eben
nach dem schema x?y? geparst wird.

dann wird beim zeichnen geprüft welche felder sichtbar sind und diese werden gezeichnet (wenn eine reihe felder über den rand rausschaut sehe ich das nicht als sonderlich dramatisch an)

die kollisionserkennung erstpart dann schon fast die verwendung von bounding boxes, da 32*32 oder 64*64 pixel oder was auch immer nicht sonderlich groß ist, also prüft man die lemminge, ob sie mit einem dieser quadrate kollidieren und setzt dann in diesem die pixelkollision an (kleines bissl mathematik, aber sicherlich kein ding)

mfg

Ja. So in etwa habe ich mir das gedacht.

Aber ich möchte die große Textur nicht in viele 32x32er zerschneiden. Sondern in Blöcke 32x32 und diese dann in eine 512x512 große Textur packen. Damit ich keine inflationäre Zunahme an Texturen habe. Evtl könnte man die Letzte dann von der Größe her auch anpassen, damit nicht zu viel Verlust entsteht. Du brauchst dann auf jeden Fall eine definition aller Teile. Also die Koordinaten an denen sich sich im Bild befunden haben und deren Texturkoordinaten.

Wobei ich pesönlich auch ungern ein Array benutzen würde. Das raubt nur Flexibilität. Das würde vorraussetzen, dass die Blöcke immer ein und die selbe Größe haben müssen. Wenn man den Algorithmus später optimieren möchten und einige zusammenhängende Teile zu einem großen Teil zusammenfassen möchte, dann hätte man mit einem doch ein leichtes Problem. Von daher würde ich eher für eine Liste. Wobei man die Liste natürlich nicht so schön eindeutig wäre. Aber eben da durch gehen und die Teile rausfinden sollte auch nicht zu schwer werden.

ich sehe das ganze im zusammenhang mit den kollisionen aber ein wenig problematischer, vor allem verstehe ich net ganz wie du das mit der 512*512 textur meinst. sagen wir mal ein bildschirm ist 640*480 groß, wir können das quad nicht größer zeichnen als die textur, bzw können schon, aber wir bekommen dann irgendwann probleme mit der pixelkollision, da man da letztenendes nur am umrechnen ist. und ich denke 640 * 480 wobei ein großer teil alpha ist, ist noch zu verkraften. aber ich maße mir net die ahnung an, die du hast lossy ^^

Ach hör auf zu schleimen. Ich helfe dir ja auch so.

Aber okay. War vielleicht ein bisschen umständlich ausgedrückt. Also es ist nur EINE 512x512 sondern beliebig viele 512x512 Texturen. Das richtet sich ganz danach wie viel du brauchst. Und da würde ich die einzelnen abzuspechernden Blöcke nehmen und in die Textur packen. Und gleichzeitig würde ich eine Liste mit Blöcken führen. Also wo hat sich der Block im Bild befunden und was ist/sind dessen Textur/Texturkoordinaten.

Und die Kollision etc sehe ich jetzt nicht ganz so tragisch. In der Klasse die die einzelnen Teile verwaltet könnte man durch diverse Strukturen das schon alles beschleunigen. Aber im Endeffekt muss man sich mal überlegen um was es dabei eigentlich geht. Nehmen wir mal an wir haben 2048*1024 als Bild. Dann sind das 2048 Blöcke mit 32x32 Pixeln. Wenn man aus Optimierungszwecken da einige Blöcke zu größeren Blöcken zusammen fassen kann wäre das sicherlich nicht nachteilig für die Performance aber ich denke jede halbwegs Moderne Karte sollte das auch so schaffen. Also könnte man da auch nen Array nehmen. Zu mindest wäre der Zugriff dann indiziert. Wobei ich in dem Array dann nur Pointer auf Klasseninstanzen oder Records ablegen würde. Und zwar auf die einzelnen Einträge aus der Liste.

Beim Generieren der Texturen arbeitet man eh in einer verschachtelten Schleife und somit würden dann so oder so benachbarte Blöcke auch benachbart in der Textur landen. Dadurch hätte man so fast auch schon eine Sortierung nach Texturen. Was die Sache mit dem Rendern auch schon mal beschleunigen könnte.

oder man nimmt gleich größere blöcke ^^ ich habe auch überlegt, ob man nicht einfach die boundingboxes im editor berechnen und diese speichern kann (eigentlich die idee von martok) das wäre garnet mal so verkehrt, nur dass diese halt net aus 2er potenzen bestehen.

Na ja. Der Witz ist ja, dass man so Speicher spart. Deswegen zerlegt man das ja erst in kleinere Blöcke. Wenn das Bild zu 50% aus leeren Bereichen besteht, dann macht es schon Sinn diese wegzulassen. Aber im Endeffekt muss man eh erst mal sehen ob das praktikabel ist.

ich verstehe nur net ganz was der unterschied zwischen meiner idee und deiner ist Oo

Okay. Wenn ich ehrlich bin habe deine gerade auch nicht so ganz verstanden.