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

Aktuelle Zeit: Di Mär 19, 2024 04:15

Foren-Übersicht » Sonstiges » Meinungen zu den Projekten
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 60 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4
Autor Nachricht
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Do Mai 22, 2014 13:06 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
"ForEach" gebaut?
http://www.heise.de/developer/artikel/C-11-auch-ein-Stimmungsbild-1345406.html?artikelseite=3

Das du dort und an anderen Stellen mit "Delegates" arbeitest, bremst durch den virtual Call nur die Performance aus und ich sehe das als Memberfunktion auch vom Design her etwas kritisch.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Do Mai 22, 2014 13:33 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Die Delegates sind tatsächlich ein Manko an der Stelle aber ich wollte nun nich alles mit einmal auf den gewollten Stand bringen und die Delegates fallen da drunter.
Die Delegates sind allerdings FastDelegate und bei voller optimierung sind die entsprechenden Delegates nur noch c Funktionen.
Wenn man die Delegates mit Klassen macht, dann bauen die Templates Methoden Calls aber es gibt extra Templates die virtual auflösung zur Compiletime behandeln. Ob das funktioniert ist ne andere Story, dass hab ich nie getestet aber im ThreadPool verwende ich ja C-Like Funktionen und die dampft das Template Bundle ein.

Zitat:
Mit Sleep(0) bin ich bei 22Cycles mit der neuen Variante, 8Cycles für die alte im Debug Build und 15Cycles für neue und 9Cycles für alte im Reelase Build gekommen.

Ich mein 15Cycles für den ganzen kram, der da passiert ist aktuell akzeptabel, vorher waren es 1115Cycles und das for auf 3 Element braucht 9Cycles bei mir.
Es gibt noch ein paar verbesserungspunkte, wie z.B. Delegates durch lambda und C Funktionen zu ersetzen, die Allokationen für Tasks aus einen seperaten Pool zu machen, damit man nicht mal in die verlegenheit kommt beim Kernel nach Speicher fragen zu müssen und das Task Sheduling ist auch noch nicht so konform mit meiner Vorstellung von tollem Task Sheduling.

Ich will aber erstmal mein Code auf ein einheitlichen Stand für Linux, Unix und Windows bringen, sowie die String Klasse finalisieren.
Leider hatte ich mit meinem Kompressor wieder mal ablenken lassen :\

_________________
"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  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Fr Mai 23, 2014 09:04 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Kannste nich die Literale aus C++11 nehmen um sichere Stringerzeugung zu machen?

grüße

_________________
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: @Radon Framework
BeitragVerfasst: Fr Mai 23, 2014 09:33 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Das ist eine Möglichkeit, die ich in betracht ziehe.
Ich hab schon einige Codefetzen im Netz gefunden die z.B.
Code:
  1. String bla("mystring"_const);

verwenden, um das Problem zu lösen.

Wie ich geschrieben hab muss ich mich erstmal intensiv mit auseinander setzen, dass soll für VS2010 funktionieren und das ist eher wenig C++11 tauglich.
Allerdings ist das auch sehr Fehlerträchtig, wenn man bedenkt, dass man es mal vergessen kann.
Code:
  1. mylist.Append("A Radon Framework String"RFS);

Sowas wäre möglich und völlig C++ Standard konform aber aktuell würde auch folgendes gehen
Code:
  1. mylist.Append("A Radon Framework String");

Da der Compiler 1 indirekten Versuch hat, findet er den entsprechenden template Constructor und baut eine Instanz on the fly und übergibt die.

Sollte die Anzahl an Konstruktoren tatsächlich sich so stark auf die Größe auswirken, dann wäre RFS eine Lösung die ich gehen würde.

_________________
"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  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Fr Mai 23, 2014 09:39 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Idealerweise sorgst du dann dafür, dass der weg mit const char* nicht gegangen werden kann. Z.B. indem du einen expliziten Konstruktor für const char* anbietest, der dann aber via static_assert fehlschlägt. Wobei, da könnte einem SFINAE beißen…

grüße

_________________
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: @Radon Framework
BeitragVerfasst: Fr Mai 23, 2014 11:21 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich biete gar kein char const * Konstruktor an und damit kann man auch nicht böses machen, nur das Literal Template kann angesteuert werden und auch nur, wenn es auch eines ist. Die restlichen Konstruktoren sind aktuell explicit und damit geht auch da nix indirektes.
Also die aktuelle Lösung ist bis her sicher.

_________________
"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  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: So Okt 02, 2016 11:17 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Wo du gerade von UI und Vektorvorschriften redest, mich würde interessieren, ob du dich schon mit der "HiDPI-Problematik" beschäftigt hast, und wenn ja, wie du das in der Radon UI lösen willst/gelöst hast.

Kurze Zusammenfassung: Durch hohe Pixeldichten hat man ja das Problem, dass Dinge, die Pixel als Maßeinheit verwenden, recht klein werden. Bei Schriften kann man das gängigerweise kompensieren indem man die Schriftgröße erhöht, aber andere UI-Elemente wie Trennlinien (die ja auch Einfluss auf Bedienbarkeit haben können) etc. werden gemeinhin nicht mitskaliert und man hat das Problem, dass man auf unterschiedlichen Bildschirmen ggfs. sehr unterschiedliche Pixeldichten hat (z.B. ein 2560×1440 13" Notebook neben einem 19" 1280×1024 TFT aus dem letzten Jahrzehnt). Bei Qt kann man inzwischen Environment-Variablen setzen, die entweder sagen, dass Qt aus den DPI der Bildschirme selber einen Skalierungsfaktor errechnen soll oder man gibt für jeden Bildschirm manuell einen Faktor an. Das funktioniert recht gut, zumindest bei ganzzahligen Faktoren. Bei nicht-ganzzahligen sieht man natürlich Artefakte, bei 1.5 z.B. ist nur jede zweite Linie dicker und sowas (was immer noch besser ist als jede zweite Linie verschwommen zu haben…).

viele Grüße,
Horazont

_________________
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: @Radon Framework
BeitragVerfasst: Mo Okt 03, 2016 00:47 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich hatte auch ein Artikel vor längerer Zeit mal im Thread gepostet, wie ich mit den Auflösungen hantiere.
Für jeden Monitor Erfasse ich die DPI und multipliziere mit den Eingaben.
Also wenn ich ein 640x480 Fenster hab, dann gehe ich 96dpi als Normal aus und errechne ein Faktor aus der 96 und der wirklichen DPI.
So sind die Fenster gleich groß auf 2 unterschiedlichen Monitoren, weil er auf dem mit über 96dpi entsprechend das Fenster größer macht.
Aktuell erfasse ich noch nicht das verschieben über mehrere Monitore, damit wird das Fenster auf dem 96dpi Monitor größer, wenn ich es rüber ziehe aber dafür müsste ich auch nur eine weitere Message vom OS API abfragen.
Ich render komplett in OpenGL und die Canvas Komponente skaliert mit dem Fenster und damit passen sich alle Vektorgrafiken in der Auflösung mit an.

Aktuell habe ich noch keine Fonts drin, würde ich Pixel Fonts nutzen, dann müsste ich entsprechend bei Größenänderungen eine andere Schriftgröße wählen und die Texturen updaten.
Ich will aber erstmal Vektorbasierte Schrift probieren und sonnst gehe ich auf signed distance field font, da die recht lange mit skalieren.
Konkret schwebt mir da aktuell ein Textur mit mehreren Mipmaps vor also 2048x2048,1024x1024,512x512 und im Shader wählt man dann konkret die mipmap, anhand der fontsize.
Signed distance field font sind ein alter Hase und funktioniert wunderbar aber ich will halt mal gucken ob Vektor basierte Fonts da nicht vieleicht schon schneller sind.

DPI Example
GetDeviceCaps mit HORZSIZE/VERTSIZE und HORZRES/VERTRES kannst dir die DPI errechnen.
Probleme mit GetDeviceCaps
Ich nutze die 2. Variante bei mir, da die immer Funktioniert, so bekommt man auch noch Displays, die angeschlossen sind aber aus sind.

_________________
"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  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mo Feb 05, 2018 20:24 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Ist Konsolensupport geplant (Xbox One, PS4, oder nur spätere Generationen)?
Was planst Du für Physik und Rendering? Deferred Shading Pipeline z.B.
Oder wird das dem User überlassen?
Schönes Projekt übrigens!

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Mo Feb 05, 2018 21:03 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Radon Framework ist nur ein Core Framework, was grundlegende Probleme lösen soll.
Ich sehe es so als das .Net,STL,QT für Spiele und deswegen gibt es kein Physic, Sound oder fertigen Renderer.
Im RF sind oder kommen Threading, Task management, lazy evaluating math mit JIT, Timer, Dateisystem Abstraktion(FileWatcher, mapping, preallocation, lazy write), Allocator, String manipulation, Container für Performance, Fenster/Rendercontext, Fonts, Bildverarbeitung, Sockets, Entity Compontent system, Cmake framework und spezielle dinge wie mDNS, micro WebServer.

Auf lange Sicht werden die großen Platformen unterstützt werden müssen.
Aktuell wären es z.B.
  • PC 32/64(Win,Linux,OSX)
  • Smartphone(iOS,Android)
  • Konsole(XBox,Playstation,Nintendo)
  • Embedded(RPi 32/64)
Momentan pflege ich Windows, von Zeit zu Zeit ziehe ich es für Linux und Raspberry nach.

Ich will allerdings noch Organesson als eine Middleware separieren und das kostenpflichtig vermarkten, um RF weiter entwickeln zu können, anfangs Feature Bounties aus zu schreiben und von Zeit zu Zeit ein Technical Writer für gute Docu bezahlen kann. Des weiterem benötige ich einiges an Software für CI.

Desweiteren plane ich aktuell Milestones für ein Patreon Account und will in Kürze mal Bounties verfassen und schauen was viel Benefit mit wenig Aufwand bringt.
Z.B. Appvoyer und Travis support, um für VS2015,VS2017, clang, gcc, windows, linux, osx zu bauen und testen können.

_________________
"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  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Di Feb 06, 2018 08:27 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Das könnte einem schon nen Haufen Arbeit abnehmen!
Vor ein paar Jahren hätte ich sowas dringend gebraucht ;)
Wegen dem Rendering und der Physik hab ich gefragt, weil ich an die ganzen Indiedevs gedacht habe, die das meistens nicht alles selber coden wollen oder können.
Was für die auch sehr wichtig wäre ist der Umgang mit Modellen und Animationen.
Wird es dafür was geben?
Das wäre mal praktisch. Die Frameworks, die ich kenne (SDL, SFML etc.), können eher nur Texturen, Fonts und Shader.
Und wird es eine Grundpipeline für FBO/Rendertextures und Shader etc. geben?
Also z.B. eine abstrakte Shaderklasse, die dann alle Plattformen handeln kann?
Siehst Du als Primärkunden Gamedevs, oder eher Entwickler von medizinische Software, Apps für Autos, Simulationen etc.?
Einige Grundfunktionen für Sound würde ich schon anbieten für die Gamedevs.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Di Feb 06, 2018 10:52 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Als Physiksystem würde ich jeden empfehlen Bullet zu nehmen, da es sehr starke Entwickler, wie Sony, hinter sich hat und einnsehr gutes API Design hat. Es ist Open Source und kostenlos, was Alternativen eigentlich nur interessant macht, wenn man was sehr spezielles wie mehrere Gravitationsfelder, zerstörung von Geometry oder Fluid simulation.
Bei sound ist es ähnlich, fmod ist wirklich so high class, dass sich für mich nicht die Frage stellt. Es kostet erst ein kleinen Ovolus, wenn man das geld dafür auch eingenommen hat.
Allerdings gibt es hier viele Alternativen, mit unterschiedlichen Features und Preisen.

Meine Sorge mit dem hinzufügen von solchen Lösungen ist, dass ich mich nur noch wenig zu Game Engines und Frameworks(sdl,sfml,..) abtrennen kann und das gleiche Problem mit unzureichenden Middlewares habe und noch Performance und Features durch abstraktion der Api hätte.

Für Modelle und Animation wird es was geben, bzw. gibt es schon was.
Ich hab ein Tool, welches noch nicht final ist aber schon zur automatischen Asset generierung genutzt werden kann.
Es ist ein mDNS basierter netzwerk service, welcher mit einem filewatcher diverse Projekte überwachen und Tools ausführen kann, wenn festgelegte Dateitypen sich ändern. Später soll es als mesh laufen und eine Datenbank liefern, die alle assets enthält. Es soll dann möglich sein die DB nach assets zu fragen und deren abhängigkeiten. Also eine sehr spezialisierte und damit optimierbare Lösung, die zwar Sqlite abbilden kann aber viel zu abstrakt und damit langsamer und speicherhungriger ist.

RF hat aktuell eine Api für Render Commands, also es gibt Materialien, Texturen, Shader, Meshes, Frame Buffer und die werden Stateless und damit Multithreaded(üner Command Buckets) in ein render kern gebracht. Da hab ich als referenzimplementierung Opengl4 drin aber das ist noch Work in Progress, da ich noch nicht ganz zufrieden mit dem Funktionsumfang bin.
Eine eigene Shadersprache dazwischen zu schalten mag ich nicht, das zerstört die Möglichkeit existierenden GLSL, HLSL Snippets zu verwenden und man muss was neues lernen.

Ich sehe mich als lieferant für alle, die keine UI starke 3D Applikationen schreiben, sei es ein Game Engine, Spiele Entwickler oder Simulations Software. Für UI starke Anwendungen gibt es QT, das macht sein Dienst sehr gut.

Ich habe die Darenbank, das Entity component System und die kleinen Tools in extra repos und können per cmake config teilweise nachgeladen werden. Das Radon CMake framework hat seit kurzem auch ein Paketsystem, wo ich Bibliotheken und so weiter bequem integrieren kann.

edit:
Pakete
Code:
  1. # add Radon CMake framework
  2. include("Integrate.cmake")
  3. # add last stable morton version to the project
  4. rcf_addpackage(morton)
  5. # generate a static library target with libmorton as dependency
  6. Generate(MODULE RADONFRAMEWORK RadonFramework "Framework")
  7. AddPublicInclude(RADONFRAMEWORK ${RADONFRAMEWORK_LOCATION}/include/)
  8. AddDependency(RADONFRAMEWORK libmorton)
  9. Finalize(RADONFRAMEWORK)

_________________
"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  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Di Feb 06, 2018 14:18 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Eigene Shadersprache würde ich auch nicht empfehlen, die wenigsten würde gerne noch eine Sprache lernen.
Was aber super wäre, wäre Übersetzung von und nach glsl/hlsl evtl. auch pssl und weitere, weiß nicht was Nintendo z.B. macht.
Glaube Unity und Unreal machen das, indem sie hlsl nach glsl anbieten, in vielen Fällen wäre es aber umgekehrt hilfreicher.
Das würde bei der Portierung enorm Zeit sparen, glaube aber das das nicht so ganz einfach ist, das zuverlässig hinzubekommen, wäre aber soweit ich das gesehen habe ein Alleinstellungsmerkmal und würde mein Interesse z.B. stark wecken.
Denke so Grundsachen wie Texturen, FBOs, Materialien, Modelle kann man sehr gut auf alle Grafik-Apis verteilen, weil es alles Verarbeitung von Datenblöcken ist.
Aber das komplizierte ist ja eigentlich die Renderpipeline und wie alles miteinander interagiert, vor allem die Shader.
Wahrscheinlich ist es aber schwer da was allgemeines zu entwickeln.
Bei Unreal muss man mit irgendwelchen Blueprints rumhantieren und sich an die Renderpipline halten, wenn man nicht die riesen Codebase umwälzen will, und da wird man alt.
Bei Unity ist es glaub ich etwas mehr dem User überlassen.
Relativ einfach ist es, einen Standard Deferred Renderer aufzusetzen, wo man definiert, welche Buffer man möchte.
Das würde ich schon anbieten, damit man relativ locker loslegen kann. Forward rendering versteht sich, und ist auch kein Problem.
Ein großes Thema sind vernünftige Schatten, hast Du da was geplant?
Es macht denke ich schon nen Unterschied, wenn Du was zeigen kannst, was schon im Grundsetup recht ansehnlich ist, vor allem wenn es irgenwie viral gehen soll.
Super nervig für Spieleentwickler: Haare.
Aber da seh ich keine allgemeine Lösung, da die Modelle irgendwo herkommen, und i.d.R. nicht für die Lösung im Renderer gemacht sind.
Also ich würde, wenn Du Modelle und Animationen hast, Schatten, physical based rendering und deferred shading (dann hast Du auch schon postprocessing wie blur mit in der Pipeline dabei), ein schickes Terrain und ein paar Environment Maps dazutun .
Dann kannst Du eigentlich Vieles recht ansehnlich rendern.
Wenn ich mir dein lowlevliges Zeug so ansehe, wird es für Dich wohl kein Act sein, das mit reinzuhauen.
Vielleicht kannst Du da auch mit nem Pilotkunden kooperieren.
Jedenfalls denke ich, dass es für viele die Entscheidung für die Nutzung des Produkts beeinflussen würde.
Wenn man gleich sein Modell reinladen kann und es sieht gut aus, ist man verleitet, weiter dran zu arbeiten.
Denke aber wirklich das es für Viele interessant wäre ein relativ lightweight Engine zu nutzen.
Bedenke sollte man aber schon, dass man auf Unreal und Unity-Seite nen riesen Asset-Store hat.
3D-Texturen, bzw. Voxelisation wäre sehr interessant für den medizinischen Bereich, und die haben Geld.
Autoindustrie hat auch massig Geld, und da wird auch mehr 3D kommen, also PBR und ein paar schicke Automodelle herzeigen :)

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Di Feb 06, 2018 16:30 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ja das wäre auch mein Weg und den MESA, Unity und Khronos gehen.
SPIRV-Cross
MESA und Unity hatten eigene Tools, Unity hatte das von MESA meines wissens genommen und überarbeitet.
Das sollte recht einfach sein, die Variablen zu tracken und per Key-Value Listen zu mappen.
Ich hab keine Ahnung von D3D und um das Sinnvoll zu implementieren, braucht man ein D3D backend.

Es gibt recht gute Umsetzungen für Cross Platform Abstraktionen, wo ich auch mich Inspirieren lasse aber was ich als Nachteil bei den sehe, ist zu starke Abstraktion und weglassen von Coolen speziellen Features, die voll Performance bringen aber nicht abstrahierbar sind.
Swapchain von D3D12 z.B. ist sehr cool aber ich kenne kein Pendant in OpenGL.

Unity ist flexibeler als Unreal Engine, bei UE muss man in der Regel das ganze austauschen oder ewig dran rum fummeln, bis es passt.
Unity kann man recht grannular die Komponenten weg knipsen, ein ehemaliger Kollege hat z.B. den ganzen Renderer durch ein eigenen ersetzt, der nicht wie bekloppt den GC getriggered hat.

Ich will mich aus den Rendering raus halten, das ist ein riesen Thema wo ich alleine schon bei Schatten gut einige Monate versenken kann und nach 6 Monaten sind die wieder veraltet. Da renne ich nur noch einem Feature nach. Firmen wie Epic, Unity, Amazon können einzelne Entwickler für sowas abstellen aber ich will erstmal Grundlegende Probleme lösen und es den Engine Entwicklern überlassen sich mit sowas rum zu schlagen.
Es kommen ständig neue Schattensysteme für Spezielle Kamerazustände, wie ISO, Ego, Gott, 3rd Person Perspektive.

Meine aktuelle Prio, sind die wirklichen Basisprobleme, die die Indies nicht lösen aber die waren Performance killer sind, weil sie nur die Fancy Papers von den Großen sehen und Rendertechnik XY umsetzen und vergessen, dass die auch schon Jahrelang ein Kern pflegen, der wirklich durchoptimierten kram hat. Eine schlechte String Klasse kann mal eben 20% Performance bedeuten(spreche aus Praxis-Erfahrung).

Einige Dinge werde ich auch als Middleware auslagern, die zwar OpenSource ist, wie RF aber ab bestimmten Umsätzen eine Comercial License benötigt.
So wie es FMOD, QT, Unreal Engine, Lumberyard und einige andere machen.
Aktuell hab ich folgende Module im Auge.
Organesson
RadiumDB
RadonFastEntityComponentSystem

Bei Animationen, Haare, Partikelsysteme, Pfadfindung und so weiter gibt es in der Regel ein Authoring Tool, was die nötigen Daten generiert.
In den Game-Studios nutzt man in der Regel Intermediate Formate wie FBX oder die meist genutzten Tools, Maya, Photoshop und erzeugen auf basis dieser dann die restlichen Daten in dem Tool.
Das geht heute wesentlich einfacher, wo man schon Loader Code von den Firmen bekommt.

Die Promodemo muss noch ein bisschen warten aber ich hab da schon ein Script für und wird schon 2-3k€ an Freelancer kosten.

Ich hab auch schon überlegt, mit wen ich kooperieren könnte. Bitsquit z.B. hatte mit Fat Shark zusammen gearbeitet und wurde dann von Autodesk gekauft und in die Produkte integriert. Ich will nicht aufgekauft werden aber Kooperationen, wo beide was von haben wären schon Sinnvoll.

PBR steht bei mir sehr hoch auf der Liste und ich hatte sogar in meiner Firma schon dazu über 1 Jahr an ein Projekt gearbeitet aber wir haben es eingemottet und uns auf das Kerngeschäft konzentriert.
PBR ist nicht nur für die Autoindustrie wichtig, sondern die ganze Produktindustrie. Die müssen auf extrem langsame renderer und kleine Materialdatenbanken zurück greifen, wenn die in ihren Konstruktionsprogrammen die sachen raus rendern und es dauert auch noch ewig.
Der Renderer ist nicht das Problem, sondern die Materialdatenbank und da hab ich ja Software schon geschrieben aber die Hardware ist voll aufwändig und teuer. Allerdings hab ich da mitlerweile andere Konzepte im Kopf, die möglich wären um zu setzen. Das geht aber nicht so schnell.
Da benötigt es ein bisschen Zeit, für ein neues Mockup um zu setzen ist aber in Arbeit.

Ich hatte gestern Nacht mit den Infrastrukturänderungen angefangen.
Github Organisation
Domain auf die Github Website umgeleitet.
Patreon werde ich heute fertig machen und auch die nötigen Schriftkram für Firmengründung.

_________________
"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  
 Betreff des Beitrags: Re: @Radon Framework
BeitragVerfasst: Fr Feb 09, 2018 21:15 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Hier die Mindmap, in der ich nun mal alles sammel.

_________________
"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  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 60 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4
Foren-Übersicht » Sonstiges » Meinungen zu den Projekten


Wer ist online?

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