spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

So wie du willst, sollte das funktionieren. Habe das auch mal so gemacht.

Hast du aber auch alle Matrizen schön multipliziert? (World*View*Proj)
Dann das ganze Ding übergeben an den Shader und das läuft.

Zitat

D3DFVF_XYZRHW gerendert. Dieser weg ist mir aber nciht performant genug, deswegene wollte ich einen etwas abgeänderten weg über D3DFVF_XYZ gehen.

Afaik ist die erste Version schneller. Bin mir jetzt nicht mehr ganz sicher, aber ich habe glaube ich das mal getestet und gemerkt, dass es schneller ist.
Aber auch wenn nicht, wirst du nicht viel rausholen können.

Zitat von »"unsigned long"«

drakon
doch da kann man einiges mit rausholen. Bei den RHWs muss man immer locken bevor man sie verschiebt, bei den non-RHWs transformiert man einfach die Matrix, was bei mehreren dutzend Vertices ordentlich performance rausholt.

Jo, aber das sind ja Sprites, die unabhängig von einander sind. Und er wird ja kaum für jedes Sprite einen eigenen VB haben, und daher muss er sowieso alles nochmal füllen.
Und da bringt der Shader auch nicht sehr viel. (Habe es mal getestet, indem ich das per Instancing + Shader gelöst habe, dass der Shader mir die Vertices transformiert für jedes Sprite einzeln). Am Schluss ist es drauf rausgelaufen, dass beides in etwa gelich schnell ist. Und manchmal das einte, manchmal das andere schneller ist.

Man könnte aber mehr sparen, indem man hald einschränkungen in der Rotation macht, dann kann man Sprites rendern und mit nur einem Vektor die Position an den Shader übergeben und dann ist das ganze natürlich viel fixer. (ev. noch Rotation in Z übergeben). Aber wenn man die gleiche Funktionaltität haben will, dann kommts etwa auf s'gleiche raus.

EDIT:
Ich kann mich irren, aber ich habe sonst keine bessere/schnellere Möglichkeit gefunden.
Also wenn du noch einen Tipp hast, nur raus damit.

Zitat von »"TrommlBomml"«

Zitat von »"drakon"«

jo, aber das sind ja Sprites, die unabhängig von einander sind. Und er wird ja kaum für jedes Sprite einen eigenen VB haben, und daher muss er sowieso alles nochmal füllen.

doch hab ich, pro sprite 1 vb. das einzige, wo ich mehrere vertexbuffer sparen könnte wäre alle sprites die ich render in einen packen und nach texturen sortieren und dann stückweise rendern. meinst du das?

Jop. Genau das meine ich. Wobei du aber mit deiner Variante schauen musst, wenn du z.B ein Partikelsystem hast.
Dann solltest du nicht diesselbe Sprite Klasse verwenden.

Jetzt ist hald nur die Frage, was performanter ist. Den Wenn du z.B viele Partikel hast diese entweder in einen VB füllen (jedes Frame) oder hald, wie du es machst für jeden Partikel einen VB. Ich würde mal so spontan auf ersteres tippen.
Da kommt man um einen direkten Vergleich wahrscheinlich nicht drum herum. Wobei SetStreamSource schon recht teuer ist und das einmalige locken + füllen im Vergleich zu ständigen SetStreamSource wahrscheinlich kaum noch was ausmacht.