aufrufe von SetRenderState minimieren

DEvent

Hallo
habe ein bisschen mit dem oben genanntem thema rumexperementiert.
ich hab eine singleton klasse gebaut, die einen hash_map hatte, die die render state speichert. wenn man dann ein render state setzen will, überprüft die klasse den status im hash und falls er von dem zu setzendem state nicht übereinstimmt, wird SetRenderState aufgerufen.
( tests immer mit D3DRS_FILLMODE, D3DFILL_WIREFRAME )
bei 100.000 aufrufen gibt das folgende zeiten:
und ohne diese klasse, also direkt SetRenderState() ergibt das:

Klasse     Direkt
0,6011     0,0216
0,5958     0,023
0,5522     0,022
0,5342     0,0222

also seht viel schneller.
also hab ich die klasse vereinfacht:
in einer variable speichert sie den render state und falls man einen neuen status setzen will, dann überprüft die klasse den alten wert ( also wie oben nur jetzt statt einem hash_map eine extra attribut ).
die zeiten bei 10.000.000 :
wenn man normal SetRenderState aufruft:

Klasse      Direkt
2,3674      3,3822
2,6541      3,4451
2,8141      3,2714
2,7269      3,4652

also schon gut 1 sec weniger. Aber das ist ja bei 10.000.000 aufrufen ! bei einer kleinen anzahl ist der unterschied = 0. Lohnt es sich dann überhaupt so eine guard klasse zu bauen? oder war jetzt D3DFILLMODE schlecht gewählt und bei anderen RenderStates wird der unterschied viel grösser ?

rapso

normalerweise ruft man setrenderstate aus einem statemanager nicht auf, wenn etwas gesetzt wird, was von dem aktuall gesetzten unterschiedlich ist, sondern speichert sich in einer extra table was aktuall zu setzen ist (man hat noch ne liste was aktuell gesetzt ist) und erst bei einem renderaufruf (z.b. drawindexprimitiv) setzt man alles, was zum vorherigen status unterschiedlich ist.

das macht man deswegen, weil es manchmal vorkommt, dass jemand 'versucht' nach seinem renderaufruf etwas zurückzusetzen auf den standard wert. z.B.

setwireframemode
render
setbacktofillmode

wenn das mehrmals gemacht wird, reicht es ja nur einmal auf wireframe zusetzen und vielleicht erst wenn ein objekt wirklich mit fillmode gezeichnet wird, das zurücksetzen zu übernehmen.

zu deiner hashmap:
würde es nicht perfomanter sein, wenn du einen vector hast? die ganzen renderstates sind doch enumeriert, sollte doch fixer sein drauf zuzugreifen.
ich weiß zwar nicht wie groß deine hashmap ist, aber eigentlich gibt es nicht dermassen viele renderstates, vielleicht wäre da sogar ne map eventuell schneller.

rapso->greets();

TGGC

So wie ich das sehe, hat er selbst schon festgestellt, das die Hash-map lahm ist. Das würde für mich auch nicht unbedingt Sinn machen.

Ich frage mich allerdings ob so ein "Trockentest" (es wird ja offensichtlich nix gerendert) überhaupt aussagefähig ist? Und dann auch nur mit einem speziellen State, den man normal nie setzt.

Bye, TGGC (Hast du's drauf?)

DEvent

ahja, das macht auch mehr sinn, rapso
das wusst ich vorher nicht
thx

rapso

dazu gibt es auch ne art demo bei dem Dx9SDK.

rapso->greets();