Valve stopt met ondersteuning van SteamVR op macOS

Valve stopt met de ondersteuning van SteamVR op macOS. Het bedrijf zegt in een korte verklaring dat het al zijn energie voortaan wil steken in het ontwikkelen voor Windows en Linux. Legacy builds blijven wel werken.

Steam-ontwikkelaar Valve schrijft in een korte verklaring op zijn eigen website dat alle ondersteuning op OSX eindigt. Het bedrijf geeft geen verklaring, behalve dat 'het team zich kan blijven focussen op Windows en Linux'. OSX-gebruikers kunnen nog wel gebruik maken van legacy builds van het platform. Dat doen ze door in de SteamVR-sectie in Steam bèta-builds aan te zetten.

SteamVR voor Apples desktopplatform werd in 2017 aangekondigd, maar populair is het nooit echt geweest. Uit een recent gebruikersonderzoek bleek dat het overgrote merendeel van de SteamVR-gebruikers op Windows zit. Opvallend genoeg blijft de Linux-client dus wel werken.

Reacties (69)

[Amanoo]

Ik ben niet verbaasd. Apple is extreem koppig en weigert constant om zich aan standaarden te houden. Het vindt liever eigen standaarden uit, limiteert beschikbare hardware opties, en sluit alles af. Softwarebedrijven moeten zich vaak door allerlei hoepels wringen om OSX te blijven ondersteunen. Het is niet ongehoord dat een bedrijf meerdere keren hun programma voor een aanzienlijk deel moet herschrijven door API veranderingen in updates van OSX. Dan heb je nog dat hele gedoe met Metal, waarvan Apple blijkbaar verwacht dat iedereen het gaat ondersteunen, in plaats van zelf fatsoenlijk OpenGL of Vulkan te ondersteunen. Hun huidige OpenGL versie is behoorlijk verouderd en officieel niet eens meer ondersteund. In Vulkan hebben ze helemaal geen zin.

Het lijkt bijna alsof Apple de nieuwe Linux wil worden. Waar Linux steeds beter wordt met gaming en ondertussen wel het meeste ondersteunt, zit Apple het alleen maar moeilijker te maken om ze te ondersteunen. Ze concurreren zichzelf doelbewust de markt uit.

[nils83]

Vulkan werkt gewoon op MacOS, waarom zou Apple hier iets voor moeten doen?

https://www.khronos.org/vulkan/

[jabwd]

Dat is meer een wrapper over Metal heen. Het werkt; maar ideaal is het ook niet. Zeker ook omdat er best wat features missen in Metal die Vulkan wel heeft; en daardoor of geemuleert moeten worden of niet beschikbaar zijn. Dit vereist veel testen en waarschijnlijk hoofdpijn tijdens development voor ontwikkelaars.

Een vergelijkbaar probleem zie je ook in de grafische stack op macOS. Apple gebruikt nvidia niet meer omdat nvidia geen toegang wil geven tot de chips zelf; waar apple dus Metal drivers zelf wilt schrijven. AMD heeft daar geen issues mee maar wij macOS gebruikers zitten nu met het probleem dat je geen nvidia kaarten meer kan proppen in je macpro.

Aangezien kernel extensions ook deprecated zijn in de laatste versies van macOS verwacht ik dat macOS vrij snel gaat lijken op iOS en de mac als platform heel oninteressant gaat worden voor mij persoonlijk.

[Reactie gewijzigd door jabwd op 29 juli 2024 13:32]

[Wolfos]

Metal is niet zo'n groot probleem als dat jij omschrijft. Bijna alle grote ontwikkelaars gebruiken DirectX op Windows en geen Vulkan of OpenGL. De engines zijn toch zo opgezet om meerdere graphics API's te kunnen ondersteunen. Eéntje erbij is niet zoveel moeite dat het ineens niet meer rendabel is om te porten.

[Flake]

Dat valt vies tegen, het verleden (DX11 en lager) buiten beschouwing gelaten want als je DX12 afzet tegen Vulkan dan heeft Vulkan de betere papieren. De lijst van games met Vulkan is ook groter dan de lijst met DX12, en een hoop titels kunnen beide. OpenGL is voor 3D behoorlijk achterhaald maar voor 2D titels nog steeds mateloos populair.

@Amanoo heeft gelijk, een eigen graphics API voor een relatief impopulair platform voor gaming is een hindernis die niet de moeite waard is om te nemen.

[Verwijderd]

Grappig, want DirectX is een standaard
Als 1 bedrijf heeft laten zien eigen standaarden tot algemene standaard te willen uitroepen is het Microsoft wel...

Maar de VR game-markt is al niet heel groot, dan is OSX gewoon 'te klein' in aantal gebruikers gok ik, dus te duur.

[Amanoo]

In dat opzicht lijkt DirectX op Metal. Het is inderdaad ook een OS-specifieke standaard.

Het belangrijke verschil is dat Microsoft al vele jaren geleden verschillende veldslagen en oorlogen heeft gewonnen. DirectX stamt uit een tijd dat er tig grafische API's waren, en geen een ervan de grootste was. DirectX hoefde dus niemand van de troon te stoten. Op soortgelijke manier is ook Windows de grootste geworden. En ook al is DirectX 12 compleet anders dan voorgaande versies, en is het draagvlak voor DirectX 12 daarom kleiner geworden, het is nu een begrip.

Nu Windows en DirectX de grote jongens zijn, is er niet echt plaats meer voor een andere platform-afhankelijke API. Microsoft heeft nooit echt iemand van de troon hoeven stoten. Ze hadden concurrentie, maar niemand was destijds zo groot als zij nu zijn. In tegenstelling moet Apple het nu opnemen tegen een grote reus. Uiteraard kunnen ontwikkelaars voor zowel DirectX als Metal ontwikkelen, maar de geschiedenis leert dat ze vaak weinig zin hebben om een klein specifiek platform te ondersteunen als dat extra moeite kost.

De enige reden waarom Vulkan nog een kans maakt, is doordat Vulkan vrij breed ondersteund wordt. Vulkan werkt gewoon op Windows, Linux, Android, Nintendo Switch, toch een goed aantal platforms. Op OSX werkt het alleen via een wrapper, welke niet alle functionaliteit bevat. Als je een spel Vulkan laat gebruiken heb je dus direct Windows compatibiliteit, maar kan je ook nog ports maken naar andere platforms. Metal werkt alleen op OSX. Als het ook op Windows zou werken, zou ik nog een kans zien voor Metal. Dan nog hadden ze een koning die ze van de troon moesten stoten in DirectX, maar dan hadden ze nog een kans gehad. Die kans gaat nu naar Vulkan.

[InsanelyHack]

Absoluut geen -1

[field33P]

Je zou haast gaan verwachten dat makers van pro apps de constante rewrites op een gegeven moment zat gaan worden en hun klanten vertellen om naar Windows te gaan.

[Jimbolino]

Juist niet. Een nieuwe versie betekent opnieuw betaald worden.
Op Windows kun je tot in de oneindigheid oude software blijven gebruiken.

[84hannes]

Heeft de ondersteuning van Linux iets te maken met SteamOS? Bestaat dat nog?

[Gimmeabrake]

Ik weet niet of de naam SteamOS nog gebezigd wordt (edit zo te zien wel: https://store.steampowered.com/steamos/), maar Valve investeert sowieso nog steeds in Steam op linux. Ze leveren bijdrages aan onder andere wine en dxvk om meer Windows-game Linux-compatible te krijgen, en hebben Proton geintroduceerd (https://www.protondb.com/) om games automatisch met de juiste settings in wine op te starten. Op die site kun je ook zien welke games allemaal wel/niet compatible zijn op dit moment. Qua aantallen valt het aantal Linux gamers nog steeds in het niet bij Windows, en de ervaring laat - ondanks Proton - nog steeds af en toe te wensen over. Het is wel al beter dan een paar jaar geleden.

Mijn vermoeden is dat Steam verder op Linux blijft inzetten omdat ze bang zijn dat Microsoft haar gebruikers steeds meer naar de Microsoft Store gaat pushen, met restricties zoals je die op mobiele platforms als Android en iOS nu al hebt. Steam zou daar last van kunnen krijgen. Des te beter Steam op Linux werkt, des te beter is hun exit strategie, en des te beter is dus ook de onderhandelingspositie als Microsoft dreigt de boel op slot te gooien.

[Reactie gewijzigd door Gimmeabrake op 29 juli 2024 13:32]

[Eonfge]

Idem voor Mac natuurlijk. Het feit dat Apple alle 32bit applicaties over de schutting heeft gegooid, betekend dat Valve daar nog maar een fractie van zijn catalogus kan aanbieden. Het is niet ondenkbaar dat we over 10 jaar twee walled gardens hebben op de desktop, wat elke onafhankelijke winkel kan buiten sluiten. Zie ook, smartphones.

Voor nu zal de reguliere client nog wel Mac blijven ondersteunen, maar ik zie als Linux gebruiker een behoorlijke focus verschuiving in de afgelopen paar jaar vanuit Valve.

[84hannes]

Interessante insteek: Valve dumpt MacOS omdat het bang is dat het ze het steeds moeilijker gaan krijgen op prioritaire platformen. Maar ze kunnen het zichzelf simpelweg (nog) niet veroorloven ook Windows te dumpen.

[Eonfge]

Mogelijk krijgen jij en andere gebruikers geen keuze.

Je ziet dat Windows al een paar keer heeft geprobeerd om een gesloten platform te maken. Eerst Windows 8 RT, nu Windows 10 ARM en Windows 10 S. Dit zijn speciale versies van Windows welke nu al geen software meer kunnen installeren buiten de Store om. Bij ARM is dat minder problematisch want de hoeveelheid ARM software is nog beperkt, maar als jij over tien jaar nog je eigen programma's wilt draaien, dan zul je mogelijk alleen nog met de Windows Pro versie uit de voeten kunnen.

En voor 90% van de gebruikers is dat waarschijnlijk prima. Microsoft zit toch al elleboog diep in de zakelijke wereld en mensen vinden het bij telefoons ook prima. Ik zie het dan ook zelf met lede ogen aan. (Retro) Gamers en gebruikers van 'reguliere' applicaties zullen dus nog wel eens een hele lastige keuze kunnen krijgen: Of je eigen gewoonten aanpassen en Linux gebruiken, of Pro editie kopen, waar Windows omwille van de zakelijke markt nog wel langer 'reguliere' applicaties zal dulden.

[84hannes]

offtopic:
Maak je over mij niet druk. Ik houdt niet van lock-in en zit al decennia op Linux. Maar ik heb het makkelijk: ik speel zelden computerspelletjes en steek liever extra moeite in een alternatief dan dat ik iets van Adobe gebruik.

[Reactie gewijzigd door 84hannes op 29 juli 2024 13:32]

[graverobber2]

Bij ARM is dat minder problematisch want de hoeveelheid ARM software is nog beperkt

Het principe achter UWP (Universal Windows Platform) is dat apps cpu architectuur onafhankelijk zouden moeten zijn (toen geïntroduceerd voor windows mobile).

[xFeverr]

Wil er nog wel aan toevoegen dat je de S-mode in Windows 10S gewoon uit kunt zetten. En dat Windows 10 ARM dus weldegelijk software buitenom de store accepteert.

Windows ( RT moest eigenlijk het iOS/Android alternatief worden. Maar omdat er een desktop bij zat was het wat lastig uit te leggen allemaal. Ze hadden het zichzelf een stuk makkelijker gemaakt als er dus geen desktop bij zat.

Maar goed dat ze er van zijn teruggekomen dan.

[field33P]

Elke keer wanneer Microsoft het platform dicht probeert te gooien is de backlash groot genoeg om het niet te doen, simpelweg omdat mensen nog een hele rits aan x86-applicaties willen draaien.

[Daoka]

Valve zal misschien moeilijker krijgen op de populaire platformen. Maar die dumpen voor de minder populaire platformen dan hebben ze ook waarschijnlijk minder potentiële klanten.

[marhalm]

Catalina heeft 99% van de bestaande software onbruikbaar gemaakt voor de Mac. Ik snap dat je met je tijd wilt meegaan, maar maak dan iets van een emulator ofzo.

Apple heeft alle kans op gamen op de Mac in een sierlijke zwaai de nek omgedraaid. Maar niet alleen games, ook veel oudere pakketten zoals bv Photoshop CS5 werken niet meer. Adobe patcht het niet want die wil je aan een abonnement hebben.

[Wolfos]

Om het van de andere kant te bekijken; Steam zit nu in Microsoft's natuurlijke positie. Als Microsoft niet zo ontzettend lang gefaald had om een fatsoenlijk werkende app store te bouwen dan was het nooit wat geworden met Steam.
Microsoft zal waarschijnlijk nooit alternatieve softwarebronnen blokkeren, maar ze kunnen wel de markt veroveren.

[Tokkes]

Goh... met al het streaming geweld tegenwoordig, Steam Streaming dat op zich best goed werkt en het hele gedoe met de Steam Link app, en hun inzet op Linux zegt mij dat binnen dit en 5 jaar Valve met een 'echte' stream service komt... Dan kan er flink wat concurrentie inpakken volgens mij.

[skunkopaat]

Ja, volgens mij is steamOS gewoon een schil bovenop een ietwat uitgeklede Linux. Alle spellen voor steamOS werken ook op Linux.

Als je je PC gebruikt exclusief om te game en hij draait Linux, kan ik me best voorstellen dat je steamOS draait.

[Gjaerd]

Officieel nog steeds in beta volgens de downloadpagina, maar bestaat zeker nog. Valve blijft voor zover ik weet ook nog steeds groot voorstander van Linux.

[Amanoo]

Ik hoorde onlangs dat Valve werkt aan een rework van SteamOS. Sowieso hebben ze nog steeds plannen met Linux. In zijn huidige vorm is SteamOS behoorlijk geflopt. Ze hadden dan ook wel heel erg ingezet op die Steam Machines, maar dat waren uiteindelijk vooral een soort overpriced computers. Ze waren heel leuk binnen een bepaalde niche, de niche die een computer onder de TV wil hebben en sowieso al veel games heeft op de PC. Maar ze hadden niet echt een goed selling point buiten deze vrij specifieke use case. En eigenlijk was SteamOS niets zonder Steam Machines, dus dat flopte samen met die Machines.

[Reactie gewijzigd door Amanoo op 29 juli 2024 13:32]

[mrtl]

MacOS is niet goed geschikt voor video games, vooral door het gebrek aan ondersteuning voor een fatsoenlijke grafische API zoals Vulkan of een moderne versie van OpenGL.

[Shaidar]

Nah, Metal kan dat ook allemaal, maar voor die 3 man en een paardekop die op macOS wille gamen is de sop het kolen niet waard.

[Blubkens]

Volgens mij zijn er niet echt SteamVR games beschikbaar. Van alles wat ik in mijn library staat werkt er niks met MacOS.

[Wolfos]

Het zijn er grofweg honderd. De vraag is dan wel weer of die ook VR op MacOS ondersteunen.

[GekkePrutser]

Ja, maar allemaal oudere vanwege die oudere versie van OpenGL die Apple ondersteunt. Echte AAA content is er niet meer, helaas... Apple heeft een paar keer wat games gestimuleerd (dacht dat de laatste keer een Call Of Duty erbij was), maar het blijft brak.

Zoals @Shaidar al zegt: Metal kan het allemaal maar zolang het gesloten blijft zal je alleen wat ports van iPhone games daarmee zien.

[Reactie gewijzigd door GekkePrutser op 29 juli 2024 13:32]

[Wolfos]

Mijn comment ging specifiek over VR games voor Mac. Van de traditionele games zijn er 21.680 beschikbaar. Daar zitten ook een paar AAA games bij. De Total War games zijn bijvoorbeeld allemaal beschikbaar. Ook Paradox Interactive heeft een groot aanbod voor Mac.

Voor gaming moet je geen Mac kopen, maar als je een Mac hebt en af en toe een spelletje wilt spelen is er voldoende aanbod. Meer dan voor welke game console dan ook.

[Reactie gewijzigd door Wolfos op 29 juli 2024 13:32]

[Blubkens]

Ja inderdaad. Want ik weet dat Keep Talking Nobody Explodes niet in de lijst staat op Mac. Ook als je bij de systeemvereisten kijkt op de gamepagina onderaan staat informatie over VR alleen onder het windows tabje.

Ook als je die lijst sorteert op reviews staat er niet veel soeps tussen. Ik verwacht dat grotendeels daarvan een normale Mac game is en niet in VR en als VR wel beschikbaar is dat het dan meer een bioscoop achtige ervaring is.

[SuperDre]

Maar dat is nou net het probleem, Metal is weer een andere API die nog niet zo heel lang geleden (in verhouding) is toegevoegd, als Apple nu gewoon fatsoenlijke Vulkan ondersteuning zou toevoegen, en van hun eigen API af zouden stappen, zou dat enorm veel schelen. Maargoed in dit geval is sowieso het aantal Mac gebruikers dat Steam gebruikt is 3,8% en daarvan zal dus het aantal personen dat ook nog aan VR marginaal zijn. Linux is zelfs maar 0,85%, maar de reden dat die ondersteund blijft heeft waarschijnlijk meer te maken met dat een hoop mensen bij Valve zelf Linux fanaten zijn..

[Amanoo]

Valve schijnt ook nog steeds iets van plan te zijn met Linux/SteamOS. Het schijnt niet alleen fanatisme te zijn, maar ook een financieel plan. Volgens geruchten zouden ze nog behoorlijk aan SteamOS aan het timmeren zijn. Wat ze precies verwachten te doen is alleen nog niet duidelijk.

[Ayporos]

Precies dit.

Je kunt niet alleen naar de huidige cijfers kijken en zeggen x of y.
Het gaat ook om wat ze verwachten wat de toekomst gaat doen en wat ze zelf op de roadmap hebben staan.
Gezien het (gefaalde) Steambox idee heeft Valve wel zeker aspiraties om een 'alles in een' oplossing te willen aan kunnen bieden.. misschien zelfs een gamestreaming service die op (linux based) servers kan draaien. Who knows, maar persoonlijk zou ik als ik Valve was in der daad meer zien in een toekomst op Linux dan op MacOS. Hell, kijk naar Apple desktops/laptops, je ziet duidelijk dat dat een beetje een ondergeschoven kindje is waar Apple niet écht (meer) in geloofd, als ze dat ooit al gedaan hebben.

En dan hebben we het nog niet eens gehad over gameondersteuning. Valve bied met Steam(VR) een platform aan.. en als er geen content (voor MacOS) op dat platform gemaakt wordt door publishers/studios dan heeft het voor Steam ook geen nut om MacOS te ondersteunen.
API ondersteuning en/of het gebrek daarvan speelt daar uiteraard ook een rol bij..

[Reactie gewijzigd door Ayporos op 29 juli 2024 13:32]

[Wolfos]

Apple's Metal schijnt een hele goede graphics API te zijn, die door de populaire engines gewoon ondersteund word.

[rboerdijk]

... maar voor de "kleinere" totaal oninteressant. Als je multiplatform wilt gaan en vulkan/openGL hebt en windows/Linux, dan zou macOS ook voor de hand liggen... Maar de extra moeite om naar native-Metal te gaan staat niet in verhouding tot de te verwachten verkoop ( en dan bedoel ik geen kleine iOS games, maar de wat grotere titels).

Ondertussen is er wel een vulkan-oplossing op basis van Metal (niet dat je daar wat aan hebt als je op openGL zit) maar zelfs dan, te langzame gpu's. VR op mac? Niet echt onverwacht dat valve daar geen moeite in wil steken.

[Reactie gewijzigd door rboerdijk op 29 juli 2024 13:32]

[johnkeates]

Het lijkt me juist als kleine erg interessant om dat je dan toch je eigen engine niet gaat maken, daar ben je niet groot genoeg voor. Als je dan dus met Unity of UE aan komt zetten is packages maken voor Windows, Linux, en macOS een kwestie van klikken. Zo werkt dat ook met CryEngine, IdTech enz. Vaak komt dat ook de kwaliteit van de engines ten goede: waar je normaal misschien een vieze native hack zou gebruiken moet je nu in je engine altijd een goede abstractie neerzetten om dat je geen platform-specifieke calls kan doen zonder compatibility stuk te maken. Alleen platform-specifieke functionaliteit (bijv. TouchID vs. Windows Hello) zou je misschien andere moeten aanroepen, maar vaak genoeg doe je dat ook niet zelf; je roept iets in het OS aan om de authenticatie voor je te doen en dan zoekt het OS maar uit welke opties er zijn. Zelfde met netwerken, graphics, storage etc.

[Noxious]

Er zijn een boel kleinere engines/frameworks die populair zijn voor indie games hoor.

Om er maar wat te noemen: Godot, MonoGame, Armory, Defold, Corona, Phaser, Love2D, alle GameMaker/RPGMaker versies, kaal Electron met een framework of losse tools (zoals isodom.js) en nog veel meer...

Veel van de grote/bekende indie games van de afgelopen jaren hebben gebruik gemaakt van deze engines. Om uiteenlopende redenen, maar vaak heeft het te maken met gemak, prijs, community, het niveau van controle wat je hebt, enz.. Veel van deze kleinere communities hebben niet de kracht om zomaar even een nieuwe API als Metal te gaan supporten. Sommige gebruiken SDL2 en kunnen gebruik maken van het werk van anderen hiervoor, maar het gaat niet allemaal automatisch - en testen kost ook geld (devices nodig), kennis en tijd.

[johnkeates]

Uiteraard, het ging ook niet specifiek over die vier engines, maar eerder over het feit dat een developer niet zelf gaat kijken wat voor low level API ze willen gebruiken, dat is waarom je een engine gebruikt.

Vaak zie je dat je in kleinere opstellingen dan eerder voor een porting layer gaat, bijv. MoltenVK zodat je je Vulkan base kan gebruiken op Metal. Je hebt dacht ik ook twee andere layers (een die low level abstraction in C# .NET doet?) die ook Metal als backend hebben. Sommige kleinere eingines hebben ook gewoon nog steeds OpenGL en OpenGL ES support, en ja, dat is in Apple land deprecated, maar het werkt nog steeds.

Daarnaast is er nog niet echt een andere oplossing; tenzij je je op 1 platform richt zal je nagnoeg altijd meerdere soorten graphics APIs moeten gebruiken. Vulkan is pas recent in Android aanwezig om maar wat te noemen, en niet eens compleet. PlayStation heeft nagenoeg bij elke console een andere low-level en mid-level API gehad, en bij Nintendo was dat niet echt anders. SDL kan je gebruiken met Metal als renderer, dus ook daar zit je niet vast.

Met andere woorden: ook kleinere engines en andere frameworks werken relatief goed met elkaar (Behalve DirectX, dat werkt zonder DXVK nergens behalve op MS spullen, en Metal werkt alleen op Darwin), en door dat de verschillende low-level API's steeds meer op elkaar lijken (qua features en conventies) kan je met een gemeenschappelijke porting layer steeds vaker zonder veel wijzigingen renderen op verschillende backends.

Dat wil niet zeggen dat het een ideale situatie is, maar DirectX zal nooit cross-platform worden, en OpenGL heeft gefaald in een sterke complete standaard zijn, ongeacht of dat aan de harware, software of integrators lag.

Misschien dat als Microsoft DirectX open had gemaakt en Linux en macOS daar dus implementaties van hadden kunnen hebben er wat schot in de zaak zat, maar dat zal niet gebeuren want dat is een van de weinige USP's van home user sales. Als je alles in een browser kan doen en high performance graphics op elk OS kan doen, dan heeft Windows weinig bestaansrecht meer als je niet in een lifecycle management circlejerk vast zit op bijv. een kantoor.

[rboerdijk]

Apple heeft meegedaan aan Vulkan, maar het uiteindelijk gedropt een Metal gepresenteerd. Zal wel een goede reden achterzitten, misschien vanwege eigen hardware en flexibeler om specifiek geschikt te maken voor hun hardware. Volgens mij is dat een gemiste kans geweest (ook om software buiten de bestaande 'grote game engines') naar het eigen platform te trekken.

OpenGL staat op de deprecated lijst ( dus oude games zullen op een gegeven ogenblik niet meer werken). Vorig jaar een windows PC gekocht (na 10 jaar mac-only) en nu speel ik daarop games ( en ondertussen ook grotendeels terug gestapt van xcode naar visual studio voor prive ).

[Reactie gewijzigd door rboerdijk op 29 juli 2024 13:32]

[johnkeates]

Het is sowieso jammer dat we nog steeds geen API 'voor iedereen' hebben, maar dat zal ook niet gebeuren vrees ik; die technische utopie wordt tegengehouden door geforceerde marktsegmentatie. Op dit moment kan je alleen voor twee platformen met 1 codebase uit: xbox/windows, en ios/macos/tvos, voor Linux/Android moet je twee keer ontwikkelen en nintendo en playstation zijn gevallen apart. Eigenlijk zitten we dus nog met 6 'destinations'.

[Reactie gewijzigd door johnkeates op 29 juli 2024 13:32]

[PhantomPotato]

Even een correctie als een programmeur in embedded systemen en high performance applicaties in algemeen: Voor een game wil je dergelijke abstractie NIET hebben. De processor moet dan instructies on the fly via een pointer krijgen en die staan typisch niet in je cache als je dat via een pointer doet. Dan krijg je een cache miss. Afhankelijk van de compiler/linker gebeurt dit zelfs met een "gewone" function call.
Id Tech doet dit bijvoorbeeld niet met abstractie in dezelfde zin als virtual functions, maar met ifdefs. Dit is in sommige gevallen dubbel werk, maar significant sneller dan abstractie. Hun editor gaat live uit van de Vulkan renderer en WinAPI, maar de export naar een ander platform omzeilt deze code en pakt dan bijvoorbeeld de PS4 GNM met de PS4 toolchain daar voor in de plaats.
Veel directer en sneller. Abstractie is niet gewenst (en IMO zijn diens voordelen erg overdreven en verre van de enige oplossing om software beter onderhoudbaar te maken)

[johnkeates]

Met abstractie doelde ik ook niet op de vorm die je misschien in software architectuur verwacht (zoals generics), maar bijv. macros en andere compile-time selectie (zoals je genoemde ifdefs). Sommige spullen zijn altijd wel een abstractie (als in, layered), bijv als je shaders programmatisch opbouwt voor dat je ze naar de GPU stuurt, of selecties moet maken op basis van beschikbare APIs (bijv. verschil in hardware ondersteuning). Je kan in theorie wel meerdere binaries maken zoals je dat in Windows nog steeds voor 32-bit en 64-bit moet doen, en dan ook versies voor verschillende soorten hardware (SSE niveaus, GPU API niveaus) maar dat is niet echt een UX waar de gebruiker blij van zal worden ;-)

[rboerdijk]

Ik had wat specifieker moeten zijn, de kleinere indie-devs pakken uiteraard een bestaande engine (eigen engine ontwikkelen is onrealistisch). De ietwat grotere hebben de keuze zelf een engine te schrijven (of werken al jaren op een eigen engine) en in dit geval is metal te oninteressant (misschien nog wel via de omweg MoltenVK).

[Caayn]

Populaire game engines ondersteunen doorgaans "alles" mede daarom zijn ze populair Dat zegt verder niks.

Ze moeten ook wel willen ze mee dingen op de iOS userbase als game engine.

[Gustaaf437]

Metal is op zich best capabel, maar het probleem is dat Apple ontwikkelaars niet echt steunt met problemen in de API. Als er in DirectX een klein dingetje mist, dan brengt Microsoft daar snel een update voor uit. Bij Apple mag je hopen dat het in de volgende major macOS-versie zit, maar zelfs dat is niet altijd zo. Het gevolg is dat sommige games halfbakken uitgebracht moeten worden of worden gecanceld.

Wat er bij Apple nog meer speelt is dat Apple de volledige controle heeft over wie grafische drivers kan leveren. Nvidia’s eigen drivers worden als sinds Mojave geblokkeerd, terwijl er nog wel Macs met Nvidia kaart worden ondersteunt. Je moet als ontwikkelaar ook hier maar weer geluk hebben dat Apple de drivers update als dat voor jouw technische hoogstandje nodig is. Apple is daar heel laks in. Alleen voor hun eigen programma’s voegen ze nog wel eens tussentijds wat toe, maar voor anderen; ho maar.

[slamhk]

Klopt, alhoewel wil ik er wel bij toevoegen dat er wel projecten gaande zijn om Vulkan naar MacOS te brengen via MoltenVK: https://en.wikipedia.org/wiki/MoltenVK. Een aantal games maakt hier al gebruik van zoals te zien: https://en.wikipedia.org/wiki/Metal_(API)#Performance . Dit maakt het veel "makkelijker" om voor devs toch de stap te maken om hun game zelf te porten naar MacOS aangezien het daar toch echt achterloopt als je het vergelijkt met iOS.

Als ik me goed herriner heeft Apple vooral aan Metal gewerkt omdat er tijdens de release geen alternatief was (Vulkan was er nog niet echt) en Apple kennende ontwikkelen ze graag hun eigen software wat ook aansluit op hun hardware (b.v. A-series ARM processors). Super zonde als je b.v. alleen MacOS product hebt en je enige alternatief is om te gaan Bootcampen om uberhaupt spellen te spelen.

Natuurlijk is het veel fijner als er vanuit MacOS zelf al ondersteuning is voor Vulkan, niet allen voor games, maar ook voor de hopelijke groei in GPGPU applications met Vulkan, aangezien de industrie nog vooral gebruik maakt van CUDA zoals vele machine learning libraries. Maar ik betwijfel dat het wel gebeurt, tenzij AMD zelf echt grote stappen maakt in dat gebied. Dan wordt het toch echt lastiger voor Apple om Vulkan te negeren.

[thof]

Kan het niet te maken hebben met de geruchten/plannen van Apple om meer op eigen CPU's in te gaan zetten gebaseerd op de ARM structuren?

[johnkeates]

Nee het heeft te maken met geld en tijd vs. opbrengst. SteamVR ondersteuning aanbieden zonder dat mensen games voor een platform publiceren betekent dat je wel kosten hebt maar geen inkomsten voor dat onderdeel. Dat kan je een tijdje doen om te kijken of de markt aantrekt, maar niet oneindig. Dat is wel jammer, want als de hele optie er niet meer is zal het gewoon verdwijnen. Aan de andere kant heeft Apple bijv. zelf genoeg AR games in hun eigen store en verdienen publishers daar ook prima geld aan. Wat dat betreft is het niet anders dan bijv. PS vs. XB native stores.

[Chrisje1983]

Dat was ook het eerste waar ik aan dacht, als de twijfel van steam er al was dan zal dit de laatste genadeklap zijn geweest.

[johnkeates]

Ik zou dan verwachten dat ze heel Steam opheffen, 32-bit is al gedropt, dus tenzij hun devs frameworks en engines gebruiken die kunnen publiceren naar meerdere architecturen (en ze daar zin in hebben en nog bestaan) zal heel veel spul niet meer werken.

[Chrisje1983]

Waarom zouden ze heel steam moeten opheffen, ik heb niet heel veel verstand van hetgeen waar jij over praat maar heel steam opheffen zie ik de noodzaak niet zo van in.
Windows en de pc architecture is een vaste basis die niet veranderd, apple daarin tegen heeft er een handje van om de boel om te gooien.

Als ik even mijn eigen situatie mag uitlichten, apple is van power pc naar intel overgestapt, dat kwam mij destijds toevallig goed uit, ik stapte over van windows naar apple wat toevallig goed uit pakte op apple, daarnaast keek ik destijds uit naar apple omdat het os mij wel aansprak ivm creativiteit, je hebt niet altijd zin om de computer nerd uit te hangen toch?

Als apple de overstap maakt van intel naar arm, dan hang ik. Ik heb veel hardware die niet meer mee gaat met apple's nieuwe arm plan (windows nog wel) en dus mijn hardware wordt vergeten. Nou hebben we het niet over simpele hardware maar over spullen waarvan het me destijds behoorlijk wat heeft gekost om toekomst zeker te zijn.
Nou mag ik niet klagen want het loopt al even mee, maar... als apple stopt met intel en de plugins die ik gebruik ook, heb ik 2 opties. Dat is of mac blijven gebruiken en alle hardware vervangen en dat kan ik eigenlijk niet betalen, of de tweede optie, terug overstappen naar windows, en dan ineens kan ik nog jaren verder.

Nou is mijn situatie natuurlijk een situatie die niet standaard is, maar ik denk dat dit wel het begin is van het einde van apple in mijn wereldje.

[Reactie gewijzigd door Chrisje1983 op 29 juli 2024 13:32]

[johnkeates]

Ze moeten niks, maar als Valve het 'over-de-schutting-gooi' concept wil handhaven zou je op elk OS tot in den treure de API's die toen de content gemaakt werd moeten blijven ondersteunen. Dat is niet realistisch. 8-bit en 16-bit software draait op Windows en macOS bijv. al jaren niet meer, terwijl er gigantisch veel software voor is. Dat kan je dan wel emuleren, maar niet meer native draaien, tenzij je dus hardware en software uit die tijd bewaart.

Wat Apple doet is niet perse uniek, het is bijna eerder uniek dat Windows het niet doet (of er kompleet mee faalt, zie hun uitstapjes naar ARM). Windows NT3.51 draaide prima op meerdere architecturen, en toen dat over was hebben we nog jaren Itanium versies van Windows gehad, maar eigenlijk is dat aan het eind van de rit allemaal gefaald. De xbox draaide eerst op x86, daarna op PowerPC en daarna weer op x86, da's ook vaag. Het kan dus wel, maar blijkbaar is het ecosysteem zo vastgeroest op het 'pleur de software neer en raak het niet meer aan' dat dat alleen werkt als je zelf de hardware en software maakt. Dat is dan iets wat Apple eigenlijk 100% doet; dat is waarom ze van custom naar m68k naar ppc naar intel kunnen bewegen, en ondertussen parallel ARM draaien op mobile en TV devices.

Wat je in een situatie doet waar je specialistische hardware hebt, of 'veel' hardware die om een of andere reden een harde dependency op de host architectuur heeft is voor de levensduur van je hardware zorgen dat je dat spul allemaal als 'set' behoudt tot dat je toch al zou mireren en dan neem je wat er op dat moment beschikbaar is.

Apple zal ook niet zomaar Intel droppen, net als dat ze bij PPC, m86k en classic vs. unix jaren lang complete VMs en porting layers gehad hebben zal dat als ze bijv. naar ARM overstappen ook zo gebeuren.

Hetzelfde is met het maken van binaries: de SDKs en Tools zijn vooraf al beschikbaar dus je kan er van uit gaan dat je een overgangsperiode hebt waar 'alles' beschikbaar blijft.

Niks is 'toekomstvast' en zodra je interactie aan gaat met de rest van de wereld (bijv. internet, opslag media) zal een gemeenschappelijke vooruitgang er altijd voor zorgen dat 'oudere' systemen of systemen die langer leven niet altijd mee kunnen gaan. Je kan tegenwoordig bijv. niet echt makkelijk een SLIP verbinding van je internetprovider krijgen. ISDN is ook dood. En inbellen met een modem kan vaak niet, want 'telefoonlijnen' zijn bij nagenoeg alle moderne installaties VoIP of een ATA waarbij inbellen meestal niet werkt of gefilterd wordt. IrDA is ook vrij dood, net als floppies, diskettes en CD's.

Vergelijk het met de media/infotainment systemen in auto's: vaak zijn die ergens tijdens het ontwerpen van de auto geselecteerd, maar zodra het op de markt komt is het eigenlijk al verouderd, en voor de resterende levensduur van de auto wordt het er niet bepaald beter op.

[Reactie gewijzigd door johnkeates op 29 juli 2024 13:32]

[Chrisje1983]

Oke, ik vind je verhaal interressant en ga het onthouden. Ik begrijp jouw ook.

Mijn situatie is nu goed te doen, ik kan vanaf de macbook pro (2014 model) en mac pro (2008, 8-core) bij mijn hardware maar als ik dit ARM verhaal begrijp en ik ga upgraden gaat het niet zo blijven .

Windows daarintegen (ik moet zeggen dat ik best wel content ben met win 10, ik heb een creatieve laptop in de woonkamer waarvan het niet zo erg is als de kinderen het stuk maken) geen moeite met mijn hardware, daarnaast, als de fabrikant en/of windows het niet ondersteunt kan ik mij eigenljik altijd wel redden door drivers te sideloaden of te knooien of wat dan ook.

[johnkeates]

Zolang je MacBook Pro en je Mac Pro het blijven doen zal je ze ook kunnen blijven gebruiken. Maar als het stuk gaat en vervangende onderdelen steeds moeilijker te krijgen zijn zal het een keer afgelopen zijn.

Dat staat op zich ook los van ARM: dat is eigenlijk alleen belangrijk op het moment dat je iets nieuws koopt. Alles wat er al is blijft tot op een zekere hoogte werken. Dat zie je eigenlijk al aan je Mac Pro, die doet het sinds 2008 en nu nog steeds, da's 12 jaar!

Het enige waar je snel last van krijgt met oudere systemen is interactie met dynamische systemen zoals het internet. Internet gaat door en blijft veranderen. Een windows versie van 10 jaar oud zal je niet echt aan internet willen hangen, die zal bijgewerkt moeten worden naar en recentere versie om veilig en effectief te internetten. Hetzelfde geldt voor Linux en macOS uiteraard.

[Chrisje1983]

Ik snap je, mijn macs hangen alleen aan de nas en zijn geblokkeert op de wan poort, ik heb ze ook niet nodig op het internet.

De book en desktop macs zullen het ongetwijfeld wel blijven doen maar uiteindelijk zal ik willen upgraden om meer plugins, te kunnen draaien.
Dat is dus ook mijn probleem, ik kan dan niet mee met mac, want dan verlies ik mijn hardware en moet ik een investering doen in nieuwe hardware, als ik voor windows kies, kan mijn hardware voorlopig nog even mee, en ik denk dat apple daarmee heel veel hobbyisten en professionals in mijn hoek het nekschot geeft, wie gaat de kaasschaaf betalen? Alleen de bedrijven waar de kaassschaaf echt geld opleverd, dat is bij mij niet het geval.

Goed, ik ben nogal afgedwaalt maar het mac intel>arm verhaal houd mij wel bezig, ik heb in elk geval een zekerheid en dat is windows 10, het systeem waar ik destijds juist van weg gelopen ben.

[EvilItSelf]

Wat is je argument dat Metal geen fatsoenlijke grafische API is en Vulkan of OpenGL wel?

[Verwijderd]

Gabe Newell heeft notorisch een hekel aan Microsoft (Windows), zijn voormalige werkgever. In interviews heeft hij aangegeven zich daarom in te zetten om Linux een fatsoenlijk alternatief voor Windows te maken voor o.a. games. Vandaar dat Valve's games en software nog steeds wordt ontwikkeld voor Linux. Waarom ze hun MacOS support staken weet ik alleen niet.

[Muna34]

Ik denk dat het gewoon niet interessant is. 85% van de gebruikers gebruiken Windows. Zie statistieken.

Persoonlijk ben ik aan het genieten van Proton/Lutris/Wine. Met de komst van Vulkan draait alles echt super performant op Linux (Arch).

Ik juich alles wat Valve hieraan bijdraagt alleen maar toe. Hulde voor deze ontwikkelaars die een mogelijkheid tot keuze maken.

[Amanoo]

Als Linux gebruiker ben ik ook wel zeer te spreken over het handelen van Valve. Het is niet te overschatten hoeveel ze voor Linux hebben betekend. Ze hebben ook enorm in WINE geïnvesteerd. De ontwikkelaar van DXVK (die het oorspronkelijk als hobby deed) wordt nu door Valve betaald zodat hij full-time ermee bezig kan. Verder hebben ze veel samengewerkt met CodeWeavers, en via hen veel geld in de ontwikkeling van WINE gestoken. En uiteindelijk brachten ze zelf Proton uit, waarmee WINE binnen Steam zelf bruikbaar wordt. Het resultaat mag er wezen.

Wat betreft Mac OS, ik denk dat dat gewoon aan Apple ligt. Apple doet notoir moeilijk. Ze weigeren constant om andere standaarden te ondersteunen, en gaan alsmaar hun eigen weg. Momenteel is de laatste OpenGL versie die onofficieel wordt ondersteund zwaar verouderd. Officieel is er helemaal geen ondersteuning. Ook Vulkan wordt compleet niet ondersteund. Ze verwachten dat iedere ontwikkelaar in plaats daarvan zomaar hun eigen Metal API gaat ondersteunen. Alleen is er bijna niemand die dat wil.

Dat is dan ook het grote verschil tussen Mac en Linux. Linux wil juist heel graag zoveel mogelijk ondersteunen. Als iets niet ondersteund wordt zijn er al gauw een paar nerds die zich in alle bochten wringen om het toch werkend te krijgen op Linux. Ook werkt de open source community er hard aan om ondersteunen van Linux zo makkelijk mogelijk te maken. Apple weigert dit, en verwacht van de ontwikkelaars van software en hardware dat zij enorme moeite doen om juist Mac te ondersteunen.

Waar Linux moeite doet om ontwikkelaars naar zich toe te trekken, verwacht Apple juist dezelfde hoeveelheid moeite van de ontwikkelaars. Op een gegeven moment zijn ontwikkelaars er een keer klaar mee.

[johnkeates]

Het zou me niks verbazen als VR a la console gescheiden wordt van de traditionele desktop-ervaring. Microsoft wil alles natuurlijk graag mengen, en Stream VR start je nog steeds van je desktop, maar ik heb niet het idee dat dat een houdbare positie is, daar is het gewoon te 'anders' voor.

[Caayn]

Opvallend genoeg blijft de Linux-client dus wel werken.

Opzich niet zo gek. Valve is al lange tijd gek van Linux.

MacOS, tja, daar zal Apple toch eerst eens serieus aandacht moeten besteden aan het ondersteunen van standaarden (Vulkan of MS heel lief aankijken voor DirectX) inplaats van eigenwijs te zijn met Metal en third-party drivers toestaan zoals die van Nvidia voordat het een "game" platform wordt. Zo gek vind ik de keuze van Valve dan ook niet om MacOS ondersteuning te laten vallen voor SteamVR.

[Reactie gewijzigd door Caayn op 29 juli 2024 13:32]

[johnkeates]

MS gaat DirectX nooit ergens anders toestaan, dan hebben gamers geen reden meer om Windows te draaien. Apple heeft Metal, en veel gebruikte engines die Vulkan ondersteunen ondersteunen nagenoeg altijd ook Metal. Alles is gewoon aanwezig maar men gebruikt het niet. Een game developer gaat ook niet low level tegen OS-API's aan praten, daar heb je engines voor, soms heb je in een team nog wel een low level engineer zitten maar dat is voornamelijk als je cutting edge hardware en non-standaard uitbreidingen wil gebruiken, en dat is nou juist iets van 99% van de developers toch niet doet.

Valve draait gewoon verlies op VR voor macOS, dus stoppen ze er mee. En dat komt puur door het gebrek aan VR games op macOS (in Steam) en door het gebrek aan VR-gebruikers op macOS.

[Wolfos]

Verbaast me eigenlijk dat het wel ondersteunt werd. Het gros van de Mac gebruikers zal een geïntegreerde GPU hebben. VR games hebben meestal toch wel wat pittigere hardware nodig.

[johnkeates]

Het gros van de PC-gebruikers heeft ook een iGPU dus dat zal het nier perse zijn De meeste cheap-ass laptops die men koopt hebben misschien net een mid-range radeon in een APU aan boord, en dat is dan wel het beste wat je kan verwachten (en niet genoeg voor high-res high-refresh VR).

[pBook]

Niemand koopt een Mac om op te gamen, dat is nooit zo geweest. Er zullen altijd wel een handjevol games op werken en de Metal API is ook behoorlijk goed maar gezien het marktaandeel en de interesse in games van die groep, lijkt me dit een logisch besluit.

[Menesis]

Lol, ik wist niet eens dat dat bestond. Ik werk met VR en heb een 2019 macbook pro als dagelijkse computer, maar gebruik een windowsbak voor VR. Die windowsbak is ook 20x sneller maar dat terzijde.

Volgens mij kun je alsnog geen VR headset aan je Mac koppelen en dan in Unity in de play mode gebruiken? Zou wel handig zijn om via de Quest te kunnen previewen op macos. Wel zal virtual desktop voor de Quest binnenkort MacOS ondersteunen. Wellicht dan.

[Reactie gewijzigd door Menesis op 29 juli 2024 13:32]