Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 134 reacties
Bron: VNUnet

Electronic Arts slaagt er niet in zijn spellen voor Mac OS X uit te brengen op dezelfde dag dat ook de Windows-versies verschijnen. De spelontwikkelaar wilde de edities simultaan lanceren, maar dat blijkt niet haalbaar.

Madden NFL 08EA kondigde in juni op de Worldwide Developers Conference aan dat onder meer Madden NFL 08 en Tiger Woods PGA Tour 08 voor Mac OS X gelijktijdig met de wereldwijde Windows-lancering beschikbaar zouden zijn. Het bedrijf komt nu terug op deze belofte en stelt dat de Mac OS X-release zo snel mogelijk op de Windows-versie zal volgen.

Madden NFL 08 is op 14 augustus beschikbaar gekomen en Tiger Woods PGA Tour 08 wordt op 28 augustus verwacht voor het Windows-platform. Als de nieuwe planning wordt gehaald, zullen de Mac OS X-edities van beide games voor eind oktober in de schappen te vinden zijn.

De OS X-versies van Battlefield 2142, Need for Speed Carbon en Harry Potter and the Order of the Phoenix zouden al naar de retailers verstuurd zijn en zeer binnenkort in de winkel moeten liggen.

Moderatie-faq Wijzig weergave

Reacties (134)

Grappig al dat gebash op de 'achterlopende' Mac hardware. Natuurlijk is de nieuwe iMac totaal ongeschikt om op te gamen; er zit immers maar een ATi HD2600 in!

Ter vergelijking: eerder dit jaar werd het NK gaming gehouden tijdens TheParty 5 in Eindhoven. Het NK Quake4 werd daar gespeeld op machines die 'slechts' een GeForce 7600GT hadden. Nu kan het aan mij liggen, maar deelnemers van het NK gaming kwalificeren in mijn ogen behoorlijk als die-hard gamers.

Overigens mag gesteld worden dat zolang Intel graphics het overgrote marktaandeel in OEM machines hebben, dat Apples productlijn niet beter of slechter voor games geschikt is dan de gemiddelde PC. Het enige dat je Apple kwalijk kan nemen is dat de Mac Pro de enige Mac is waarbij de videokaart gewisseld kan worden... maar dat is een keuze, en gezien de markt-brede trend richting de overstap op notebooks lijkt de meerderheid van de consumenten het ook niet heel erg te vinden.
EA is te lui om een echte port te maken van de games en gebruikt helemaal geen Open GL. Ze gebruiken Cider van Transgaming Tech. De spellen van EA die op de mac komen zullen daarom ook enkel op het Intel platform werken. Cider pakt het spel in met een aantal Win32 APIs en laat zo Direct X lopen op de mac.
http://video.google.nl/vi...o=0&type=search&plindex=0

Zo lastig is het niet om games te porten. Ook gelijk een mooi voorbeeld dat de 24" iMac van de vorige generatie prima games speelt.
Is het zo moeilijk om games voor OS X te maken?

Ik weet dat blizzard het namelijk wel voor elkaar krijgt..
Starcraft, Diablo World of Warcraft.

Je hebt niet eens andere cd's nodig voor deze spellen om de mac.
Vrijwel alle games worden tegenwoordig geschreven met behulp van DirectX. DirectX is een API (Application Programming Interface) van Microsoft welke game ontwikkelaars in staat stelt zich te concentreren op de game ipv van de aansturing van een videokaart.

Misschien kun je nog DOS van vroeger nog voor je halen. Toen moest je bij een game precies aangeven welke geluidskaart je had en op welke addressen (IRQ, DMA, etc) deze gevonden kon worden. Met DirectX kan een game ontwikkelaar simpel zeggen "Speel dat fragment".

Omdat DirectX dus een API van Microsoft is, is deze dus niet beschikbaar op OS X of linux. Games voor dergelijke platforms worden meestal geschreven met behulp van OpenGL.

Er zijn overigens wel projecten welke proberen DirectX zo goed mogelijk naar Linux of OS X te brengen. Cedega is inmiddels al een heel eind om spellen te laten laten werken on Linux of OS X.
Er zijn overigens wel projecten welke proberen DirectX zo goed mogelijk naar Linux of OS X te brengen. Cedega is inmiddels al een heel eind om spellen te laten laten werken on Linux of OS X.
Erm... Cedega is eigenlijk alleen maar een heel dun laagje gebakken lucht boven op Wine. Het enige wat het doet is je in staat stellen om de boel wat makkelijker te configureren voor specifike games (en daar betaal je dan 5 euro per maand voor terwijl wine GPL is), derest (directX/Windows emulatie) doet wine. Cedega heb je geeneens nodig als je een echte tweaker bent.
Cedega is zeker niet 'een beetje lucht'. Cedega is jaren geleden van Wine afgesplitst en ze hebben elk hun eigen richting gekozen.
Cedega richt zich er vaak op om een recent spel werkend te krijgen. Wine heeft een betere 'simulatie' van het hele systeem.

Transgaming (Cedega) heeft bovendien licenties gekocht, zodat ze een aantal CD/DVD beveiligingsmethoden mogen implementeren, etc.

Dat je voor de e5 mogelijk weinig waar voor je geld krijgt is een andere zaak (ik speelde gewoon de verkeerde spellen, die dus niet ondersteund werden).


Een ander punt wat wel betrekking heeft op het artikel; Was EA juist niet van plan om de OS X variant voor Cedega te gaan gebruiken voor het porten van games? En laat hier dus BF2142 in de lijst staan van games die naar OS X geport worden. Dat terwijl (naar ik weet) Punkbuster nog steeds niet ondersteund is in Cedega..
vaag toch eigenlijk dat cedega maar 1mb groot is en wine als dependancy heeft.
bovendien vreemd dat alle problemen met wine direct invloed heeft op cedega.
ook vreem dat games die niet werken met wine ook niet werken met cedega en visa versa.
bovendien, heb je al die wine processen giezien als je cedega draait?


kortom, vette wine rip en geldklopperij

[Reactie gewijzigd door j0nathan op 17 augustus 2007 14:21]

vaag toch eigenlijk dat cedega maar 1mb groot is
Je bedoelt het cedega proces? Dat is maar de GUI. Maar alle libraries waar de applicaties gebruik van maken zijn samen ettelijke megabytes.
bovendien vreemd dat alle problemen met wine direct invloed heeft op cedega.
ook vreem dat games die niet werken met wine ook niet werken met cedega en visa versa.
TransGaming concentreert zich op de DirectX ondersteuning, de rest is nog grotendeels gebaseerd op Wine. Anderzijds geven ze ook vaak patches aan Wine, zodat sommige zaken toch grotendeels gelijklopen. Vergeet ook niet dat enkele TransGaming werknemers zeer grote bijdragen hebben gelevert aan verscheidene onderdelen van Wine vůůr ze er ook een cent aan verdiend hebben. Ten slotte kan Cedega wel degelijk spellen draaien die Wine nog niet kan draaien.
Je bedoelt het cedega proces? Dat is maar de GUI. Maar alle libraries waar de applicaties gebruik van maken zijn samen ettelijke megabytes.
nee, de ingepakte binary+lib
TransGaming concentreert zich op de DirectX ondersteuning, de rest is nog grotendeels gebaseerd op Wine. Anderzijds geven ze ook vaak patches aan Wine, zodat sommige zaken toch grotendeels gelijklopen.
Vaag, ik lees alleen maar dat ze (bijna) nix terug geven.
Vergeet ook niet dat enkele TransGaming werknemers zeer grote bijdragen hebben gelevert aan verscheidene onderdelen van Wine vůůr ze er ook een cent aan verdiend hebben.
heb je toevallig een linkje daarvan?
Ten slotte kan Cedega wel degelijk spellen draaien die Wine nog niet kan draaien.
ik heb al heel wat geprobeerd en nix gevonden, je moet alleen hier en daar wat tweaken voor wine (de instellingen) om de boel te laten draaien..

[Reactie gewijzigd door j0nathan op 17 augustus 2007 15:57]

nee, de ingepakte binary+lib
Dat is dus de GUI. De bulk van Cedega zit in de DLLs.
Vaag, ik lees alleen maar dat ze (bijna) nix terug geven.
Bijna niks? Zeg maar bijna alles: http://lists.transgaming.org/pipermail/winex-cvs-logs/
heb je toevallig een linkje daarvan?
Om er ťťntje uit te halen: Ove KŚven.
ik heb al heel wat geprobeerd en nix gevonden, je moet alleen hier en daar wat tweaken voor wine (de instellingen) om de boel te laten draaien..
Draaien, ja, maar de meer geavanceerde DirectX 9 features en betere performance moet je toch bij Cedega zoeken hoor. En 5§ de maand vind ik toch redelijk om niet telkens te moeten prutsen met configuraties en dergelijke.

[Reactie gewijzigd door c0d1f1ed op 17 augustus 2007 18:33]

Dat is dus de GUI. De bulk van Cedega zit in de DLLs.
met 'binary +libs' bedoel ik heel cedega en update, sorry hoor maar derest is toch heel wine.
ja er is een source versie en nee, die is niet open source (GPL) maar lgpl en anderen (o.a. Aladdin Free Public License) en mag niet gebruikt worden om code uit over te nemen als je dat voor een (o.a.) bedrijf with gebruiken. verder ben ik geen jurist hellaas maar het is niet zonder meer 'vrije sofware' (gebruiken in jou code en meeleveren met je product).

verdacht trouwens dat die code onder compleet verschillende licentie modellen vallen.
Om er ťťntje uit te halen: Ove KŚven.
Dat is niet de transgaming maar bijdragen van een van de (bijna voormalig zoals het verhaal verteld) wine medewerkers die transgaming toevallig heeft binnen gehaald.
Draaien, ja, maar de meer geavanceerde DirectX 9 features en betere performance moet je toch bij Cedega zoeken hoor. En 5§ de maand vind ik toch redelijk om niet telkens te moeten prutsen met configuraties en dergelijke.
performanace valt reuze mee, directx 9 features ok, wine ontwikkellingen zijn niet puur op gaming gericht dus het duurt wat langer, en what can i say... soms heb ik meer voldoening als ik het zelf aan de praat krijg.


hey, ik heb genoeg van deze wat op een Rant begint te lijken thread. ik pak een biertje

mzzl
ja er is een source versie en nee, die is niet open source (GPL) maar lgpl
LGPL is vrijer dan GPL. Je mag een LGPL bibliotheek gebruiken zonder al je code vrij te geven, met GPL moet dat wel. Er staat ook letterlijk in de LGPL licentie dat je ook de gewone GPL licentie mag gebruiken (en dus wel al je eigen code vrijgeven). LGPL omvat dus GPL.
Dat is niet de transgaming maar bijdragen van een van de (bijna voormalig zoals het verhaal verteld) wine medewerkers die transgaming toevallig heeft binnen gehaald.
Niks toevallig. Daniel Koch, graphics lead van TransGaming, heeft ook talloze contributies gemaakt aan Wine. Gavriel State, CTO en oprichter, heeft ook zijn steen bijgedraden aan Wine. Het is dus niet een bende vreemden die Wine 'gestolen' hebben. Het is een significant deel van de Wine ontwikkelaars zelf dat een fork heeft gemaakt en zich concentreerde op DirectX, waarbij perfect aan de licenties voldaan wordt om het te commercialiseren.
en what can i say... soms heb ik meer voldoening als ik het zelf aan de praat krijg.
Misschien eens soliciteren bij TransGaming? :P
hey, ik heb genoeg van deze wat op een Rant begint te lijken thread. ik pak een biertje
Natuurlijk krijg je er genoeg van, als je uit je duim aan het zuigen bent. Ik open nog een flesje Wine... Santť!
Ik weet dat lezen moeilijk is: Aladdin Free Public License, The Better String Library, (bstring) License, etc..

Hier heb je een linkje: http://www.cedega.com/license.php?source=1

bovendien, als je m e quote, doe dat dan goed en niet alleen wat je wilt lezen
maar lgpl en anderen
---
Natuurlijk krijg je er genoeg van, als je uit je duim aan het zuigen bent. Ik open nog een flesje Wine... Santť!
alleen argumenteren op punten waar je wat op weet te zeggen kom je idd heel ver mee.

Who let the trolls out? oh well, i've got a cage full...

[Reactie gewijzigd door j0nathan op 18 augustus 2007 02:52]

Ik weet dat lezen moeilijk is: Aladdin Free Public License, The Better String Library, (bstring) License, etc..

Hier heb je een linkje: http://www.cedega.com/license.php?source=1

bovendien, als je m e quote, doe dat dan goed en niet alleen wat je wilt lezen
Ik wou je de schaamte besparen maar ook AFPL en bstring zijn open source. AFPL is minder vrij maar het is dan ook gebruikt voor TransGaming's eigen code, om te voorkomen dat een derde ermee vandoor gaat en geld aan verdient zonder eigen werk.
alleen argumenteren op punten waar je wat op weet te zeggen kom je idd heel ver mee.
Jij bent anders wel stil geworden over de bijdragen van TransGaming werknemers aan Wine he?

Als je nog iets te zeggen had over de "vette Wine rip", laat maar weten.
Ik wou je de schaamte besparen maar ook AFPL en bstring zijn open source. AFPL is minder vrij maar het is dan ook gebruikt voor TransGaming's eigen code, om te voorkomen dat een derde ermee vandoor gaat en geld aan verdient zonder eigen werk.
dus, tadaa! zware restricties op de code! wat ben je brilliant!
Jij bent anders wel stil geworden over de bijdragen van TransGaming werknemers aan Wine he?
heej blinde, ik zei transgaming (nu voor de 3e keer), niet de werknemers.
Als je nog iets te zeggen had over de "vette Wine rip", laat maar weten.
net gedaan?
dus, tadaa! zware restricties op de code!
Helemaal niet. Je mag gewoon niet verdienen aan hun code. En zoals ik al zei het is hun code die gebruik maakt van de AFPL, dus ze hebben alle recht daarmee te doen wat ze willen. Ze hoeven het zelfs niet open source te maken, maar doen het toch! Een gekregen paard...
ik zei transgaming (nu voor de 3e keer), niet de werknemers.
Da's een goeie. TransGaming, net als elk ander bedrijf, is z'n werknemers. Of werken ze bij jou met robots en aapjes?
net gedaan?
Nee, je valt in herhaling met jezelf belachelijk te maken.
OpenGL valt alleen te vergelijken met Direct3D. DirectX verzorgt onder andere ook de audio en input verwerking. DirectX is te vergelijken met een combinatie van SDL en OpenGL.
Is het zo moeilijk om games voor OS X te maken?
...ja
bijna alle games van vandaag worden in Direct3D geschreven (de DirectX API), welke een gesloten API is. Moesten alle Games in OpenGL zijn, zou het al een stuk makkelijker zijn om ze multiplatform te maken (ook voor linux dus) maar zelfs dan is het nog niet vanzelfsprekend, gezien elk OS natuurlijk verschillend is.
...worden in Direct3D geschreven (de DirectX API), welke een gesloten API is.
Niks van. De API is volledig open en je kan de SDK vrij downloaden. Daarom juist dat TransGaming het kan implementeren voor Linux en OSX.
Direct3d is wel gesloten. De API zelf is wel open, maar de implementatie ervan niet. En het draait nu juist om de implementatie. Er staat nergens beschreven wat iets in de api moet doen en hoe. Hierdoor moet Direct3d reversed engineered worden, en dit beste man vertraagd de boel gigantisch.

Aan de API te voldoen is een peuleschil, maar om hetzelfde gedrag te vertonen als Direct3D is een stuk moeilijker.
De API zelf is wel open, maar de implementatie ervan niet. En het draait nu juist om de implementatie. Er staat nergens beschreven wat iets in de api moet doen en hoe.
De SDK documentatie legt tot in de puntjes uit wat de API doet. Uiteraard moet je wel iets over 3D kennen, maar het 'echte werk' kan je door OpenGL laten doen (of niet).

Bovendien is er ook de WHQL DCT, dat miljoenen tests bevat waarmee je de implementatie kan verifiŽren. En het is volledig vrij.

Ik vind zelfs OpenGL minder goed gedocumenteerd, en dus lastiger te implementeren. Bovendien zijn de officiŽle tests ervoor niet vrij!
Hierdoor moet Direct3d reversed engineered worden, en dit beste man vertraagd de boel gigantisch.
Ik kan niks bedenken dat niet voldoende gedocumenteerd is. Zelfs het binaire formaat voor shaders is zeer volledig gedetailleerd: Direct3D Shader Codes. Je moet gewoon weten waar te zoeken. Uiteraard gaan ze niet zomaar een implementatie in je schoot werpen, maar zeg niet dat de API niet open is.
Aan de API te voldoen is een peuleschil, maar om hetzelfde gedrag te vertonen als Direct3D is een stuk moeilijker.
De documentatie voor de API is 3000 pagina's, dus laat me je verzekeren daar ben je een tijd zoet mee om dat allemaal te implementeren. Met voldoende expertise in 3D en de documentatie heb je alles wat nodig is om het te implementeren, zonder noemenswaardig reverse engineering. Het is gewoon heel veel werk omdat de API zo groot is en 3D technologie zowiezo niet eenvoudig is. Maar DirectX implementeren is niet lastiger dan OpenGL implementeren.
Maar DirectX implementeren is niet lastiger dan OpenGL implementeren.
Het is zelfs makkelijker (uitgaande van gewone 3d-hardware), want DirectX wordt voor iedere generatie hardware ontwikkeld, in samenwerking met de hardware-fabrikanten.
De functionaliteit komt dus sterk overeen met wat de hardware kan, en er zit geen onnodige 'fluff' in de API zoals bij OpenGL, dat totaal losstaat van wat de hardware doet en kan, maar meer een overblijfsel is uit software-renderingtijden etc.
'Nadeel' hiervan is dat je als programmeur moet weten hoe de hardware werkt, om er efficiente code voor te schrijven. Maar dit doen game-ontwikkelaars toch altijd al, en daar is het in feite op gericht.

Enige praktische feiten om dit te onderbouwen: historisch gezien hebben fabrikanten altijd goede Direct3D-drivers geleverd, maar was OpenGL een groot probleem, zowel qua compatibiliteit als qua performance.
nVidia was lange tijd de enige die een behoorlijke OpenGL-implementatie leverde. ATi is eigenlijk pas sinds de komst van Doom3 een beetje bijgekomen.
Maar nog steeds zijn er soms grote problemen met beeldkwaliteit en dergelijke (zoals 16-bit textures waar je 32-bit wil hebben, wat enorme banding kan veroorzaken bij herhaald blenden/shaden). Het is allemaal wat te vaag en te vrijblijvend (misschien mede omdat het zo 'open' is).

De mensen van Autocad zijn over aan het stappen op Direct3D, puur omdat ze zoveel workarounds moeten maken voor bugs in OpenGL-drivers, dat het veel te duur wordt.
Direct3D-drivers zijn dankzij de WHQL-tests altijd zeer betrouwbaar.
Microsoft levert ook een Reference Rasterizer, die de zaken rendert zoals het volgens de standaard moet. Dat is ideaal om te testen of je probleem in de applicatie zit, of in de driver/hardware.
Als je goed over dingen nadenkt dan is het onlogisch om een game eerst in DirectX te schrijven om het daarna te porten naar OpenGL. Je kan dan beter je game gelijk in OpenGL schrijven want dat draait ook op Windows. Als ze een 'simpelweg' een multiplatform engine zouden gebruiken is er niets aan de hand en kunnen ze het meteen releasen voor beide platformen. Maar soms zijn nieuwe verfrissende graphics belangrijker dan nieuwe verfrissende gameplay...
Als je goed over dingen nadenkt dan is het onlogisch om een game eerst in DirectX te schrijven om het daarna te porten naar OpenGL.
Wie zegt dat je het moet porten naar OpenGL?
De meeste Mac-games worden met DirectX-libraries zoals www.macdx.com geport.
En dan is het ineens niet zo gek om het in DirectX te ontwikkelen.
Er zijn zelfs bedrijven gespecialiseerd in het porten van Windows-games naar Mac.
Je levert gewoon je sourcecode aan, zij prikken de MacDX-library (of vergelijkbaar iets) erin, testen op eventuele fouten, en fixen dat.
Porten van een game naar de Mac is een kwestie van een paar weken.
Een OpenGL-game zou ook niet direct op een Mac werken, daar zit ook nog wel wat weekjes werk in. OpenGL is toch niet helemaal hetzelfde op de Mac (sowieso zijn de drivers anders, dus er kunnen bugs optreden), en daarnaast heb je ook nog vele dingen naast graphics, zoals audio, input devices, threading etc, die eventueel aangepast moeten worden op MacOS. Bij DirectX heb je de meeste dingen al te pakken, dus is dat eigenlijk handiger.
De meeste Mac-games worden met DirectX-libraries zoals www.macdx.com geport.
MacDX ondersteunt geen DirectX 9 en geen D3DX, en is dus niet echt interessant voor hedendaagse spellen.
Er zijn zelfs bedrijven gespecialiseerd in het porten van Windows-games naar Mac.
Deze EA games worden door TransGaming geport, gebruik makend van Cider.
MacDX ondersteunt geen DirectX 9 en geen D3DX, en is dus niet echt interessant voor hedendaagse spellen.
Hoe kom je daarbij?
Ze hebben pas Cars nog geport, en bij mijn weten is dat toch echt DirectX9.
Er staat zelfs letterlijk op de website "MacOS version of DirectX API uses the Microsoft Direct-X API version 9 headers untouched".
Bovendien zijn er ook nog andere bedrijven, zoals ik al aangaf (maar MacDX is het makkelijkst te onthouden, en de naam spreekt het meest tot de verbeelding).
Het gaat er dus niet om om hier MacDX af te gaan lopen zeiken. Mijn punt is dat er meerdere DirectX-implementaties voor de Mac bestaan, en dat het gros van de ports naar Mac via dergelijke implementaties gebeurt. Dat lijken de meesten hier niet te beseffen, gezien het constante gezeur over OpenGL.

[Reactie gewijzigd door ddbruijn op 17 augustus 2007 13:18]

Mijn punt is dat er meerdere DirectX-implementaties voor de Mac bestaan, en dat het gros van de ports naar Mac via dergelijke implementaties gebeurt. Dat lijken de meesten hier niet te beseffen, gezien het constante gezeur over OpenGL.
en het enige wat al die implementaties zullen doen, is DirectX calls vertalen naar OpenGL, uiteindelijk draai je dus nog altijd OpenGL, geen DirectX. (en dat is logisch, omdat heel de GUI van Mac OS X in OpenGL draait)
en het enige wat al die implementaties zullen doen, is DirectX calls vertalen naar OpenGL, uiteindelijk draai je dus nog altijd OpenGL, geen DirectX. (en dat is logisch, omdat heel de GUI van Mac OS X in OpenGL draait)
Daar gaat het toch niet om?
De ontwikkelaars hoeven hun engine niet te porten naar OpenGL, en dat was het argument waar ik op reageerde.
doordat elke call eerst vertaald moet worden daalt de performance dramatisch....
doordat elke call eerst vertaald moet worden daalt de performance dramatisch....
Zoals al gezegd, het gros van de Mac-games is op deze manier geport. Het is niet ideaal, maar je kunt de spellen zeer acceptabel spelen.
'Dramatisch' is dus niet het juiste woord.
doordat elke call eerst vertaald moet worden daalt de performance dramatisch....
Fout. Een spel maakt slechts een paar honderd API-calls per frame, die relatief snel vertaald zijn naar hun OpenGL-equivalent. Het duurt niet langer dan wat de DirectX runtime van Microsoft zelf erover doet. Dit vormt dus geen prestatiekritieke laag. De CPU wordt het zwaarst belast door de driver. Enig prestatieverlies tegenover native DirectX is dus te wijten aan de kwaliteit van de OpenGL-driver op deze platforms.

Maar native OpenGL tegenover een DirectX-implementatie die naar OpenGL vertaalt is niet beduidend sneller. Je doet dan immers bijna dezelfde 'vertalingen' in de engine van het spel.
Hoe kom je daarbij?
Ze hebben pas Cars nog geport, en bij mijn weten is dat toch echt DirectX9.
Laat het me anders zeggen: ze ondersteunen geen DirectX 9 features.
Er staat zelfs letterlijk op de website "MacOS version of DirectX API uses the Microsoft Direct-X API version 9 headers untouched".
Untouched inderdaad. Daarmee bedoelen ze gewoon dat ze exact die interface implementeren, en geen andere. Maar het is triviaal om van een bestaande DirectX 8 implementatie een DirectX 9 implementatie te maken. Daarmee zijn de capabilities echter nog niet op DirectX 9 niveau gebracht.
Waarom geen games maken die draaien op een eigen bootalble zwaar geoptimaliseerd OS?
Dan kun je op elke machine dat ding op volle toeren draaien zonder vast te zitten aan de eigenaardigheden beperkingen van de bestaande Osen. Of zeg ik nu iets heel raars?
Sja, kijk naar consoles... Dat is een hardwarematig platform van wat jij met software zou doen...

Het eerste probleem met een softwarematig platform is de ondersteuning van alle apparatuur om te beginnen, daar gaat enorm veel werk inkruipen.

Ik ben een apple gebruikter dus vergeef eventuele bias maar waar mijns inziens Apple voorop loopt op Windows is de hardwareondersteuning, simpelweg omdat ze zo goed als geen hardware kennen (relatief gezien, en dit is dan meteen ook voor veel mensen een nadeel, de beperte/onmogelijkheid tot upgraden). Die paar grafische kaarten, chipsets e.d. die Apple heeft gebruikt zijn perfect geÔntegreerd, Apple kan dat nu eenmaal doen omdat ze zelf alle controle daarover hebben.

Kijk naar Vista, de compatibiliteit is daar heel lang een issue geweest (of is nog? geen idee eigenlijk), hetgeen niet echt aan Microsoft ligt maar meer aan de enorme verscheidenheid aan hardware dat Windows moet ondersteunen.

Een geoptimaliseerd OS uitbrengen zou bijgevolg economisch niet haalbaar zijn. Wat is het marktaandeel van Mac? 5% ofzo? Geen idee, maar het is niet veel... Volgende vraag; hoeveel Macs zijn geschikt om zware 3D-toepassingen te draaien?
Ongeveer vanaf de midrange iMac, dus meer dan de helft van de verkochte Macs zijn niet geschikt om te gamen (de Macbook is nu't meest populair nu en heeft relatief eenvoudige onboard-video).

Microsoft heeft een perfect werkend systeem, Apple heeft een kleine doelgroep, Microsoft heeft veel hardware te ondersteunen, Apple niet. Dat gaat gewoon nooit werken.

[Reactie gewijzigd door mcstrat op 17 augustus 2007 12:34]

Ja. Dat gaat namelijk niet werken vanwege de grote hoeveelheid hardware die je dan moet ondersteunen. Je moet dan ook drivers hebben voor alle soorten videokaarten, geluidskaarten, enzovoorts.
Het onderste uit de kan halen qua OS en hardware doen ze op consoles, omdat je dan precies weet welke hardware je hebt. En zelfs op consoles is het meestal pas de latere generatie games die alles eruit perst, maargoed, dat komt door de learning curve voor de programmeurs (en deels commercie; nieuwere games moeten 'beter' zijn).

[Reactie gewijzigd door SiliconError op 17 augustus 2007 12:19]

iedereen heeft het over de mac hardware die trager zou zijn.
wat ik mij echter afvraag is wat het invloed van mac OS zelf zal zijn voor spellen. vraag me af of er directx gebruikt zal worden? moet haast wel want dat zijn die video kaarten allemaal wel compatibel voor.

maar misschien is de mac OS gewoon efficiŽnter en draaien spellen misschien wel gewoon soepeler
DirectX is een puur Microsoft technologie. Die zal niet in OS X ondersteund of gebruikt worden. Mac OS X maakt wel gebruik van OpenGL, de tegenhanger van DirectX die ook in Linux wordt gebruikt.

Naar mijn gevoel maakt OS X veel meer gebruik van de grafische kaart. Alle 'effecjes' in het OS worden namelijk door de grafische kaart afgehandeld en niet door de processor. Zoek maar eens op internet naar core graphics en core video.
OSX maakt wel veel gebruik van de videokaart, maar zelfs dan is het een veel lichter systeem dan XP of Vista. De code is vele malen schoner omdat ze (buiten veel meer aandacht te besteden aan de code) niet backwards compatible zijn met programma's uit het jaar van Windows '98.

Windows is wat dat betreft echt een "hog", waardoor games minder uit de videokaart halen dan mogelijk is. Het feit dat Microsoft / Windows zo groot is is een van de voornaamste redenen dat games vooral op dat platform uitkomen.

Daarnaast, OSX z'n OpenGL zorgt er niet voor dat midrange videokaarten ineens topnotch worden, maar het zorgt er wel voor dat er meer mee gedaan kan worden voor je (of de game) aan de videokaart z'n limieten zit.
Uh..right, vandaar dat OSX ook 1Gb RAM nodig heeft om lekker soepel te draaien, zeker? Het is allemaal zo veel cleaner :+

OS X z'n OGL is op dezelfde machine vaak trager als een XP install (bootcamp) met OGL, zoek maar even de benchmarks op ipv RDF blaat te verspreiden.

[Reactie gewijzigd door Tijger op 17 augustus 2007 13:23]

Stop met het verspreiden van die onzin, wil je? OSX draait soepeltjes met 512 MB RAM, slechts als je fanatiek wilt geen multitasken is meer RAM raadzaam. In ieder geval draait OSX met 512 MB RAM stukken soepeler dan Vista met 512 MB.
Tja, da's jouw opinie, mijn ervaring is anders en bepaald niet met fanatiek multi tasken.
totdat microsoft directx 10 maakt wat niet meer backwards compatible is en dan begint iedereen te huilen dat het niet in xp werkt. het is ook nooit goed
DirectX is een puur Microsoft technologie. Die zal niet in OS X ondersteund of gebruikt worden. Mac OS X maakt wel gebruik van OpenGL, de tegenhanger van DirectX die ook in Linux wordt gebruikt.
Toch blijf ik het raar vinden dat ontwikkelaars niet gebruik maken van OpenGL. Met OpenGL heb je gewoon meer platformen die het ondersteunen (Linux/Mac/Windows/PS3 en misschien andere) in tegen stelling tot DX die alleen voor Windows en XboX is.

Of mag je DX niet zo vergelijken met OpenGL?

edit:
@fredmatrack: Ik dacht te hebben gelezen hierop t.net dat OpenGL alleen word 'vertaalt' als het spel niet volledig scherm draait.

@--MeAngry--: Is OpenGL zoveel lastiger om te implementeren? Uiteindelijk pak je als Gamestudio een grotere doelgroep zonder dat er veel aangepast moet worden aan je engine. Waarschijnlijk is de extra ontwikkel kosten op dit moment hoger dan de extra opbrengsten.

[Reactie gewijzigd door AppleTalk op 17 augustus 2007 12:33]

OpenGL zit danig verweven in OS X (en Linux) zoals DirectX verweven zit in Windows. Ga je OpenGL gebruiken in Windows, dan wordt dat nog een extra laag tussen het OS en de game zelf.

Idem voor DirectX. Als je DirectX zou kunnen porten (wat bijna niet realistisch is), dan ga je een extra laag creŽren. Die laag vraagt op zich ook resources en dus gaat het boeltje nog trager draaien.
OpenGL zit danig verweven in OS X (en Linux) zoals DirectX verweven zit in Windows. Ga je OpenGL gebruiken in Windows, dan wordt dat nog een extra laag tussen het OS en de game zelf.
OpenGL is nix anders dan een library die zelfs meestal in het OpenGL spel zelf wordt geintregeerd om incompatibiliteit tussen verschillende OGL versies te voorkomen dus dat is onzin. Was het niet voor de gesloten mentaliteit van MS dan was het voor directX het zelfde verhaal geweest.

edit:typo's

[Reactie gewijzigd door j0nathan op 17 augustus 2007 12:24]

Idem voor DirectX. Als je DirectX zou kunnen porten (wat bijna niet realistisch is), dan ga je een extra laag creŽren.
Daar heb je dan ook Wine voor. Als die API implementatie werkt kan je prima Dx spellen op Linux spelen(dit kan al met een enkel aantal spellen).
wine/cedega emuleert al dingen die gebruik maken van directx, dus is het wel degelijk realistisch...

Ik vind het positief dat er games uitkomen voor OS X. Voor sommigen blijft gamen toch een plezante ervaring die ze niet graag willen opgeven. Enja er bestaat bootcamp, maar vergeet niet dat je nog altijd voor die windows moet betalen. Dan is het goedkoper om gewoon op OS X te gamen als je het hebt.


Hopelijk brengt dit linux-gaming ook wat in het licht.
ik denk niet dat EA de komende 5 jaar ene LinuxGame gaat maken, maar...
Wanneer een game voor de Mac wordt geschreven, is eht al geschreven in OpenGL. Hierdoor moet er een stuk minder geŽmuleerd worden om de game in Linux te laten draaien, wat dus ook als resultaat heeft dat gamen in Linux een pak sneller gaat!
Idem voor DirectX. Als je DirectX zou kunnen porten (wat bijna niet realistisch is), dan ga je een extra laag creŽren. Die laag vraagt op zich ook resources en dus gaat het boeltje nog trager draaien.
als je het al zou mogen :p
MS houdt DX namelijk goed gesloten, OpenGL is OpenSource, wat het naar mijn mening eigenlijk al superieur maakt.
Tja, als jij 'designed by comittee' superieur vindt...prima maar de meesten onder ons zien liever performance en features.
Dit heb ik al eens post: bv Doom3 is volledig ontworpen n OpenGL, waarom wordt het dan zo bestempelt als inferieur? voor de WIndowsevrsie hebben ze het geport naar D3D, voor een betere performance, gewoon omdat windows in de basis D3D ondersteund, en OpenGL slechts op een hoger niveau.

OpenGL is TOTAAL niet inferieur aan D3D, D3D krijgt gewoon meer kansen zich te bewijzen...

[Reactie gewijzigd door kiang op 17 augustus 2007 15:57]

waarom wordt het dan zo bestempelt als inferieur?
Niet zozeer vanwege OpenGL zelf, maar vanwege het feit dat het in principe een game was rond DX8-features, in een tijd waar je DX9-games als Far Cry en HalfLife2 had.
Ik denk dat Prey een wat sterker voorbeeld is. Gebruikt ook de Doom3-engine, maar wordt als spel beter ontvangen, omdat het geheel er wat beter uitziet.
voor de WIndowsevrsie hebben ze het geport naar D3D, voor een betere performance, gewoon omdat windows in de basis D3D ondersteund, en OpenGL slechts op een hoger niveau.
Helemaal niet.
De Windowsversie is net zo OpenGL als de linux- en Mac-versies.
Desondanks is de Windowsversie de snelste, dus de OpenGL-implementaties (of de rest van het OS?) van de andere varianten laat nog iets te wensen over.

[Reactie gewijzigd door ddbruijn op 18 augustus 2007 00:38]

OpenGL als basis implementeren is vrij lastig. Als er in Windows ontwikkelt wordt, met Visual Studio, staat de DirectX SDK echter meteen voor je klaar, naadloos geintegreerd.

Als er echter van bijvoorbeeld SDL gebruik wordt gemaakt is het weer een ander verhaal, daarmee zou een game net zo makkelijk van DX als OpenGL, of zelfs software rendering gebruik kunnen maken. Ik weet alleen niet precies wat voor nadelen eraan kleven.
DirectX is een puur Microsoft technologie. Die zal niet in OS X ondersteund of gebruikt worden.
http://www.macdx.com/
Het was een beetje te verwachten. Die man kwam daar op het podium naast Steve Jobs iets te enthousiast vertellen over hun grootse plannen.
De afzetmarkt voor games op Mac is vele malen kleiner dan die op PC. Het leek mij dan ook een dure belofte voor een bedrijf.

Ik ben zelf geen gamer, wel een Mac-freak in hart en nieren. Ik ben al blij dat ze hun games gewooon voor Mac uitbrengen. Dat dat een week, maand,... later gebeurt, dat is niet belangrijk. Ik vind het belangrijker dat ze de aangeboden technieken die OS X bevat goed gebruiken. Ik denk maar aan OpenGL, core graphics, core audio en binnenkort core animation.

Als ze dat goed doen, kunnen ze degelijke games maken die niet de zwaarste Mac Pro eist om een beetje vlot te draaien.
Als ze het een beetje goed doen, kunnen ze degelijke games maken die niet de zwaarste Windows bak eist om een beetje vlot te draaien. Zulke argumenten gaan aan weerszijde op en zullen zeker wel toegepast worden tot in het redelijke. En mede hierdoor ontstaat er juist een sterke scheiding tussen Windows & Apple bakkies, Apple bakken worden relatief minder vaak vernieuwd doordat ze afhankelijk zijn van 1 enkele producent daarintegen WIndows bakken genieten constant van het allernieuwste qua hardware en blijven gepushed worden. En het gepush wordt veroorzaakt door de software industrie. Hierdoor blijft Apple dan ook ondergeschikt zolang ze de hardware gesloten houden. En hierdoor blijft Apple dan ook achter qua software op ieder vlak.
je hebt gelijk dat Apple hardware minder vaak geupdate wordt (wat idd het logische gevolg is van het feit dat er maar 1 (officiŽle) leverancier is)
maar dat Apple daardoor echt achterstaat vind ik een overstatement.
Zo was bv de Mac Pro de eerste quad-core Xeon PC op de markt. Ook was Apple de eerste leverancier die algemeen op 64bit is overgestapt.

(maar zoals ik zei: je hebt gelijk hoor, als er meerdere apple-OEMs waren zou de hardware een stuk beter zijn, maar ik vind gewoon dat de hardware nu toch goed is vergeleken met de gemiddelde PCs)
Hardware gesloten houden???

Als ik mijn Apple open vijs, dan zie ik net dezelfde dingen als in jouw pc zitten. Ik kan perfect een onderdeel uit jouw pc halen en dat in mijn Apple aansluiten.

De software van Apple, Mac OS X, die is gesloten. De hardware niet.
Stop jij eens een 8800 in je Apple, en dan kun je eens kijken hoe open deze is.
--edit--
@followup bij mijn weten zijn er nog steeds geen 8800 drivers te krijgen, en is er in de applestore ook geen systeem uit te rusten met een 8800.

[Reactie gewijzigd door n4m3l355 op 17 augustus 2007 12:26]

in een macpro? geen probleem.
in een andere bak: idd een probleem, omdat die laptop grakas gebruiken
Je opmerking vind ik dus nogal dom, in een windowslaptop kun je ook de graka neit veranderen...
Kiang, er is geen bios voor de 8800 die EFI compatible is. Een 8800 zou in een MacPro gebruikt kunnen worden, wanneer als OS bv Windows XP of Vista gebruikt wordt...
ok, ik dacht dat je vooral doelde op het feit dat je de kaart neit kan vervangen in een gewone iMac.
maar in de Mac Pro kan dat dus wel, idd op voorwaarde dat de kaart met EFI kan werken zoals jij zegt.
Welke kaarten dat zijn weet ik niet echt, de 8800 dus niet zeg jij. Maar de meeste chips kan je wel krijgen met EFI ondersteuning.

[Reactie gewijzigd door kiang op 17 augustus 2007 15:53]

Snap niet wat het probleem is. Madden wordt gemaakt voor de PC, Xbox 360, PS3, Wii, DS, PSP, volgens mij ook GSM's, en als ik het juist heb ook nog voor de PS2...

Wat is nou 1 platformpje meer?
hoewel ik in mn vorige post (hierboven) zei dat het porten niet zo eenvoudig is, heb je hier wel een sterk punt :D

Ik vind het dus idd nogal hautain van EA om OSX zo te negeren wanneer ze zelfs nog games maken voor de Ngage, de meest geflopte console van de laatste 5 jaar :D
De kop is wel erg misleidend. 'Op de lange baan' betekent zoiets als 'we nokken ermee en we zien wel of die spellen in de toekomst ooit nog uit komen', terwijl EA meer lijkt te bedoelen dat ze gewoon in tijdsnood zitten, maar dat de spellen uiteindelijk niet in gevaar zijn. :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True