Opensourcegame-engine Godot krijgt ondersteuning voor Wayland-displayserver

Opensourcegame-engine krijgt ondersteuning voor de Wayland-displayserver. Daarvan zit een eerste experimentele feature in een bèta. Het gaat nog om een test, waar de makers ruim twee jaar aan hebben gewerkt.

De ontwikkelaars achter Godot beschrijven de ondersteuning in de releasenotes van Bèta 1 van Godot 4.3. Die krijgt officieel ondersteuning voor Wayland, de displayserver die door steeds meer Linux-distributies wordt geïmplementeerd. De ontwikkelaars achter Godot schrijven dat gebruikers al sinds 2014 vragen om ondersteuning, maar dat het nu pas mogelijk was om die in de game-engine te zetten. Daar werd volgens de makers twee jaar aan gewerkt. Godot werkte al sinds 2020 aan de ondersteuning, maar destijds was de architectuur daar volgens de ontwikkeling niet klaar voor.

De ondersteuning voor Wayland gaat gepaard met ondersteuning voor OpenGL ES-driver voor desktops. Dat werkt voorlopig alleen nog voor Linux-apparaten en nog niet op Windows.

De ontwikkelaars van Godot waarschuwen dat Wayland nog een work in progress is. De makers willen op termijn dat Wayland dezelfde status krijgt als de huidige X11-ondersteuning, maar die laatste blijft voorlopig nog de standaard. Ontwikkelaars kunnen Wayland inschakelen door het commando --display-driver wayland te gebruiken.

In de bètaversie van Godot 4.3 zit ook een optionele Direct 3D 12-back-end voor Windows-gebruikers, voor gebruikers die een alternatief willen voor api's als Vulkan of OpenGL.

Reacties (26)

[rjberg]

Waarom moet een game engine worden aangepast aan de displayserver?

Zitten er geen APIs tussen die twee zoals de compositor en de desktop omgeving? Of heeft het met de direct rendering interface te maken?

[Zezura]

Het kan beide, in Linux kan je direct naar een display buffer schrijven van je videokaart. Maar je kan dus ook als je een venster wil en netjes wil samenwerken met andere applicaties een buffer gebruiken die een display-server je toekent. Die doet vervolgens alle applicaties en desktops bij elkaar en wegschrijven naaf de video kaart.

Maar je hebt dus 2 keuzes, gebruik API van compositor (X11) /GNOME(wayland) bijvoorbeeld of hardcore heel het beeldscherm overnemen en een compositor/display-server omzeilen.

Linux is daarin een beetje verdeeld er is geen een generieke API voor window management. Althans niet meer, want heel lang was X11 gangbaar, maar Wayland heeft populariteit gewonnen omdat het moderner is en geloof ik beter presteert (maar dat durf ik niet echt te zeggen, dat is een aanname).

Het is dus niet zo dat de Linux kernel zelf een window API heeft. Zoals Windows dat wel heeft.

[Reactie gewijzigd door Zezura op 23 juli 2024 03:34]

[JeroenED]

Wayland heeft niet gewonnen omdat het moderner is. Of toch niet rechtsreeks. Het probleem is dat X11 al van de jaren 80 stamt (en dus van voor Linux) en dat over de jaren heen met meer en meer "plakband" aan elkaar is beginnen hangen. 1 wijziging heeft ondertussen zoveel invloed en niemand die nog echt kan zeggen waar die wijziging impact heeft dat eigenlijk niemand meer een wijziging durft aan te brengen om het kaartenhuisje niet te laten instorten. Wayland daarentegen is gewoon een protocol en de plakband om 4K resolutie en HDR te ondersteunen kun je al dan niet zelf implementeren. Gnome zal dat vb wel vanaf dag 1 doen, maar voor XFCE zal dat misschien wat minder prio zijn.

[Hydranet]

Wayland daarentegen is gewoon een protocol en de plakband om 4K resolutie en HDR te ondersteunen kun je al dan niet zelf implementeren. Gnome zal dat vb wel vanaf dag 1 doen, maar voor XFCE zal dat misschien wat minder prio zijn.

Naar mijn mening zit er ook niet veel standaardisatie met hoe Wayland geïmplementeerd word op de verschillende DE's en WM's, want ze lijken allemaal het op hun eigen manier te doen. Ik ben geen expert op dat gebied maar het lijkt mij dat dit later ook voor problemen gaat zorgen? Ik gebruik zelf ook Linux en ik gebruik Gnome met Wayland maar als veel applicaties nog onder XWayland draaien dan moet er eerst nog gezorgd worden dan alle applicaties Wayland ondersteuning hebben en Wine/Proton(en Steam) games, dus het kan nog wel even duren voor dat alles werkelijk op Wayland draait en niet meer op XWayland.

[JeroenED]

Ja en nee. Bij X11 heb je een client en server. De client (Mutter, Kwin, etc) spreekt met de server en de server spreekt met je gpu die de output doet. Wayland is client en server tegelijk. De window manager zal rechtsreeks met de gpu spreken (via de GBM api die nvidia niet wou implementeren). Dit gezegd zijnde is dus de enige vereiste die gestandaardiseerd moet worden GBM api omdat de gpu niet kan bepalen welke DE je kan gebruiken (theoretisch toch niet). Dus doordat mutter van gnome of kwin van kde zelf server en client tegelijk is, zal alleen de incompatibiliteit tussen gnome en kde vergroten. Problemen die er al zijn en dus nog meer communicatie tussen DEs vereisen.

Ivm met Xwayland kan ik je ook gerust stellen. Ik verwacht niet dat Xwayland veel gebruikt zal worden. Apps praten voornamelijk met de Window Manager, ze sturen (normaal gezien) geen rauwe X11 server requests. Enkel de programma's die zelf X11 server calls doen (en dus nu reeds de vormgeving van je OS negeert) zullen Xwayland gebruiken. En dat zijn bij mijn weten vooral CLI programma's om vb input te detecteren of resoluties aan te passen (xrandr vb)

[Hydranet]

Bedankt voor de uitleg, die details wist ik niet. Weet jij hoe het met applicaties zoals Steam en Lutris zit? Gebruiken die Wayland of XWayland, ik had ergens gelezen dat Steam ieder geval nog geen native Wayland ondersteund? Ik had wel ergens gelezen dat voordat games met Wayland zouden werken dat Wine/Proton nog een patch zouden moeten krijgen die voor Wayland support zorgt?

[Reactie gewijzigd door Hydranet op 23 juli 2024 03:34]

[JeroenED]

Games maken gebruik van Vulkan, EGL, etc. Die libraries maken een aparte surface met de game (voor de GPU rendering van Vulkan etc. te kunnen gebruiken) die de wayland compositor zal integreren in de globale surface. Die surface creëren gebeurt nu ook de X11 server. De update die nodig, is de update om vulkan wayland compatible te maken. Dus zolang er geen update is zal deze xwayland gebruiken.

Maar er is wel een belangrijk detail: dit is een uitleg voor native linux games. Bij proton of wine zal wine een update nodig hebben aangezien de game niet met de native opengl/vulkan spreekt maar met de opengl van wine.

[Hydranet]

Bij proton of wine zal wine een update nodig hebben aangezien de game niet met de native opengl/vulkan spreekt maar met de opengl van wine.

Hier had ik het dus over, want de meeste games hebben toch geen Linux natives maar werken meestal via Wine of Proton. De paar Linux natives die ik via Steam gespeeld heb liepen erg achter op de de Windows versies die via Proton draaien, dus dat is een reden waarom ik meestal toch wel voor de Windows versie kies voor een spel dan de Linux native versie want dan weet ik dat ik een recente versie van het spel heb.

[rjberg]

Was het niet ook zo dat het client server model van applicaties naar beeldscherm dat X gebruikt GPU-rendering lastig maakt?

[JeroenED]

Dat was ook een reden om nu met een protocol te werken. De GPU word gebruikt door de X-server, niet de client. Door client en server te combineren kun je rechtsreeks de GPU aanspreken en dus rechtsreeks GPU rendering gebruiken.

[lezzmeister]

Maar je kan X11 applicaties toch onder Wayland draaien? Blijft het toch de de facto standaard lijkt me.

[Wolfos]

De meeste game engines gebruiken SDL als tussenlaag op Linux, waardoor ook Wayland ondersteunt word.

[kabelmannetje]

Omdat de programmeren naar X anders is dan Wayland.

[rdk1980]

Wayland anders heeft ook compositor ingebouwd x11 heeft dat totaal niet. Moet daarom ook apart ondersteund worden. Via xwayland kan ook gedragingen krijgen die je niet wilt

[Guru Evi]

De Wayland display server bestaat eigenlijk niet, het is een ‘standaard’ waar vervolgens voor de meeste benodigdheden extensies op gebouwd zijn. De implementatie hangt af van de window manager (Gnome, KDE etc). Dingen zoals vensterdecoraties, knoppen, globale shortcuts, 3D, venstercompositie zitten niet ‘standaard’ in Wayland en implementaties hangen sterk af van de WM.

De vraag is dus, welke Wayland heeft GoDot dus ondersteunt, welke extensies zijn ze overeengekomen te ondersteunen of gebruiken ze gewoon een X of Mesa3D venster “zoals vroeger” en is Wayland ondersteuning gewoon “voor het venster te maken”.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 03:34]

[bezeria]

That's great news! Godot is amazing

[Reactie gewijzigd door bezeria op 23 juli 2024 03:34]

[84hannes]

Misschien kun je uitleggen wat er fantastisch is aan Godot, en welk voordeel gebruikers gaan hebben van Wayland-ondersteuning.

[tweaker29789]

Ik weet niet of je ervaring hebt met Unreal of Unity, maar het eerste wat je opvalt is hoe soepel de app draait. Je kunt het makkelijk draaien op een verouderde laptop. Unreal en Unity voelen enorm log aan vergeleken met Godot. Het lijkt weinig uit te maken, maar het is wel zo prettig als je even snel iets kunt opstarten om verder aan je projekt te werken.

Het node systeem in Godot werkt ook erg intuitief vind ik. Maar als je de workflow van Unity bent gewend, zal dat misschien wat tijd vergen, gewoon omdat het anders is.

Imo 1e keus als je eenvoudige 2d games wilt maken. Godotscript is ook erg makkelijk te leren. Al helemaal als je met Python bekend bent.

[Sandor_Clegane]

Godot is een open source game engine. Dat alleen is al een ding vergeleken met Unity (en het bijbehorende debacle) of Unreal. Het lijkt erop dat het nu genoeg momentum heeft dat een hoop ontwikkelaars en andere mensen Godot als standaard game engine kiezen.

Het lijkt erop dat het hetzelfde traject als Blender gaat volgen: eerst een beetje uitgelachen worden, dan bereikt het een kritische massa en ineens wil iedereen het ondersteunen en gebruiken.

De switch van Brackeys naar Godot ipv Unity is wel een mooie afspiegeling hiervan.
Wayland lijkt de toekomst te zijn (ben ik het niet mee eens, maar ja) en betere ondersteuning voor het ontwikkelen van games onder Linux is natuurlijk alleen maar goed. Open source ontwikkeling op een opensource OS.

[Reactie gewijzigd door Sandor_Clegane op 23 juli 2024 03:34]

[Wolfos]

Godot wil alleen niet echt met de grote engines concurreren. Als je voor de eisen van grote professionele teams gaat bouwen dan word het al snel minder gebruiksvriendelijk, de editor word minder snel, etc. De dingen die mensen fijn vinden aan Godot raak je dan kwijt.
Het is dus niet het doel van Godot om de nieuwe Unity te worden.

Blender heeft het grote voordeel dat alternatieven erg duur zijn, waardoor er voor velen niet echt een keuze is. Dat het open source is maakt voor de meeste mensen niet zoveel uit. Dat het geen €2200 per jaar kost wel. Dat speelt hier eigenlijk niet omdat er zoveel gratis en goedkope game engines zijn.

[blorf]

Volgens mij is het probleem gewoon nog steeds dat Linux geen volledig open toegang krijgt tot de recente aansturing van GPU's.
Zelfs bij niet-3d graphics was het nooit anders. Nog steeds is het onmogelijk om je display output in de hoogte en breedte te schalen zodat je vloeiend kan in- en uitzoomen op je desktop/root window. Xrandr is er bijna maar blijft opgescheept zitten met een noodzakelijke software-layer waardoor het niet real-time werkt. Bij mij kost eenmalig de schaal veranderen achter een legacy Nvidia-driver ongeveer een halve seconde. Raar dat game-werelden er geen enkel probleem mee hebben. Ook niet in een venster...

[Reactie gewijzigd door blorf op 23 juli 2024 03:34]

[Sandor_Clegane]

De dingen die je noemt zijn niet een gegeven.

Voor de mensen die het maken is het wel een ding en voor mij ook. Met mij, anekdotisch, genoeg anderen.

[justinkb]

Wayland is nog steeds geen display server, zoals ik al vaker heb opgemerkt onder dit soort artikelen. Het is een protocol definitie voor de communicatie tussen display servers en de client applicaties.

[RoestVrijStaal]

WAS het maar een display server.

Nu staat ieder desktop environment dev team z'n eigen display server te bouwen inclusief de beslissingen om bepaalde wayland protocollen te implementeren of te negeren.
Lekker nog meer fragmentatie in het FOSS applicatielandschap.

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 03:34]

[johnbetonschaar]

Je kan dat zowel als een voordeel zien als een nadeel.

Het nadeel is inderdaad fragmentatie, hoewel dat niet per se een specifiek Wayland probleem is, want X11 is ook een protocol, X11 heeft ook een hele sloot aan optionele extensies, en ook voor X11 zijn verschillende display server implementaties.

Het voordeel is dat de veelheid van Wayland compositors ook tot een hoop innovatie en keuze leidt. Het is schier onmogelijk zelf een werkbare X11 display server te schrijven. En nutteloos, want linksom of rechtsom is X11 gewoon dead tech. Een Wayland compositor schrijven is goed te doen en daarom zijn er ook zoveel, waarvan sommige echt unieke eigenschappen/voordelen hebben en er eindelijk weer iets gebeurd in de Linux desktop UI wereld. Denk aan zoiets als Niri, of Gamescope, etc.

Uiteindelijk gebruiken bijna alle wayland compositors zoiets als wlroots of smithay waardoor je de basis infrastructuur voor je compositor niet from scratch hoeft te bouwen en je je alleen maar met de UI en rendering features kunt concentreren. Niet heel anders dan een window manager voor X11 schrijven dus behalve dat je met wayland veel meer mogelijkheden en vrijheid hebt.

[webster]

So now everybody is Waiting for Godot?

Badam psssh!

(iemand moest het doen)