Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Sa Dez 15, 2018 22:25

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 107 Beiträge ]  Gehe zu Seite Vorherige  1 ... 3, 4, 5, 6, 7, 8  Nächste
Autor Nachricht
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Di Apr 29, 2014 17:08 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 566
Programmiersprache: C++
hobbyfrickler hat geschrieben:
In dem Code benutze ich doch keine Extensions, aber warum muss ich ReadExtensions aus der dglOpenGL.pas aufrufen?
Lasse ich das weg schmiert das Programm ab.
ReadExtensions ruft auch ReadOpenGLCore auf. In letzterer Methode werden die Adressen der unbedingt nötigen Core-Funktionen von OpenGL abgefragt. Wenn du ReadOpenGLCore manuell aufrufst, kannst du ReadExtensions wahrscheinlich weglassen.

hobbyfrickler hat geschrieben:
Allerdings ist mir nicht wirklich klar wozu diese w-Komponente da ist, ich kann mich nicht erinnern jemals etwas anderes als w = 1.0 benutzt zu haben
Homogene Koordinaten sind dazu da, um Translation via Matrixmultiplikation zu ermöglichen. Für die Anfängertutorials reicht es aber zu wissen, dass man immer 1 einsetzt. Wenn du mehr zu homogenen Koordinaten wissen willst, mach einen neuen Thread auf.

hobbyfrickler hat geschrieben:
-Vertexshader zeichnet Dreieck: Auch hier ist wohl wieder meine Unwissenheit die Geburtsstätte der Formulierung. Ich könnte sonst nur irgendwie sagen, das der Vertexshader seine Daten innerhalb der Render-Pipeline weiterreicht, was da nun abschließend wirklich zeichnet, keine Ahnung, die GPU? ;-) Hier wäre ich sehr dankbar eine brauchbarere Formulierung von euch zu bekommen.
Nunja, was ist zeichnen? Ich denke da erstmal an Stift und Papier. Man bekommt die Koordinaten dreier Punkte gesagt und kann dann ein Dreieck daraus zeichnen, d.h. die Punkte mit Linien verbinden und ggf. die eingegrenzte Fläche ausmalen. Die Analogie dazu ist auf der Grafikkarte nach dem Vertexshader zu finden, denn der Vertexshader rechnet nur die Koordinaten aus.
Der Rasterizer bestimmt, wo der Stift angesetzt wird und der Fragmentshader bestimmt dann, in welcher Farbe gemalt wird. Oder er widerspricht dem Rasterizer und legt den Stift wieder weg (discard).

Solche Vergleiche sind aber immer nur sehr begrenzt brauchbar, denn die Rendering-Pipeline funktioniert einfach völlig anders als herkömmliches Zeichnen. Aber wichtig ist auch, dass der Vertexshader immer nur auf einem einzelnen Vertex arbeitet. Egal, was man also beim Rendern als "zeichnen" bezeichnet, niemals zeichnet der Vertexshader ein Dreieck - denn dazu brächte er schon alle drei Ecken. Was macht nun der Vertexshader? Aufgrund der freien Programmierbarkeit ist das schwierig allgemein zu beschreiben ;) In der Regel wendet er einfach Verschiebung, Drehung und Skalierung auf die Vertices an. Oder das ist nicht nötig und er reicht einfach weiter, was aus dem VBO gelesen wurde.

hobbyfrickler hat geschrieben:
Zu den Folgetutorials: Hier sehe ich die Notwendigkeit mal zu überlegen bzw. festzulegen welche MatheLib denn nun benutzt werden soll. Da sollte in allen Tuts die gleiche verwendet werden und nicht mal diese und mal jene.
Für den C++-Code würde ich für CoolMath stimmen. Es macht in vorbildlicher Weise Gebrauch von Templates, static Assertions und Operator-Overloading. Zudem kommt es aus der Community und ist einfach zu verwenden. Beim Entwickeln meiner eigenen Mathe-Klassen habe ich mich von CoolMath inspirieren lassen. Auch wenn es offenbar nicht mehr weiterentwickelt wird, bietet es für Anfänger eigentlich alles, was nötig ist (und noch mehr). Das einzige Wesentliche, was fehlt, ist eine GLSL-kompatible Syntax.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Di Apr 29, 2014 20:19 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7715
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Wenn der Abschnitt von Phobeus so gelungen war, dann nehmt ihn doch ins neue Tutorial rüber und zitiert ihn. Ist doch absolut nichts verwerfliches.
Was ihr nicht machen solltet ist, die Leute in andere Artikel zu schicken, in der Hoffnung, dass sie wiederkommen.

"Alles in einem Fluss" muss das Ziel sein.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Mi Mai 07, 2014 14:06 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 566
Programmiersprache: C++
Nun bin ich endlich dazu gekommen, die Übersetzung nach C++ abzuschließen. Das Ergebnis ist im Anhang (allerdings wegen des 256kiB-Limits ohne Binaries) und darf kritisch unter die Lupe genommen werden. Außerdem wäre es auch hier gut, wenn mal jemand probiert, das auf auf einer Linux- oder Apfel-Maschine zu kompilieren.

Am Code habe ich noch ein paar Details geändert:
  • glCreateShader und glCreateProgram geben im Fehlerfall nicht -1, sondern 0 zurück! Dasselbe tut jetzt dementsprechend auch die Funktion LoadShaders. Dies ist auch im Pascalcode anzupassen.
  • Die Abfrage von GL_ATTACHED_SHADERS habe ich raus genommen, da ich nicht wüsste, welche Fehler hier abgefangen werden sollten.
  • Das InfoLog wird in meinem Quelltext grundsätzlich ausgegeben - nicht nur im Fehlerfall. Allerdings nicht per MessageBox (das würde nerven), sondern auf der Konsole. So sieht man auch Compilerwarnungen.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Zuletzt geändert von glAwesome am Mi Mai 07, 2014 16:16, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Mi Mai 07, 2014 15:16 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Ich habe den C++ Code mir mal angeschaut und ein paar Kritikpunkte gefunden...
  1. "#include <stdio.h>": In C++ wäre "cstdio" pragmatisch.
  2. Ich sehe: Du verwendest C++ Strings. Deren Header wird nirgends eingebunden.
  3. "Globale Variablen"; In dem Beispiel zwar eigentlich egal, aber Anfänger werden möglicherweise auf dem Code aufbauen und so möglicherweise dazu verleitet, fälschlicherweise globalen Variablen dafür einzusetzen.
  4. "(void)" sollte ich C++ nicht mehr verwendet werden. Im Gegensatz zu C nicht notwendig.
  5. Die Verwendung von Präfixen ist in C++ nicht mehr modern. Ich sehe hier den Sinn generell nicht, aber wie wäre es mit einer Klasse?
  6. "std::string"; "cout": Manchmal wird der Namensraum angegeben, manchmal nicht. Irgendwie inkonsequent.
  7. "NULL": Verwende besser "nullptr". "NULL" ist nicht typsicher, ein Makro und müsste für die korrekte Verwendung erst included werden! (zb. "cstddef")
  8. "glViewport( 0, 0, w, h );": Im Gegensatz zum restlichen Codestil sind hier Leerzeichen in den Klammern.
  9. "std::string"s sollten per konstanter Referenz übergeben werden um unnötige Kopien zu verhindern.
  10. Ich halte es in modernen C++ für wesentlich konsequenteren und besseren Stil, Werte immer direkt zuzuweisen und nicht Variablenlisten anzufertigen, alle Default zu konstruieren und dann später mittels "="-Operator zuzuweisen.
  11. Wieso verwendest du C Streams wenn es ein C++ Tutorial ist? Noch dazu mit gleich mit einem Fehler: Wenn "resize" eine Ausnahme wirft wird die Datei niemals geschlossen.

Ob es läuft kann ich leider gerade nicht testen, weil ich keine passenden SDL Libs herumliegen habe.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Mi Mai 07, 2014 16:15 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 566
Programmiersprache: C++
Danke für das schnelle Feedback.

OpenglerF hat geschrieben:
"Globale Variablen"; In dem Beispiel zwar eigentlich egal, aber Anfänger werden möglicherweise auf dem Code aufbauen und so möglicherweise dazu verleitet, fälschlicherweise globalen Variablen dafür einzusetzen.
Die globalen Variablen sind Absicht, weil es nunmal die einfachste Lösung ist. Natürlich kann man für VBOs, VAOs und alles mögliche andere eigene Klassen schreiben (habe ich für meine Projekte auch) und das ganze Programm selbst in eine Klasse stecken. Aber erstens ist das für ein Tutorial dieser Größe schlicht mehr Aufwand und zweitens würde dies beim Leser eher den Eindruck erwecken, als hätte man bereits ein Konzept entworfen, wie Klassen zueinander in Beziehung stehen usw. Ein Klassenkonzept sollte sich ein Entwickler imho lieber selbst überlegen, wenn er mehr als nur einzelne Primitiven rendert. Dafür folgt der Tutorial-Code dem KISS-Prinzip.

OpenglerF hat geschrieben:
Die Verwendung von Präfixen ist in C++ nicht mehr modern.
"Nicht mehr modern" ist für mich kein Argument. Die Frage sollte (nicht nur auf Programmiersprachen bezogen) eher lauten: "Macht es Sinn?" Und das tut es meiner Meinung nach. So lassen sich z.B. lokale bzw. Membervariablen von globalen auseinander halten.

OpenglerF hat geschrieben:
"NULL": Verwende besser "nullptr". "NULL" ist nicht typsicher, ein Makro und müsste für die korrekte Verwendung erst included werden! (zb. "cstddef")
Ich sehe nicht, wieso man für NULL Typsicherheit bräuchte (für 0 oder 5 braucht man es auch nicht) - jedenfalls nicht, wie ich es verwende. Zudem scheint es das von dir genannte nullptr erst seit C++11 zu geben, womit ältere Compiler unnötig ausgeschlossen würden. Und dass man für NULL irgendwas includen müsste, wäre mir auch neu.

OpenglerF hat geschrieben:
Ich halte es in modernen C++ für wesentlich konsequenteren und besseren Stil, Werte immer direkt zuzuweisen und nicht Variablenlisten anzufertigen, alle Default zu konstruieren und dann später mittels "="-Operator zuzuweisen.
Mir ist nicht ganz klar, auf welchen Teil meines Codes das jetzt eine Anspielung ist... Kannst du ein konkretes Beispiel nennen?

OpenglerF hat geschrieben:
Wieso verwendest du C Streams wenn es ein C++ Tutorial ist? Noch dazu mit gleich mit einem Fehler: Wenn "resize" eine Ausnahme wirft wird die Datei niemals geschlossen.
Ich verwende seit geraumer Zeit FILE, fopen usw. Ich weiß, dass dies kein C++ sondern C ist, aber bietet C++ mit seinen fstreams irgendetwas, das mir die C-Schnittstelle nicht bietet? Ist schon Jahre her, aber als ich mir damals die C++-Klassen für Dateihandling angeschaut habe, bin ich zu dem Schluss gekommen, dass diese vor allem etwas komplizierter zu bedienen sind, aber keinen Mehrwert bieten.

Die Nichtbehandlung einer Exception ist in diesem Zusammenhang kein Fehler - hier werden Dateien geladen, die maximal ein paar Kilobyte groß sind. Da wird nie eine Exception fliegen.

Die anderen deiner Kritikpunkte habe ich angepasst und die neue Version angehängt.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Zuletzt geändert von glAwesome am Fr Mai 09, 2014 13:54, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Mi Mai 07, 2014 16:59 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 1968
Programmiersprache: C++
Wir sollten schon aktuellen Code schreiben, was in Bezug auf die Features der Sprache zu beziehen ist. Andernfalls denken Anfänger, dass die alten Objekte "good practices" sind und verwenden sie und machen dann entsprechende Fehler.
Von daher sollten schon std::fstream verwendet werden anstatt FILE.
Und fstream hat Vorteile gegenüber FILE und zwar RAII. Du brauchst nicht fclose(f) aufzurufen, dies geschieht automatisch.

Und OpenglerF meint solche Abschnitte:
Code:
  1.   string strVertShader, strFragShader;
  2.  
  3.   // Dateien laden
  4.   strVertShader = LoadShaderFromFile(vsFilename);
  5.   strFragShader = LoadShaderFromFile(fsFilename);

welche so aussehen sollten:
Code:
  1.   // Dateien laden
  2. std::string strVertShader = LoadShaderFromFile(vsFilename);
  3. std::string strFragShader = LoadShaderFromFile(fsFilename);

Bringt einen Geschwindigkeitsvorteil, da direkt der String von LoadShaderFromFile verwendet wird und kein eigenes Objekt erstellt werden muss. Und du läufst auch nicht in Gefahr auf eine uninitialisierte Variable zu laufen.

Dann bitte nicht using namespace std verwenden und es sollte eine globale Überlegung sein vielleicht das SDL in eine Klasse zu kapseln. Ggf. benötigt es dann ein spezielles Nebentutorial was diese Klasse erklärt, aber es reduziert den Code auf den wesentlichen (interessanten) OpenGL-Code.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Mi Mai 07, 2014 18:05 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Zitat:
Die globalen Variablen sind Absicht, weil es nunmal die einfachste Lösung ist

Globale Variablen sind einfach. Zu einfach.
Sie sind aus Designsicht ein Graus. Anfängen ist das möglicherweise nicht bewusst. Aber ich halte es nun mal für verantwortungslos es auch noch falsch vor zu machen. 10 Klassen in Klassen verlangt keiner. Aber eine(!) Klasse zu erstellen und eine leicht Objekt orientierte Vorgehensweise anzudeuten würde es nicht komplexer machen, wäre aber schon deutlich näher an der "best practice".

Ich gebe damit recht, das das Design die Sache des Lesers ist. Allerdings sehe ich den Sinn des Codes mitunter daran, dass Leute darauf aufbauen und als Basis verwenden. Und dann sollte das schon Praxisorientiert und nicht nur Einfachheitsorientiert sein.

Zitat:
Ich sehe nicht, wieso man für NULL Typsicherheit bräuchte (für 0 oder 5 braucht man es auch nicht) - jedenfalls nicht, wie ich es verwende. Zudem scheint es das von dir genannte nullptr erst seit C++11 zu geben, womit ältere Compiler unnötig ausgeschlossen würden. Und dass man für NULL irgendwas includen müsste, wäre mir auch neu.

Die Typsicherheit kommt eher bei verschiedenen Überladungen oder Templatespezialisierungen zum tragen. Konsequent wäre es aber, wenn man es überall einsetzt. Der C++ Standard führt so ein Schlüsselwort nicht zum Spaß ein. "nullptr" kann man auf halbwegs modernen Compilern voraussetzen, sollte schon relativ lange unterstützt werden und ist ebenfalls die "best practice" in modernen C++.
Das ist dir scheinbar ja neu: http://stackoverflow.com/questions/924664/why-is-null-undeclared
Das es deklariert ist, ist damit Glückssache. Vermutlich wird es von einem anderen Header den du verwendest inkludiert. Das das so ist, ist aber nicht garantiert und nicht standardkonform.

Zitat:
Ich verwende seit geraumer Zeit FILE, fopen usw. Ich weiß, dass dies kein C++ sondern C ist, aber bietet C++ mit seinen fstreams irgendetwas, das mir die C-Schnittstelle nicht bietet? Ist schon Jahre her, aber als ich mir damals die C++-Klassen für Dateihandling angeschaut habe, bin ich zu dem Schluss gekommen, dass diese vor allem etwas komplizierter zu bedienen sind, aber keinen Mehrwert bieten.

Wenn du so fragst, ja sie bieten schon einige zusätzliche Dinge zb. bei der Formatierung. Das die C++ Streams alles andere als das Gelbe vom Ei sind, ist allgemein bekannt. (Bei komplexeren Aufgaben komplex zu verstehen, Mehrfachvererbung, Stream/Formatierungsfunktionen vermischt, ...)
Wenn du mich persönlich fragst, dann bin ich auch kein Fan von den C++ Streams und habe für mich da auch schon eigene Ersatzklassen geschrieben.
Aber das ist alles nicht Thema des Tutorials. Ein C++ Programmierer sollte normalerweise immer C++ Streams verwendet haben und es ist auch generell üblich das zu tun. Und ein gewaltiger Vorteil im Vergleich mit C-Streams ist: Automatisches RAII, wie i0n0s schon gesagt hat. Wenn man nicht GANZ genau aufpasst(so genau kann ein Teil der Zielgruppe des Tutorials kaum aufpassen), hat man sehr sehr schnell keine Ausnahmesicherheit mehr.

Zitat:
Die Nichtbehandlung einer Exception ist in diesem Zusammenhang kein Fehler - hier werden Dateien geladen, die maximal ein paar Kilobyte groß sind. Da wird nie eine Exception fliegen.

Es wird wahrscheinlich keine fliegen. Ist in der Tat sehr unwahrscheinlich das eine fliegt. Aber möglich. Das ist der Punkt. Insbesondere der Punkt bei Ausnahmesicheren Code und wiedermal der "Best pracise". Ausnahmen die geworfen werden können, dürfen nicht zu fehlender Destruktion führen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Do Mai 08, 2014 06:09 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
OpenglerF hat geschrieben:
Zitat:
Ich verwende seit geraumer Zeit FILE, fopen usw. Ich weiß, dass dies kein C++ sondern C ist, aber bietet C++ mit seinen fstreams irgendetwas, das mir die C-Schnittstelle nicht bietet? Ist schon Jahre her, aber als ich mir damals die C++-Klassen für Dateihandling angeschaut habe, bin ich zu dem Schluss gekommen, dass diese vor allem etwas komplizierter zu bedienen sind, aber keinen Mehrwert bieten.

Wenn du so fragst, ja sie bieten schon einige zusätzliche Dinge zb. bei der Formatierung. Das die C++ Streams alles andere als das Gelbe vom Ei sind, ist allgemein bekannt. (Bei komplexeren Aufgaben komplex zu verstehen, Mehrfachvererbung, Stream/Formatierungsfunktionen vermischt, ...)
Wenn du mich persönlich fragst, dann bin ich auch kein Fan von den C++ Streams und habe für mich da auch schon eigene Ersatzklassen geschrieben.
Aber das ist alles nicht Thema des Tutorials. Ein C++ Programmierer sollte normalerweise immer C++ Streams verwendet haben und es ist auch generell üblich das zu tun. Und ein gewaltiger Vorteil im Vergleich mit C-Streams ist: Automatisches RAII, wie i0n0s schon gesagt hat. Wenn man nicht GANZ genau aufpasst(so genau kann ein Teil der Zielgruppe des Tutorials kaum aufpassen), hat man sehr sehr schnell keine Ausnahmesicherheit mehr.

Der Punkt ist einfach, dass hier C anstatt C++ geschrieben wird (ja, weder die eine noch die andere Sprache ist eine echte Teilmenge der jeweils anderen). Wenn wir C++ als Tutorialsprache verwenden wollen (was wir sollten!), dann sollten wir auch C++ schreiben und nicht C. NULL ist C, FILE ist C, nullptr bzw. vor C++11 0 ist C++, std::Xstream ist C++.

Wir sollten da pingelig sein, weil hier Anfänger hinkommen. Ich will Anfänger nicht auf eine Seite verweisen, wenn ich weiß, dass da bad practices (wie NULL und FILE sie in C++ sind) gelehrt werden.

viele Grüße,
Horazont

p.s.: Den Punkt mit der Compilerversion kann ich nachvollziehen. Ich bin mir auch nicht sicher, ob wir C++11 erfordern sollten. Das kann frustrierend für Anfänger sein, wenn der Code dann nicht kompiliert, nur weil sie nicht wissen, dass sie -std=c++11 irgendwo einstellen müssen. Ich glaube wir sollten, soweit möglich, auf forward compatible C++03 setzen. Wenn es den Code sehr stark verkompliziert gerne auch C++11. Das heißt dann, 0 (nicht NULL) anstatt nullptr.

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Do Mai 08, 2014 13:36 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 566
Programmiersprache: C++
OpenglerF hat geschrieben:
Ich glaube wir sollten, soweit möglich, auf forward compatible C++03 setzen. Wenn es den Code sehr stark verkompliziert gerne auch C++11. Das heißt dann, 0 (nicht NULL) anstatt nullptr.
RAII ist wirklich ein Argument, das mich überzeugt. Lustigerweise habe ich für meine Privatprojekte längst aus (u.a.) diesem Grund eine Klasse geschrieben, die fopen, fread usw. kapselt. Den Quelltext habe ich nun auf ifstream statt FILE umgestellt und ich muss sagen, es ist wirklich kein Stück komplizierter als die C-Methoden. Persönliches Fazit: Urteile für oder gegen eine bestimmte Vorgehensweise können nach 5 Jahren ruhig mal überdacht werden... :oops:

Um die globalen Variablen kümmere ich mich dann auch noch, sobald ich Zeit hab.

OpenglerF hat geschrieben:
Ist in der Tat sehr unwahrscheinlich das eine fliegt. Aber möglich. Das ist der Punkt. Insbesondere der Punkt bei Ausnahmesicheren Code und wiedermal der "Best pracise". Ausnahmen die geworfen werden können, dürfen nicht zu fehlender Destruktion führen.
Diese Auffassung teile ich grundsätzlich nicht. Man sollte die Wahrscheinlichkeit für eine Exception schon berücksichtigen. Wenn man für jeden Unsinn einen try-catch-Block einrichten will, leidet die Übersichtlichkeit enorm. Und das führt potenziell zu anderen Fehlern. Wer versucht, eine 1 GiB große Datei als Shader zu laden, dem fliegt das Programm zurecht um die Ohren. Und selbst wenn es das nicht täte, dann würde es vielleicht der Grafiktreiber tun. Wir entwickeln hier keine Flugzeugsoftware, wo alles beweisbar korrekt laufen muss.

Lord Horazont hat geschrieben:
Ich glaube wir sollten, soweit möglich, auf forward compatible C++03 setzen. Wenn es den Code sehr stark verkompliziert gerne auch C++11. Das heißt dann, 0 (nicht NULL) anstatt nullptr.
Finde ich einen guten Vorschlag. So werde ich es umsetzen.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Do Mai 08, 2014 23:21 
Offline
DGL Member

Registriert: Mi Sep 04, 2013 14:08
Beiträge: 34
Programmiersprache: FPC/Lazarus - Delphi
Ich halte die derzeitige Vorgehensweise für, naja, unschön für den Tutorialschreiber :wink:

Ich gehe davon aus das beide Versionen des Quellcodes für dieses Tut einen prinzipiell gleichen Aufbau haben sollten.
Jetzt den C-Port total umzustricken (keine globalen Variablen, SDL in Klasse und am besten noch ein eigenes Tut dafür) bedeutet, den Pascalcode (der schon seit Wochen einsehbar ist) auch wieder umzustricken, was wohl wiederum bedeutet das Tutorial ebenfalls deswegen umzustricken.
Das sind grad mal ca. 300 Zeilen Code MIT Kommentare, meiner Meinung nach sind ein paar globale Variablen wohl nicht ernsthaft ein Problem.
Oder 2 Prozeduren statt einer Klasse. Aber das ist nur meine persönliche Meinung die ich hier nicht dogmenhaft verteidigen werde.
Ich dachte ich schreibe für OpenGL-Anfänger, nicht für Anfänger der Sprache und war jetzt davon ausgegangen, das am Pascalcode nichts mehr geändert werden muss, da hätte ich mir dann eine Reaktion gewünscht BEVOR man mit dem Schreiben des Tutorials beginnt.

Natürlich wird das Argument kommen, das man Anfängern nicht "schlechte" Praktiken beibringen soll, das stimmt schon. Aber nur weil es in größeren Projekten nicht gut ist viele globale Variablen zu haben, gilt das auch für einen kurzen Beispielcode für OpenGL?
OK, von mir aus. Aber das der Pascalcode als Vorlage für die C-Version dienen würde, war doch wohl auch irgendwie klar. Ich finde es schade das da nicht früher reagiert wurde. Der Pascalcode ist seit fünften April einsehbar, mit den oben genannten "Fehlern". Das Template auf dem der Code aufbaut, als ich zusagte das Tut zu schreiben, ist sogar schon seit 23.März im Forum.

In Verbindung mit einer 6-wöchigen Reaktionszeit (wie es aussieht nach dem DGL-Treffen?) bis das Team mal etwas zum Entwurf des Tutorials sagt, empfinde ich diese Vorgehensweise, zumindest für mich, eher nicht motivierend. Glücklicherweise bin ich noch nicht dazu gekommen, das einzige Feedback zu meinem Code einzuarbeiten und werde jetzt erstmal abwarten was zum Tutorial gesagt wird und wie der C-Code dann aussieht, bevor ich da weiter Zeit investiere die nachher evtl. umsonst war.

Das soll kein Angriff sein, aber es ist schade das der Pascalcode anscheinend nicht genügend begutachtet wurde und das Resultat einen, wie ich finde, unnötigen Mehraufwand meiner Zeit bedeuten könnte :(

_________________
Die Benutzung von Web 2.0+ mithilfe eines Brain 1.0 wird wegen unzureichender Security-Updates NICHT empfohlen.
Bitte upgraden Sie auf Brain 2.0, jetzt für Sie exklusiv noch lieferbar!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Do Mai 08, 2014 23:32 
Offline
DGL Member

Registriert: Mo Nov 09, 2009 12:01
Beiträge: 196
Zuviel Diskussion ist auch nicht gut.
Schlechtes Tutorial ist besser als kein Tutorial.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Fr Mai 09, 2014 07:58 
Offline
Compliance Officer
Benutzeravatar

Registriert: So Aug 08, 2010 08:37
Beiträge: 454
Programmiersprache: C / C++ / Lua
Code geht unter Linux einwandfrei (wenn auch nur unter meiner NVIDIA Grafikkarte).

Was mir beim kurzen Drüberschauen (schreib Montag Matheabitur, nicht sooo viel Zeit ;) ) aufgefallen ist, du solltest vielleicht erwähnen, dass {$mode Delphi} nicht nur für @ da ist, sondern einfach auf http://www.freepascal.org/docs-html/prog/progse74.html#x290-305000D.3 verweisen.

Wir können einen C++ Port auch einfach sein lassen. DelphiGL und so.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Fr Mai 09, 2014 13:52 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 566
Programmiersprache: C++
hobbyfrickler hat geschrieben:
Ich gehe davon aus das beide Versionen des Quellcodes für dieses Tut einen prinzipiell gleichen Aufbau haben sollten.
Diesen Aspekt hatte ich mittlerweile völlig aus den Augen verloren. hobbyfrickler hat Recht. Entweder beide Quellcodes werden objektorientiert geschrieben oder keiner von beiden. Ich habe meinen Code jetzt um einen Kommentar ergänzt, der darauf hinweist, dass globale Variablen eigentlich schlechter Stil sind. Große Änderungen sollten nicht mehr vorgenommen werden - denn das würde entsprechende Änderungen am Pascalquellcode und am Tutorial selbst erfordern. Und die Arbeit ist so schon aufwändig genug. Wenn jemand dennoch meint, dass wir eine objektorientierte Variante brauchen, so stehe ich niemandem im Weg, den Code zu "forken".

Ansonsten nehme ich natürlich weiterhin gerne Feedback entgegen, sofern es keine aufwändigen Umbauten notwendig macht. :)

Edit: Anhang geändert. Jetzt konnte ich es auch auf openSuSE kompilieren und ausführen. Dazu musste bei linker options folgendes eingetragen werden:
Code:
  1. -ldl -lGL -lSDL2main -lSDL2
Ein richtiger Test scheitert jedoch momentan daran, dass das System nur OpenGL 3.1 unterstützt (Mesa 9.2 :( ).


Dateianhänge:
OpenGL3 Tutorial1 cpp.zip [84.76 KiB]
97-mal heruntergeladen

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Sa Mai 10, 2014 12:50 
Offline
DGL Member

Registriert: Mi Sep 04, 2013 14:08
Beiträge: 34
Programmiersprache: FPC/Lazarus - Delphi
Jens01 hat geschrieben:
Zuviel Diskussion ist auch nicht gut.
Schlechtes Tutorial ist besser als kein Tutorial.

Du hast die Wahl zwischen 2 Antwortmöglichkeiten:

Antwortmöglichkeit A:
Ich habe kein Problem damit wenn jemand mein Tut schlecht findet, man kann es sowieso nie allen Recht machen.
Aber deine Bemerkung würde sinnvoller sein wenn Du auch eine Begründung abliefern würdest.
Vielleicht kannst Du das ja auch viel besser, dann würde ich mich freuen deine Version des Tuts bald lesen zu können :mrgreen:
Deswegen gilt ohne Begründung Antwortmöglichkeit B :wink:

Antwortmöglichkeit B: ><((((*>


@end: Danke für das Testen unter Linux und den Hinweis zum Delphi-Mode. Viel Erfolg beim Abi.


@glAwesome: Meine Bemerkung zur MatrizenLib weiter oben bezog sich natürlich auf eine Pascal-Variante, sorry unklar ausgedrückt.
Für C++: Nachdem was ich gelesen habe (nur überflogen) hat glm eine GLSL-kompatible Syntax?
Um deinen Code auf openSuse zu testen könntest du doch einen 3.1 Kontext erstellen? Klar ist das dann kein 3.3, aber für die verwendeten Techniken reicht das doch aus?


@Team: Maßgeblich für die Entscheidung, ob wir nun gleich von Anfang an einen OOP-Ansatz verfolgen oder erst im zweiten Tut damit anfangen, seid ihr.
Es ist eure Seite und ich möchte hier kein Tut abliefern, welches als "schlecht, aber besser als garnichts" empfunden wird. Wenn es sein soll frickel ich den ganzen Kram auch nochmal um (Code als auch Text), nur muss man dazu auch wissen wie denn nun. Und natürlich vorausgesetzt glAwesome baut auch nochmal seinen Code um.
Außerdem wäre es schön mal zu wissen ob das Tut generell überhaupt zu gebrauchen ist, also ob sich was draus machen lässt, oder eher nicht. Dazu reicht meiner Meinung nach ein kurzes Überfliegen des Textes, was maximal 10 Minuten erfordert. Denn momentan weiss ich überhaupt nicht wodran ich bin und möchte ungern nach einigen Wochen Bescheid bekommen dass das Tut eher zum größten Teil für die Tonne ist. Dann lieber gleich. Mag sein das ich da einen gewissen Negativismus verfolge, aber der einzige Kommentar zum Tut vom Team lässt für mich einen grossen Interpretationsspielraum zu, bis hin zu "Ist eher nicht so toll".
Damit keine Missverständnisse aufkommen, dies ist als Bitte zu verstehen, nicht als Forderung.

_________________
Die Benutzung von Web 2.0+ mithilfe eines Brain 1.0 wird wegen unzureichender Security-Updates NICHT empfohlen.
Bitte upgraden Sie auf Brain 2.0, jetzt für Sie exklusiv noch lieferbar!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: [WIKI] OpenGL3
BeitragVerfasst: Sa Mai 10, 2014 14:12 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 1968
Programmiersprache: C++
hobbyfrickler hat geschrieben:
Mag sein das ich da einen gewissen Negativismus verfolge, aber der einzige Kommentar zum Tut vom Team lässt für mich einen grossen Interpretationsspielraum zu, bis hin zu "Ist eher nicht so toll".

Du bist deutlich zu negativ eingestellt. Ich habe mir mal die Team-Kommentare im Thread nochmal angeschaut und da war zwar auch einiges an Kritik darunter, aber nichts negatives.

Zum weiteren Vorgehen:
Ja es ist gemein und es würde dafür sorgen, dass du das erste Tutorial nochmal überarbeiten müsstest. SDL sollte als Klasse verwendet werden. Zum einen wird bis auf die Initialisierung von OpenGL SDL ja nur genutzt damit man schnell auf jeder Plattform ein Fenster bekommt. Somit ist es 'nur' ein Hilfsmittel und sollte in einen kleinen Minitutorial erklärt werden. Die Klasse hat auch den Vorteil, dass du sie in den Folgetutorials einfach einbinden kannst ohne ständig Code zu kopieren.
Das würde für dein Tutorial bedeutet, dass du die Erklärungen über SDL einfach in das Minitutorial kopieren kannst. Der Abschnitt über die Initialisierung von OpenGL sollte aber in beiden Tutorials vorkommen. Das gehört schon in Tutorial 1 der Reihe.
Den restlichen Code hätte ich auch gerne in einer Klasse gekapselt. Hier ist die Frage wie man es macht. Die Klasse darf natürlich auch nicht von deinem Code ablenken und verwirren. Mit 'Pech' entwickelt sich diese Klasse erst während der Reihe.
Das ist aber nicht als negativ zu sehen. Da hier eine Reihe entstehen soll ist es sehr unwahrscheinlich, dass ein Teil komplett fertig ist und bei den anderen nicht wieder angefasst wird. Also sehe es nicht als negativ wenn immer hin und wieder an verschiedenen Teilen nachgebessert wird.

Den Tutorialtext habe ich übrigens auch gelesen und es hat länger als 10 Minuten gedauert ;-)
Wie oben geschrieben sollten Teile des SDL-Teils ausgelagert werden. Bei der Einleitung bin ich am überlegen ob diese nicht auf die Übersichtsseite gehört anstatt in den ersten Teil, aber dies ist etwas, dass sieht man erst wenn man mehrere Teile hat. Also lass sie so.
Du gehst am Anfang von kaum Grundwissen voraus (->Definition Dreieck). Dies ist für das erste Tutorial gut, aber in den folgenden sollte mehr voraus gesetzt werden. Aber eine entsprechende Anmerkung das das erste Tutorial etwas langsam ist, hast du ja auch im Tutorial verarbeitet ;-)

Wie du schon angemerkt hast, fehlen die erklärenden Bilder und auch Screenshots, vielleicht auch direkt am Anfang als Motivation.
Deine Frage wegen dem Beispiel "wo Positions- und Farbdaten abwechselnd hintereinander sind" würde ich so vorschlagen, dass es ein weiterer Beispielcode wird. Dann kann der Leser anhand diesem sein Verständnis überprüfen.
Noch eine Anmerkung zu der Wortwahl: Bezeichne die Abschnitte vielleicht nicht Kapitel sondern als Abschnitte. Kapitel sind für mich etwas größerer und man könnte dann die einzelnen Teile der Reihe als Kapitel bezeichnen sodass die Reihe dann ein Buch ergibt :)

Schreibe gerne an weiteren Teilen das sieht alles mehr als gut aus, aber sehe es bitte auch nicht negativ, dass Änderung an den Teilen erfolgen werden. Diese dienen der Verbesserung, aber sagen auch nicht aus, dass das Tutorial schlecht ist!

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 107 Beiträge ]  Gehe zu Seite Vorherige  1 ... 3, 4, 5, 6, 7, 8  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.056s | 16 Queries | GZIP : On ]