Nieuwe Steam-bèta maakt spelen van Windows-games op Linux mogelijk

Valve heeft een verbeterde versie van Steam Play aangekondigd, die nu beschikbaar is via een bèta van de Steam-client voor Linux. Door gebruik van een aangepaste versie van Wine is het mogelijk een groeiende selectie aan Windows-games op Linux te spelen.

Volgens de aankondiging van Valve-ontwikkelaar Pierre-Loup Griffais hebben de aanpassingen aan het oorspronkelijk in 2010 geïntroduceerde Steam Play tot gevolg dat Linux-gebruikers Windows-games kunnen spelen die geen aparte Linux-versie hebben. Het werkt inclusief ondersteuning voor Steamworks, OpenVR, fullscreen, controllers en verbeterde multithreading.

Implementaties van DirectX 11 en 12 zijn gebaseerd op Vulkan, waarbij compatibiliteit met Direct3D 11 en 12 wordt geboden door respectievelijk DXVK en vkd3d. Om dit mogelijk te maken heeft Valve samen met CodeWeavers Proton ontwikkeld, dat een aangepaste versie is van Wine, waarmee Windows-software op Linux-systemen te gebruiken is. Volgens Griffais heeft Wine ook geprofiteerd van het werk aan Proton.

Er zijn inmiddels 27 games die getest zijn op compatibiliteit, waaronder verschillende versies van Doom, Tekken 7, Star Wars: Battlefront II uit 2005 en Quake. Deze zijn in de bèta te spelen. In de toekomst moeten daar meer games bijkomen, spelers kunnen ook non-whitelisted games spelen door gebruik te maken van een instelling in de Steam-client. Werking is dan niet gegarandeerd, complexe drm of anticheatmaatregelen kunnen bijvoorbeeld voor problemen zorgen. In de toekomst moeten spelers kunnen stemmen voor games om ze kandidaat te stellen voor opname in de whitelist.

Wat betreft de prestaties stelt Griffais: "Het is te verwachten dat er een verschil in prestatie is voor games waar graphics api translation nodig is, maar er is geen fundamentele reden dat een Vulkan-titel langzamer zou moeten draaien." Ontwikkelaars zouden de beste prestaties kunnen behalen door Vulkan native te ondersteunen. Hoewel Proton macOS ondersteunt, zijn er op dit moment geen plannen om de vernieuwde versie van Steam Play op dat platform te laten werken. Spelers die de bèta willen uitproberen kunnen zich daarvoor aanmelden en vervolgens de nodige instructies opvolgen.

Reacties (134)

Wel heel netjes van Steam/Valve dat ze linux niet uit het oog verliezen. Gaming op linux blijft altijd nog een ondergeschoven kindje. De kids hier zijn overgegaan van linux op windows ivm gaming.

Ze moeten wel, als ze alleen op Mac en Win richten zitten ze straks ineens in een situatie waar MS of Apple zegt: Zo en nu gaat alles via de app store (ivm veiligheid bijv) en daar dragen jullie 30% op af. Via Linux houden ze de deur open op een platform wat ze nergens toe zal kunnen dwingen in de toekomst.

Overigens is dat voor gebruikers dus ook een argument om Linux te willen.

[Reactie gewijzigd door teek2 op 22 augustus 2018 11:17]

Ik verwacht dat Microsoft dat niet gaat doen. Zeker niet omdat ze ookal dat Linux subsysteem in Windows hebben draaien en juist die vrijheid de USP is van Windows 10. Vergeet overigens niet dat voor game developers, ze ook 30% aan Steam af moeten dragen. Daarom hebben stores als Steam e.a. zoveel moeite met mobiele gesloten platformen. Bedenk dat Valve al 30% wilt, dan Apple of Google nogeens 30%, hou je als developer nogal weinig over.

"Niet uit het oog verliezen" is nogal een understatement. Ze investeren kapitalen in Linux. Wat ook bekend is geworden, doch niet in dit nieuwsartikel niet vermeld staat: De programmeur van DXVK werkt sedert februari bij Valve, dat maakt het mogelijk voor hem om dag-in-dag-uit aan DXVK te werken. En zo heeft Valve vele cruciale programmeurs inmiddels in dienst, waaronder mensen die aan de videodrivers werken, mensen die aan X werken e.d.

Er is bij velen een beeld dat Steam Machines mislukt zoudeb zijn en Valve het om en nabij wel SteamOS gaat stoppen, maar dan ben je volledig blind voor alle investeringen; geen enkel ander platform krijgt zoveel aandacht.

Valve is heel duidelijk geweest dat ze de spellenindustrie naar Linux willen hebben en beetje bij beetje scheppen ze de voorwaarden waarin dat kan gebeuren.

Het is echt top dat Valve tijd en geld gaat stoppen in Wine! Wat ik nog veel beter vind is dat ze de installatie/configuratie zelf regelen via hun client, dat maakt de drempel voor veel gebruikers veel lager.

Ik zou graag willen zien dat ze verder gaan kijken dan hun eigen Steam aanbod en ook gaan werken aan bv. MS Office en Adobe Creative Cloud integratie via hun client (als in de Steam client regelt de configuratie van die applicaties). Dat zou er voor zorgen dat veel hindernissen om over te stappen op Linux worden weggenomen...

Ze kunnen zich nog wel eens lelijk in de vingers snijden door de bestaande 'gratis' gaming opties onder Linux ongewild te promoten. Ik denk niet dat ze de complete Steam-doelgroep in de maling kunnen nemen met pretenderen dat het installeren van Steam technisch noodzakelijk is.

De Steam-constructie heeft naar mijn idee het tegengaan van piraterij als primaire doel. Het aansturen van graphics hardware gaat nog steeds via gesloten software om te voorkomen dat het DOS-scenario zich herhaalt en iedereen games gaat uitwisselen die gewoon hardware-compatible zijn en onafhankelijk werken. Dit staat haaks op het karakter van Linux en de OSS-wereld. Daar is het de bedoeling dat de eigenaar van de hardware ook echt de baas is.

Het voordeel van Steam, Netflix, of een "markt" zoals App Store of Play Store is dat je een gigantisch aanbod hebt dat makkelijk is te installeren, gebruiken, en bekijken. Als de DRM -waar ik geen fan van ben- dan transparant is dan accepteer ik het met gemok. Behalve wanneer er mij teveel censuur optreed. Een nadeel is dat je er zoveel hebt omdat het lucratief is.

Het DOS scenario is onvergelijkbaar omdat je toen dit soort markten nog niet had. Het enige dat je kunt doen is de content aanbieden via vage bronnen. Bij video en audio kan dat geen kwaad (tenzij er een bug zit in je decoder) maar bij games is er sprake van software. En dan is het maar de vraag of die Russische crack niet vanalles met je computer doet. Je zou het kunnen sandboxen maar het heeft networking nodig en zoals je hoort wordt 't al gauw veel te complex.

Dit staat haaks op het karakter van Linux en de OSS-wereld. Daar is het de bedoeling dat de eigenaar van de hardware ook echt de baas is.

Slechts een deel van de FOSS wereld vind dat belangrijk anders draaiden we niet met z'n allen Android. Belangrijke delen van Android zijn gesloten. Routers? De populaire merken zijn gesloten. Open hardware? Het is er, maar het gros heeft binary blobs en is gesloten.

Kortom soms moet je pragmatisch zijn.

Dit argument houdt niet echt steek. Steam is veeeeel meer dan enkel DRM. Steam is eerst en vooral een distributieplatform, een community platform en middleware om het leven van developers makkelijker te maken.

De Steam DRM is maar een heel kleine feature van het hele platform. Elke developer kan kiezen wat voor DRM die gebruikt, of gewoon helemaal niets. Zie hier een zeer uitgebreide lijst van games op Steam zonder DRM, die je gewoon zonder Steam kunt spelen. Die kan je dus nu al vrolijk copy/pasten naar eender waar spelen, onafhankelijk van Steam.

Het aansturen van graphics hardware gaat nog steeds via gesloten software om te voorkomen dat het DOS-scenario zich herhaalt en iedereen games gaat uitwisselen die gewoon hardware-compatible zijn en onafhankelijk werken.

Het DOS scenario is vooral irritant voor developers, omdat ze voor elk type hardware speciaal support moeten inbouwen. DirectX en OpenGL zijn er gekomen om het makkelijker te maken om software op verschillende hardware te draaien, niet moeilijker. Dit staat ook weer volledig onafhankelijk van DRM. Als developer wil je dat zo veel mogelijk mensen je spel kunnen spelen (dus compatible met veel hardware), maar dat ze er ook voor betalen (al dan niet DRM). Er waren dan ook genoeg DOS games die een beperkte vorm van DRM hadden. Als je een Vulkan game via de open source AMD driver op Linux speelt komt er bijna geen closed source code aan te pas. Of de GPU drivers en/of DirectX open source zijn of niet staat volledig los van DRM, want alle APIs zijn gewoon openlijk bruikbaar en gedocumenteerd.

Ik denk niet dat er veel mensen wakker liggen van het feit dat een groot bedrijf zoals Valve geld investeert in open source projecten waardoor meer software naar het platform komt. De kern van het hele OSS gebeuren is vrijheid. Die vrijheid houdt ook in dat bedrijven closed source software kunnen en zullen draaien op het platform, en dat is maar goed ook. Zolang dat Valve niets opdringt past dit project van Valve volledig in het OSS verhaal.

Als je Nvidia hebt is de driver gesloten, maar niet bij AMD en Intel. Valve heeft 3 man in dienst de aan de open AMDGPU-driver werken... zouden ze dat doen als ze gesloten drivers promoten?

Volgens mij is de ideogische gebruiker toch echt een minderheid en is het 9 van de 10 keer toch een "free as in beer"-scenario. Zeker bij gaming, waar mensen Windows hekelen omdat het geld kost. Het lijkt me ook niet reëel om te verwachten dat commerciële games open source zouden kunnen gaan. Waarbij je zeker alleen betaald voor de commerciële support .

Vond dit artikel toentertijd wel een goede weergave van de hedendaagse ideologische staat onder velen: https://computerworld.nl/...rce-vrij-of-vooral-gratis

[Reactie gewijzigd door MsG op 22 augustus 2018 11:42]

Als m'n games goed op linux draaien zou ik Windows dumpen. Hopelijk gaat Adobe ook een keer Linux ondersteunen. Dan gaat de werk Mac er ook uit!

Draai mijn games in een VM, speel via een steamlink. Als je geen multiplayer games speelt waarin "twitch" reacties vereist zijn is het prima te doen.

Als je je comfortable voelt met CLI en wat wilt knutselen kan je misschien eens kijken naar deze serie, op het moment zijn alleen nog maar eerste twee videos online, maar wat er nog moet komen wordt alleen maar leuker!

Intro;
https://www.youtube.com/watch?v=SsgI1mkx6iw
Serie;
https://www.youtube.com/w...KZBgRud3e1AqRiGxjse9S6BRk

Zeker looking glass belooft echt een hele gave technologie te worden als het wat gebruiksvriendelijker is. enkele ms latency tussen je VM en linux klinkt als een droom, dan kan je ook aan de 'twitch' titels beginnen die niet native via Linux te spelen zijn!

Ik heb Looking Glass draaien, alleen wil je het goed gebruiken dan moet je eigenlijk een tweede muis hebben vanwege de schermgrootte en het niet goed werken van KVM input( wil de muis ineens niet voorbij een bepaald punt). Het werkt wel mooi, vooral als het full screen draait is er bijna geen verschil met een "native" systeem.

Heel vet dat je het al gebruikt! Zelf durf ik het nog niet aan met mijn beperkte ervaring met Linux (en het feit dat het me niet blijft lukken een legale W10 key te activeren in een VM), maar als het in de toekomst wat makkelijker wordt ga ik het zeker uitproberen!

Door het te doen wordt je ervaring vanzelf groter en dan wordt het ook gemakkelijker.

Gewoon eerst een VM installeren op KVM en dan pas de GPU doorzetten. Als je wilt dat het echt goed draait is het doorzetten van een USB controller ook wenselijk.

Langzaam maar zeker wordt dat wel bereikt: Valve's hele activiteit op Vulkangebied heeft te maken met de Linuxstrategie. DirectX11 op Vulkan, wat Valve nu evens droog aankondigt is een verdere stap om spellen beter op Linux te laten draaien.

Ik heb zelf nagenoeg uitsluitend spellen die op Linux draaien in m'n Steam-collectie en ben dik tevreden over het aanbod. Alleen als je een bestaande collectie hebt is het even slikken dat je 2/3 niet meer kunt spelen. Maar dat kan nu met de Wine-integratie wel eens in korte tijd terugklopen naar slechts enkele procenten. Dat neemt toch weer een flinke barrière weg voor mensen.

Adobe werkt over het algemeen prima met Wine. Zo goed dat Disney het intern gebruikt icm Wine ipv Windows.

heb je daar een bron van?

BRON?

Dit betrof Photoshop 7 (2002)

Photoshop cs6 - Limited functionality:
https://www.codeweavers.c...sover/adobe-photoshop-cs6

De huidige photoshop installeert niet eens
https://www.codeweavers.c...ssover/adobe-photoshop-cc

Ik denk niet dat Disney hier verder mee is gegaan

Volgens WinHQ werkt Adobe Photoshop gewoon (Rating Silver).

Photoshop: WineHQ - Adobe Photoshop

De trial installations lijken problemen te hebben.

heel interessant artikel. Ben benieuwd of ze er nog steeds aan vasthouden :-). Snap an sich het ook wel, de overhead op een linux is minder dan op een windows systeem (zeker in het xp tijdperk) dus heb je meer resources te spenderen aan het werk.

btw, bedankt ;-), ik vond het niet zo direct terug.

https://linux.slashdot.or...DreamWorks-Pixar-Go-Linux

Mijn issue daarmee is dat de Adobe software de laatste paar jaar véél sneller is onder Windows dan onder macOS. Ik zie ook steeds meer Microsoft apparaten bij mensen die voorheen een macboek moesten hebben, onder andere om deze en meer redenen. De vraag is, als Adobe ooit Linux gaat ondersteunen, gaat dat dan ook zo ten kosten van de performance als macOS? Ik verwacht zelf dat het sneller gaat zijn dan macOS, omdat de drivers onder Linux véél moderner zijn, maar of ze dan Windows op dit vlak evenaren vraag ik mij dan af.

Dus misschien gewoon lekker op Windows klooien met adobe dingen en overschakelen op Linux voor andere dingen. Of gewoon het Linux subsysteem binnen Windows 10 gebruiken. Dat is natuurlijk wel de kracht van Linux dat Microsoft ook heeft ingezien. Je hoeft niet meer te dual booten en het werkt best wel lekker.

Steam heeft al meerdere malen gezegd (kon zo snel maar 1 quote vinden) dat ze meer in willen zetten op Linux. Zeker nu Vulkan langzaam maar zeker meer voeten in de aarde begint te krijgen. Ik denk dat nu SteamOS niet echt van de grond komt, het nu met Proton gaan proberen. Daarbij hoop ik dat dit meer succes krijgt, zeker aangezien je met Proton jezelf niet in allerlei bochten moet wringen om een apart OS aan de praat te krijgen.

Mja, ik zou zo weer willen switchen maar zit met een probleempje: Nvidia. M'n monitor ondersteunt gsync, en geen freesync, en ik heb een Nvidia kaart. Nvidia werkt niet goed met macOS of Linux wanneer je Wayland gebruikt. Oudere kaarten worden wel voor Nouveau ondersteunt. Dus kom je uit op een nieuwe AMD kaart (geen idee welke) bovendien moet ik dan een monitor regelen met freesync (geen idee welke). Moet ik wel bijzeggen dat ik met liefde over zou stappen op een Threadripper. Die hebben prima performance onder Linux.

[Reactie gewijzigd door Jerie op 22 augustus 2018 11:05]

Met wayland liep ik inderdaad ook tegen problemen op.
Maar het staat je vrij om gewoon xorg te gebruiken in de plaats.
Bij mij loopt mijn NVidia GTX 970 als een trein op xorg.

Voor bvb. Gnome3 is er ergens een optie in een config file om dat te switchen, maar ik weet niet meer vanbuiten hoe het zat.

Misschien minder ideaal als HW aanschaffen welke wel werkt onder Wayland, maar in elk geval een pak goedkoper.

Jep, Xorg werkt prima en Nouveau werkt ook redelijk goed met oudere kaarten maar... ik wil geen Xorg. Ik vind X11 kut, traag, bloated, en vooral onveilig. En ik wil ook geen proprietary drivers als ik Linux draai.

Ondergeschoven kindje ja, en met recht. Al vijfentwintig jaar ben ik een enthousiaste gamer die ook erg geintereseerd is in nieuwe platforms, maar na ca vijftien jaar heb ik het toch opgegeven na tutorials als:

How to install Titan Quest on Linux in thirty-five easy steps!
1. Make an account on www.tq4linux.net and await moderator activation
2. Download the following files: the convertor driver, the video driver, the bulb driver, and the hashed executables and ....
3. Go to blabla.com and download the additional libraries for your videocard. Note: GT8800 users must use the alpha versions found in the \dev\temp\marco\test folder. Skip step 28 if this applies to you.
4. Install titan quest and use X-rays TimeMachine to downgrade titanquest to version 1.12. Keep the 1.18 machine.dll in a backup folder, you will need this in step 21.
et
ce
te
ra.

Dit is hoe ik mij gaming onder linux herinner lol, en uiteindelijk had je het dan draaiend, in software modus, met lage fps, geen geluid, en afschuwelijke mouse-drag. Ik heb er al in geen 10 jaar meer naar gekeken dus wellicht is het in de afgelopen tijd makkelijker geworden. Maar de conclusie gamen doen we onder windows is voor de eindgebruiker toch wel een hele redelijke. Zelfs voor mij, als bovengemiddeld geinteresseerde nerd is het altijd te bewerkelijk geweest. Ik vind dit een erg interessante zet van Steam.

Games kunnen draaien is inderdaad ook voor mij altijd een van de hoofdredenen geweest om niet over te stappen naar Linux. Ik geloofde ze namelijk wel hoor, de talloze 'nerds' (zo noemde je it-ers in de goede oude tijd) die bleven volhielden dat het een superieur OS was en dat Windows in vergelijking daarmee een brak instabiel zooitje was.

Een handjevol spellen waar iemand héél veel aandacht aan heeft geschonken werkt nu zeker beter. Maar de grote meerderheid van software heeft nog steeds een 37 stappenplan nodig. Veelal zelfs nog specifieke Wine versies ook, soms 32bit, dan weer 64bit libraries, dan weer wine-staging, dan weer een oude wine versie en iedere applicatie vereist weer een hele eigen serie aan dll's en andere onderdelen via winetricks. Het is verre van een betrouwbaar geheel.

En aangezien Windows 10 toch eigenlijk niet zo tegen blijkt te vallen als initieel gedacht... Is het mij een groot raadsel waarom je nog zoveel moeite moet stoppen in het aan de praat krijgen van spelletjes op Linux. Linux heeft zeker z'n meerwaarde op veel vlakken, daarom gebruikt Microsoft het ook massaal voor Azure en is Android zo populair… Maar dit is niet zo'n vlak, dit is een plek waar Linux op z'n zwakst staat. Niet alleen door Wine, maar ook door de beperkte kwaliteit van de drivers en de beperkte development en optimalisaties op dit vlak. Als je ziet hoe lang men al bezig is om dit voor elkaar te krijgen en de gebrekkige kwaliteit van wat opgeleverd is, zou ik misschien weleens gaan overwegen of dit al die moeite wel waard is.

Ik werk ook dagelijks op Manjaro, maar voor spellen pak ik lekker Windows. In de tijd die ik nodig heb om een spelletje op Linux aan de praat te krijgen, heb ik 'm onder Windows 10 3x uitgespeeld.

Goh @ fapkonijntje (leuke naam haha), jouw eerste alinea - daar schrik ik eigenlijk een beetje van! Had gedacht dat het anno 2018 toch al wat smoother zou gaan, maar kennelijk is het een zichzelf-instandhoudend fenomeen: de markt voor linux gamers is te klein zodat gamehuizen er niet specifiek voor gaan 'porten'. Tsja dan hou je dit.

Het hele idee van wat Valve doet met Steam Play is juist dat soort (handmatig) gedoe uit handen nemen. Ik heb net zelf een aantal spellen getest die geen native Linux ondersteuning hebben en zowaar werken die alle drie. Kwestie van op Install klikken, wachten tot het spul gedownload is en spelen maar. In dit geval ging het om Anno 1404, INSIDE en Overcooked die volgens WineHQ platinum/gold status hebben en dus zonder problemen moeten werken en dat is ook het geval. De performance was dik in orde en geen rare dingen tegengekomen al heb ik de spellen nog niet uitgebreid kunnen testen. Volgens WineHQ heeft Titan Quest ook platinum status dus ik neem aan dat dat spel op dezelfde manier te spelen is.

Zal dit voor ieder spel even goed werken? Waarschijnlijk niet maar wat Valve hier doet is een grote stap in de goede richting en maakt het aantal spellen die ik kan spelen zonder naar Windows te moeten booten een stuk groter. Hopelijk dat dit als een soort van katalysator werkt voor de adoptie/marktaandeel van Linux distributies, dan volgen de ontwikkelaars vanzelf wel .

Ik ben erg benieuwd wat het verschil in prestaties is. Voor zo ver ik het altijd heb begrepen is Wine een soort emulator, Het is dus geen emulator maar een soort API, dus er zal een overhead zijn, maar wellicht niet zo groot als je normaal van een emulator zou verwachten.

Wellicht wil valve toch nog weer verder met steamboxes of een eigen OS gebaseerd op Linux.

Wel jammer dat DRM mogelijk roet in het eten kan gooien, het zou zonde zijn wanneer dat de enige beperking zou zijn om bepaalde games in deze setting te draaien (en er verder dus geen technische beperkingen zouden zijn).

[Reactie gewijzigd door kid1988 op 22 augustus 2018 10:46]

Wine is geen emulator maar een tolk. Dat zorgt voor een beetje overhead waardoor het misschien net wat trager kan zijn.

DRM werkt in veel gevallen al in Wine. Sommige DRM is nog te agressief en komt wine niet doorheen maar naar mate de implementatie beter wordt zal ook dit verbeteren.

Een emulator *is* een tolk En wine is beide niet. Wine is een implementatie van de windows API's. Een API is geen vertaallaag, maar een collectie functies waar applicaties gebruik van kunnen maken.

Om een zwaar versimpeld voorbeeld te geven (ook voor @kid1988): als je een functie hebt in bv de C library genaamd print(), wat tekst in een terminal schrijft, zal deze onder water Linux-terminal-specifieke code uitvoeren die er voor zorgt dat de tekst daadwerkelijk op je scherm verschijnt. Onder Windows heb je dan misschien een functie winprint(), die dit onder water op een Windows-specifieke manier doet voor de Windows terminal.

Windows programma's draaien normaal niet onder Linux omdat die geen functie winprint() heeft. Wat wine dus doet, is zorgen dat Linux wél een functie winprint() krijgt, zodat Windows programma's dat aan kunnen roepen. Onder water doet de wine implementatie van winprint waarschijnlijk hetzelfde als print(), of het roept simpelweg de native print() aan zodat ze het niet zelf hoeven implementeren. Welke keuze ze hiervoor pakken hangt af van welke beter is voor de situatie (gelet op performance of code maintainability).

Wine is dus een grote collectie libraries die Windows-specifieke functies aanbiedt aan software die daar gebruik van maakt, oftewel software die voor Windows is geschreven. O.a. DirectX is zo'n collectie functies die ze dus hebben moeten implementeren (alsof ze DirectX vanaf de grond af opnieuw opbouwen).

Hoe efficiënt dat is, hangt van de implementatie af. Ze kunnen dus vaak de performance nog verbeteren door de implementatie te optimaliseren. In theorie zouden ze zelfs sneller kunnen zijn dan Windows, als ze een implementatie schrijven die beter is dan die van MS. Hoe dit in de praktijk uitpakt weet ik niet, ik speel al vele jaren geen Windows-only spellen meer, maar uit vorig decennium kan ik me herinneren dat ze het wel aardig deden. Mijn eigen ervaring met bijvoorbeeld GTA San Andreas, een DirectX spel, is dat die sneller liep onder wine dan onder Windows zelf. Maar dit hangt van een heleboel factoren af (o.a. je grafische kaart en de driver ervan).

DRM kan in wine werken als die DRM alleen functies gebruikt die wine geïmplementeerd heeft. Wine kan ondersteuning voor die DRM inbouwen door ontbrekende functies nog toe te voegen. De echte nasty DRM zal echter allemaal vreemde dingen doen die normale programma's niet doen (hooks in de kernel, geheugen uit proberen te lezen waar ze normaal niet in mogen, etc), dus daarom zou het lastig kunnen zijn om het helemaal te ondersteunen. Er blijven altijd verschillen tussen de systemen die niet goed te overkomen zijn. En DRM lijkt tegenwoordig steeds meer op een virus, en dat zijn juist zaken die een OS probeert te blokkeren...

Een emulator *is* een tolk

Nee, een emulator doet alsof hij iets anders is, hij emuleert, hij vertaald niet direct.
In het geval van een perfecte emulator merkt de gebruiker, of gebruikte software niet dat hij niet met het echte product te maken heeft.

Dus een perfecte emulator is een perfecte tolk
Een perfecte tolk laat jou alles in jouw taal horen zonder ook maar te merken dat dat niet is wat de andere persoon zegt (een babel fish bijvoorbeeld ). Lijkt mij redelijk analoog aan jouw perfecte emulator.

Nee, als je met een tolk praat heb je door dat je via een tolk praat, praat je met een Engelsman die een Nederlander emuleert dan heb je niks door.

Conclusie, de perfecte tolk bestaat niet (tenzij die Babel fish echt ergens in het heelal bestaat )
Maar goed, het is ook maar net hoe je het wil noemen allemaal, je kunt het beide kanten op redeneren.

Wine zorgt er dus voor dat Windows specifieke methods vertaald worden naar Linux specifieke methods, dus is het een tolk. Een tolk zet dingen om in een andere taal zodat de andere partij het begrijpt en er iets mee kan gaan doen. Dit hoeft niet minder efficiënt te zijn maar af en toe bestaan er woorden die niet in die doel taal bestaan en dan moet je ze uitleggen en dat maakt het minder efficiënt.

Het vertaalt bijvoorbeeld ook DirectX calls naar OpenGL, door het te implementeren met Linux native commando's. Sommige commando's zijn gewoon 1:1 over te nemen maar andere moeten wat meer uitgelegd worden. Omdat Vulkan native op Linux draait hoeft daar geen vertaling plaats te vinden en dus *kan* dat zoals Valve claimt even snel draaien.

[Reactie gewijzigd door NanoSector op 22 augustus 2018 18:29]

Heb onlangs op Youtube een video gezien met Gaming on Linux met de ins en outs.
Misschien interessant om eens te bekijken. Steam wordt er ook in besproken.
https://www.youtube.com/watch?v=SsgI1mkx6iw

[Reactie gewijzigd door Blubkens op 22 augustus 2018 11:01]

Hier kan je ook de uitgebreide versie vinden van deze video;
https://www.youtube.com/w...KZBgRud3e1AqRiGxjse9S6BRk
(alleen episode 1 en 2 zijn nog maar online, de rest komt nog)

Eigenlijk, zelfs desondanks dat Wine staat voor Wine Is Not an Emulator, is Wine wel een emulator in een bepaalde vorm.

https://www.kb.nl/organis.../emulatie/wat-is-emulatie
Emulatie kan het best worden omschreven als het nabootsen van een bepaald computerplatform of computerprogramma op een ánder platform of programma.

Ik denk dat het wel duidelijk is dat Wine iets nabootst van het Windows platform.

Alleen mag je Wine niet vergelijken met virtualisatieoplossingen zoals VirtualPC, VirtualBox, Hyper-V, Xen en dergelijke. Wine emuleert enkel de software-omgeving van Windows zodat applicaties die gemaakt zijn voor Windows daarmee onder Linux functioneren.

Ook mag je Wine niet vergelijken met een emulator voor oude spelletjes zoals een Commodore-, playstation-, of andere emulator. Die emulators emuleren zelfs de CPU van dat andere platform en dat kost prestaties. En dat is waarschijnlijk wat men bedoeld met Wine Is Not an Emulator.

Het verschil zit dit in de diepgang van de emulatie. Wine emuleert geen hardware en heeft minder geheugen en CPU rekenkracht nodig. Alleen naar drivers toe en voor zaken waar hardware wel intensief aangesproken wordt, is er nog wel een verschil in prestaties op te merken. De compatibiliteit is ook (nog) niet 100%. Aan beide wordt wel constant en hard gewerkt en er werd ook al veel vooruitgang geboekt.
Ik heb voor de prestaties minder schrik dan voor de compatibiliteit. Zeker als je oudere softwaretitels wil gebruiken op je nieuwere en snellere pc. Voor de compatibiliteit zijn er echter de lijsten met gekende softwaretitels die werken (of juist niet).

Windows API zegt het al.
Application Programming Interface.

Oftewel, Wine implementeert de interface.
Dat is geen emulatie, want de code achter de interface is specifiek voor het Linux platform.
Er is geen vertaalslag, dus geen emulatie.

Ik denk niet dat er per definitie sprake moet zijn van een vertaalslag opdat iets emulatie zou zijn.

Binnen Windows heeft een applicatie een vorm van omgeving ter beschikking waarin het functioneert. De applicatie heeft zelf niet rechtstreeks toegang tot de hardware in het systeem, maar de toegang wordt aan de applicatie toegestaan of ontzegt door het OS. Bvb. Terwijl Excel een rekenblad afdrukt en bvb aan de 15e regel bezig met afdrukken, is het niet de bedoeling dat Word daar een eerste stukje van diens document gaat gaan drukken. Het OS regelt dat eerst de ene pagina volledig wordt afgedrukt en vervolgens pas de andere pagina. En eigenlijk geldt datzelfde principe voor alle andere zaken op de pc. Bvb welk programma diens venster er getoond word op het scherm.
Ook intern heeft het programma nood aan bepaalde zaken zoals geheugenruimte of bvb om sneller te comprimeren op een multi-cpu systeem wil het programma extra processortijd krijgen op de overige cpu cores.
Al die zaken vormen wat ik bedoel met de omgeving die voor de applicatie ter beschikking staat.

Het is die omgeving die onder Windows standaard aanwezig is die WINE onder Linux moet ter beschikking stellen zodat Windows applicaties onder Linux kunnen werken. De API's waarover gesproken wordt maken daar een essentieel deel van uit. Daar komt wel iets meer bij kijken dan puur een functie die aangeroepen kan worden. Vandaar is het een omgeving die nagebootst wordt en dus wel een vorm van emulatie.

Het is misschien duidelijker als volgt:
Een arbeider in een fabriek verricht in het algemeen handenarbeid en daarom noemen we het een arbeider. Een poetsman houdt zich doorgaans bezig met poetsen zoals bezemen. De arbeider houd echter ook diens werkvloer proper en neemt daarom ook al eens een bezem vast. Maar noemen wij die arbeider daarom 'de poetsman'?

Nee, zo werkt een API niet.
Een API is de Interface waaraan een aanroep moet voldoen, plus de beschrijving wat deze moet doen.
Dus de naam, de parameters (+ hun type en returntype) + omschrijving functionaliteit.

Windows implementeert deze API voor het windows subsysteem.
Linux implementeert deze API d.m.v. Wine voor het Linux subsysteem.

De implementatie in Windows kan hierbij sneller zijn dan Linux.
Maar Linux zou ook gemakkelijk sneller kunnen zijn dan Windows.
Hier kun je niets over zeggen.

Maar Linux zou ook gemakkelijk sneller kunnen zijn dan Windows.
Hier kun je niets over zeggen.

In z'n algemeenheid, nauw gekeken naar een enkele API call, kan je hier inderdaad niets over zeggen.

Wanneer je er echter vanuit gaat dat WINE als doel heeft vrijwel alle functies van de Windows API te ondersteunen op Linux, dan valt dit in de categorie "Wij willen alles wat Windows kan, maar dan wel binnen een ander OS, dat andere architecturele keuzes gemaakt heeft", wat best te doen is. Wanneer wordt toegevoegd: "Ow ja, het moet ook allemaal minstens even snel, maar we hebben voor WINE niet méér ontwikkelaars beschikbaar dan voor Windows, en we bouwen nog steeds op de fundamenteel andere Linux architectuur" dan gaat het al snel richting onmogelijk... (Was dit makkelijk geweest, dan had Microsoft dit al lang zelf gedaan).

Dan nog wil ik best geloven dat een aantal API calls onder WINE sneller is dan bij Windows, en dat veel games prima draaien onder WINE, maar het zou me verbazen als een zware game met honderden API calls significant sneller draait onder WINE.

Ik ken het ook niet maar even Googlen leert:
Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.
Dus de games zullen wel vlot lopen?

Misschien technisch geen emulator, maar ‘to emulate’ betekend toch iets in de richting van ‘nastreven’ of nadoen.

Dus feitelijk doet Wine dat wel

Wine is geen emulator zoals we dat kennen in de IT wereld in de strikte zin van het woord. Wat zij proberen te doen is een open source implementatie van de Win32 API.

Nee zo werkt wine niet. Een emulator probeert een hardware omgeving na te bootsen en vertaalt het output naar een begrijpelijke taal voor het hoofd OS.
Wine vertaalt direct het input wat normaal gesproken naar de emulator zelf zou gaan en voert de commands direct uit in het hoofd OS
Het verschil zit em in het wel of niet aanmaken van een fake hardware omgeving wat effectief het deel is wat de naam "emulator" krijgt.
Als je het toch zou willen gebruiken zou je technisch gezien moeten zeggen Wine = Een emulator zonder emulator.

Dat is een erg eng begrip van emulatie. Een bredere definitie is dat emulatie is het nabootsen van een ander systeem aan de buitenzijde, terwijl de werking aan de binnenkant volledig anders kan zijn. Dit in tegenstelling tot simulatie waarbij ook de interne werking van iets nagebootst wordt.

Als we moeten kiezen tussen simulatie en emulatie, dan is bij Wine sprake van emulatie.

Wine bootst helemaal niks na maar vertaalt de programma code direct in een leesbare formaat voor het OS.
Het gaat er juist om dat het systeem wat "geëmuleerd" wordt juist overgeslagen wordt om systeem resources vrij te houden en juist daarom zijn de twee fundamenteel anders..

Ik weet hoe Wine werkt en ken de gedachtengang achter dat het geen emulator in de zin van programma's als Vice is.

Maar dat betekent niet dat de term emulatie fout is. Wat is een printer die een Epson-emulatie heeft? Of een geluidskaart die een Soundlaster emuleert? Beiden zijn geen "emulator" in de zin die in Wine bedoelt worden. Wine bootst een Windowsomgeving na. Een programma denkt dat het onder WIndows draait. En dat valt binnen de bredere definitie van emulatie.

Wine lijkt veel meer op een API dan een emulator waarom noemen we het niet gewoon een API ook al is dat ook niet accuraat maar is een veel betere omschrijving dan emulator.

Het is een implementatie van de Win16/32/64 API. Maar, een API alleen zou je enkel in staat stellen programma's te hercompileren, maar we willen programma's ongewijzigd kunnen draaien. Om ze te draaien is bijvoorbeeld ook omgang met het PE-EXE-formaat van Windows nodig en het nabootsen van het schijflettersysteem in Windows. Tevens worden daar bestandsattributen nagebootst omdat dat in Linux heel anders werkt. En zo zijn er een helehoop kwesties waar Wine toch wat meer doet dan puur een API-implementatie.

Ik had toch duidelijk gezegd dat het niet gewoon en API is maar dat het meer lijkt op een API dan een emu.

nee, het doet niks na. Je draait de oorspronkelijke executable zonder wijzigingen. Er zijn hoogstens wat API's 'nagemaakt' om met name IO te laten werken.

Nee. Wine is net zo veel een emulator van Windows als dat een Audi een emulator is van een BMW: beide merken maken voertuigen met een stuur, pedalen, banden, ruitenwissers, etc. Ze werken in de basis hetzelfde, maar ze komen allebei van een andere aanbieder. Op dezelfde manier zijn Microsoft en Wine allebei aanbieders van een win32 API. Dat MS nou misschien de eerste was, doet daar niks aan af. Er was ook ooit iemand die de auto heeft uitgevonden, en de rest die dat na ging doen.

In sommige gevallen is Wine sneller dan Windows.

Wine staat voor Wine Is Not An Emulator. Eigenlijk is hetewoon een tussenlaag die windows APIs omzet. Een winfows programma doet een call, Wine vangt het op en zet het om naar een Linux call.

Strikt genomen implementeert Wine de Windows APIs op Linux.
De aanroepende software roept gewoon dezelfde methodes aan, ongeacht of deze software in windows of Linux draait.

Dat is ook wat ik zeg: Een windows programma doet een call, Wine vangt het op en zet het (verwijst naar de windows API call) en zet het om naar een Linux call

Je zet geen API om, je implementeert een API.
Maar we bedoelen inderdaad hetzelfde

Je implementeert een API die de API calls omzet naar een andere API

Hoeft niet perse. Je kunt API calls ook met compleet eigen code implementeren. Niet alles van Windows heeft een tegenhanger in Linux. Neem bv het register. De enige manier om een register aan te bieden die zich gedraagt als die van Windows is om dit from scratch zelf te bouwen.

en die andere functies, zoals een van scratch gebouwd register, zijn benaderbaar via een API

(erg jammer dat ik -1 krijg en jij +1 ondanks dat de discussie hetzelfde is en we nagenoeg hetzelfde zeggen)

[Reactie gewijzigd door StefanJanssen op 22 augustus 2018 20:27]

Je implementeert een API die de API calls omzet naar een andere API

Je implementeert een interface en daar zitten (logischerwijs) ook systeem calls naar het Linux subsysteem in, maar de Windows API calls zet je niet perse om naar andere API (Linux) calls. Je kunt ook gewoon dedicated code schrijven die deze calls afhandelt.

Al zou dat niet de handigste manier zijn, mocht een andere windows versie net een andere implementatie hebben zal er vaker dezelfde logica geschreven moeten worden. De ideale manier om dit dan te doen is een API te hebben die niet veranderd. Je zal dan alleen hoeven te mappen.

Je API verandert ook niet, alleen de implementatie.

Ik noem het zelf een middleware achtige laag, ik denk dat dat WINE het beste verwoord.

Staat Wine niet voor

Wine
Is
Not
Emulated

Dat begreep ik in ieder geval.

Helaas presteert linux over het algemeen iets minder goed vergeleken met windows op native gaming gebied:
https://www.phoronix.com/...=pascal-win10-linux&num=1

Dus met een extra vertaalslag er tussen ook net weer wat minder.

Niet dat het enorme verschillen zijn maar toch, ben al heel blij dat Valve er nu zo serieus mee bezig is maar het kan een duwtje in de rug zijn van de grote game makers om eindelijk crossplatform te gaan ontwikkelen met Vulkan.

Meeste moderne bedrijven ontwikkelen sowieso standaard crossplatform dus het wordt tijd dat de 'oude' garde zich hier ook eens bij aansluit.

Dus met een extra vertaalslag er tussen ook net weer wat minder.

Dit hoeft niet waar te zijn, het kan namelijk zijn dat de game slecht is geoptimaliseerd voor Linux, dan kan het zijn dat de Windows versie+Wine een stuk beter werkt.

Meer keus is altijd goed. Masr ik denk niet dat het een grote groep gebruikers gast aanspreken. Niet alleen vanwege de kleinere groep Linux gebruikers maar ook omdat niemand er op zit te wachten zijn games over twee OSen te verdelen.

Ze hebben het over een 'groeiend aantal titels'. Dus blijkbaar zit er nog wel werk in per titel en is het niet zo dat automatisch de gehele Steam catalogus zo naar Linux komt.

Vergeet SteamOS niet Daar zal het ze voornamelijk om te doen zijn

SteamOS is half dood, maar de theorie is dat Valve SteamOS voornamelijk gemaakt heeft om te voorkomen dat Microsoft hun Store te sterk zou pushen. Stel Microsoft zou namelijk net zoals Apple hun Store de default place maken waar je software vandaan haalt (en het actief moeilijk/onmogelijk zou maken om vanuit andere plaatsen software te installeren), dan zou dat natuurlijk ongelovelijk pijnlijk zijn voor Steam. SteamOS gaf/geeft Valve zeg maar een plan B mocht Microsoft dit doen, en geeft ze ook een sterkere onderhandelings positie mochten ze met Microsoft om de tafel gaan zitten.

Dit zal denk ik ook wel in dat plaatje passen van: "Pest ons niet te veel Microsoft!"

[Reactie gewijzigd door David Mulder op 22 augustus 2018 11:08]

VALVe/Steam probeert al jaren een stuk van de console markt er bij te pakken, onder andere door middel van SteamOS, steam controllers, in-house streaming, etc. Het lijkt me dan ook dat je het in die hoek moet zoeken. Steam op Windows heeft al lang zijn plek bemachtigd.

Persoonlijk denk ik oprecht dat dat meer een bonus is voor Valve mocht het zijn gelukt. Steamlink hebben ze kort geleden lopen dumpen voor 10 euro per stuk omdat ze er te veel van hadden. Aan de andere kant blijven ze inzetten aan de linux kant, zelfs nu ze geen SteamOS machines meer in hun store hebben staan (volgens mij).

Neem zo iets als Windows S mode, dat was letterlijk een poging van Microsoft om een Microsoft store only versie van Windows op de markt te zetten. Hebben ze na redelijk wat kritiek uitgesteld weer, maar ze blijven het proberen. Kan me echt wel voorstellen dat Microsoft graag die cut van Steam in handen wilt krijgen.

Dat was Windows 10 S, niet S Mode, S Mode is een functie in Windows 10, en is volgens mij al beschikbaar voor de MS Surface. Ik weet niet of het ook voor Retail copies van Windows 10 Pro beschikbaar wordt, maar OEM's hebben de mogelijkheid om dit te implementeren, maar het blijft altijd optioneel, en gratis om uit te zeten.

[Reactie gewijzigd door MrFax op 23 augustus 2018 06:34]

maar het blijft altijd optioneel, en gratis om uit te zeten.

Klopt inderdaad dat ze het hebben hernoemd van "S" naar "S Mode", maar het doel was dat het niet gratis zou zijn. Hebben ze inderdaad na veel kritiek uitgesteld tot onbekend moment, maar waar haal jij het idee vandaan dat ze dat voor altijd hebben opgegeven. Microsoft wilt extreem die cut van alle software verkopen hebben.

De vraag is, hoe lang zijn beide partijen nog tevreden met de bestaande situatie?
Mocht Microsoft de gamingtroon van w10 terugeisen (momenteel bezet door Valve met Steam) dan krijg je de poppen aan het dansen.

We weten inmiddels dat Microsoft plannen heeft om ooit Windows 10 en Xbox te unificeren tot 1 uwp platform. Die plannen hebben ze voor nu in de koelkast gedaan vanwege tegenstand van oa Valve en andere uitgevers. Next gen zouden ze dat in principe zo kunnen doorvoeren met voor Valve alle gevolgen van dien. Niet gek dat ze dus werken aan een exitstrategie.

Ik denk overigens ook dat Valve niet echt weg wilt uit het lucratieve Windows ecosysteem. Voor nu is het alleen maar dreigen om hun markt te verdedigen.

Zal voor die ene 'anti windows' gebruiker wel interessant zijn neem ik aan, wat is anders de reden om Linux te gebruiken als je aantal spellen hebt die nog steeds niet (en ws nooit) zullen draaien erop? Elke keer is het 'groeiende lijst', 'steeds meer spellen', maar kijk je naar het absolute aantal en wat ervan in grote getalen wordt gespeeld, valt het opeens best tegen.

Zal hoofdzakelijk wel blijven voor hun SteamOS, maar ik heb zo al 4 MMO's die niet werken onder Wine (of welke versie dan ook), of in geval van Defiance 2050 en Warframe, de performance aanzienlijk slechter is.

"Anti-windows" betekend ook, anti een mogelijke toekomst waarin alles via een app store moet (MS wil dat heel graag), wat zou betekenen dat devs altijd een percentage van de winst mogen gaan afdragen en wie mag dat betalen? Het betekend ook dat er protocollen komen over wat wel en niet mag van MS en censureren wordt heel makkelijk. Als je het platform hebt (in dit geval Windows) heb je veel macht. Linux is Valve's poging om vrijheid te behouden. Ik vind dat heel slim van ze.

En Steam vraagt niet nu al diezelfde fee die de Microsoft Store zou doen? Jazeker wel, Valve charged 30%. De grote verliezer van zo'n zet zou dus vooral Valve zelf zijn. Voor de spelontwikkelaar is het dan financieel om het even of hij die 30% aan Microsoft kwijt is of aan Valve.

Zeker, maar concurrentie tussen beiden zet wel druk op die tarieven. Een toekomst waarbij alles via de Windows Store gaat levert die druk niet.

Het is al jaren 30%, dat lijkt ook de standaardsom die iedereen neemt. Apple met haar alleenheersschap in de AppStore ook. Daarnaast zorgt de concurrentie voornamelijk voor versplintering met eigen platformen en launchers. Iets wat paradoxaal genoeg dan weer niet als positief wordt bevonden .

Het verschil tussen de Windows Store en Steam is natuurlijk dat je de Windows Store opgedrongen krijgt vanuit het besturingssysteem en Steam los geinstalleerd moet worden. Je kunt makkelijk launchers van concurrenten er naast zetten (wat ook vaak gebeurt, iederen grote game producent heeft een eigen launcher tegenwoordig). Met de Windows Store kan dat niet.

Zoals Steam nu al is? Ironisch toch?

Zoals SinergyX al aankaart: Je hebt zonet een heel accurate omschrijving van Steam gegeven

Zeker, en daarom is er voor de dev ook weer een argument om Linux puur, zonder Steam, te ondersteunen

Het lijkt mij belangrijker dat er eens een fatsoenlijk PC-gaming alternatief komt naast Windows; dat is voor de markt het beste.

Dit. Het is een enorm voordeel dat PC gaming niet langer afhankelijk van Windows is.

Vind ik ook, maar de markt voor Steam Boxes kwam niet van de grond. Een grote concurrent van PC gaming op Windows is overigens de consoles. Die gesloten kastjes lopen als een trein, maar die kant gaat Valve duidelijk niet op.

Graag, de tijden van gestripte Windows Gamer editions voor die extra 1fps was okey.
De introductie van SteamOS leek dan een oplossing te zijn, mits de beloftes van 'een grote bibliotheek' dan nageleefd werd.

Maar zoals velen hier aangeven is het nog een stevige kunst moeilijke titels werkende te krijgen op Linux.
Ik zou extreem graag willen overstappen naar voltijds Linux, maar dan moet ik enkele games stoppen te gebruiken of wat gaan springen tussen 2 OS's.
Daarbij dat Windows nu een stevige hand heeft rondom het eqo systeem en hun nieuwe "snufjes" in Windows 10 om ons goed te analyseren ben ik zelfs van plan gamen op te geven op een PC en naar console te gaan om dan mijn PC gewoon Linux (Arch) te laten draaien.

Ik heb heb hoop, ik wil, ik hoop...

Voor mij is het meer dat ik liever Linux gebruik omdat ik er beter mee om kan gaan en omdat mijn desktop voor mijn werk ook linux moet hebben. Gaming is voor mij niet het primaire gebruik van mijn hardware. Het liefst heb ik geen dualboot, dus het liefst zou ik alles op linux doen, maar dat kan atm niet omdat te veel games niet op Linux draaien.

Omdat er ook mensen zijn die andere dingen doen dan gamen op hun pc? Het is echt niet zo dat elke Linux gebruiker 'anti-windows' is hoor.

Ik heb heel veel (zakelijke) tools die veel beter zijn en makkelijker te configureren onder Linux dan Windows. Langs de andere kant zijn er dan weer dingen die ik niet van Windows zou willen inruilen.

Zo’n probleem is het niet dat niet alle spellen op Linux draaien. Dat doen ze op Windows namelijk ook niet. Gamers die puur alleen op een Windows PC spelen vergeten wel eens dat een flink deel alleen op consoles draait en nooit naar de PC zal komen. Is dat een probleem voor Windows gamers? Natuurlijk niet, die hebben genoeg andere games om te spelen.

Maar op diezelfde manier is het ook geen probleem dat niet alle Windows games onder Linux draaien. Als Linux gamer koop je gewoon de spellen die wél draaien. Zolang het aanbod maar groot genoeg is ga je die paar Windows-only spellen niet missen. Daarom is de huidige opzet van Valve om de meest populaire games het eerst te ondersteunen naar mijn idee wel de juiste richting. Het grootste deel van het game aanbod (in het algemeen, niet alleen onder Windows) zijn toch obscure of simplistische games die niet langer dan een middagje leuk zijn. Als ze alle grote titels onder wine kunnen draaien hebben ze voor de meeste gamers al genoeg aanbod dat die Windows niet meer nodig hebben (en dus mogelijk een Steam Machine zouden willen kopen).

Jij klinkt als de juiste persoon om de beta te proberen

ah wat leuk, een submitje die het haalt

Ik hoop dat dit een mooie boost geeft voor Linux gaming, en Vulkan in het algemeen. Maar ik denk zelf toch dat de grootste drijfveer voor Valve is om Steam toch meer voeten aan de grond te laten krijgen in de Linux-wereld; gezien men inmiddels op Windows steeds meer concurrentie krijgt van uitgevers die toch weer met hun eigen store/launcher komen om zelf daar het maximale rendement uit te halen (vrij begrijpelijk). Of dit mogelijk weer leidt tot SteamOS en "gestandaardiseerde" Steamboxes lijkt me een vervolgstap.

Hmmm, Valve maakt zich gereed voor 'next gen' en microsoft's mogelijke volgende zet: de fusie van Xbox en Windows tot 1 uwp platform.
Betekent niet dat dat daadwerkelijk gaat gebeuren maar Valve lijkt wel voorbereidingen te treffen voor mocht het die kant op gaan.

Adoptie en ondersteuning van wine is een erg slimme zet van Valve; native ondersteuning van Windows apps in Linux tegen een minimale performance hit middels vertaalde API calls.
En naarmate tech en wine evolueren zal die performance hit alleen maar kleiner worden.

Ik lees hier verschillende termen in de comments.

Misschien een leuk artikel/review voor tweakers.
stap voor stap uitleg om linux gaming op te zetten, en performance vergelijken?

Mijn nieuwe pc is met een mATX moederbord gebouwd. Dat laat niet echt ruimte voor een tweede videokaart voor Linux met Windows pass-through.

Maar met dit vooruitzicht ga ik mooi voor dual boot om dit eens uit te proberen.
Met mijn all-AMD systeem is het gebruik van Vulkan erg fijn.

Steam VR werkt ook gewoon (met een deel van de headsets, waaronder mijn Vive). Dus dat wordt in ieder geval gewoon even snel wat Beatsaber tussendoor zonder reboot.

[Reactie gewijzigd door ArmEagle op 22 augustus 2018 11:13]

Nice beat saber op linux.
vanavond maar is proberen.

Ik ben over naar Linux, Overwatch werkt prima met DVXK en wine-esync via Lutris.
Voeg daar nog een aantal Linux native games aan toe en ik heb straks geen reden meer voor dual boot.

Net even het spel Company of Heroes 1 geprobeerd. CoH1 was wel niet whitelisted, dus moest even het vinkje aanzetten om toch alles te kunnen spelen. Het werkt gewoon, netjes. Click-Install-Play, geen input-lag, kleine inpact op framerate, geluid werkt, beeld werkt, etc. Accepteerde mijn standaard zoom-mod en een custom map, rondje tegen comp gespeeld.

Voorlopig oordeel: werkt goed.