Fenster-Clipping für ScreenGUI
- Fluid Byte
- Beiträge: 3110
- Registriert: 27.09.2006 22:06
- Wohnort: Berlin, Mitte
Fenster-Clipping für ScreenGUI
Ich bin mal wieder gerade dabei ein Interface für ein Spiel zusammenzustricken. Nun frage ich mich wie man für ein Screen GUI, basierend auf Sprite / Sprite3D, Fenster-Clipping realisieren könnte. Diese Technik sollte dann auch für Gadgets übertragbar sein. Das Einzige was mir dazu einfällt wäre alle zugehörigen Gadgets eines Fenster nicht separat zu rendern sondern auf das Ausgabesprite, nämlich das des Fensters zu zeichnen. Wenn man also mit der Maus über ein Gadget fährt oder per Mausklick dessen Funktionalität auslöst wird der aktualisierte Status des Gadgets per Start-/StopDrawing() neu auf das Sprite des Fensters gezeichnet.
Nun ist die Frage wie performant ist das und welche Alternativen gäbe es?
Nun ist die Frage wie performant ist das und welche Alternativen gäbe es?
Windows 10 Pro, 64-Bit / Outtakes | Derek
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
- Fluid Byte
- Beiträge: 3110
- Registriert: 27.09.2006 22:06
- Wohnort: Berlin, Mitte
Ich ja auch nicht, deshalb frag' ich ja. UseBuffer() war das richtige Stichwort hier. Aber wieso clippen? Nun es gibt schon ein paar Gründe wie Gadget-Animationen, Zeichenoperationen und vor allem Resizing des Fensters.Kaeru Gaman hat geschrieben:ich versteh jetzt noch nicht ganz, wie und wieso du clippen willst...
DX9 brauche ich im Moment eigentlich nicht aber damit kommen wir auf meine zweite Frage. Gibt es überhaupt Alternativen? Die Frage ist nicht nur wegen dem Subsystem interessant sondern auch weil UseBuffer() ja anscheinend nicht mit Sprite3D funktioniert.Kaeru Gaman hat geschrieben:grundsätzlich ist es soweit ich gehört habe wohl so, dass UseBuffer mit DX9 subsystem extrem inperformanter ist als mit DX7 subsystem.
Windows 10 Pro, 64-Bit / Outtakes | Derek
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
> DX9 brauche ich ... nicht aber ... Sprite3D Lib
> Nun es gibt schon ein paar Gründe wie Gadget-Animationen, Zeichenoperationen und vor allem Resizing des Fensters.
hm... *grübel*
also, wenn du gerne Sprite3D verwenden willst, und eventuell DX9,
und es sich um dein eigenes Game handelt, nicht um ein GameMaker-system...
... dann würde ich von vorne herein so konzipieren, dass niemals geclippt werden braucht, schon aus performancegründen.
> Nun es gibt schon ein paar Gründe wie Gadget-Animationen, Zeichenoperationen und vor allem Resizing des Fensters.
hm... *grübel*
also, wenn du gerne Sprite3D verwenden willst, und eventuell DX9,
und es sich um dein eigenes Game handelt, nicht um ein GameMaker-system...
... dann würde ich von vorne herein so konzipieren, dass niemals geclippt werden braucht, schon aus performancegründen.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
- Fluid Byte
- Beiträge: 3110
- Registriert: 27.09.2006 22:06
- Wohnort: Berlin, Mitte
Warum hast du so zitiert? Ist das ein Widerspruch?Kaeru Gaman hat geschrieben:> DX9 brauche ich ... nicht aber ... Sprite3D Lib
Grundsätzlich bin ich voll deiner Meinung. Wenn wir uns aber mal auf das Verkleinern/Vergrößern von Fenstern beschränken wie sollte das denn ohne Clipping gelöst werden?Kaeru Gaman hat geschrieben:... dann würde ich von vorne herein so konzipieren, dass niemals geclippt werden braucht, schon aus performancegründen.
Windows 10 Pro, 64-Bit / Outtakes | Derek
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
> Warum hast du so zitiert? Ist das ein Widerspruch?
nein.
nur um beide punkte mit reinzubekommen,
also dass du sprite3D und/oder DX9 haben willst,
also UseBuffer vermieden werden sollte.
> Grundsätzlich bin ich voll deiner Meinung.
thnx
> Wenn wir uns aber mal auf das Verkleinern/Vergrößern von Fenstern beschränken wie sollte das denn ohne Clipping gelöst werden?
ich finde, ein komplett vorbereitetes fenster zu clippen würde eh nix aussehen.
aber ClipSprite funktioniert doch, damit kann man hintergrund und rahmen auch life zusammensetzen,
direkt auf den screen malen, ohne den buffer zu ändern.
nuja...
eigentlich wäre ein fenster über nem fullscreen auch nicht resizable... öh
versteh mich richtig.
ich find das nicht schlecht, dass du dein system flexibel machen willst,
aber ich kenne spontan nur wenige games, wo ingame-fenster resizable sind,
und bei z.B. Lokomotion wird das Windows-Interface verwendet...
nein.
nur um beide punkte mit reinzubekommen,
also dass du sprite3D und/oder DX9 haben willst,
also UseBuffer vermieden werden sollte.
> Grundsätzlich bin ich voll deiner Meinung.
thnx
> Wenn wir uns aber mal auf das Verkleinern/Vergrößern von Fenstern beschränken wie sollte das denn ohne Clipping gelöst werden?
ich finde, ein komplett vorbereitetes fenster zu clippen würde eh nix aussehen.
aber ClipSprite funktioniert doch, damit kann man hintergrund und rahmen auch life zusammensetzen,
direkt auf den screen malen, ohne den buffer zu ändern.
nuja...
eigentlich wäre ein fenster über nem fullscreen auch nicht resizable... öh
versteh mich richtig.
ich find das nicht schlecht, dass du dein system flexibel machen willst,
aber ich kenne spontan nur wenige games, wo ingame-fenster resizable sind,
und bei z.B. Lokomotion wird das Windows-Interface verwendet...
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
- Fluid Byte
- Beiträge: 3110
- Registriert: 27.09.2006 22:06
- Wohnort: Berlin, Mitte
Ich geb' zu, außer meinem Paradebeispiel Steam fallen mir auch nicht allzu viele Spiele ein. Aber wie du richtig erwähnt hast soll mein System so flexibel wie möglich sein auch wenn es in naher Zukunft wohl eher Lernzwecken dienen wird. Aber is' ja nich' verboten sich weiterzubilden. 
Windows 10 Pro, 64-Bit / Outtakes | Derek
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22