OpenGL oder Vulkan lernen?



  • Ja, ich bin da echt überfordert. C++ macht mich ab einem gewissen Level echt fertig. Ich finde es auch schwer zu lesen und schwer zu erkennen was da nun eigentlich passiert. Früher habe ich eine simple 3D-Grafikengine für den Amiga in Assembler geschrieben, das war wesentlich einfacher.


  • Mod

    Schlangenmensch schrieb:

    Das Tutorial scheint etwas mehr als "nur Vulkan" zu machen. Den Wrapper den die da bauen, den brauchst du nur wenn du ordentlich nach dem RAII Prinzip arbeiten willst. Und dazu verwenden die C++11 Sprachfeature, die einen C++ Anfänger vielleicht erstmal überfordern.

    Aber der Ratschlag kann wohl kaum lauten, das nicht von Anfang an sauber zu machen. Grundsätzliche Ressourcenverwaltung in C++ sollte man schon können, wenn man C++ benutzt. Das hat aber nichts mit Vulkan vs. OpenGL zu tun, sondern würde für beide gelten. Bringt einem schließlich nichts, wenn man aufgrund mangelnder Grundlagen irgendetwas schnell hin frickelt, das Ressourcen leckt ohne Ende und bei der kleinsten Änderung explodiert.

    Da muss man eben erst die Grundlagen der verwendeten Sprache lernen (Templates sind Grundlagen von C++!), und wie man allgemein Ressourcen sauber verwaltet (Das ist Grundlage jeder Programmierung!). Ganz besonders bei Vulkan, bei dem diese Aufgabe wieder verstärkt in den Händen des Programmierers liegt.

    Früher habe ich eine simple 3D-Grafikengine für den Amiga in Assembler geschrieben, das war wesentlich einfacher.

    War die denn auch technisch korrekt, dass sie keine Ressourcen geleckt hat? Ich behaupte mal, dass die Antwort Nein sein dürfte, du es aber bloß nicht bemerkt hast.



  • SeppJ schrieb:

    Aber der Ratschlag kann wohl kaum lauten, das nicht von Anfang an sauber zu machen.

    Das heißt es nicht. Aber das in einem Tutorial mit std::function, lamdas und delegating contructors zu implementieren ist schon 'ne Ansage. Das geht auch mit "alt bekannten" Sprachmitteln, auch wenn das dann nicht so nach "modernem c++" aussieht.

    Aber natürlich ist es keine Frage zwischen Vulkan oder OpenGL, dass gilt für beide. Meiner Meinung nach gilt auch für beide, dass sie nicht Anfängerfreundlich sind.


  • Mod

    Schlangenmensch schrieb:

    SeppJ schrieb:

    Aber der Ratschlag kann wohl kaum lauten, das nicht von Anfang an sauber zu machen.

    Das heißt es nicht. Aber das in einem Tutorial mit std::function, lamdas und delegating contructors zu implementieren ist schon 'ne Ansage. Das geht auch mit "alt bekannten" Sprachmitteln, auch wenn das dann nicht so nach "modernem c++" aussieht.

    Ahh, ok. Die Beschreibung klang so, als ob die Nutzung von RAII und Templates als zu fortschrittlich angesehen würde.



  • Eine naive D3D11/OpenGL Implementierung wird eine naive D3D12/Vulkan Implementierung von der Performance locker schlagen. Auf gamedev sind ab und zu mal Leute unterwegs die auf D3D12 umgestellt haben und dadurch einiges an Performance verloren haben.



  • SeppJ schrieb:

    Früher habe ich eine simple 3D-Grafikengine für den Amiga in Assembler geschrieben, das war wesentlich einfacher.

    War die denn auch technisch korrekt, dass sie keine Ressourcen geleckt hat? Ich behaupte mal, dass die Antwort Nein sein dürfte, du es aber bloß nicht bemerkt hast.

    Keine Ahnung ob die technisch korrekt war, was auch immer das zu bedeutet hat. Sie hat so funktioniert wie sie sollte. Da gab es kein Ressourcen-Management, die Ressourcen waren alle von Anbeginn im Speicher an festen Adressen. Da musste kein Speicher alloziert werden etc. Das war alles noch sehr unkompliziert zu programmieren.

    Ich wollte damit auch nur zum Ausdruck bringen, dass ASM + Software Rendering alles von der Pike auf selfmade mir früher extrem leichter fiel, als heute C++ und Vulkan oder OpenGL. Hat einfach mehr Spaß gemacht und das zählt unter dem Strich. Was soll ich Sachen machen die mir keinen Spaß machen?



  • Zee++ schrieb:

    ]Keine Ahnung ob die technisch korrekt war, was auch immer das zu bedeutet hat. Sie hat so funktioniert wie sie sollte. Da gab es kein Ressourcen-Management, die Ressourcen waren alle von Anbeginn im Speicher an festen Adressen. Da musste kein Speicher alloziert werden etc. Das war alles noch sehr unkompliziert zu programmieren.

    Naja, Technik entwickelt sich weiter. Ich habe zwar nie auf 'nem Amiga gearbeitet, aber wenn du dir heute einen Assembler nimmst und einfach Werte in eine feste Speicherstelle schreibst, stürtzt bestenfalls dein Programm ab. Heutzutagen laufen mehrere Anwendungen gleichzeitig auf dem Computer, die sich nicht in die Quere kommen dürfen. Dafür verwaltet dein Betriebssystem die Speicherbereiche, die für dich zur Verfügung stehen. Das ist unabhägig davon, welche Programmiersprache du verwendest, dass ist nur unterschiedlich abstrahiert.

    Und da ich mich auch schon mal ein bisschen mit Assembler auseinandergesetzt habe, fällt es mir schwer zu glauben, dass alles Selfmade für dich einfacher war (könntest du heute immer noch machen). Aber Menschen sind ja zum Glück unterschiedlich.



  • Ja klar, die Systeme sind komplexer geworden und dann brauch es auch solch Monstersprachen wie C++ um Herr der Lage zu werden. Was nicht heißt, dass in C++ nicht viel mehr Mist programmiert wird als andersherum. Dass immer nur auf die Lernenden zu schieben ist natürlich der Weg des geringsten Widerstands. Mir ist das im Endeffekt alles egal. Ich programmiere nur so zum Hobby, da ich in Rente bin und mir jeden Tag mit den Sachen fülle die mir Spaß machen.

    Vielleicht ist die Idee von dir aber nicht schlecht, einfach wieder für die alten Kisten was in Assembler zu machen, oder mich auf C und OpenGL zu beschränken. C++ und Vulkan kann man ja immer noch mal in Betracht ziehen falls das andere nicht gut für mich funktioniert.


  • Mod

    Vulkan und OpenGL sind ziemlich unabhängig von der benutzten Sprache. Du kannst super auch alles in Assembler machen (oder in C). Du wirst aber voraussichtlich folgende Dinge feststellen:
    * Mit den gestiegenen Ansprüchen ist auch alles sehr viel komplizierter geworden, auch - oder gerade erst recht - in low-level-Sprachen. Mit ein paar statischen Speicherbereichen kommt man eben nicht besonders weit. Sonst sieht's am Ende eben auch aus wie auf dem Amiga.
    * Die höherleveligen Sprachen versuchen dir viel von dieser Komplexität abzunehmen. Dynamische Ressourcenverwaltung ist in Assembler sehr viel anstrengender als z.B. in Python. Da passiert dann mehr oder weniger unsichtbar im Hintergrund, was dich in Assembler viel Mühe kostet.
    * Am Ende fährt man aber meistens am besten mit der Sprache, die man am besten beherrscht. Wenn du Assembler besser als C++ kannst, ist klar, dass die Assembler einfacher vorkommt und du bessere Ergebnisse erzielen wirst.
    * Deine Ergebnisse in Assembler werden aber voraussichtlich sehr viel bescheidener Aussehen, als die von irgendeinem anderen Programmierer, der genau so gut ist wie du, dabei aber eine höher-levelige Sprache benutzt, bei der er weniger Denkarbeit auf unnötige Details aufwenden muss.



  • Schlangenmensch schrieb:

    SeppJ schrieb:

    Aber der Ratschlag kann wohl kaum lauten, das nicht von Anfang an sauber zu machen.

    Das heißt es nicht. Aber das in einem Tutorial mit std::function, lamdas und delegating contructors zu implementieren ist schon 'ne Ansage. Das geht auch mit "alt bekannten" Sprachmitteln, auch wenn das dann nicht so nach "modernem c++" aussieht.

    Der Code aus diesem Tutorial gehört auch zum grottigsten C++, das mir in letzter Zeit so untergekommen wäre. Das Ganze ließe sich einfach mit std::unique_ptr und custom Deleter lösen und fertig; da braucht es weder einen dermaßen selbst-hingekotzten Smartpointer noch Lambdas, delegating Constructors, std::function oder dergleichen...



  • Ja und als Anfänger hat man keine Chance gutem vom schlechtem C++ Code zu unterscheiden.

    @SeppJ
    Logisch, es wurde mehr Abtraktionsebenen erschaffen um dem Entwickler die Arbeit mit dem Komplexen einfacher zu machen. Nur scheint mir C++ zu versuchen eine hohen Abstraktion mit LowLevel zu vermischen, was auch meiner Sicht schwer möglich ist.

    Mir ist auch klar, dass jemand mit gleichem Produktions-Aufwand in C++ die besseren Ergebnisse erzielt(Wenn es einer der wenigen ist der C++ wirklich kann). Was für mich zählt ist nicht wie technisch korrekt oder effektiv ich programmiere, sondern wie viel Spaß mir die Sache macht.



  • Naja, wenn man ehrlich ich, ist C++ auch ein kleines böses Biest. Ich studierte E-Technik im Master, war aber schon seit meiner Kindheit ein begeisterter Programmierer (Bin der klassische Nerd!). Daher habe ich die sprachliche Entwicklung von C++ noch gut mitbekommen. Wenn ich aber sehe wie viele meiner Komilitonen bereits mit dem klassischen OOP Konzepten von C++ überfordert sind und bei den eingeführten C++11 Features entgültig der Kopf explodiert, frage ich mich schon manchmal, ob es mir Heute noch spaß machen würde C++ zu lernen.

    Ich bin auf jeden Fall gespannt, ob sich diese Low"er" Level API's wie Vulkan und D3D12 durchsetzen werden.



  • Ich bin auch die ganze Zeit am recherchieren und irgendwie scheint DX12 und Vulkan wirklich was für absoluten Spezialisten zu sein und nicht wirklich was für den Einsteiger.

    Und was ich von C++ halten soll weiß ich ehrlich gesagt auch nicht so recht. Ich habe wirklich schon viele Versuche gestartet mit C++ warm zu werden und jedesmal habe ich wieder hingeschmisse. Dann die neuen Standards, die bestimmt viel verbessern, aber mich nun komplett verwirren. Es kommt mir so vor als würde immer mehr an die Sprache rangeflanscht und nur 5 von 100 C++ Coder blicken da wirklich durch und schreiben auch guten Code. Ist aber nur so ein Gefühl.

    Gibt es wirklich Leute die C++ mögen und nicht nur nutzen wegen der großen Codebase?

    Welche Programmiersprache macht euch denn so richtig Spaß?



  • Ich mag C++ sehr. Der Hauptgrund dürfte RAII, Templates und Sachen wie const sein. Besonders ersteres hält mich von C# oder Java ab. Sprachen wie Rust setzen zwar auf Ähnliches, jedoch würde ich gerne die gewohnte C-Syntax benutzen.



  • Ich programmiere auch gerne C++. Aber im Embedded Bereich (Microcontroller, etc ... ) hat man da eh nicht viele Auswahlmöglichkeiten 😃



  • Ich dachte Mikrocontroller werden hauptsächlichen in ASM und C programmiert und weniger in C++?



  • Mit dem Vormarsch der Cortex M Serie hat das sehr stark nachgelassen. Die Cortex M sind extrem günstig und mit den modernen C++ Compilern kann man sehr effizienten Code produzieren. Einige C++ Features wie z.B. Templates sind wie geschaffen für flexiblen + performanten Code!

    Meist steckt der Rechenleistung fressende Teil eh nur in ein paar wenigen Zeilen Code, und die kann man dann immernoch in ASM schreiben. Aber das ist sehr selten nötig, die Compiler produzieren meist bereits optimalen Code.

    Und auch in dem Bereich wird die Software immer umfangreicher. Und vorallem hat man heute viele Unterschieldiche Hardware die in kombination entworfen wird, die man aber gerne mit der gleichen Sprache programmieren würde. Für fast jede Platform gibt es inzwischen C++ ähnliche Sprachen zum programmieren. Günstige Microcontroller, programmierbare Grafikkarten, leistungsfähige FPGA's, tolle Zeit in der wir leben! 😃



  • Ok, danke für die Info. Gibt es Themen bei C++ die man unbedingt lernen sollte? Ich meine alles von C++ zu lernen bevor man anfängt produktiv damit zu arbeiten verdirbt einem ja jegliche Lust an der Sprache.



  • So, ich habe mir jetzt das Buch "Eine Tour durch C++" von Bjarne Stroustrup besorgt und werde das durch arbeiten. Vielleicht hilft mir das ja die Grundlagen richtig zu lernen.


  • Mod

    Mit einem guten tutorial wuerde man feststellen, dass Vulkan und D3D12 eigentlich wieder naeher dran sind so zu sein. Leider bleiben beide sehr sehr code aufwendig.

    NVidia bietet die moeglichkeit ueber opengl an vulkan zu arbeiten. Damit kann zumindestens in der lernphase einiges einfacher sein als von 0 alles auf vulkan zu portieren (bzw ueberhaupt anzufangen).
    http://www.gdcvault.com/play/1023525/Vulkan-and-NVIDIA-The-Essentials


Anmelden zum Antworten