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

Aktuelle Zeit: Do Mär 28, 2024 23:27

Foren-Übersicht » Programmierung » Allgemein
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 11 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Do Okt 20, 2016 23:51 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Hallo miteinander!

Ich habe ein paar Funktionen bzw. Klassen mittels c++ und OpenGL geschrieben.
Diese machen gewisse Berechnungen und Renderings.
Die Berechnungen kann man eigentlich alle via FBO mit Ping-Pong-Float-Texturen und entsprechenden Shadern machen.

Ich würde gerne diese Funktionen in eine Engine einbauen, um sie anderen besser zugänglich zu machen (als Asset oder so), und evtl. auch selbst ein kleines Game zu machen, wo die Berechnungen verwendet werden.

Ich schwanke gerade zwischen Unity und Unreal.
Unreal scheint mir sinnvoll, da es ja auch c++ ist, und meine Sachen berechnen auch manches einfach auf der cpu. Die Teile könnte ich dann eher problemfrei übertragen.

Ich habe aber gelesen, dass es in Unity einfacher sein soll, seine eigenen Shader, Renderpfäde, etc. einzubauen und bin deshalb unschlüssig.

Oder hat jemand vielleicht einen ganz anderen Vorschlag.

Ist es denn überhaupt möglich, solche Sachen zu übertragen, oder sind die Engines zu weit weg abstrahiert?
Bzw. was passiert mit der Performance, wenn ich es schaffe, es zu übertragen?

Grüße,
VinZ

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Okt 25, 2016 18:18 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Nun keine Ahnung was diese beiden Engines betrifft. Aber schau doch einmal bei den reinen OpenSource Vertretern wie etwas der Quake-, Build- oder Cube-Familie rein. Dort dürfte das Ganze am einfachsten umzusetzen sein und wer weiß vielleicht kommt ja dann noch ein weiterer Branch hinzu :)

Es gibt zum Beispiel einen MinGW Port von Quake II auf SF.NET, den ich immer mal wieder rauskram um solche Sachen zu Prototypen. Da läuft das ganze Setup (Compiler Einstellungen und co.) locker in ner halben Stunde durch und das Design ist so primitiv das man alles Mögliche sehr leicht umsetzen kann. Einziges Problem sind halt nur die ganzen Geschichten für das Lightmapping, die brauchen etwas an Hintergrundwissen damit die einen nicht ausbremsen... Man kann die allerdings auch für Decals missbrauchen :mrgreen:

Achja wenn du willst das ich dich ganz doll lieb hab, es gibt auch noch ein ähnliches Projekt für das beste Spiel ever: https://github.com/Alenett :)

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Okt 25, 2016 20:16 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Die großen Engines abstrahieren die APIs so weit möglich und haben i.d.R. auch eigene Shadercompiler/Sprachen, könnte also schwierig werden.

Die Unreal Engine ist Open Source (https://github.com/EpicGames/UnrealEngine), man muss sich nur einmal anmelden (siehe https://github.com/EpicGames/Signup). Danach darf man dann auch forken und Änderungen am Quellcode machen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Okt 26, 2016 00:59 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich kann davon abraten an Unreal dran rum zu fummeln, das ist unglaublich stark miteinander verstrickt und kann sehr schnell zum Zeitloch werden.

Unity ist zwar wesentlich einfacher dort ein Shader auf ein seperates Rendertarget laufen zu lassen aber ist C# und der GC macht für größere Projekte echte Probleme.
Unity arbeitet noch mit ner sehr alten Mono version die hat sogar Bugs, die schon 4-5Jahre alt sind und der GC ist echt mies und da geht für aufwändige Projekte die meiste Zeit rein.

Ich würde gucken ob du eine Data Driven Engine finden kannst die C++ ist oder eine sehr übersichtliche kleine Engine benutzen, wie z.B. Sauerbraten.

Lumberyard ist noch recht übersichtlich vom Code und nicht so stark verzahnt wie Unreal Engine.
Amazon hat CryEngine Code gekauft und stark überarbeitet, der aktuelle Code ist sehr übersichtlich allerdings ändert sich da noch recht viel, da es noch Beta ist.

Wenn noch studierst oder zur Schule gehst, wäre Stingray die beste Option.
Stingray war vorher Bitsquid und gilt bis dato als die beste Data-Driven Engine auf dem Markt.
Diese hat ein C++ Kern und nutzt json und Lua um den meisten Kram wie Renderpipeline, logic und so weiter zu machen.
Der Blog von den wird weiter geführt, da hatte Autodesk wohl nix gegen und er ist nun auch etwas lebendiger und jedesmal sehr Interessant.

Es kann aber genauso gut sein, dass ein kleines SDL, SFML framework mit Lua und ein paar libs dir besser zu diensten ist.
Lua hab ich so häufig erwähnt, weil Lua-Jit immer noch die schnellste Scriptsprache ist und in einigen Teilen sogar VC++ und Java schlägt.
Daher wird es meistens den anderen Scriptsprachen vorgezogen obwohl diese vieleicht bessere Syntax oder coole Sprachfeatures haben.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Okt 26, 2016 18:30 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Mhh vielleicht auch recht interessant: Wie wäre es denn mit einer Unterstützung für WPF / XAML-Editor? Da gibt es immer wieder Stellen an denen ich mich einfach nur nach OpenGL sehne. Oder besser gesagt etwas das einen mehr Kontrolle über das Rendering gibt.

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Okt 26, 2016 20:43 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
yunharla hat geschrieben:
Mhh vielleicht auch recht interessant: Wie wäre es denn mit einer Unterstützung für WPF / XAML-Editor? Da gibt es immer wieder Stellen an denen ich mich einfach nur nach OpenGL sehne. Oder besser gesagt etwas das einen mehr Kontrolle über das Rendering gibt.

Schau dir am besten mal QML an, das ist WPF sehr ähnlich aber arbeitet mit OpenGL.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Okt 27, 2016 17:54 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Na ich dachte da eher an etwas wie das Beispiel in OpenTK. Also Formshost mit vielleicht ein paar Rendertargetbitmaps oder so. Halt nichts außergewöhnliches.

[edit]

so jetzt endlich wieder daheim :)

ich war letzte Woche im Dauereinsatz zum Thema Performance und WPF. Das aktuelle Projekt ist ein gigantisches Framework mit mehreren GB an MVVM code. Der Grund war das der Proxy-Generator teilweise 3D über diesen ****** Viewport 3D gebunden hat. Das Problem hierbei ist halt das der UI-Thread dann total mit solchen billigen Krimskram wie Matrix Operationen und co. überlastet wird.

Leider konnten wir das dort nicht mit OpenTK umgehen da... nun ja MVVM halt. Tatsache ist aber das jeder Anfänger in OpenGL etwas besseres liefern könnte als Microsoft :)

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Okt 29, 2016 00:57 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Vielen Dank für die Vorschläge!
Ich habe jetzt auch noch weiter recherchiert und nachgedacht.
Ich denke, wenn ich es eh schon in eine bestehende Engine einbaue, sollte es eine sein, die zu möglichst vielen Plattformen (also auch neue Kosolengeneration und VR) kompatibel ist.
Somit fallen kleinere, bzw. ältere oder nicht mehr gepflegte Engines weg.
Es soll auch definitiv c++ sein.
Leider ist alles, was ich in die Richtung gesehen habe auf Hlsl-Shader ausgelegt, die cross-compilet werden.
Und ich habe leider auch kein Tool gefunden, dass glsl nach hlsl compliet.
Kenn da jemand was?
Bzw. von Spir-V nach hlsl? Dann könnte man es über den Umweg machen.
Ich tendiere jetzt jedefalls schon zu Unreal, habe kürzlich mit einem gesprochen, der hauptberuflich Spiele portiert, und der hat mir auch Unreal empfohlen.
Es gibt da anscheinend schon diverse Klassen, die auf einer relativ tiefen Ebene Zugriff erlauben, und ich hoffe mal, ich komme dann zurecht, ohne in den eigentlichen Enginecode einzugreifen.
Etwas nervig wird es aber wahrscheinlich, wenn ich die Renderpipeline grundlegend ändern möchte und mein eigenes Postprocessing will etc.
Es gibt aber mittlerweile echt verdammt viele Engines und ich werde noch etwas weitersuchen.

Lumberyard ist auch interessant, aber Amazon bindet einen dann an ihren Marketplace, wenn ich richtig informiert bin, und das finde ich grundsätzlich nicht so toll.

TAK2004 hat geschrieben:
Stingray war vorher Bitsquid und gilt bis dato als die beste Data-Driven Engine auf dem Markt.
Diese hat ein C++ Kern und nutzt json und Lua um den meisten Kram wie Renderpipeline, logic und so weiter zu machen.


Sind denn die Performance-Vorteile bei einer Data-Driven Engine so drastisch? Bzw. wieso wäre es noch empfehlenswert?
Wenn jetzt nur der Kern c++ ist und der Rest via Script läuft, kann ich dann überhaupt eigene c++-Klassen verwenden?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Okt 29, 2016 10:11 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Data driven design tendiert dazu besser für die Hardware zu sein.
Daten liegen in listen, arrays und ein paar anderen Container vor und werden häufig linear oder in festen schritten durchlaufen. Dies ist cachefreundlich, wenig branches und die cpu kann das nächste Element in der Liste häufiger vorraus ahnen. Pointerlisten können durch indirekt pointer resolution schneller arbeiten. Es ist vom design her schon stark parallelisierbar. Das langsame random access gibt es sehr viel seltener. Was noch langsam ist, sind logische verarbeitung, weil man viele vergleiche auf die daten macht. Diese kann man leider wegen dem design nicht zur compiletime optimieren, da daten erst zur Laufzeit bekannt sind. Deswegen macht es sinn diesen teil in eine jit sprache optimieren zu lassen. Diese schauen sich die branches an und sortieren die cases so, das die Masse true ist.
Branches sind nur langsam, wenn der true branche nicht zu trifft, denn dann wird nach ca100cycles ein rollback gemacht. Wenn er true ist, dann kostet dich ein branch nur ca 10 cycles. Zum
Vergleich eine Multiplikation sind 1 cycle, ein Register zugriff sind 1 cycle, cache level1 10cycles und Speicher Zugriff ~1000cycles.

edit:
Ein If braucht 10cycles für die ausführung und hat eine Latenz von 100cycles, also die cpu kann erst nach 100 cycles sagen ob true case eingetreten ist oder nicht. In der Zeit wartet die CPU nicht, sondern versucht weiteren Code aus zu führen und wenn das Ergebniss verfügbar ist guckt er ob er weiter machen kann oder in den else branch muss.
Ausführen kann er natürlich nur Code, der keine Auswirkung auf Speicher hat, z.B. eine neue Variable im Register mit einem Wert belegen, eine Rechenoperation oder ein Speicherblock anforder. Eine Operation, die ein Objekt zerstört kann man nicht rückgängig machen und dann würde die CPU warten, bis das Ergebniss da ist und das ist bei Profilern als "Stall" zu finden.

Visual Studio C++ hat "Profile Guided Optimization", wo man die Anwendung startet und dann Branches, cases, Ausführungszeiten von Funktionen und vieles mehr getrackt wird und dann beim nächsten kompilieren nutzt er diese Daten um dann Branches um zu stellen, Code um zu schieben, sachen zu inlinen, inlines wieder aufzuheben und einiges mehr, was halt nur mit Laufzeitdaten geht.
Dies ist nicht Deterministisch und damit kann je nach Laufzeit und Hardware des Profiles ein anderes Binary raus kommen und mal ist das Partikelsystem langsamer und mal schneller aber prinzipiell schneller als ohne "Profile Guided Optimization".
Wenn man also sich die Mühe macht ein Benchmark zu bauen und mit dem Feature durchlaufen zu lassen, dann kann man auch ohne eine Jit und Scripting unglaublich gute Ergebnisse erzielen.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Okt 29, 2016 11:03 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Vinz hat geschrieben:
Lumberyard ist auch interessant, aber Amazon bindet einen dann an ihren Marketplace, wenn ich richtig informiert bin, und das finde ich grundsätzlich nicht so toll.

Du bist nicht am Marketplace gebunden, du kannst es selber vertreiben. Amazon macht damit Geld, indem sie ihren eigenen Cloud Service direkt integriert haben und somit es viel einfacher ist Gameserver automatisiert und einfach dort zu hosten und zu entwickeln.
Du bekommst schon fertige Beispiele um Highscore, Useraccounts und so weiter zu verwalten.

Vinz hat geschrieben:
Leider ist alles, was ich in die Richtung gesehen habe auf Hlsl-Shader ausgelegt, die cross-compilet werden.
Und ich habe leider auch kein Tool gefunden, dass glsl nach hlsl compliet.
Kenn da jemand was?
Bzw. von Spir-V nach hlsl? Dann könnte man es über den Umweg machen.

HLSL zu GLSL wird gemacht, weil MESA diesen für D3D emulation entwickelt und pflegt.
Wieso was eigenes bauen, wenn eine große Entwicklergruppe mit teilweise bezahlten Leuten sich drum kümmert es zu schreiben und zu pflegen.
Hier arbeiten Intel, NV und AMD mit kostenlos gestellten Programmierern dran, damit es möglichst Performant auf der eigenen Hardware läuft.

Es sollte aber auch ein GLSL zu HLSL compiler geben, da FireFox, Chrome, Edge und co ja WebGL auf D3D mappen(unter Windows, zumindestens als ich das letzte mal geguckt hab).
Ich würde mal in den Code bases von diesen Projekten gucken aber da die WebGL Implementierungen ziemlich lahm sind und auch nur für Windows verwendet wird, wird das wohl nicht so gut optimiert sein wie HLSL zu GLSL.

Vinz hat geschrieben:
Wenn jetzt nur der Kern c++ ist und der Rest via Script läuft, kann ich dann überhaupt eigene c++-Klassen verwenden?

Klar, die haben mit Reflection halt nur den ganzen C++ kram für Lua verfügbar gemacht, damit du auch per Scripting alles machen kannst aber du kannst genauso gut alles in C++ machen. Die Kamera ist in C++ geschrieben aber die Steuerung dann halt mit einem Lua Script, weil selten jemand die Kamera neu erfinden wird aber die Steuerung für jedes Spiel total unterschiedlich ist.
Ein guter Richtwert ist immer die häufigkeit der Änderung * Wartezeit bis zum Testen der Änderung.
Je höher die verbrannte Zeit je sinniger ist es dies mit Scripten zu erschlagen, da man diese zur Laufzeit neu bauen kann und nicht die Applikation neustarten muss.
Runtime Compiled C++ ist ein Versuch das auch mit normalen C++ machen zu können.
Dabei wird hot patching von VC++ genutzt, wo man eine oder mehrere units neu baut und zur laufzeit patched.
Dies geht aber nur auf ein sehr beschränkten Scope und ist sehr viel Aufwand.
Ich hab das mal ausprobiert und fand es unpraktisch.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Okt 30, 2016 21:45 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
TAK2004 hat geschrieben:
...
Es sollte aber auch ein GLSL zu HLSL compiler geben, da FireFox, Chrome, Edge und co ja WebGL auf D3D mappen(unter Windows, zumindestens als ich das letzte mal geguckt hab).

Stimmt. Ich habe jetzt auch was gefunden, von NVIDIA, ist zwar nicht mehr ganz aktuell, aber man kann glsl oder cg nach glsl oder hlsl shader source code oder auch assembly code übersetzen lassen, was auch interessant sein kann:
http://http.developer.nvidia.com/Cg/cgc.html

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 11 Beiträge ] 
Foren-Übersicht » Programmierung » Allgemein


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 25 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.192s | 17 Queries | GZIP : On ]