Projekstruktur

[Matthias Gubisch]

Hallo Forum
ich würde gerne mal eure Meinung hören zu folgendem Problem:

Aktuell kompiliere ich meine Engine als statische library.
Das hat den Vorteil dass ich z.B. die Main und damit auch init und shutdown calls zur engine darin gut verstecken kann und damit die Testprojekte einfacher werden, ähnlich wie die SDL das macht.
Das impliziert aber auch dass alle Anwender der Engine alle Abhänigkeiten explizit linken müssen.
Bisher ist mir das nicht aufgefallen weil VS das schön versteckt solange man sich in der gleichen Solution befindet.

Idee deshalb: Man packe die Engine in eine DLL (die API ist dafür vorbereitet und sollte kein Problem machen...)
Aber was mach ich dann mit meiner Main? Das würde ich gerne aus convienience Gründen beibehalten dass die einfach nur reingelinkt wird und sich der User (wenn er das nicht explizit will) sich nicht damit rumschlagen muss.

Idee meinerseits ist jetzt eine statische lib als Engine Loader zu schreiben in der die Main beinhaltet ist und die ansonsten die API einfach nur durchreicht. Aber ich scheue etwas den Warnungsaufwand da ich ja alle API Änderungen dort ebenfalls nachziehen muss.

Hat hier jemand eine Meinung oder gute Idee wie ich
a) das Linker problem gelöst bekomme
b) trotzdem noch die Main zur Verfügung stellen kann?

[antisteo]

Bau doch lieber die Engine als Executable und das Spiel ist ein Skript / eine DLL / ein Asset-Ordner.

[Matthias Gubisch]

Interessanter Gedanke, muss ich mir mal durch den Kopf gehen lassen.

[Schrompf]

Ich würde erstmal die Frage klären, warum Du das Problem überhaupt lösen möchtest, wenn es für Dich doch funktioniert und niemand sonst jemals die Engine in die Hand kriegt? Für mich klingt das nach reinem Sauberkeitsdrang, also ein reines Wohlfühl-Problem. Und ich würde spekulieren, dass es auch echte Probleme gibt, die man stattdessen lösen könnte.

Ansonsten seh ich ehrlich keinen Unterschied, wenn Du das jetzt in ne DLL schiebst. Ist halt alles bissl langsamer als statisch gelinkt, weil jeder Call ne doppelte Indirektion geworden ist, aber sonst ist alles genauso wie beim statischen Linken. So why bother?

[Matthias Gubisch]

Ich würde erstmal die Frage klären, warum Du das Problem überhaupt lösen möchtest, wenn es für Dich doch funktioniert und niemand sonst jemals die Engine in die Hand kriegt? Für mich klingt das nach reinem Sauberkeitsdrang, also ein reines Wohlfühl-Problem. Und ich würde spekulieren, dass es auch echte Probleme gibt, die man stattdessen lösen könnte.

Ansonsten seh ich ehrlich keinen Unterschied, wenn Du das jetzt in ne DLL schiebst. Ist halt alles bissl langsamer als statisch gelinkt, weil jeder Call ne doppelte Indirektion geworden ist, aber sonst ist alles genauso wie beim statischen Linken. So why bother?

Meine Engine besitzt mittlerweile einen Editor (ok, der steckt noch in den Kinderschuhen, aber trotzdem...), und der legt mir beim anlegen einens neuen Projektes auch eine VS Solution nebst Projekt an um Entity verhalten programmiern zu können und so weiter (aktuell mit c++)
Das funktioniert recht gut, aber sobald sich an den Dependencies er Engine was ändert, ist es zwar trivial das für neue Projekte zu berücksichten, für bestehende Projekte allerdings nicht, das müsste ich von Hand machen und das nervt mich.
In der Regal sind das interne Dinge die die API nicht betreffen wie der D3D12Memory Allocator, ShaderCompiler usw., von daher möchte ich auch gar nicht unbedingt das das nach aussen hin sichtbar ist...

Und ja ich will tatsächlich mal ein Game damit machen ;) hoffentlich spätestens zur nächsten ZFX-Action

[Chromanoid]

Stumpf ist Trumpf :)

Mach das, was Du am einfachsten findest. https://grugbrain.dev/

Am Ende ist sowas bei Hobby-Projekten halt Hobby oder Prokrastination der eigentlichen Herausforderung... Also meiner Erfahrung nach...

[Schrompf]

Ich kapier's nicht. Du hast eine Lib. Die muss halt neu gebaut werden, wenn sich was ändert. Du packst die Lib mit in die Solution, Du stellst sie als Dependency in Deinem Hauptprojekt ein, fertig.

Falls Dein Editor irgendwie Code generiert, wär's wirklich ne Idee, diesen Code in ne DLL zu packen und die Engine als HostProzess diese DLL laden zu lassen. Ermöglicht Dir auch Hot Reloading in gewissem Maße. Schlug ja auch schon Anti vor.

[Matthias Gubisch]

Ich kapier's nicht. Du hast eine Lib. Die muss halt neu gebaut werden, wenn sich was ändert. Du packst die Lib mit in die Solution, Du stellst sie als Dependency in Deinem Hauptprojekt ein, fertig.

Falls Dein Editor irgendwie Code generiert, wär's wirklich ne Idee, diesen Code in ne DLL zu packen und die Engine als HostProzess diese DLL laden zu lassen. Ermöglicht Dir auch Hot Reloading in gewissem Maße. Schlug ja auch schon Anti vor.

Leider nicht, weil der schrott von VisualStudio die dependencies nicht dazupackt zur .lib, das macht die *** IDE nur für executeables und DLLs...
Was dazu führt das ich die lib nicht einfach zu einer exe dazulinken kann wenn ich eine neue Abhängigkeit bekomme...

Einfach eine DLL nimmt mir halt die Möglichkeit die Main bereitzustellen, was ich einfach praktisch finde...

Denke es wied darauf rauslaufen dass ich die Engine in eine DLL packe, die "main" exportiere und meinen Editor eine echte Main generieren lasse die genau dies eine Methode aufruft, alles andere klingt nervig komplex

Engine als Hostprozess gefällt mir bei genauerem überlegen von der usability in meinem setup nicht so gut.
Hätte lieber ein executeable per Client...

[NytroX]

Wenn du die Engine als DLL machst, stellst du dann nicht sowieso einen Header (engine.h oder wieauchimmer) bereit für den "Benutzer" der Engine?
Und wenn du dann darin die main() oder WinMain() machst, ist doch alles bestens, oder nicht?

Du könntest das dann auch so wie SDL machen, dass man dann aussuchen kann, ob die main() von der Engine gemacht wird oder nicht.
https://wiki.libsdl.org/SDL3/SDL_MAIN_USE_CALLBACKS

[Matthias Gubisch]

Wenn du die Engine als DLL machst, stellst du dann nicht sowieso einen Header (engine.h oder wieauchimmer) bereit für den "Benutzer" der Engine?
Und wenn du dann darin die main() oder WinMain() machst, ist doch alles bestens, oder nicht?

Du könntest das dann auch so wie SDL machen, dass man dann aussuchen kann, ob die main() von der Engine gemacht wird oder nicht.
https://wiki.libsdl.org/SDL3/SDL_MAIN_USE_CALLBACKS

Die SDL Lösung mit 2 Libs eine für die main() und eine für die Engine könnte tatsächlich auch ganz gut sein.
Die Headerlösung geällt mir irgendwie einfach nicht

Danke schonmal für eure Vorschläge, ein wenig was zum experimentieren hab ich ja jetzt ;)