Window creation

Der Plan des Tickets ist, eine Grundlage des Fensters zu schaffen aus mit dem weitergearbeitet, sowie erweitert werden kann und schonmal grundlegende Funktionalitäten zu bieten.
Zur Diskussion steht ob sowas wie die Swapchain und Events in der Window-Klasse gehandelt werden oder in dem eigentlichen Programm gehandelt werden soll.

• Extensions + GLFW
• Fenster erstellen
• simpler Eventpoll, damit man das Fenster schließen kann
• Surface erstellen -> Swapchain

@gaida @jfmorgenstern @kkraemer4 @vaka1997

added 🍪 ToDo label

added 🖥️ I/O label

assigned to @gaida

assigned to @jfmorgenstern and unassigned @gaida

assigned to @gaida and unassigned @jfmorgenstern

assigned to @jfmorgenstern and unassigned @gaida

assigned to @gaida and unassigned @jfmorgenstern

no multiple assignees

See: https://gitlab.com/gitlab-org/gitlab/-/issues/22171

changed the description

changed due date to May 04, 2021

Ablauf

• entsprechendes Issue zur Window Creation wurde erstellt
• wir hätten nichts dagegen, die offenen Todos in der Context Klasse zu ergänzen (am besten noch diese Woche fertigstellen)
  • Katharina, Vanessa
• Diese Woche mit dem Window beginnen (bis Dienstag)
  • Sebastian, Josch
• Nächste Woche vermutlich Swapchain

Überlegungen

• Was soll das Fenster können?
  • z.B. Resizing
  • was passiert beim resizing?
  • Fullscreen mode on/off?
• Swapchain
  • wie setzen wir gewisse Attribute? (z.B. ob ein spezifischer Rechner eine bestimmte Operation/Einstellung überhaupt unterstützt)
• Welche Freiheiten geben wir dem User des Frameworks? (z.B. soll immer die dedizierte/nicht-dedizierte Grafikkarte verwendet werden)

Unser nächstes Treffen

• keine regelmäßigen Treffen, eher spontan
• für Vorbesprechung oder Coding
• nicht um Stand zu besprechen (dafür wäre doch Dienstag)
• aktuell Montag, 03.05.21, 12:00 Uhr

Ich hab schonmal eine Window.cpp/.hpp erstellt und Minimales implementiert, damit wir am Montag einfacher starten können.

Beim Verändern der Größe eines Fensters muss die Swapchain neu erzeugt und ersetzt werden. Ich würde tatsächlich raten, die Events von GLFW alle in separate Event-Handler zu überführen, so dass man sich kaum mit Pointern wie GLFWwindow* oder void* rumschlagen muss. Hilfreich dafür ist std::function um sich z.B. eine Liste an Lambdas oder Funktionen anzulegen, welche bei einem Event aufgerufen werden sollen.

-> #14 (closed)

changed the description

removed 🍪 ToDo label

added 💻 Doing label

changed the description

Eine Frage zum VkSurfaceKHR und ob dieses in der Window-Klasse angelegt werden soll.
So wie ich das gerade gesehen habe ist das VkSurfaceKHR nur relevant für die Swapchain und kann auch erst für die Swapchain erstellt werden.
Da das VkSurfaceKHR und die Swapchain die Instance benötigt würde es deshalb erst nach dem Erstellen des Context erstellen. Der Context wiederum benötigt die Extensions für GLFW, deshalb würde ich vorschlagen, das glfwInit() in die Window-Klasse zu legen, welche vor dem Context aufgerufen werden sollte.
-> nicht aufrufen würde bedeuten, dass man Offscreen-Rendering machen möchte oder sollte das glfwInit() immer in der Context-Klasse aufgerufen werden?

Das war auch so eine Sache, worüber @kkraemer4 und ich uns Gedanken gemacht haben. Eventuell könnte man auch in der create Funktion vom Context einen bool mitgeben, z.B. bool enableWindow. Falls diese Variable auf true steht, könnten wir das auch so machen, dass dann die Window class gecalled wird und dabei GLFW initialisiert und weitergibt. Über das Window könnten wir dann die benötigten Extensions getten und dann der Instance übergeben. Wir waren uns noch unsicher, wie viele Argumente man der create Funktion mitgeben sollte ^^; Im Grunde genommen, würde das bisher nicht wirklich viel an unserem Code ändern. Man hätte dann wie ein windowInit(), welches dann die Window class aufruft und GLFW initialisiert. Jeglicher Rest würde dann in der Window class passieren, I guess. :)

Würde sagen außer Width, Height und Titel kann eigentlich alles optional bei creation sein.

Edit: Da vorher im falschen Thread:

Denke glfwInit() sollte in Window Klasse, weil es ohne window keinen Sinn für glfw gibt, oder?

https://www.glfw.org/docs/latest/context.html#context_offscreen
"GLFW doesn't support creating contexts without an associated window."

Ich find die Idee des Einbinden sehr gut, da es alle Probleme löst die ich mit dem Konzept habe.
Da das VkSurfaceKHR unabhängig ist kann man das hervorragend trennen.

Ich würde vorschlagen Aufrufe wie glfwInit() und andere globale Initialisierungen auszulagern in eine Funktion, die nicht Instanz-abhängig ist. Also möglichst weder bei Erzeugung eines Fensters noch bei Erzeugung eines Contextes. Ansonsten bräuchte man da definitiv noch eine Sicherung, dass es bloß einmal aufgerufen wird.

Es sollte auch überprüft werden, ob die Initialisierung erfolgreich ist.

Würdest du dies in eine Utils-Klasse stecken oder in Context nur nicht in dem create?
(Context wäre je ebenfalls abhängig)

Vielleicht eine CoreManager-Datei nur mit globalen Funktionen. Die würden wir dann nicht in die Client-side API einbinden. Also am besten diese auch nur in den Source-Files includen, statt in den Headern.

changed the description