Also ich würde das vom inhaltlichen Ziel her weniger als "Tutorial-Reihe" beschreiben, sondern eher als eine Art Kompendium. Immerhin wird der Reihe nach alles erklärt. Einsteiger können direkt am Anfang beginnen und Fortgeschrittene oder Umsteiger schlagen einfach mittendrin nach. Ich denke wenn man frei herraus nach vorne hin einfach alles erklärt, so wie Tak es vorhat und bisher macht, dann ist es auch ohne Weiteres für alle geeignet, ohne dass man damit jemanden tatsächlich Steine in den Weg legt. Wer ein Problem in dem Tut hat, der wird im Forum fragen und wenn es echt ein wichtiger Punkt ist bei dem es hapert, dann kann man das nachträglich im Tut ändern. Sich jetzt schon das Gehrin zu zerreißen über etwaige Fehlerchen und Unverständlichkeiten, obwohl noch alles in den Fußstapfen steht, ist denke ich aktuell nicht förderlich für das Projekt.
Meiner Meinung nach sollten wir Tak erstmal schreiben lassen und regelmäßig mal reinschauen was er so treibt und im Verlauf seines Fortschritts die Verbesserung suchen, anstatt ihm an jedem Satz aufzuhalten und ihn auf Kleinigkeiten aufmerksam zu machen.

Allerdings: Wenn man schon in pseudo-code schreiben möchte, was ja in unserer multi-code-lingualen-community nicht falsch ist, dann sollte man auch tatsächlich pseudo-code schreiben und nicht einfach c++ als pseudo-code einstufen.

Zum Niveau der Texte: Persönlich bin ich von Taks "wir müssen immer nach der Spitze des Fortschritts streben" Art nicht so sehr angetan. Wenn man sich aber dem Thema "die aktuelle Spitze des Fortschritts" annimmt und das erklären möchte, dann muss man meiner Meinung nach nicht darauf Rücksicht nehmen, dass es jeder noch so ungeschulte Anfänger versteht. Desweiteren halte ich einen "Schnelleinstieg" als sekundäres Ziel einer Tutorial-Reihe durchaus für interessant, allerdings nicht als Primärinhalt angebracht, da man bei solchen Pseudo-Tutorials einfach was in die Hand gelegt bekommt, was man für den Papierkorb gemacht hat und meist auch ohne wirklichen Lerneffekt ist.
Außer ein kleines "es funktioniert"-Lächeln kommt da nichts bei rüber. Im Gegenteil, es dauert 1-2 Tutorials, bis man aus seiner Traumwelt wieder auf den harten Boden der Tatsachen zurückgezogen wird und dann schmerzlich feststellt, dass man Grafik eben doch nicht ausm Ärmel schütteln kann. Wir betreiben hier ja keine Dauerwerbesendung, sondern ein hauptsächlich Informationen und Hilfe zur Verfügung stellendes Forum. Jemanden weiß machen zu wollen, es wäre ja alles einfach und mit 10min Aufwand am Tag wird man der Grafik-Guru, ist da Augenwischerei.

Nächster Punkt ist mal wieder SDL. Manchmal frage ich mich, ob es Not tut an jeder Ecke "SDL" zu schreiben. Gibt es denn keinen anderen Weg ohne eine Fremdbibliothek Plattformunabhängigkeit zu realisieren? Kann man das nicht selbst realisieren mit OpenGl und einer beliebigen Programmiersprache? Klar kann man den Hinweis darauf geben, das es mit SDL geht und wahrscheinlich auch einfach ist. Auch kann man gerne an einer Stelle im Tutorial erklären wie man es damit macht, aber bitte schön als Alternative. Es wird hier hin und wieder (ich extremisier das gerade ein bischen, also bitte nicht so eng sehen) das Bild vermittelt, dass Software ohne Plattformunabhängikeit schlecht wäre und SDL der einzige Weg wäre aus der Dunkelheit in die ultimative Göttlichkeit zu treten. Denn die Plattformunabhängigkeit, die ich durch SDL erziele legt mir das Ei ins Nest SDL auch auf meinem Rechner installiert zu haben, wenn ich die Software nutzen will, bzw. SDL mit meiner Software auszuliefern.
Von daher finde ich den Ansatz, ersteinmal nur mit OpenGl die Plattformunabhängigkeit zu erzielen und AUCH, aber nicht NUR, den Weg per Fremdbibliothek zu beschreiben, sehr interessant, weil man dann die Wahl hat, sich von der einen Abhängigkeit in die nächste zu stürzen, einen Umweg zu gehen um garkeine Abhängigkeit zu haben, oder gar plattformabhängig zu bleiben.

Edit: Mir ist gerade im lineare Algebra teil die Kleinigkeit aufgefallen, dass die Reihenfolge der vektor-funktionen folgende ist: vektor, einheitsvektor, addition, subtraktion, betrag, skalarprodukt, kreuzprodukt, normalisieren... Im Skalarprodukt wird normalisieren erwähnt und erklärt, was man sich sparen kann, wenn man Normalisieren unmittelbar nach Betrag setzt, da man beim Skalarodukt dann schon weiß, was Normalisieren heißt und normalisieren den Betrag vorraussetzt. Übrigens ist der Betrag des Kreuzproduktes gleich der Fläche des von den beiden Basisvektoren aufgespannten Parallelogrammes. Vielleicht ist das noch ein netter Zusatz, der niemanden etwas bringt. ^^

_________________
Klar Soweit?

SDL hat hier immerhin den Vorteil das der Code ersteinmal kurz und leicht lesbar wird. Dazu kann jemand der noch am anfang steht immerhin auch seinen IO kram darüber abwickeln. WGL/GLX gehöhrt definitiv nicht zu den dingen die man als Anfänger lernen muss nur um einige Dinge in 3d Darzustellen. (Es wir ja noch schlimmer wenn man für jede platform eingabegeräte unterstützten soll...) Es spricht ja nichts dagegen auf einer extra seite zu erklären wie man es mit WGL/GLX oder anderen biblioteken schaffen kann.
Früher wurde einfach GLUT für testprogramme benutzt, jedoch solange es kein neues GLUT für OpenGL3 gibt. Ist SDL das nächste was da ran kommt. Außerdem bringt man so die SDL leute mal dazu das sie sehen, das der kram gebraucht wird....

ZUm coding Stil: Altere tutorials ließen sich auch von C usern recht gut interpretieren, bis auf das es so aussah als wenn der schreiber ein falsches tastaturlayout hatte (@ = & .....)


Optimierungen kann man relativ weit nach hinten schieben. Vorallem wenn man richtig optimiert, dann muss man auch in den shadern teile der matrizen Nullen damit der compiler weiß das diese werte nicht von uniform variablen abhängen und die ergebnisse auch null sind.
Und die SSE keule raushohlen bringt einem anfänger definitiv nichts... Der ist echt glücklich über eine matrixklasse, die die alten OpenGL matrizen ersetzt. Da dies sprachabhängig ist sollte dieser teil womoglich für die wichtigsten sprachen geschrieben werden.

_________________
Lumina plattform unabhängige GLSL IDE

Um mal die Diskussion ob man SDL oder plain Win/Unix api verwendet zu beenden:

Tak es wäre ja nicht schwierig, dieses eine Tutorial zur erstellung des Renderkontextes nicht nur WinAPI und GLX zu beschreiben, sondern auch noch den SDL weg dazu.

Später wenn du dann zu den Texturen kommst, kannst du ja einmal den SDL_Image weg zeigen und einen einfachen image pascal loader für den API teil.

Was ich auch sehr gut finden würde, Source beispiele.

Grad beim erstellung des Rendercontextes werden die meisten Fehler gemacht, da ist es umso besser wenn man nen src hat, indem man alles im ganzen sieht. Fände es gut wenn es in jedem Tutorial nen source gäbe und nicht erst am ende.

In diesem sinne und gruß aus Japan,
Final =)

@Tak2004: Ich biete Dir an, die Formulierung der Texte ein bissel zu streamlinen. Du musst mir aber Dein OK dafür geben. Ich habe das zwar schon früher mal ohne Rückfrage gemacht, aber hier können wir ja mal ein wenig professioneller vorgehen.
Viele Grüße,
Traude

Ich habe nichts dagegen.


Ich hab mich dafür entschieden im Artikel, über Renderkontext bei Windows und X11 API zu bleiben, diese sind im Treiber verfügbar und kann jeder nutzen.
Dabei gehe ich nicht auf die APIs ein sondern zeige den OpenGL Teil, wer sich für erstellung von Fenster und IO Handlich interessiert, dann kann sich eines der vielen Tuts aus dem Netz suchen.
Es wird von mir ein C/C++ Quellcode für Windows und Linux im Wiki Artikel verlinkt werden, es steht jeden frei eines für SDL, QT, wxWidget, GTK, .net, mono und wie die ganzen Framework heissen bereit zu stellen. Im Prinzip ist es wie bei Nehe, wo etwas erklärt wird und am Ende stellen dann Programmierer die Lösungen für andere Sprachen und Frameworks bereit.

Alle meine Beispiele werden C/C++ sein wobei, wie ich gut nachvollziehen kann, ich es in der einfachsten Form nutzen werde. Es bringt wirklich niemanden wenn ich templates, Makros, Präprozessor anweisungen oder Compilerextensions verwende und sowas wie a=a<b?a:b; wird es definitiv auch nicht geben. Dieses sind zwar C und C++ Standards aber der Sache in keinster weise dienlich, darum hab ich bewusst [C]/C++ geschrieben.

Die Codesamples im Lineare Algebra werde ich vollständig ersetzen und auf operator überladung und Templates verzichten.

Wegen der SSE Keule, das kam vieleicht falsch rüber und gehört hier in die Diskussion eigentlich weniger rein aber ich will für eine Mikrosekunde nochmal drauf eingehen.
Im Optimierungstext steht drin, dass GCC eine Vektorextension besitzt. Diese erlaubt das nutzen von SSE und MMX ohne inlineasm oder ähnlichen, um genau zu sein unterscheidet sich der Code vom Samplecode nur dadurch, dass man keine Forschleifen mehr im Code hat. Sowas wäre schon SSE basierter Code, wenn man TVec4f wie folgt vorher definiert.

Dies ist eine Extension vom GCC, die es seit ewigkeiten gibt und die Basisoperationen über operator überladung zur verfügung stellt und alle weiteren speziellen über Funktionen.
Man braucht kein ASM, hält damit den Code sehr lesbar und unglaublich performant, sowie platformunabhängig.

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

Projekte: https://github.com/tak2004

k, dann werde ich wohl um auch wieder selbst wieder in die materie reinzukommen den SDL source basteln.
Freu mich auf jedemfall auf das fertige tutorial =)

Gruß,
Final