spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

ganz richtig! (s.o.) Ach wird ja manchmal garnichts verändert, sondern man will nur was überprüfen (ebenfalls s.o.)

das sagt ja auch niemand.

aber was wenn du z.b. für kollisionsabfragen einfach nur die geometriedaten des modells brauchst?

wirst du da dann auch locken und diese auslesen?

Also es gibt meiner Meinung nach 2 Anwendungsgebiete:
- das Ändern des Inhalts
- das Überprüfen des Inhalts

Beim ersten Fall kann die Klasse helfen, die Lock-Zeiten zu verkürzen. Beim zweiten Fall macht eine solche Klasse den Lock sogar komplett unnötig.

ich wollte damit sagen, dass es keine gute idee ist, den buffer wann immer man will zu locken, nur weil man sich keine kopie der daten halten will.

512 MB VRAM bedeuten nicht, dass man diese gleich nutzen sollte um RAM zu sparen, eher sollte man sie so nutzen, dass möglichst wenig über den BUS muss...

außerdem hat jeder API call seinen overhead, der dir so erspart bleibt.

z.B. dazu

Zitat

Ja,aber der VB kann doch im Lock bleiben bis zum rendern,und erst wenn alle Änderungen im VB getan sind,wird eben unlock aufgerufen.

wenn du jetzt DrawPrimitive aufrufst, dann heißt das nicht, dass die GPU rendert und DrawPrimitive dann zurückkehrt.
die GPU rendert vielleicht gleich, vielleicht später weil sie grad noch was andres im sinn hat.
wenn du jetzt hergehst und nur kurz unlockst um schnell zu rendern und dann wieder lockst, dann müssen GPU und CPU andauernd aufeinander warten, was den sinn einer GPU sehr schnell zu nichte macht (gut, wer weis was der treiber macht und z.b. mit D3DLOCK_DISCARD ist das evtl. nicht so dramatisch, aber es geht ums prinzip)

außerdem kann es ja durchaus sein, dass du vertexattribute hast, die die graka zum rendern gar nicht benötigt (was weis ich; boneindex bei einem softwareskinning system), warum diese dann über den bus schicken?.

.
.
.

Zitat von »"dx sdk doku"«

Locking a static vertex buffer while the graphics processor is using the buffer can have a significant performance penalty. The lock call must wait until the graphics processor is finished reading vertex or index data from the buffer before it can return to the calling application, a significant delay. Locking and then rendering from a static buffer several times per frame also prevents the graphics processor from buffering rendering commands, since it must finish commands before returning the lock pointer. Without buffered commands, the graphics processor remains idle until after the application is finished filling the vertex buffer or index buffer and issues a rendering command.

Dennoch gilt: bei reinen Lesezugriffen, kann man sich per Kopie den Lock sparen.