OpenGL Menü

[Chrisel]

Hallo alle zusammen,
ich will mit OpenGL ein kleines Spiel programmieren und wie in bekannten Strategie-Spielen eine art Tastleiste zeichnen lassen auf der einige Variablen stehen. Das zeichnen lassen ist auch kein problem eigentlich aber leider sieht es bei mir immoment nur gut aus weil es auf meinen Bildschirm angepasst wurde. Ich zeichne einfach ein Quadrat das bei meinem Bildschirm im Vollbildmodus immer richtig aussieht aber bei anderen Bildschirmauflösungen nicht mehr.
Meine Frage ist wie ich bewerkstelligen kann das mein Quadrat genau am oberen linken rand anfängt und auf der anderen seite wieder aufhört egal wie die bildschirmeinstellung ist?

Vielen Dank für antworten
Viele Grüße
Chrisel

[Hancock]

Wie zeichnest du denn das Menü?
Also bei meine 3D Kentnissen ist der Backbuffer auf 1.0fx1.0f normalisiert, da sollte solch eine Anpassung automatisch passieren.

[[GP] mino]

wirst dir einen bruch heben, mit einfachem opengl ein spiel zu implementieren. nimm lieber das framework OpenSceneGraph, welches OpenGL benutzt. such hier nach dem windows installer.

das ganze ist sehr einfach zu installieren und in dein projekt einzubinden. beispiele zu OSG findest zu hauf im web, sowie in den beispielanwendungen, die mit dem installer mitgegeben werden.

das was du mit taskleiste meinst, ist das sg. HUD (head up display). such dazu in google nach "osg hud".

[Chrisel]

Jein... also es macht Beispielsweise einen unterschied ob man 16:10 bildschirmauflösung hat oder 16:9. Und in meinem Programm werden, aus welchen gründen auch immer, keine objekte gezeichnet die sich auf der z=0 ebene befinden. deshalb muss alles ein stückchen weggerückt werden und damit ist das 1.0fx1.0f verhälnis zerstört
immoment zeichne ich das menü mit glbegin(GL_QUADS); und habe die koordinaten der quadrate manuell angepasst sodass alles stimmt.

[Hancock]

Du setzt doch normaerweise irgendwo eine Field of View Matrix, dort musst du doch sowieso das Seitenverhältnis einprogrammieren.
Mit 1.0fx1.0f mein ich die normalisierten Koordinaten, die dein Bildschirm darstellt. Wenn du ein Quad mit -1,-1x1,1 als Eckpunkte zeichnest, sollte es ja den ganzen Bildschirm füllen.
Wenn du jetzt dein Menü zeichnest, speicherst du dir irgendwo das Seitenverhältnis und machst dann beispielsweise jede y-Koordinate/Seitenverhältnis, dann sollte dein Menü proportional richtig angezeigt werden (und über die ganze Breite).

[daemon777]

Also Problem Nr. 1:
Objekte verschwinden wenn sie der Kamera zu Nahe kommen. Jedenfalls habe ich das so verstanden. Da hilft es sich mal näher mit Clipping zu beschäftigen (Stichwort Near-Distance-Clipping).


Mein Ansatz für ein Menü sähe so aus:
- erst alles Andere zeichnen
- Orthogonale Projektion ein
- Depht-Testing ausschalten
- Menü als Textur auf Quads malen oder Quad mit Textur als Hintergrund wählen + Text im Vordergrund
- nicht vergessen die Projektion und Z-Buffer wieder umzuschalten

Auf die Art und Weise würde das Menü ja intern immer gleich berechnet werden und bei richtig eingstelltem Viewport müsste alles immer gleich gezeichnet werden. Die Bildschirmeinstellungen wären dann ziemlich wurscht.
Stimmt denn bei dir die Viewport-Transformation?

Alternativ könnte man sicher auch das Menü in ein Screen-Aligned-Quad rendern und dann mit der eigentlich Szene per Shader verknüpfen. Das kommt mir aber jetzt grad nu so in den Sinn. Keine Ahnung ob das Sinn machen würde.

[toxn]

Der Ansatz von daemon777 klingt plausibel. Du kannst aber auch einfach eine schon vorhandene Lib nehmen.
Beispielsweise GiGi

[Hancock]

@daemon777:
Am schnellsten ist es, wenn man von Vorne nach hinten zeichnet, weil dann die Grafikkarte vorzeitig clippen kann.
Depth testing würde ich anlassen, das ermöglicht dir, wie mit Fenstern zu arbeiten, die sich gegenseitig überlagern.
http://www.opengl.org/resources/faq/...epthbuffer.htm
Das erklärt auch, warum du bei z=0 nichts siehst, weil es nicht geht^^.

[daemon777]

Natürlich beschleunigt Early-Z-Clipping eine große Graphikanwendung erheblich aber die paar Fenster eines Menüs machen wohl eher keinen Unterschied

Aber der Tip mit dem Front-To-Back ist natürlich interessant für diejenigen, die das noch nicht gehört haben und ein größeres Projekt durchführen wollen. Schließlich war früher ja genau die umgekehrte Strategie zielführend.

Aber ich frage mich gerade ein bisschen wie du das Ganze denn machen willst wenn Depth testing immer noch an ist. Das mit den multiplen Fenstern ist natürlich richtig: ohne Z-Buffer geht das irgendwie schlecht oder man muss eben einen ganz anderen Weg gehen. Aber angenommen die Near-Clipping-Plane ist bei 0,1. Dann zeichne ich die Panels eben kurz vor diesem Bereich also zB 0,1. Was machst du jetzt wenn eines der Objekte der Szene plötzlich zwischen Clipping-Plane und Panel kommt? Dann würde man ja theoretisch störende Effekte bekommen.

Btw: was passiert eigtl mit einem Objekt, dass sich genau auf der Cliping-Plane befindet? Wird das auch schon abgeschnitten?

[Hancock]

Für das mit dem Objekt zu weit vorne, da gibts doch ne Funktion: glSetDepthRange oder so.
Ich glaub, dass direkt auf der Plane wirds noch angezeigt, aber es könnte zu Artefakte kommen, float und so...
Front-To-Back war schon seit Source schneller als Back-To-Front.

Dir ist hoffentlich bewusst, dass bei vielen Strategiespielen (z.B. Supreme Commander) das Menü ca. 1/4 des Bildschirmes belegt, wenn du das nun als erstes zeichnest sparst du dir durch early z-clipping gleich mal 1/4 aller PS Berechnungen, das ist viel.

[daemon777]

An Strategie-Spiele habe ich bisher tatsächlich noch nicht gedacht. Da wird es wohl wirklich einen großen Unterschied machen. Eventuell sogar auch bei Rollenspielen wobei der Anteil hier natürlich schon wieder geringer ist. Jedenfalls Grund genug da mal drüber nachzudenken

glSetDepthRange werde ich mir mal anschauen sobald ich selber so ein Menü mal ausprobieren möchte ^^

Alternativ könnte man (wenn man eh schon auf orthogonale Projektion umschaltet) ja auch die Near-Distanz-Plane verschieben. Also so, dass sich das Menü in einem Bereich befindet in dem nichts Anderes gezeichnet werden kann. Naja darüber habe ich aber ehrlich gesagt noch nciht wirklich nachgedacht.