Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

11

02.10.2015, 13:12

ist glBegin()/glEnd() nur veraltet oder auch deprecated?
In modernem OpenGL (i.e. Core Profile) ist es nicht mal mehr verfügbar. In allen anderen Fällen ist es deprecated. Schneller ist es ebenfalls nicht, sondern das komplette Gegenteil, es ist durch die vielen Calls sau langsam.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

SlinDev

Treue Seele

Beiträge: 142

Wohnort: Lübeck

Beruf: Programmierer

  • Private Nachricht senden

12

04.10.2015, 18:04

Ob du nun durch deine Daten durchgehst und glVertex aufrufst oder sie in einen Buffer kopierst ist ja erstmal für die Geschwindigkeit kein wirklicher Unterschied.
Der Unterschied liegt allerdings darin wie dein Grafiktreiber damit umgeht und das ist im Fall von Vertexbuffern VIEL schneller.
Wobei das natürlich auch von der Anzahl deiner Vertices abhängig ist. Wenn es eh nur 100 sind ist es ziemlich egal, wenn es 1mio sind kommst du mit glBegin/glEnd nicht weit.
Auch ist mir deine OpenGL 2.1 Einschränkung nicht so ganz klar. Es gibt doch quasi keine Hardware mehr die nicht mindestens 3.2 kann!?

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

13

04.10.2015, 20:59

Ob du nun durch deine Daten durchgehst und glVertex aufrufst oder sie in einen Buffer kopierst ist ja erstmal für die Geschwindigkeit kein wirklicher Unterschied.
Doch, genau da liegt der Geschwindigkeitsunterschied, denn glVertex ist saumäßig langsam, bedingt durch einen Kontext-Switch in den Treiber.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

SlinDev

Treue Seele

Beiträge: 142

Wohnort: Lübeck

Beruf: Programmierer

  • Private Nachricht senden

14

04.10.2015, 23:25

Schon klar, mir ging es nur um den Vergleich "Durch die Daten Loopen" vs "Durch die Daten Loopen". Auf Seiten des Users ist das ja erstmal egal. Lahm wird es erst durch den Treiber.
Aber du hast natürlich recht, ich hab mich da ungünstig ausgedrückt, da das ganze sequentiell passiert und die Schleife dann entsprechend lange braucht.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

15

05.10.2015, 06:33

Auch durch den Treiber selbst wird es nicht lahm. Wie gesagt wird es lahm durch die vielen Kontext-Wechsel / Calls an sich. Auf der User-Seite muss aber so oder so geloopt werden, das ist schon schon richtig.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

16

05.10.2015, 07:21

Auch ist mir deine OpenGL 2.1 Einschränkung nicht so ganz klar. Es gibt doch quasi keine Hardware mehr die nicht mindestens 3.2 kann!?


Leider gibt es die doch (wobei meistens nicht die Hardware sondern die Treiberunterstützung das Problem sind). Neben diversen Panel-PC's ist das z.B. die freie Version von VMware. Und Verbindungen über den unsäglichen Windows Remotedesktop haben da auch noch irgend einen ganz seltsamen Knacks - da scheint bei OpenGL-Anwendungen nicht nur der Bildschirminhalt kopiert zu werden, sondern die Clientapplikation irgend was OpenGL-artiges selbst anzubieten.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

17

05.10.2015, 07:32

Und Du musst unbedingt VMWare und RemoteDesktop unterstützen? Wie viel % der von Dir angestrebten User werden darunter fallen? Mit wie vielen Usern rechnest Du überhaupt? Nach meiner Erfahrung sind über 500 schon ein illusorisches Ziel und da wäre ich an Deiner Stelle lieber froh, wenn es mit aktuellen Mitteln überhaupt schnell implementiert ist als wegen 2 Usern einen Aufwand von mehreren Monaten zusätzlich zu betreiben.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

18

05.10.2015, 08:05

Naja, die Anzahl aktiver User ist jetzt schon größer als 500 ;-)

Nur um Mißverständnisse zu vermeiden: es geht hier nicht um ein Spiel, sondern um eine CAD-artige Applikation. Deswegen auch diese etwas eigenwillige interne Repräsentation der Daten. Und dass es unter VMware funktionieren muss ist schlichtweg eine Grundanforderung an die Software.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

19

05.10.2015, 08:29

Nun, gerade bei CAD solltest Du dann allerdings glBegin und glEnd absolut vermeiden. Vertex-Arrays sind da definitiv besser und laufen auch unter 2.1.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Tobiking

1x Rätselkönig

  • Private Nachricht senden

20

05.10.2015, 08:45

Bei einer CAD Anwendung wirst du dann vermutlich auch gar nicht dauernd rendern, sondern nur wenn sich etwas ändert, oder? Da sind die Performance Anforderungen natürlich deutlich niedriger. Allein aus Zukunftssicht würde ich aber trotzdem auf VBOs umsteigen. Alles mit glBegin kannst du bei einer späteren Portierung wegschmeißen, Buffer wirst du immer in irgendeiner Form haben.

Wenn du noch die Möglichkeit hast etwas an deiner internen Struktur zu ändern, könntest du die Koordinaten dort auch einfach nur referenzieren und sie direkt separat in einem für OpenGL passenden Array/Buffer speichern. Alternativ lässt sich vielleicht was mit Stride bauen und die für OpenGL unnötigen Daten in deiner internen Repräsentation überspringen. Bin allerdings nicht sicher wie gut oder schlecht diese Lösung ist.

Werbeanzeige