Aber wenn's ohne Displaylisten läuft muss ich doch an der Stelle einen gültigen und aktiven Renderkontext haben. Oder?

Ach so und noch was: das macht man doch mit wglmakecurrent() oder?

Also einen gültigen RC musst du beim Erstellen und beim Aufrufen haben. Und wenn du beim Aufrufen nur die eigentlichen Quellen aufführst hat das nicht viel mit der Erstellung der Liste zu tun.
Wie SOS schon sagte. Schau dir mal an was bei glGenLists zurückgeliefert wird! Es kann nämlich nur sein, dass du das zum falschen Moment aufrufst.

Und ja wglMakeCurrent ist zum festlegen des aktuellen RC's. Der muss selbestverständlich vorher erstellt worden sein. Da du aber etwas ohne DL's siehst gehe dich doch mal davon aus, dass der richtig funktioniert.

Ich hätt da auch noch ein Problem mit den DisplayListen.
Mein DukesOfWar läuft recht langsam (25-30 Frames Laptop noch weniger) und da hab ich mir gedacht Displaylisten könnten helfen. Ich habe mich dazu entschlossen das gesamte zeichnen der Karte in ne DL zu speichern. das sieht ungefähr (ausm Kopf gepinselt) so aus.
Ich hab ne DL erstellt und geöffnet. Dann durchlaufe ich meine Karte und Werte den untergrund aus. Je nachdem Zeiche ich ein Quad mit der entsprechenden Textur. Am ende schliße ich die DL. Beim beenden des Programms wird die DL freigegeben.

Folgendes passierte: Beim ersten Start wear die gesammte Karte schwarz. Bei einem weiteren aufruf war sie da, aber die Framerate wär nicht höher.

Jemand ne Idee?

Code kommt sobald ich an in rankomme.[/code]

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Eine Displayliste ständig zu ändern ist sehr performance raubend. Für mich schreit das förmlich nach einem VBO (GL_ARB_vertex_buffer_object).

Die Vertex, Textur und Farbdaten der Grundfläche kannst du in ein Speicherbereich auf der Graka legen und schnell und geziehlt ändern. Also musst du nicht alles wieder komplett neu aufbauen sondern kannst die Sachen halt im Speicher der Graka verändern.

Evtl. wäre es sogar sinnvoll die Fläche mittels TriangleStrip zu renden. Geht oftmals schneller als per Quad oder andere Primitive.

Deine Bäume packst du am Anfang des Spiels inne DL und zeichnest diese dann bei Bedarf. Wenn der Rest deines Programmes recht gut optimiert wurde solltest du somit recht viel aus der Karte holen.

Für den Fall, dass die Karte keine VBO's unterstützt kannst du die Flächen entweder mittels Vertexarray (genau wie VBO nur liegt es nicht auf der Karte) oder iterativ rendern.

Was ich halt komisch finde is, dass dieses hier:


überhaupt keine performance bringt.
(DL wird gebaut wenn fenster geöffnet wird, zeigkarte läuft im OnIdle ab)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Wenn DLs nix bringen, dann liegt das definitiv am Treiber bzw. der Graka in deinem Laptop, denn Displaylisten werden vom Grafiktreiber optimiert im VRAM abgelegt. Ich gehe auch mal davon aus, dass deine Laptopgraka shared Memory benutzt, also keinen echten VRAM sondern ihre Daten im Hauptspeicher ablegt.
Dazu noch ein Treiber der Displaylisten schlecht bis gar nicht optimiert (Intel und SiS-Grakas sind für schlechte GL-Implementationen bekannt) und schon ist alles was DLs dir bringen würden zunichte gemacht. Auf halbwegs brauchbaren Grakas sollte diese Optimierung aber trotzdem einiges bringen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Das muss ja auch nicht unbedingt einen Geschwindigkeitsvorteil haben. Es kann. Das kommt ganz darauf an was der Treiber macht und was die Hardware überhaupt unterstützt.

Mein Lieblingsbeispiel eine TNT2 zum Bleistifft.
Da ist eine Displayliste genau so schnell wie ein Vertex Array oder seit neustem auch ein Vertex Buffer Object oder aber genau so schnell wie wenn man das Iterativ Rendert. Das liegt ganz einfach daran, dass die Hardware es nicht unterstützt. Wo soll denn dabei dann auch ein Geschwindigkeitsvorteil herkommen.
Auf modernen Karten hast du aber schon einen Vorteil. Von daher heißt es noch lange nicht, dasss weil bei dir nicht schneller ist, dass es bei anderen auch nicht schneller ist.

Es kommt aber in einer DL mitunter auch darauf an wie du etwas renderst. Sprich du solltest deine Grundfläche nach Möglichkeit als TriangleStrip rendern, da das das optimiereste Primitiv überhaupt ist. Und am Vertexschonensten.

Die Hütten und Burgen kannst du jeweils in eine seperate Liste packen und diese bei bedarf (beim Rendern) aufrufen. So frisst sie nur einmal Speicher und nicht mehrfach in der kompletten Karte. Das ist resourcenschonender und einen Geschwindigkeitsverlust hast du dadurch auch nicht.

Nun wirds ganz verrückt

Nach obiger aussage hab ich mir gedacht, teste doch einfach mal auf deiner Station (2500MHz 512MB RAM Radeon 9000) wenns beim Laptop (2000GHz 256MB RAM Intel-Grafik-Chip) net geht.

-----------------------Ohne DL | Mit DL
Framerate Laptop | 15-18 | 15-18
Framerate Station | 23-28 | 5-7

Wie kann sowas sein??? Ich mein das ne DL wirkungslos is, kann ich mir Vorstellen, aber das sie bremst is neu! Oder!?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Was renderst du denn genau in die DL? Also nicht den Code von Oben sondern was in glBurg etc. gerendert wird.

Ich kanns mir nur so erklären, dass du irgendwo etwas benutzt worauf der Ati Treiber gar nicht steht. Evtl nen Bug in der OpenGL Implementation. Vielleicht kannst du auch nicht alles in eine DL legen. Sondern musst das ein oder andere raus lassen.

Ich würde mal mit ein paar glErrors auf Fehler zwischenchecken - die können recht performanceraubend sein, und werden erst beim Aufruf einer Displayliste ausgelöst.
Bei einem "perfekt" programmierten OpenGL Treiber sollte eine DL sogar das schnellstmögliche Konstrukt sein, da der Treiber selbständig den performantesten Code generieren sollte (z.B. Vertexdaten in VBOs anlegen, Statechanges zusammenfassen) - der Nachteil ist, dass sie halt ziemlich statisch sind.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Hi ich hab mal eine Frage oder suche eher eine bestätigung .
Unzwar folgendes Problem: Ich hab 4 Render Kontexte für ein Editor und eine einzige Zeichenroutine läuft auch alles mit einer ausnahme DL.
Diese wird nur im ersten Kontext gezeichnet aber nicht in den anderen liegt es daran das DLs Kontext abhängig sind ? Wenn ja wäre VBO vieleicht eine alternative ?

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Jeder Renderkontext hat seinen eigenen Namespace, also einen eigenen Namensraum für Texturen- und Displayliste-IDs (uvm.). D.h. das eine DisplayListe erstmal nur in dem Kontext gültig ist in dem diese erstellt wurde.
Allerdings gibt es die Funktion wglShareLists(RC1, RC2), mit der man die Namensräume zweier Kontexte untereinander Teilen kann. Bei 4 Viewports erstellst du deine DL's also im ersten Kontext und rufst dann dreimal wglSharelists auf, wobei bei jedem Aufruf der erste Kontext als RC1 übergeben wird.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich würde mir auch überlegen, ob es wirklich notwenig ist, vier Renderkontexte aufzusetzen - wenn es eine normale TriView wie in den meisten 3D-Editoren ist, die einzelnen OpenGL Fenster also nicht separat verschoben werden können, lässt sich das Ganze doch auch relativ komfortabel in einem RC unterbringen (glScissor und glViewport lassen grüßen) - Wegfall von zeitaufwändigen Wechseln der Renderkontexte (mit zugehöriger Instabilität auf gewissen, schlecht programmierten GraKas) inklusive.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Danke erstmal für die antwort mit den Texturen wusste ich auch noch nicht, dass wäre warscheinlich dann problem nummer 2 geworden . Mit dem Kontext Sharen werde ich so machen und hier mal ein paar screenshots von der altuellen Version. Ja es lehnt stark an 3ds Max an! Ist auch das beste progg und die icons werden ausgetauscht wenn der rendermodus funktioniert. Auf http://TAK2004.no-ip.com/pic/ stell ich immer wieder neue Bilder rein diese heissen XD3DEditor[xx].jpg.

http://tak2004.no-ip.com/pic/XD3DEditor.jpg
http://tak2004.no-ip.com/pic/XD3DEditor1.jpg
http://tak2004.no-ip.com/pic/XD3DEditor2.jpg
http://tak2004.no-ip.com/pic/XD3DEditor3.jpg
http://tak2004.no-ip.com/pic/XD3DEditor4.jpg
http://tak2004.no-ip.com/pic/XD3DEditor5.jpg
http://tak2004.no-ip.com/pic/XD3DEditor6.jpg
http://tak2004.no-ip.com/pic/XD3DEditor7.jpg

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004