Software Renderer - Rat u. Beispiele



  • Apple unterstützt OpenGL spärlich und Vulkan erst recht nicht.
    Ferner ist OpenGL in Systemen wie dem Raspberry Pi kaum Beachtenswert.
    Wenn man ein nicht so aufwändiges 3DProjekt hat und man Plattform-Unabhängig sein möchte, dann tut’s wohl auch SDL2 und C mit Linux als de facto IDE (cppcheck, valgrind, ddd, astyle, gcc, make, bash), dann kann man ja leicht nach Windows portieren mit MinGW.

    Ist meine Überlegung gut?

    Gibt es Beispielprojekte die 3D Software Rendering mittels SDL2 erzielen?



  • Die Frage ist halt, was genau du dir so vorstellst. 3D Software Rendering ist rein prinzipiell selbstverständlich möglich, nur ist das ein beliebig komplexes, potentiell massives Unterfangen und an hardware OpenGL, Vulkan etc. wirst du nichtmal annähernd rankommen was Bildqualität und Performance betrifft, vor allem auf kleinen CPUs.

    Notiz am Rande: Es gibt auch Software Implementierungen von OpenGL et al. wie z.B. Mesa...



  • SDL2 verwendet OpenGL. Wie willst du also SDL ohne OpenGL verwenden?
    Check ich grad nicht.



  • dot schrieb:

    ... vor allem auf kleinen CPUs. ...

    Guter Einwand! Aber ich denke mal die Meisten haben zumindest einen Intel Core i5 inne oder etwas aehnliches.

    hustbaer schrieb:

    SDL2 verwendet OpenGL. Wie willst du also SDL ohne OpenGL verwenden?
    Check ich grad nicht.

    Stimmt, aber wo genau und wann? Apple unterstuetzt OpenGL nicht mehr weiter (offenbar) und bei denen muss alles proprietary sein (offenbar) angefangen bei Swift und Metal API. Viele weichen deshalb in puncto App-Entwicklung nach JavaScript aus. Bei Grafikprogrammierung ist es halt nach wie vor OpenGL/Vulkan (das immer weniger unterstuetzt wird und letzteres gar nicht) und auch DirectX.
    In den Framebuffer kann ich platformunhabhaening eh nichts machen. Bei Linux gab es eine Headerdatei dafuer (hab' den Namen allerdings vergessen) und bei Windows war es glaube ich GDI+.

    Brauche eigentlich etwas, womit ich direkt in den Bildspeicher schreieben kann... Frueher war das viel einfacher...

    Man kann das mit der Platformunabhaenigkeit und dem direkten Zugriff in den Bildspeicher eh vergessen. Man kann ja dann gleich mit C++ und DirectX kaempfen, da Windows sowieso die meistgenutzte Platform ist. Schade, dachte, dass es mit C guenstig bzw. besser waere einen platformunhabhaengingen 3D Software Renderer zu schreiben, aber mangels Unterstuetzung bei Apple (OpenGL und damit auch SDL) und Microsoft Visual Studio (C11), eher ein einsames Unterfangen. Bei MinGW faehlt mir der ddd, valgrind, ... Bei Apple ist es zurzeit 'ne Katastrophe mit valgrind und der brew-Packetverwaltung.



  • *-Paketverwaltung



  • Das einzige 'was mir noch einfaellt waere Java\1:

    https://www.youtube.com/watch?v=C0ev80NwMXg

    Aber mit C waere es viel performanter...



  • tl;dr: mich stoert einfach, dass die 3 Platformen Mac, Windows, Linux gewisse APIs nicht genuegend unterstuetzen und mich stoert auch die Tatsache, dass es nicht's gibt womit man platformunabhaengig auf den Framebuffer zugreifen kann.



  • iceyu schrieb:

    dot schrieb:

    ... vor allem auf kleinen CPUs. ...

    Guter Einwand! Aber ich denke mal die Meisten haben zumindest einen Intel Core i5 inne oder etwas aehnliches.

    Auch dann bist du immer noch viele viele Größenordnungen von der Performance einer GPU entfernt. Microsoft hat mit WARP einen ziemlich optimierten Software Renderer der vollen Direct3D support anbietet. Um ein Gefühl zu bekommen wie die Performance da so aussieht kannst du ja mal hier schauen: https://msdn.microsoft.com/en-us/library/gg615082.aspx#architecture

    Crysis 800×600 auf nem Core i7 mit niedrigsten Settings lauft mit ca. 7 FPS. Gleicher Test auf ner integrierten billig GPU -> 380 FPS... das ist so die Performance von der wir hier sprechen, auf nem Software Renderer in dem ziemlich sicher einige Mannjahre stecken...

    iceyu schrieb:

    tl;dr: mich stoert einfach, dass die 3 Platformen Mac, Windows, Linux gewisse APIs nicht genuegend unterstuetzen und mich stoert auch die Tatsache, dass es nicht's gibt womit man platformunabhaengig auf den Framebuffer zugreifen kann.

    Wir leben jetzt halt im 21. Jahrhundert wo direkter Zugriff auf den Framebuffer vom Usermode aus im Allgemeinen weder sinnvoll noch wünschenswert ist...



  • dot schrieb:

    Auch dann bist du immer noch viele viele Größenordnungen von der Performance einer GPU entfernt. ...

    Tja, dann war meine Idee wohl nichts.

    dot schrieb:

    Wir leben jetzt halt im 21. Jahrhundert wo direkter Zugriff auf den Framebuffer vom Usermode aus im Allgemeinen weder sinnvoll noch wünschenswert ist...

    Ich kann jetzt eh nichts machen. Ich dachte, man kann die schlechten OpenGL-Treiber Support auf Platformen wie dem Mac umgehen und selbst Hand anlegen mit einem Software Renderer.

    Microsoft arbeitet gegen einen, wenn man mit C und OpenGL entwickelt (da Visual Studio kein C11 kennt). Microsoft ist hilfreicher, wenn man mit C++ entwickelt. Nur Linux bietet mir diese de facto C IDE und mit Ubuntu on Windows hat man zwar die bash, aber ddd fehlt z.B. und man kann das dann mit OpenGL eh vergessen.

    Ich kenne nur C und OpenGL. Auf Metal API und Swift habe ich kein Bock (Apple nervt mich langsam). Auf Linux würde ich gerne, aber die Leute verwenden dieses scheiß Windows. C++ kenne ich ein bischen, aber muss wohl 10 Jahre lang mich durchbeißen damit ich zumindest die Sprache einigermaßen gut behersche. Was bleibt ist DirectX 11/12 und C++ mit Visual Studio. Hat wohl keinen Sinn gegen C++ sich zu sträuben. Es wird überall in der Computergrafik verwendet.
    OpenGL 4.6 gibt es zwar, aber wenn es nur ein Windows und Linux-Produkt ist und Windows schon DirectX hat, dann kann ich gleich DirectX nehmen (muss mich halt nur Umgewöhnen, da ich von OpenGL es anders gewohnt bin).

    Software Renderer! Ich dachte Du wärst meine Rettung um ja kein C++ mit DirectX zu lernen. (Nein, ich will kein Unreal und Unity. Es gibt kein rationalen Grund dafür, außer, dass ich Herr meiner Lizenzen werden will und Unabhängigkeit vorziehe.)



  • *den schlechten OpenGL-Treibersupport... (ich wollte Unterstützung schreiben...)



  • Visual Studio geht ja mittlerweise auch mit dem Clang Frontend (google mal nach "Clang/C2"). Würde mich wundern wenn damit kein C11 ginge.

    Und was OpenGL auf Apple angeht... würde mich auch sehr wundern wenn man auf OS X kein OpenGL mehr verwenden könnte. Dann würde kaum ein Spielt mehr auf OS X laufen und vermutlich auch kein einziger HTML 5 Browser.



  • hustbaer schrieb:

    Visual Studio geht ja mittlerweise auch mit dem Clang Frontend (google mal nach "Clang/C2"). Würde mich wundern wenn damit kein C11 ginge.

    Und was OpenGL auf Apple angeht... würde mich auch sehr wundern wenn man auf OS X kein OpenGL mehr verwenden könnte. Dann würde kaum ein Spielt mehr auf OS X laufen und vermutlich auch kein einziger HTML 5 Browser.

    Hat es auch so etwas wie valgrind und ddd? Stimmt es gibt ja noch WebGL...
    Also muss ich doch kein C++ lernen!? Bin zwar nicht Torvalds "C++ is a horrible language", aber ich bin faul und möchte nicht für jede scheiss API eine andere Programmiersprache erlernen (looking at you Apple). Da gibt es auch einen Entwickler der so ein MMORPG in C programmiert (kein C++). Also gibt es vielleicht doch Hoffnung mit C und OpenGL.

    Was meinst wie das bei Apple nun sein wird mit OpenGL? Werden die ir'wann noch 4.6 unterstützen oder Vulkan?



  • iceyu schrieb:

    Was meinst wie das bei Apple nun sein wird mit OpenGL? Werden die ir'wann noch 4.6 unterstützen oder Vulkan?

    Mit Vulkan hast du bestimmt gute Chancen sehr gute Platformunanbhängigkeit zu bekommen. Für Macs gibt es MoltenVK, was Vulkan auf Metal abbildet. Allerdings braucht man für Vulkan eine halbwegs moderne Grafikkarte. Da du sowieso von OpenGL 4.6 sprichst sollte das aber das geringere Übel sein, oder?
    Persönlich würde ich die Vulkan API immer der OpenGL API vorziehen; deutlich sauberer und modern designt. Was durchaus denkbar wäre (und mit sau viel Aufwand verbunden): einen Vulkan Software Renderer zu schreiben um unabhängig von der Graka zu sein. Es wurde zum letzen GSOC einer Angefangen, aber die Arbeit daran ist scheinbar zum Erliegen gekommen.



  • iceyu schrieb:

    hustbaer schrieb:

    Visual Studio geht ja mittlerweise auch mit dem Clang Frontend (google mal nach "Clang/C2"). Würde mich wundern wenn damit kein C11 ginge.

    Und was OpenGL auf Apple angeht... würde mich auch sehr wundern wenn man auf OS X kein OpenGL mehr verwenden könnte. Dann würde kaum ein Spielt mehr auf OS X laufen und vermutlich auch kein einziger HTML 5 Browser.

    Hat es auch so etwas wie valgrind und ddd?

    Alternative zu valgrind wäre DrMemory.
    Was ddd angeht - wenn du einfach nen grafischen Debugger haben willst, ja, Visual Studio hat sowas. Und was ich von meinen Kollegen so höre ist der um einiges besser als die ganzen GDB Frontends. (Ich hab bisher quasi nur mit Visual Studio debuggt, daher kann ich nur sagen dass der Visual Studio Debugger sehr gut ist, aber keinen Vergleich zu GDB & Co anstellen.)

    iceyu schrieb:

    Also muss ich doch kein C++ lernen!?

    Natürlich nicht.
    Müsstest du auch nicht wenn du einfach auf C11 verzichtest.



  • iceyu sagte in Software Renderer - Rat u. Beispiele:

    Gibt es Beispielprojekte die 3D Software Rendering mittels SDL2 erzielen?

    Wenn du eine recht gute Referenzimplementierung eines Software-Renderers sehen möchtest, so kann ich dir mal den Code der Irrlicht Engine empfehlen, da der sehr viel Out-of-the-box unterstützt (Multitexturing, Licht, usw.): http://irrlicht.sourceforge.net/

    Ist zwar jetzt nicht direkt SDL2, doch im Grunde benötigst du ja nur das wissen, wie du eine Surface anzeigst, den Rest musst du ja sowieso "per Hand" machen.