spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wieso benutzt du dafür nicht einfach shapes? Die sind einfach zu "schreiben" und flexibel sind sie auch noch...

shapes sind ne gute idee. wenn du allerdings jedes frame 200 pixelgenaue änderung vornehmen musst ist das auch nicht schneller und kostet mehr speicher als ein bitmap.
das ist alles abhängig von der verwendung. wir(zumindest ich) haben ja keine ahnung was du überhaupt willst
du sprichst von spielen und von mathematischen applikationen...

brauchst du es denn unbedingt pixelgenau? pro rendervorgang sperren und per cpu füllen ist nicht gerade die feine art, da kannst du dir auch die hardwarebeschleunigugn (grafikkarte) klemmen und gutes altes directX 7 machen.
es wird im 2d bereich alles auf spritebasis gemacht. je genauer du uns beschreibst, wie es genau aufzubauen ist, umso eher können wir dir eine performante lösung vorschlagen

Zitat von »"TrommlBomml"«

brauchst du es denn unbedingt pixelgenau? pro rendervorgang sperren und per cpu füllen ist nicht gerade die feine art, da kannst du dir auch die hardwarebeschleunigugn (grafikkarte) klemmen und gutes altes directX 7 machen.

Kann ich so nicht bestätigen ;-). Arbeite hier sehr viel mit verteilter Arbeit für CPU und GPU und komme damit auf gute 3000 FPS bei 1920x1200er Auflösung. Als ich das Ganze nur GPU-seitig gelöst hatte, kreuchte ich irgendwie bei 1200 rum.
Man sollte also nicht denken, die GPU sei das unerschöfpliche Allheilmittel ;-), man muss sinnvoll auf beide verteilen und mit mehreren Threads und Streams geht das auch wunderbar ohne Blockaden zu erzeugen.

In seinem Fall wäre die beste Lösung wohl wirklich die Textur zu aktualisieren und auf CPU-seite halt eine kleine Canvas-Klasse mit Clear(Color) und Line(X,Y,X2,Y2,Color) zu schreiben. Brensenham düfte da bei dünnen Linien deutlich schneller sein als der GPU-overhead, zumindest war's bei uns so. Wenn man nur alle X Frames aktualisiert, sowieso.

LG
Alyx

Zitat von »"Alyx"«

Kann ich so nicht bestätigen ;-). Arbeite hier sehr viel mit verteilter Arbeit für CPU und GPU und komme damit auf gute 3000 FPS bei 1920x1200er Auflösung. Als ich das Ganze nur GPU-seitig gelöst hatte, kreuchte ich irgendwie bei 1200 rum.

Ich wäre bei Frameraten der Größenordnung sehr vorsichtig was ein Urteil über die Geschwindigkeit angeht.
Entweder man betrachtet die Frametime, statt der Framerate oder man macht Messungen nur im praktisch genutzten Bereich von so 60-30fps.

Hier ein Artikel zum Thema Frametime versus Framerate.

Ich meinte schon konstante Frametimes ;-).
Um's genauer zu definieren: clientseitiges Clipping der UI-Elemente und clientseitige Transformation sowie weiteres Clipping der von ihnen zur 2D-Ausgabe erzeugten Dreiecke Vs. rein GPU-seitig clippen/transformieren.
Denn besser 150 Microsekunden CPU und 150 Microsekunden GPU-Zeit pro Frame als 0 CPU-Zeit und 225 GPU-Zeit.

Um mal zum Thema zurück zu kehren: Wenn er die 2D-Grafik in einem Thread aktualisiert und diese bei jedem Update in dem Direct3D-Thread rüber schaufelt sollte es... sofern er sie nicht gerade jedes Frame aktualsiert... definitiv schneller sein als jede rein GPU-seitige Lösung.

LG
Alyx