spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hmm, und dadurch das du die Dreiecke etc alles cullst bzw so anpasst das niemals 2 Pixel übereiander liegen, ist es auch wurscht in welcher reihenfolge du renderst. Nur blöd ist dann ja, das man bei jedem male wenn sich was in der Szene ändert, z.b. man einen neuen buffer erstellt, dass man wieder einen neuen Buffer erstellen muss und ihn wieder komplett mit den Daten füttern muss.

Darf ich mal eine Demo von dir haben, welche du mit GUI Elementen voll gestopft hast? würde mal gern sehen wie das läuft, ob es schnell genug ist etc.

4000 Quads, sowas ist niemals gut!

Da muss man ja schon an Quadtrees etc denken. Aber tut sich die Windoof API dabei nicht genauso schwer? Wenn ich Notepad vollstopfe mit Buchstaben dauaert der Seitenaufbau beim Scrollen auch seine Zeit.
Zumindest bei XP war das noch so, bei Vista läuft das ganze ja sehr flott, aber da soll ja die Oberfläche mit DX10 gerendert werden, so wie ich das verstanden habe.

Was ich mich aber grad frage ist, wie du die Transparenz hinbekommen hast? Also bei dir liegen ja niemals 2 Dreiecke übereinander, wie kommt es dann dass du runde Ecken hast? müsste da dann nichst sowas wie nen schwarzes loch entstehen, also dass an den Ecken einfach nen Bereich ist wo "Nichts" gerendert wird?

Mir ist da grad mal sone kleine Idee gekommen. Wie wäre es denn, wenn man jedes "Fenster" in einen eigenen Backbuffer rendert. Dabei werden die ganzen Controlls die ein Fenster als Children hat auch in deren Backbuffer gerendert. Also dann im prinziep ein Backbuffer in dem das Fenster selbst und deren Controlls wie Buttons etc drin sind. Anschließend rendert man die ganzen Backbuffer einfach in den HauptBackbuffer und Flipt es auf den Bildschirm. Der Vorteil wäre dann ja, das man nur das neu rendern muss, wo sich auch tatsächlich etwas verändert hat. Man hat zwar viel mehr Api Calls, dafür aber wird man kaum noch was rendern müssen.

Ich stelle mir das auch grd mal in nem Spiel vor. In 99% der Zeit die man am Spielen ist sieht die Gui immer gleich aus. Soll man nun mit jeder Frame den ganzen Kram neu rendern, oder dann doch lieber einmal alles in einen Backbuffer, und dann einfach den Backbuffer drüber kippen?

Beim rendern würde ich dann in etwa so vorgehen:
- Render das Fenster1 selbst und danach alle Controlls die in diesem Fenster1 sind in den Backbuffer des Fensters1
- Render alle Fenster im Fenster2 (also auch Fenster 1) in den Backbuffer des Fenster2.
- usw ...
- Render die Fenster die kein parent Fenster haben in den Backbuffer der GUI
- Render den GUI Backbuffer in den Haup-Backbuffer

Beim ersten Rendern würde das ganze dann schon recht lange dauern. Danach jedoch würde das ganze kaum noch Zeit in anspruch nehmen. Beispielsweise ich verschiebe Fenster1. An Fenster 1 tut sich nichts mehr, der Backbuffer wird einfach beibehalten. Der Backbuffer wird dann einfach in den Backbuffer von Fenster2 gerendert. Der Backbuffer von Fenster 2 wird einfach in den Backbuffer der GUI gerendert. Der GUI Backbuffer wird in den Haupt-Backbuffer gerendert.

Nun frage ich mich jedoch ob das denn wirklich so sinvoll ist. Ich mein, ich werde da bestimmt auf 10 RenderTargets kommen, und dann immer schön durch und durch zu rendern, ich weiß halt net :/

Ich habe zwar noch nie wirklich viel mit der WinApi gemacht, außer vllt ein paar Fenster erstellt mit Buttons und Comboboxen, aber baut nicht Windows selbst auf ein ähnliches prinziep auf. Ich mein, dort hat jedes Fenster ja auch einen "Context" in dem die ganzen Controlls gezeichnet werden?

Habt ihr was dagegen wenn ich nen neues Thema aufmache, denn das verfehlt ja grad nen wenig die Überschrift

Dachte man kann inzwischen davon ausgehen das RenderToTexture jede GraKa unterstützt :/

Jetzt bin ich nochmehr verrwirt, auf was soll ich denn nu aufsetzen. Ich habe mal in CEGUI geschaut, und die benutzen recht viele RenderTargets.