AMD: ontwikkelaars willen van DirectX af

Sommige spelontwikkelaars willen van de overhead van DirectX af. Dat zegt Richard Huddy, die namens AMD contacten onderhoudt met developers. De extra rekenkracht van videokaarten zou door de overhead niet tot zijn recht komen.

"Op een videokaart is er tien keer meer rekenkracht dan in een Xbox 360 of PlayStation 3, maar toch zien spellen er niet tien keer beter uit", aldus Richard Huddy, die bij AMD verantwoordelijk is voor het contact met ontwikkelaars, in een interview met website bit-tech. Volgens hem hebben verschillende spelontwikkelaars te kennen gegeven dat ze meer toegang tot de hardware willen hebben, om het onderste uit de kan te kunnen halen.

Huddy erkent dat er in DirectX 11 prestatieverbeteringen zijn doorgevoerd zoals multi-threaded display lists en instancing, maar noemt dat niet genoeg. Volgens Huddy kan een typische pc-game drieduizend draw calls per frame uitvoeren tot een maximum van vijfduizend. Games voor spelcomputers maken volgens hem tien- tot twintigduizend draw calls per frame.

Gamedevelopers kunnen op consoles makkelijker close to metal programmeren omdat de hardware altijd hetzelfde is. DirectX abstraheert de onderliggende pc-hardware zodat de ontwikkelaar geen rekening hoeft te houden met verschillende eigenschappen van gpu's. Chris Delay van Introversion Software onderschrijft dat voordeel, Michael Glück ziet als technical director bij Crytek wel de aantrekkingskracht van directe toegang tot hardware. Door zelf het geheugen en threads aan te sturen zouden er betere prestaties mogelijk zijn.

Glück denkt echter dat api's in de toekomst minder belangrijk zullen zijn, omdat gpu's steeds meer op general purpose hardware gaan lijken. Als voorbeeld geeft Glück dat rasterisatie en tesselation al goed mogelijk zijn met behulp van OpenCL, ook al worden de prestaties van functiespecifieke hardware op de gpu nog niet gehaald.

Door Bart de Water

Nieuwsposter

19-03-2011 • 17:43

288

Reacties (288)

288
279
171
8
1
0
Wijzig sortering
Ik heb hier de ballen verstand van, maar deze comment op /. leek wel begrijpelijk:
Discaimer: I am a pro game developer, wrote a few engines for commercial games, etc. I know what this guy means and ill try to explain it a bit better. The biggest problem with the DX model (which was inherited from GL) is the high dependency on the CPU to instruct it what to do.
State changes and draw commands are all sent from the CPU, buffered and then processed in the GPU. While this speeds up rendering considerably (the GPU is always a frame ore two behind the CPU) it makes it limiting, to get feedback from the GPU about the rendering state, and since the all the DX/GL commands are buffered, retrieving state or data means flushing/sync.
From modern algorithms related to occlusion estimation, or global illumination to overall reduction of state changes, it would benefit greatly if, for most tasks, the GPU could act by itself by running an user-made kernel that instructs it what to do (commands and state changes) instead of relying on DX, but for some reason this is not the direction GPUs are heading to, and it really doesnt make sense. Maybe Microsoft has something to do with it, but since Directx9 became the standard for game development, the API only became easier to program in versions 10 and 11, but didn't have major changes.
Bron
Wat deze man zegt is inderdaad technisch een stuk beter onderlegd dan het hoofdartikel hier. Maar ik denkt niet dat ze het beide over hetzelfde hebben. Deze meneer hier wil in principe de binnenste game-loop uitvoeren op de GPU, wat een hoop voordelen kan hebben, maar waar de GPU absoluut niet voor bedoeld is. Bovendien ontkom je niet aan een zekere mate van synchronisatie tussen CPU en GPU in de vorm van flushes (occlusion queries zijn hier een mooi voorbeeld van), tenzij je het hele spel laat draaien op de GPU, wat dus heel het nut van een gescheiden CPU en GPU teniet zou doen (afgezien van het feit dat het dus niet mogelijk is met de manier waarop huidige GPU's werken).
In de huidige spellen doet de CPU waar hij het best in is, namelijk de kernel van je OS (en daarmee ook je programmacode) faciliteren, inclusief alle toeters en bellen die daar bij horen, en de GPU doet zijn deel, namelijk hardcore 'pixels pushen' dmv shaders of FFP, matrix operaties doen, etc. En net zoals 2 mensen die samenwerken zullen ook de CPU en GPU met elkaar moeten communiceren -in beide richtingen- om alles in goede banen te leiden. Nu is het in moderne spellen 99% eenrichtingsverkeer van de CPU naar de GPU (teken een driehoekje hier, teken een driehoekje daar), maar die ene procent aan communicatie de andere kant (wat heb je net getekend?) op is het probleem. Omdat de CPU vaak 'voorloopt' op de GPU (de GPU doet immers vaak zwaarder werk en buffert ook nog eens 2 of 3 frames voordat ze daadwerkelijk op het beeld komen) zal de CPU dan moeten wachten op de GPU, dit heet 'GPU stall'. Een mooie (maar technische) uitleg hiervan geeft men hier: http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html
ik denk dat deze meneer bedoelt is dat hij de taken die uitgevoerd moeten worden door de gpu eerst via de cpu naar de gpu gaan waardoor er een vertraging in zit, wat natuurlijk beter zou zijn is, als je taken hebt voor de gpu dat die direct naar de gpu gaan waardoor de gpu niet achter loopt op de cpu
niet dat de cpu tegenwoordig nog een limiterende factor is games zijn niks sneller met een 900 euro kostende intel dan met een 130 euro kostende amd cpu.

zelofs crysis 2 alpha download draait op max 75% belasting op mijn amd 955

[Reactie gewijzigd door computerjunky op 22 juli 2024 15:39]

Dat zegt niks, de man heeft het over latency.
Weet niet veel over de GPU .

Maar de graphics boeren kunnen er toch wel voor zorgen dat een programmeur direct iets aan kan spreken op de videokaart? zonder de DirectX aan te spreken?

Dan is het nog steeds stabiel en sneller.

[Reactie gewijzigd door Anoniem: 109640 op 22 juli 2024 15:39]

Op zich kan dat wel, dat is bijvoorbeeld ook wat op consoles gebeurt zoals in het artikel genoemd wordt. Het probleem hierbij is echter dat niet elke computer dezelfde videokaart heeft, dus je spel zou voor elke mogelijke videokaart (of waarschijnlijker: voor elke generatie van een bepaalde fabrikant) net iets anders met de videokaart moeten spreken. Dit maakt het schrijven van de code natuurlijk erg ingewikkeld, en dat is juist waarom DirectX er tussen zit. Bij consoles is dit niet nodig, omdat iedere console dezelfde videokaart gebruikt.
Hij spreekt ook van een "user-made kernel". Je mag er vanuit gaan dat een game developer precies weet wanneer de videokaart bepaalde instructies moet krijgen, om maximale efficientie te bereiken. Als de developer dus een eigen kernel kan schrijven, specifiek voor een engine (of zelfs game) kan de abstractielaag die er nu voor zorgt dat alles via de CPU gaat worden omzeild.
Zou slim gebruik van amd's apu dit tegengaan? Dan ligt de bal waarschijnlijk wel bij directx. Nvidia die amd op zijn kaarten wil uitbrengen heeft zo ook een alternatief om dit te verbeteren.
Zonder DX/OpenGL wordt het bijna onmogelijk voor de kleinere ontwikkelteams om een fatsoenlijke engine te maken. Voor een miljoenen bedrijf als Crytek en een miljoenen project als CryEngine 3 zal het zelf maken van een API wellicht niet heel veel uitmaken, procentueel gezien. Compleet zonder API zie ik niet snel gebeuren, een engine wordt vaak voor verschillende platformen en games gebouwd waarbij je toch een tussenlaag nodig hebt. Het lijkt me immers dat een PS3 structureel anders in elkaar steekt dan een Xbox/PC.

Daarnaast: Ontwikkelaars die een engine aankopen zoals Unreal Engine, CryEngine of IDTech hebben ook te maken met een (engine)API. Die engines kunnen natuurlijk veel meer dan alleen grafische zaken aansturen (via DX/OpenGL), maar hetzelfde principe zie je daar ook: er zit een zekere overhead in. Toch hoor je ze hierover niet echt klagen: het maakt hun leven een stuk makkelijker, waar ze denk ik graag een klein beetje performance voor inleveren (afgezien van het feit dat ze zelf een dergelijk niveau niet snel zullen bereiken).

Bovenstaande gedachtes zijn een beetje tegenstrijdig. Engines bouwen is een elite-sport geworden, en veel ontwikkelaars kopen dus gewoon een engine aan. Hiermee zou het dus voor deze groep weinig uitmaken of er wel of geen DX/OpenGL gebruikt wordt.

Wat als DX een soort lowlevel mogelijkheid zou krijgen? Binnen C++ kun je immers ook nog steeds assembler gebruiken, als je daar behoefte aan hebt. Lijkt me een redelijke win/win: high level voor de basis, en als je tijd over hebt kun je hardware-specifiek gaan optimisen in low-level.
Anoniem: 273970 @ixi21 maart 2011 02:13
Hmmm... je hebt een punt, maar ik weet niet hoor... want "vroeger" ontwikkelden al die verschillende demo-groups (jongens van 14 tot 64 bij wijze van spreken) die uit, in veel gevallen, slechts enkele leden bestonden helemaal zelf de aansturing van de verschillende geluidskaarten, deden het memory management, zorgden dat de grafische kaarten aangestuurd werden etc. En reken maar dat het op zo goed als alle hardware draaide. En vaak snel ook. En mooi. Daar waren ze juist demo-groups voor ;-)
Wat een prachtige tijd was dat zeg. Jammer dat het voor een groot deel afgestorven is tegenwoordig.
Hoe dan ook, ik heb zo'n idee dat jongens uit die kringen hier een licht op kunnen schijnen op een manier die wij als niet programmeurs simpelweg niet kunnen.
Wat als DX een soort lowlevel mogelijkheid zou krijgen?
DirectX *is* in feite al zo lowlevel als de kernel het toelaat.
Nee, ze hebben absoluut gelijk, maar ik denk dat er nog niet echt een goed alternatief is voor DirectX (OpenGL bvb) en dat ze ook moeten denken dat DirectX hun wel Tessellation heeft gebracht en dergelijke. (en voor AMD een btere marketingpositie met DirectX 10.1 :P)

En dat OpenGL wel de mogelijkheid heeft van Tessellation wilt natuurlijk ook nog niet zeggen dat het ook werkelijk een goed punt is om op over te stappen. En ik denk dat je DirectX voor PC's niet moet vervangen, zoals ook in het bericht vermeld, zorgt het er voor dat niet alle hardware hetzelfde moet zijn. Ik snap dat het moeilijker is voor programmers om een game voor alle PC's te maken (en dat zien we duidelijk terug: steeds meer games worden gewoonweg geport van de PS3/XBOX 360 waardoor de GPU uit zijn neus kan gaan staan eten omdat in deze consoles de vele malen sterkere CPU al het werk doet) maa het marktaandeel dat ze aanspreken toch wel noemenswaardig is.

[Reactie gewijzigd door naarden 4ever op 22 juli 2024 15:39]

OpenCL is en zal nooit een alternatief zijn voor DirectX of OpenGL, daar is het ook helemaal niet voor bedoeld. OpenCL is nu net juist voor al die dingen die een GPU kan doen die helemaal niks met pixels e.d. te maken hebben, maar wel gebaat zijn bij de enorme parallelle kracht van een GPU. Ik snap dan ook de opmerking van deze meneer Gluck niet helemaal, je kan inderdaad best rasterisatie en tesselation implementeren via OpenCL, maar daarmee introduceer je alleen maar een extra laag tussen de programmeur en de hardware, het was nu juist het idee dat DirectX en OpenGL hier een front-end API voor aanbieden zodat de driver de functionaliteit zo efficient mogelijk kan implementeren.

Al met al een vreemd artikel dit... Volgens mij zou een super-lightweight DirectX of OpenGL zeker interessant zijn, een soort van DirectX/OpenGL voor masochisten, waar de API waar mogelijk alles aan de ontwikkelaar overlaat. Direct op de hardware programmeren lijkt me een stap terug in de tijd, de tijd dat elk spel alleen compatible was met een bepaalde set van GPU's en geluidskaarten hebben we al gehad en dat was een drama.
Die tijd herinner ik me helaas wel. En ieder keer maar hopen dat mijn geluidskaart er wel tussen zou staan. Als die vervelende dos-drivers al foutloos wilde laden.
Er valt echter ook wel wat voor te zeggen de abstractielaag niet ieder detail af te laten handelen.
Mwa, vroeger was een kaart compatible met een van de groten, zoals een of andere versie van de SoundBlaster, Gravis Ultrasound, of AdLib. Als je een kaart had die compatible was met een van die drie dan kon je wel 9 van de 10 spellen spelen.

Bij GPU's zal dan een soort "nVidia of AMD-compatible" opzet ontstaan denk ik, waarbij je kaart minimaal compatible zal moeten zijn met de een of andere nVidia of AMD-kaart.

Maar, een stap terug is het imho wel, als we ons daar weer druk over moeten gaan maken...

[Reactie gewijzigd door Katsunami op 22 juli 2024 15:39]

Als je een kaart had die compatible was met een van die drie dan kon je wel 9 van de 10 spellen spelen.
Die compatibiliteit ging dan wel weer via emulatie .sys drivers die weer van je kostbare geheugen snoepten en zelf ook weer buggy waren. LoadHigh, EMS, XMS, Upper Memory Blocks en al die andere trucs - als gamer werd je vanzelf ICT-er.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 15:39]

En uiteindelijk was die compatibiliteit nooit volledig.

Dus na een tijdje ging je dan vanzelf maar mee met de meute en kocht je een soundblaster om van alle problemen af te zijn...

Lange leve windows, waardoor je een geluidskaart kon kopen die de helft kostte, maar betere kwaliteit gaf en meer kon. En het werkte ook nog eens zonder problemen met al je spellen.

Nee, ik zou ook niet blij worden als directx zou verdwijnen. Maar als je het orginele artikel van Huddy leest, dan zie je wel dat er een serieus prestatie probleem in directX zit. En dat zal wel opgelost moeten worden.
Abstractie is een extra laag... dat zal altijd trager blijven dan directe toegang. De traagheid moet alleen zo ver mogelijk worden beperkt.

Nu ben ik geen game-ontwikkelaar... verre van. Ik schrijf embedded software, en zit dus vaak wel direct bovenop de hardware. Precies het tegenovergestelde van dit dus :P
De extra layer is nodig om b.v. multitasking mogelijk te maken.
Zonder een layer, grijpt iedere applicatie naar de bronnen van een apparaat en dan ontstaan er problemen (BSOD, freeze etc.)
DirectX zorgt voor de afhandeling, en uniformiteit.

Jouw punt waardeer ik ook heel erg, iedere laag is er weer eentje, en applicaties die rechtstreeks op hun manier communiceren met de hardware hebben de beste performance.

Dit was onder MS-DOS altijd het geval, de software eenmaal werkend, dan had deze ongehinderde 1:1 toegang tot de hardware.
En aangezien het steeds meer en meer om de omzet draait ook al worden sommige titels tot in den treure uitgemolken, zullen developers dit echt niet willen, ze maken dan immers zelf hun mogelijk publiek kleiner door het een of het andere of beide een beetje te ondersteunen.
OpenCL is een tegen hanger van Cuda en de Direct Compute feature van DX10 en up.

De API voor GPGPU toepassingen.

Cuda leid die markt en OpenCL en DC zijn nieuw op dit vlak en de vroege tegen hanger Steam proscesing is sowat dood en nogal onbekend bij het grote publiek.
OpenCL is natuurlijk geen vervanger of DirectX / OpenGL...... maar zou er geen zoort van grafische programmeertaal geschreven kunnen worden?

Welke hobbel moet je nemen om dat te doen? Aangezien DirectX en OpenGL niet meer zijn dan een abstracte tussenlaag, tussen een grafische applicatie en de hardware, hebben ze veel weg van een interpreter. De calls naar die APIs kun je zien als functie calls naar een abstracte grafische GPU. Dus als je een abstracte grafische programmeertaal zou bedenken, en een compiler die je als argument niet alleen de CPU, maar ook de GPU meegeeft, kun je die compiler de code laten optimalizeren voor iedere specifieke CPU / GPU combi. De programmeur hoeft niet heel dicht op de hardware te programmeren, maar je kunt wel overhead terugdringen.

Natuurlijk wil je geen dvd voor iedere type CPU/GPU combi bakken. Ook wil je geen code met compiler aanbieden. Maar als je games online aanbied is dat geen punt, de website kan je hardware detecteren.

Is dit heel erg gek gedacht??
Als er een software layer gemaakt kan worden die aan bepaalde conventies voldoet en zorgt dat het zich op elke hardware hetzelfde gedraagd (directx) zodat er een standaard is, dan kunnen er in de markt net zo goed afspraken gemaakt worden om alle hardware aan een bepaalde standaard te laten voldoen en die software laag gewoon lekker te schrappen. Even afgezien van het feit dat direct tegen de hardware praten waarschijnlijk een ontzettend moeilijke klus is.
Een beter alternatief zou een nieuw soort directx zijn, een flinterdunne laag die veel low-level functionaliteit van de hardware beschikbaar maakt, maar niet zo bloated is als de huidige directx implementaties.
Tja zoals een HEL HAL en Bypass
John Carmack noemde onlangs Direct3D zelfs beter dan OpenGL: http://www.bit-tech.net/n...k-directx-better-opengl/1
Dat komt vooral voort uit het feit dat direct3d niet echt een multiplatform standaard hoeft te zijn en opengl wel, daar heb je ook meteen het nadeel aan direct3d tov opengl: direct3d kun je niet gebruiken op meedere platforms (wat ook preces de reden is dat het bestaat: voor vendor lock-in), het heeft ook heel lang geduurd voordat direct3d ook maar in de buurt kwam overigens: in een gezonde markt had het al niet meer bestaan.
Dat komt vooral voort uit het feit dat direct3d niet echt een multiplatform standaard hoeft te zijn en opengl wel
Dat is natuurlijk gewoon een onzin excuus. Er is immers niets in DirectX wat je niet in onder OSX of Linux zou kunnen bouwen. Wat OpenGL mist is een OO laag waar meer taken in afgehandeld worden. Nu kun je zeggen, dat kun je zelf doen... maar ja, bij DirectX heeft MS dat al voor je gedaan en hoef je dat niet meer te doen.
Anoniem: 112442 @HerrPino19 maart 2011 23:58
Dat is natuurlijk gewoon een onzin excuus. Er is immers niets in DirectX wat je niet in onder OSX of Linux zou kunnen bouwen.
Ware het niet dat DirectX een gesloten standaard is.
Wat OpenGL mist is een OO laag waar meer taken in afgehandeld worden. Nu kun je zeggen, dat kun je zelf doen... maar ja, bij DirectX heeft MS dat al voor je gedaan en hoef je dat niet meer te doen.
Heb je het artikel gelezen ( In de tweakers post)?
Want dat Microsoft dit al allemaal gedaan heeft c.q. je verder van de hardware af zit heeft het hele probleem veroorzaakt.
DirectX is een openbare API. Er is niemand die je tegenhoudt die API in een ander OS te implementeren. Het verschil tussen OpenGL en DirectX is dat Microsoft bepaald waar DirectX heen gaat en je enkel kan volgen (maar aangezien veel games nog met DirectX 9 compatibiliteit uitkomen en Microsoft al op 11 zit lijkt dat niet direct een issue). Dit wordt ook gedaan in bv Wine of Mono dus zou ook kunnen voor DirectX

Je kunt jezelf echter afvragen waarom je zo'n implementatie zou maken. Is er echt zoveel vraag naar OS/X games of Linux games?

Wat Microsoft gedaan heeft, is niet de oorzaak van het probleem maar juist de oplossing van een ander probleem. Hoe ga je met grafische kaarten om van verschillende leveranciers? DirectX en OpenGL zijn twee lagen die je daartussen schuift zodat alle kaarten hetzelfde aangestuurd kunnen worden. Helaas is dit trager dan rechtstreeks naar de hardware programmeren en verdampt het voordeel van de krachtiger hardware in PCs. Aangezien er op dit moment maar 3 GPU fabrikanten over zijn wordt het voor developers weer aantrekkelijk om direct naar die 3 typen GPUs (of misschien zelfs maar 2) te programmeren in plaats van een tussenlaag te gebruiken.

Dit hele artikel heeft dus niets met een keuze voor of tegen OpenGL te maken. In essentie gaan alle argumenten dit genoemd worden tegen DirectX namelijk ook op voor OpenGL. Het is de keuze wel of geen tussenlaag.
"Je kunt jezelf echter afvragen waarom je zo'n implementatie zou maken. Is er echt zoveel vraag naar OS/X games of Linux games?"

Het enige wat mij bij Windows houd is omdat alle games hiervoor zijn/worden ontwikkeld, anders had ik al jaren op Linux gezeten.
Idem. Zonder games en misschien nog net MSN (wat ik iets leuker werken vind dan empathy) stond windows hier nooit meer op. Nu toegegeven de laatste tijd wel terug maar dat is ook weer met een excuus. De site van de school werkt alleen deftig met Internet explorer 8.0 of lager.
Anoniem: 112442 @humbug21 maart 2011 09:41
DirectX is een openbare API. Er is niemand die je tegenhoudt die API in een ander OS te implementeren.
Ik krijg de indruk dat je niet weet wat een API is.

De directX API geeft alleen maar een interface om tegen de directX code te praten, niet de directX source code. Aangezien deze code niet openbaar is zal het heel veel, reverse engineering, tijd kosten om deze te implementeren.
Je kunt jezelf echter afvragen waarom je zo'n implementatie zou maken. Is er echt zoveel vraag naar OS/X games of Linux games?
Ja, voor Android en iOS, dit openGL gebruiken, het is trouwens ook de PS3 die gewoon openGL gebruikt.

[Reactie gewijzigd door Anoniem: 112442 op 22 juli 2024 15:39]

Het zou erg veel werk zijn om een Linux implementatie te maken van DirectX, als je geen driver maker bent. ATI en NVidia hebben jarenlange ervaring met DirectX software ontwikkeling. Dat maakt het een stuk makkelijker.
Nee ik denk dat je altijd een tussen laag zult hebben, zelfs voor 360 en PS3 worden tussen lagen gebruikt tijdens renderen, 360 is dat gewoon D3D en PS3 is het GCM.

Ik denk dat we altijd een tussenlaag nodig zullen hebben, wat ik liever zou zien is een soort van C++ voor GPU's. Dus geen API maar een programeer taal die je instaat selt om de GPU net als een CPU te benadereren. Rechtstreeks op de hardware richten levert nog meer problemen op dan D3D nu gebruiken, verschillende drivers tussen twee productlijnen van dezelfde fabrikant :(.

Het probleem waarom PC graphics niet vooruit gaan op het moment zijn de consoles, die worden nu bijna altijd als lead platform gebruikt. Deze platformen zijn nu 5-6 jaar oud, dus uit het stenen tijdperk voor shader enabled GPU's.
Anoniem: 356200 @HerrPino19 maart 2011 20:19
Daarbij heeft opengl nog een lastige geschiedenis, waar de api eigenlijk niet veranderd wordt om de CAD software makers tevreden te stellen.. waardoor het zo algemeen blijft en dus api technisch gezien achter bij directX. In princiepe kan je even veel met bijde api's
De sprong naar OpenGL 4.0 zou een heel nieuwe versie zijn zonder alle troep en bagage uit voorgaande versies. Dat hebben ze laten vallen en alles is toch weer backwards compatible. Dat moet een keer ophouden. Ja ze hadden vast een hoop mensen tegen zich in het harnas gejaagd, maar ik denk dat de voordelen van een nieuwe en compleet schone API er wel tegen op hadden gewogen.
Nu zit je met allerlei lagen en een lekker stel achter de OpenGL standaard die geen keuzes durven maken. Keuzes die Microsoft wel durft te(en waarschijnlijk beter zomaar kan) maken.
Zou kunnen. Ja, daar ligt dus het probleem, natuurlijk zou het kunnen maar het probleem is dat het niet gebeurt. OGL is design by commitee en weten allemaal hoe goed dat werkt.

[Reactie gewijzigd door Tijger op 22 juli 2024 15:39]

Direct3D is wel een multiplatform techniek, vb: de Xbox bevat ook DirectX en daar zit niet eens een X86 cpu in. Alleen linux en mac osx kunnen niet overweg met DirectX.
Daarom komen die uitspraken van AMD ook zo raar over. Je wil van DirectX af omdat je net zo snel wilt worden als de XBox 360...die zelf ook op DirectX draait. 8)7
De uitspraak van AMD is dat men direct de GPU wil kunnen benaderen. Op de XBOX weet je welke GPU de gebruiker heeft en kun je dus simpelweg direct naar de GPU programmeren. Op een PC weet je dat niet. Ook kan om dezelfde reden de DirectX implementatie op de XBOX efficiënter zijn. De implementatie hoeft maar op 1 GPU te werken. Maar ik heb geen ervaring met het programmeren op een XBOX. Dus dat is theorie ;)

De uitspraken van AMD zijn dus vrij logisch maar komen voort uit het feit dat er eigenlijk maar 2 GPU series ondersteund hoeven te worden naast DirectX. Dat is te doen.
Op een PC weet je dat ook. Kan zeer eenvoudig opgevraagd worden. Het probleem is dat er zoveel verschillende GPUs zijn met allemaal verschillende mogelijkheden. Het is een zeer complexe taak om die allemaal te gaan ondersteunen. Net daarvoor zijn tussenlagen zoals DirectX en OpenGL uitgevonden.
...en dat snap ik dus niet... je zet er een enorme tussenlaag in om "Het is een zeer complexe taak om die allemaal te gaan ondersteunen" op te vangen...en dat kost geen rekenkracht/compilen ? T'is alleen veel gemakkelijker (en goedkoper op de korte duur) om er een directx pleister ertussen te kwakken... maar desalniettemin, een technische flut oplossing die geld bespaart omdat programmeurs niet zonder willen/kunnen

[Reactie gewijzigd door Anoniem: 247804 op 22 juli 2024 15:39]

Wat valt er niet aan te snappen. Standaarden maken het juist enorm toegankelijk voor meer dev's met minder of geen programeer guru er tussen. en zoals alles een voordeel heefd zijn er ook nadelen. Standaarden leggen ook beperkingen op. Dus waar deel er heel blij mee is zullen de bedrijven die beschikken over hogere programmeer talent en game engine builders en triple A budgetten, dit juist niet goed vinden.

D;r is een trade off.
Time to market vs efficentie.

De tegen hanger van dit streven is juist XNA de hele andere kant het nog meer toegankelijk maken voor een nog veel groter publiek.
Dit is geen technische flutoplossing maar gewoon standaard hoe software wordt gemaakt. En meestal niet met 1 maar met tientallen 'tussenlagen' Ja, je kan het ook zonder doen, als je een game maakt die 1 miljard euro aan budget heeft, op maar 5% van de bestaande hardware hoeft te werken en het niet meer doet met de graka die volgende maand uitkomt ...
Anoniem: 268141 @roy-t20 maart 2011 00:36
XBOX draait op Windows technologie.
Logisch dat Direct3D daarop draait, he ?
Linux en OSX (welke een Unix variant is) zijn een compleet andere format.
Daar zit en zal geen Direct3D op komen.
In theorie kan MS best directx voor Linux maken hoor. Wine kan het omzetten naar OGL, dus een native DX zou geen probleem moeten zijn. Dat doet MS echter niet, want het is een van hun grootste troeven in hun vendor lock-in strategie. Ze willen helemaal niet dat mensen games voor Linux gaan maken, en zullen er alles aan doen om het tegen te werken. Alleen daarom al zie ik DX liever verdwijnen.
ben ik wel mee eens, maar laat ze dan aub plz etc, een nieuwe OGL bouwen waar je
dezelfde (min of meer) features in kunt bouwen, met eventueel een wine-achtige versie om oude ogl-meuk eerst naar ogl5 te vertalen (net als men nu met d3d doet).

dan zal oude software nog werken, op de huidige snelheid, maar zal nieuwere software enorm veel beter kunnen worden.
Anoniem: 273970 @blouweKip20 maart 2011 01:37
Ben ik niet met je eens. DirectX is juist ten tijde van Windows 95 in het leven geroepen omdat alle developers steen en been klaagde dat er voor elke geluidskaart (Adlib, SoundBlaster, Gravis Ultrasound, etc) aparte routines gemaakt moesten worden. De VESA standaard was op videokaartniveau gelukkig iets om je aan vast te houden, maar ook VESA liep toen al tegen beperkingen aan. Iedereen was juist lirisch van DirectX. Het zorgde ervoor dat je niet meer voor elk kaartje speciale dingen hoefde te programmeren. Het werkte gewoon want de drivers voor de verschillende kaarten waren directx certified. (of niet). Dat is wat het voor velen gemakkelijk maakte voor windows te ontwikkelen. Dus dat is de reden, niet een ongezonde markt. Tenzij je dat op een andere manier bedoelt dan dat ik het interpreteer natuurlijk...
Trek het je niet aan, blauwe kip is er altijd bij als het over Dx gaat. Sommige mensen aanvaarden nog altijd niet dat een commercieel bedrijf beter heeft gereageerd op een nood die in de markt bestond. En die nood beter heeft vervuld dan de os variant die zich (te lang) op een handvol CADmensen bleef richten.
Anoniem: 112442 @Rafe19 maart 2011 23:47
John Carmack noemde onlangs Direct3D zelfs beter dan OpenGL: http://www.bit-tech.net/n...k-directx-better-opengl/1
Daar kan ik een ander artikel tegenover zetten waarin staat dat openGL beter is dan DirectX.

Why you should use OpenGL and not DirectX.

Al zouden openGL en DirectX de zelfde kwaliteiten hebben vind ik nog steeds dat ivm de open standaard van openGL voor openGL gekozen zou moeten worden.

Comparison of OpenGL and Direct3D.
Je kan op Windows van beide gebruik maken, en het is de afgelopen 15 jaar in elk geval wel duidelijk geworden wat de developers zelf de beste API vinden. Wil natuurlijk niet zeggen dat dit voor eeuwig zo is, maar toch.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 15:39]

dat heeft denk ik voor een deel te maken met het feit dat ogl een open standaard is dat net als bijv w3c behoorlijk traag kan zijn in het adopteren van nieuwe ideeën.
Ik geloof eerder een highprofile OpenGL gebruiker JC is, dan 'n OpenGL fanatic die openGL als geloof verkondigd.

Daarnaast in wat contexts vind JC DirectX beter.

Ik krijg het idee dat het hier gaat om toegankelijkheid en uniform support van hardware.
En eerder het volwassener worden van Direct3D.
Ik zie het eerder in de trant van het overboard gooien van de device caps. En hogere kernel level de API nu efficenter wordt aangesproken. Dat Direct3D kwa API gebruik OpenGL voorbijgegaan is. Dat MS direct3D nogal verbeterd heefd voor dev gebruik door de itteraties heen.

Niet om open vs gesloten of crossplatform geleuter. Want dat zal niet veranderen. Maar de API zelf.
Tessealtion is geen uitvinding van Microsoft. Sterker nog, het was een OpenGL exstensie vér voordat Direct3D 11 het daglicht zag.
Zoek maar eens wat op het internet en je zult vinden dat AMD in het OpenGL 2.0 tijdperk al dergelijke extensies had. Zelfs jaren daarvoor was het al mogelijk om met behulp van ‘fast instancing’ en ‘vertex-texture-fetch’ gelijksoortige acties uit te voeren.
Ook NVidia heeft extensions bedacht voor OpenGL met functionaliteit die je (nog) niet in DX zult vinden.

Het is een feit dat OpenGL vaak 'haar moment' mist en dat Microsoft gewoon beter is in nieuwe tech op de markt te zetten, maar dat wil niet zeggen dat OpenGL minderwaardig is of per definititie geen alternatief voor DirectX kan zijn. Ik denk dat OpenGL veel voordelen heeft ten opzichte van DX, maar dat de game industrie gekozen heeft voor DirectX en dat ontwikkelaars daardoor OpenGL links laten liggen.

Gelukkig zorgt OpenGL wel voor nieuwe impulsen (in CAD, VR, flightsimulators e.d.) en houdt het als 'oppositieplatform' de andere partij scherp.
Ik meen gehoord te hebben dat ontwikkelaars in het begin heel erg positief waren over Directx, jammer dat dit veranderd is.
Nee eerder sommige dev's niet alle.
Misschien willen ze gewoon iets nieuws, geen OpenGL or DirectX of wat dan ook. Maar gewoon compleet iets anders "DirectGPU"? zodat ze de hardware direct kunnen aanspreken en er alles uit kunnen halen waar het uiteindelijk voor bedoeld is zonder softwarematige limitaties.
Wat ik eigenlijk mis in deze hele forumpost is dat sinds de introductie van Windows Vista het door Microsoft bewust helemaal niet meer toegestaan wordt om direct de hardware aan te spreken. Wie kan zich immers het debacle rond EAX niet meer herinneren? Het 'werkt' tegenwoordig weer wel maar communiceert met de geluidskaart via DirectSound. De reden dat Microsoft dit heeft gedaan is laat ik even in het midden, maar het mag aangenomen worden dat dit vanwege stabiliteitsfactoren, veiligheid en compitabiliteitsoverwegingen is.

De verschillende api's onder DirectX (want DirectX is niets anders dan een verzamelnaam) zorgen dan wellicht voor wat overhead, maar aan de andere kant hebben ze er ook voor gezorgd dat het mogelijk is om beeld, geluid, input en zelfs output te laten functioneren in een besturingssysteem dat met een diversiteit aan hardware om moet gaan. Zonder DirectX is er gewoon geen massale driverondersteuning mogelijk en gaan we terug naar een tijd waarin fabrikanten compitabiliteit moeten emuleren. Dit emuleren gaat dan ook gewoon via een api en dezelfde overhead blijft dus bestaan.

Momenteel hebben Nvidia en AMD een enorme vinger in de pap te roeren bij de ontwikkeling van de Direct3D en DirectDraw-api. Net zoals de geluidskaartfabrikanten dat hebben bij de DirectSound-api. Ze hebben dus zelf een inbreng en kunnen hun stem laten gelden tijdens de ontwikkeling van een nieuwe versie. Echter als men teruggaat naar het direct aanspreken van de hardware dan is het de fabrikant die het meest dominant is op de markt die de lakens uitdeelt. Je krijgt dan een situatie waarin bijvoorbeeld Nvidia marktleider is en AMD een api moet ontwikkelen om zijn kaarten te laten functioneren als een Nvidia kaart. Dit is enorm ongewenst en is slecht voor zowel een goede marktwerking als innovatie.

Dat er dus een universele api is waar alle fabrikanten inspraak op hebben en die door een derde partij wordt beheerd daar wil je niet aan tornen. Neem dan die overhead voor lief. Een overhead die overigens steeds marginaler wordt. Immers, waar het 10 jaar geleden wellicht nog om 5% van de performance zou gaan (fictief cijfer) zal het met de steeds snellere hardware enkel maar omlaag gaan. DirectX passeren en direct met de hardware communiceren zonder api zou dus voor Nvidia, AMD, Logitech, Creative etc. etc. gelijk staan aan het slachten van de kip met de gouden eieren.
Ik geloof er niks van dat DX het probleem is.

Een spel berekend iets, en stuurt dat naar DX.

DX voert wat berekeningen uit, en stuurt dat naar de driver van AMD, nVidea of intel ofzo.

Deze driver gaat vervolgens ontzettend veel onzin doen, controle welk spel het is, "optimalisaties" uitvoeren, zijn eigen zin doordrukken ipv naar de DX call luisteren. enz enz enz. en pas na deze onzin worden de calls eens naar de video kaart gestuurt.

Als een spel correct de DX specs volgt, dan werkt het op alle video kaarten gelijk. Waarom moet dan nog die bloatware die een driver heet iets doen?
mijns inziens zou het beter zijn om losse patches voor spellen uit te brengen die de shaders aanpassen, ipv te proberen deze shit in de driver op te lossen.

Met printers is net zo. 300+ MB voor een driver ?
In de ideale wereld zou er alleen maar een minimale interface binnen Windows hoeven te zitten waar alle calls voor graphics en gerelateerde functies heen gestuurd kunnen worden. Het 'probleem' is als altijd weer gefundeerd op commerciele aspecten. Ontwikkelaars die de hardware zo rechtsstreeks kunnen benaderen krijgen op termijn te veel verstand van die hardware en kunnen dingen waarschijnlijk beter laten werken dan de oude club die het alleenrecht had. (MS, Intel, AMD, Nvidia en de game-huizen). M.a.w. hardware kan vandaag de dag veel te veel. Als je dat allemaal gaat vrijgeven valt er niks meer te verdienen. Het is dus zaak om het direct aanspreken van hardware zoveel mogelijk aan banden te leggen, wat is te realiseren met extra (gesloten) softwarelagen. Volgens mij begon die ellende al in de DOS-tijd. Toen kreeg je ineens van die games met een DOS4GW.EXE runtime module die zogenaamd bedoeld was om de 640K-grens te overbruggen met een abstractielaag. Het zou me dus ook niet verbazen dat die barriere moedwillig aangelegd was in de standaard PC-hardware om de thuisprogrammeur uit te sluiten van de eerste 3d-graphics mogelijkheden. Die mocht lekker doorknoeien met de SVGA hardware die nu nog steeds als legacy-standaard in videokaarten zit.

[Reactie gewijzigd door blorf op 22 juli 2024 15:39]

"Op een videokaart is er tien keer meer rekenkracht dan in een Xbox 360 of PlayStation 3, maar toch zien spellen er niet tien keer beter uit"

Dit komt niet toevallig omdat alle games worden ontwikkeld voor PS3/Xbox en daarna geport worden?
inderdaad.. dat is een grote ergernis.

Games models worden vaak op een verschrikkelijk hoogniveau gerenderd/gemaakt waarna ze verlaagt worden etc.

Waarom leveren ze voor de PC dan niet de hoge res versies hiervan? en de "gewone" zodat de oudere pc's het ook trekken..

Ik heb vooral het gevoel dat gamedevers elke pc het spel willen kunnen laten draaien.. als ze er mee weg konden kwa graphics zou hun benchmark een atom zijn vermoed ik.
Eerder dat de nvidia 9xxx serie en de amd 3xxx serie het spel nog moeten kunnen draaien, de meeste pc's waar men mee wil gamen draait dit of ietsjes beter en het zal nog wel 2 jaar zo blijven.
Anoniem: 303530 @svenk9119 maart 2011 19:13
Precies om die reden kun je de setting van je favo game op low zetten.
Dat is een tweede probleem. Maar ook dedicated PC games zien er niet 10 keer beter uit. Al ziet het ernaar uit dat battlefield 3 in de buurt gaat komen.
Maar dan blijft '10 keer beter' natuurlijk nog relatief aan de beleving, en zeer lastig om vast te stellen. Hoe een spel ervaren wordt is in veel gevallen ook niet alleen een kwestie van de grafische technieken, maar ook van de gekozen grafische stijl (dwz wat ze met de technieken doen).
Anoniem: 287428 @Asteryz19 maart 2011 19:40
hopelijk wel ja :) heb iig hoge verwachtingen

@darkstone daar zouden ontwikkelaars geen rekening mee meer moeten houden. normale details bij native resolutie schalend tot ultra hoog.
Nou , men vergeet ook dat bepaalde features het beeld subtiel kunnen verbeteren maar de proscesing need voor dat subtiele verbeteringetje enorm kunnen zijn.

Bijvoorbeeld raytracing engine.

In een spiegelpaleis kan dit extreem schelen.

'n jungle game amper totdat je wat water tegen komt tja dat ziet er beter uit.
Maar voor de rest het zelfde.

ander voorbeeld.

Het verschil tussen een race game een auto met 500 polygons en 64x64 texture tov 10000 poly model met 1024x1024 multy texture en shader effecten en AA.
dan naar 50000 poly is de verbetering subtieler maar kwa power needs enorm groter.
Ga je dan naar 200.000 ja het zag er al heel mooi uit nu heb je beetje meer polish maar 4 voudige render power nodig.En je moet goed kijken om verschil te zien in subtiele details.

Het is normaal dat meer render power niet linair schaald met wat het bied.
Anoniem: 196662 @SG21 maart 2011 08:36
Ray tracing is een gigantisch verschil in eender welke situatie. Enkel een lege wereld zal je geen verschil zien want er is niets te zien...
Anoniem: 190625 @Dorest0rm19 maart 2011 20:20
Oh hemel maar op welke prestatie schaal doelt Richard Huddy dan ?! Mid-range videokaarten van dit moment of high-end kaarten van dit moment ?!
Is natuurlijk allemaal mooi en aardig maar als een videokaart vol aan de bak moet tot het maximale aan toe heb ik altijd het idee dat je dan instellingen op high kunt vergeten en dat is nu juist wat je als gamer met bescheiden budget wel hoopt ondanks dat je geen high-end stroom slurpende portemonnee leegrovende kaart kunt veroorloven.
Als je nu gewoon even het orginele artikel van Huddy leest. (staat een link naar in het T.net artikel) dan krijg je nauwkeurig en uitgebreid antwoord op die vragen.

Hij heeft het over high-end kaarten van dit moment, die veeeeeeel krachtiger zijn dan de xbox360 en PS3. Maar die tegelijkertijd veel eerder tegen prestatie problemen aanlopen bij draw calls.

Als je dat leest, dan begrijp je dat er ergens iets grondig mis is.

Of rechtstreeks tegen de hardware programmeren de enige oplossing voor dat probleem is betwijfel ik. Maar de developers denken blijkbaar van wel, en die vertellen dat aan Huddy.
Anoniem: 196662 @mjtdevries21 maart 2011 08:31
Tja wie zegt dat dat probleem enkel bij Dx ligt.

Je moet je eens afvragen waarom de snelste kaarten vroeger +€1000 waren en vandaag maar €300.
Er zijn wel zaken als extra marktwerking, grotere productie, goedkopere productie, ... Weet ik ook wel. Maar toch vermoed ik al lange tijd dat NVIDIA en AMD te zwaar aan het besparen zijn op enkele onderdelen.
Spellen die direct de videokaart aanspreken betekent dat het ook makkelijker voor ontwikkelaars wordt platform-onafhankelijk te ontwikkelen zodat veel games ook voor Linux en OS X beschikbaar komen.

Dan blijft een kantoor Windows netwerk, een krachtige tweak-PC of een budget-PC die Windows i.p.v. Linux draait nog de enige beweegredenen om voor Microsoft producten te kiezen. Voor al het overige zijn er dan betere alternatieven zoals bijv. booten van een USB stick om zo je favoriete spel te kunnen spelen zonder de overhead van Windows.
En je denk dat microsoft zo maar stil blijft zitten als eventuele redenen voor het gebruik van hun OS weg worden genomen, ze hebben veel geld in directx geinvesteerd met het doel om juist beperkingen op te werpen voor multiplatform games, ze gaan echt niet lijdzaam toezien hoe er eventueel een technologie komt die daaraan een eind kan maken.
ze gaan echt niet lijdzaam toezien hoe er eventueel een technologie komt die daaraan een eind kan maken.
Wat kunnen ze doen? Helemaal niks. Als game-ontwikkelaars besluiten van DirectX af te stappen, kan MS alleen maar proberen te innoveren om gebruikers te blijven binden. Ik vrees echter voor ze dat ze veel klanten zullen verliezen.
de uitspraak in het artikel is gewoon gebakken lucht, misschien dat ze sommige zaken wat anders zouden willen, maar het zal niet gebeuren om dezelfde reden dat dat veel studio's een engine kopen (Unreal, IDtech,...):
een engine ontwikkelen is duur en de hele middelware herschrijven of verwerken in de engine is dat ook

de reden dat games op pc er niet 10x beter uit zien is omdat games die er 10x beter uit zien wel 100x duurder zijn om te ontwikkelen en er dan nooit winst zal zijn
sommigen hebben het dan over betere textures en hogere poly's, maar dat zijn de eenvoudige verbeteringen die je met moeite zal zien
de effecten perfectioneren, de bewegingen minder houterig maken,... dat kost VEEL meer
de uitspraak in het artikel is gewoon gebakken lucht, misschien dat ze sommige zaken wat anders zouden willen, maar het zal niet gebeuren om dezelfde reden dat dat veel studio's een engine kopen (Unreal, IDtech,...):
We hebben het hier over uitgevers die naast de PC dus ook al ontwikkelen voor de xbox en PS3 en de videokaart direct weten aan te spreken. Ook is al het grafisch werk gedaan voor de console-versies dus een port naar de PC zal er altijd minimaal even goed uit kunnen zien, maar dat is volgens het artikel niet het geval vanwege de overhead van DirectX.
Ja dus daarom hebben we geen DOS games meer zeker :x
Voor al die zaken zijn er al lang dingen uitgevonden om het de developer aangenamer te maken. Nu nog steeds zie je nieuwe technologieën verschijnen die voor betere graphics zorgen met minder moeite. Dus het is stom om te zeggen dat deze games meer kosten, er worden oplossingen voor bedacht. Waarom zouden ze anders altijd betere graphics willen :s
Dat zal wel los lopen, veel mensen doen meer dan alleen maar gamen, en veel zijn gewoon tevreden met windows. Die kleine groep die nu alleen windows draait vanwege games kunnen ze waarschijnlijk wel missen.
denk het niet aangezien er verschillende merken en achitecturen videokarten zijn waardoor er meer geprogrameerd moet worden om alle typed en merken te ondersteunen.

een amd kaart werkt anders dan een nvidia en games moeten ze anders aanspreken.
Anoniem: 119304 19 maart 2011 18:11
Op een videokaart is er tien keer meer rekenkracht dan in een Xbox 360 of PlayStation 3, maar toch zien spellen er niet tien keer beter uit"
Misschien omdat een gemiddelde PC niet de kracht heeft van een Xbox360 of PS3? Wat veel mensen (en Tweakers) vergeten is dat het klassieke PC-platform met zijn uitbreidbare componenten heel veel concurrentie heeft gekregen afgelopen 10 jaar. 10 jaar geleden waren Notebooks nog relatief duur, nu heb je voor rond de 400-500 euro al een degelijke Notebook. Nog maar te zwijgen over de Netbooks, Pads, Smartphones etc. De klassieke systeemkasten zullen komend jaren nog veel meer concurrentie krijgen van de moniele apparaten. En in die apparaten zit helemaal geen goede videokaart.
kwa specificaties van xbox vs pc of ps3 vs pc, zulle er hier vele pc sneller zijn maar omdat games op de 360 of ps3 direct met de hardware communiceren zijn ze vele male sneller,
en dat is iets waar de pc terrein verliest, een gemiddelde laptop is momenteel ongeveer evensnel als een xbox 360 maar kwa gaming performace geen vergelijking met een console
Tsja, maar dat zal niet (alleen) door DirectX komen.

Geef mij een console die een virusscanner+firewall+backup+duizende drivers/services draait terwijl ik game en je zult zien dat de PC het helemaal niet zo slecht doet ;).
Anoniem: 119304 @roy-t20 maart 2011 09:17
Maar een console hoeft die rommel NIET te draaien
Zelfs de grafische kaarten van 100 euro die je op dit moment kan kopen zijn al gauw 5-10 keer sneller dan een PS3/360. De GPU van de PS3 is een aangepaste Geforce 7800GT, de 360 heeft een iets andere opzet maar is ongeveer vergelijkbaar. Richard Huddy weet heel goed waar hij over praat en hij heeft absoluut gelijk in zijn vergelijking.

En ja, netbooks en entry-level notebooks hebben een bagger GPU, maar die hebben dan ook niks met dit artikel te maken. Je kan er namelijk ook niet fatsoenlijk een game op draaien.
Anoniem: 273970 @Snoitkever21 maart 2011 01:29
Door dit artikel en je laatste twee zinnen vraag ik me het volgende af: IS dat wel echt zo? Zou het niet zo kunnen zijn dat wanneer je de Intel GPU direct aanspreekt, deze net zo hard kan lopen als een onder DX draaiende 4850 oid? Eigenlijk zou iemand een benchmark onder dos oid moeten maken om dat uit te proberen.
Die hebben wel degelijk iets te maken met Console vs. PC, het is niet meer vanzelfsprekend dat mensen een desktop hebben...

Maar Huddy heeft absoluut gelijk. En zelfs met de netbooks kan het nog wel eens zover komen dat de Xbox weggeblazen wordt, neem de nieuwe fusion chips met 400 streamprocessors bijvoorbeeld (das ongeveer net zo snel als mijn 5770 gok ik).
de xbox heeft over het algemeen een veel snellere gpu als de ps3. De ps3 gebruikt namelijk ook zijn cpu voor grafische berekeningen, er is pas later besloten dat er ook maar een videokaart in moest omdat de cell cpu toch net niet snel genoeg was.
"over het algemeen een veel snellere gpu" ? LOL. Wat wil dat nou weer zeggen. Het ding is sneller of niet. Daarbij is het onzin, de grafische performace van de 2 consoles is ongeveer gelijk.
Wat je stelt klopt inderdaad wel voor wat jij de gemiddelde pc noemt (ik neig eerder naar de benaming 'budget'), maar het probleem wat hier genoemd wordt is dat snellere hardware blijkbaar niet in staat gesteld wordt om daadwerkelijk de hogere kwaliteit beelden te bieden die je ervan zou mogen verwachten vergeleken met tragere hardware. Zo zou je van een 5 keer snellere videokaart 5 keer zoveel berekeningen verwachten, maar dit schijnt dus nogal tegen te vallen.
nvidia 550ti 135 euro
moederbordje rond de 80 euro
4 gig geheugen 45 euro
harde schijf 55 euro
kast en voeding 80 euro
quad phenom 2 cpu 130 euro
tb+muis 50 euro


575 euro voor een pc waarmee je iedere game op zo goed als max zal kunnen spelen en de prijzen zijn ruim genomen aangezien je daar makkelijk 80 euro afkrijgt als je goed shopt.
max zou ik niet zeggen, metro 2033 zou bv toch met inperkingen draaien
Voor 260 euro heb ik een PS3 in huis met Blu-ray speler en veel exclusieve games (zelfde geld trouwens voor de Xbox360). Voor 200 euro heb ik een Wii in huis met games die al helemaal niet op de PC verschijnen
De PC heeft Steam; als je daar een beetje handig games inkoopt heb je het verschil in een handvol games terugverdient. Het aankoop bedrag is absoluut geen issue.

Voor 300 euro koop je 6 console games. 12 als je heel goed shopt. Voor 300 euro koop je honderden games via Steam gedurende de holiday games.
Geen honderden, true ze hebben wel leuke aanbiedingen. Maar je kan ook bij de PS3 in de budget bak kijken.
Anoniem: 260538 @Rarz19 maart 2011 23:34
Want op de console kan je niet wachten tot spellen goedkoper worden zoals bij steam?

Daarnaast koop ik spellen ook deels voor het verzamelen en dan is steam gewoon saai.
Anoniem: 119304 @Rarz19 maart 2011 23:46
Flikker op met je Steam. Kom eens buiten en loop eens een gewone winkel binnen. Daar liggen honderden games voor veel minder in budget bakken.
Steam is een leuk platform en dat mag imo gewoon blijven... Toch zou ik daar niet al mijn games vandaan halen behalve games in de sale. Kopen via webshops is en blijft vrijwel altijd goedkoper dan via Steam voor nieuwe titels.
Wel wat ik dan niet snap is waarom games op de Mac dan niet zoveel sneller/beter zijn dan die voor de PC? Er zijn maar een handvol configuraties voor Macs (Apple promoot het zelfs zo vanwege hogere performance & stabiliteit vanwege een specifiek aanbod aan hardware waar ze dus nauw mee kunnen werken) dus het principe is dus gelijk aan dat van consoles??

Het is
1. Games worden van (tragere) consoles geport naar de PC
2. Game-ontwikkelaars zijn ook liever lui dan moe, niemand wilt graag op laag niveau programmeren dus pinnen zich maar al te graag vast op DirectX. Bovendien zou extra werk hierin ook weer duurder zijn.
Er is een heel simpele reden voor. Er zijn nu eenmaal weinig Mac's in vergelijking met Windows PC's. En de meeste mac's zijn echt geen snelheidsmonsters, zeker niet op grafisch vlak.
De kosten die een ontwikkelaar zou moeten maken om zijn game specifiek aan te passen aan mac's (die ondertussen ook wel in heel wat varianten in de huiskamers staan) zijn gewoon niet te rechtvaardigen. Ze halen die kosten er nooit uit. Mac's zijn gewoon geen interessante markt voor gamers games.

Het toverwoord hier is ook optimalisatie. Steek meer tijd in je code (maak het dus duurder) en het wordt sneller.

[Reactie gewijzigd door MenN op 22 juli 2024 15:39]

Omdat MACs OpenGL gebruiken en die heeft exact dezelfde inherente problemen (nouja volgens die topman dan) als DirectX.
Ik vraag me af in hoeverre Apple snelheid opoffert voor stabiliteit dan... Ik weet bijvoorbeeld van HP dat ze bepaalde RAID controllers licenceerde van LSI en Adaptec etc. welke beduidend trager waren door de firmware en drivers die HP ontwikkeld had dan dezelfde kaarten van LSI en Adaptec zelf met hun eigen firmware en drivers. De HP kaarten waren dan wel minder snel, maar wel veel stabieler. Ik denk dat zoiets ook bij Apple aan de hand kan zijn.
Ook kan het zo zijn dat de Apple drivers gewoon *niet* geoptimaliseerd zijn voor snelheid. Een kennis van me is nogal bezig met programmeren voor verschillende platformen en was eens bezig met de PS/2 driver voor iets met een Apple, of voor een hackintosh oid. Anyway... wat hij mij vertelde is dat hij nog nooit zo'n brakke PS/2 driver gezien had als die van Apple zelf. Dus als dat echt zo zou zijn, dan is het niet ondenkbaar dat dat op grafisch vlak ook zo kan zijn.
We weten het simpelweg niet... en zullen er waarschijnlijk nooit achter komen ook. Helaas.
Wel wat ik dan niet snap is waarom games op de Mac dan niet zoveel sneller/beter zijn dan die voor de PC? Er zijn maar een handvol configuraties voor Macs (Apple promoot het zelfs zo vanwege hogere performance & stabiliteit vanwege een specifiek aanbod aan hardware waar ze dus nauw mee kunnen werken) dus het principe is dus gelijk aan dat van consoles??
OS X maakt gebruik van de tegenhanger van DirectX, nml. openGL, wat ook voor de nodige overhead zorgt. Zouden we we DirectX en OpenGL weglaten, dan heeft OS X iets meer resources dan Windows beschikbaar voor het spel, echter zul je de verschillen in de praktijk amper merken.

Mochten ontwikkelaars buiten DX om gaan werken dan is het haast aannemelijk dat spellen cross-platform worden vanaf de lancering, net zoals bij de xbox en PS3. Mocht dat gebeuren, zal Apple mss wel een game modus in OS X inbouwen die alle behalve de core services pauzeert. Dat kan onder Linux/UNIX vanwege een betere "process control" makkelijk en efficienter dan onder Windows en dan kan er een verschil in snelheid van een spel merkbaar zijn en heb je ook geen irritante dingen op de achtergrond draaien die je lastig vallen tijdens het spelen.
Mochten ontwikkelaars buiten DX om gaan werken dan is het haast aannemelijk dat spellen cross-platform worden vanaf de lancering, net zoals bij de xbox en PS3.
Uh, de XBox is zelf ook al DirectX-based.
Source engine: Gebruikt een laag om DirectX dynamisch naar OpenGL te converteren. Een traag kutsysteem dat gewoon voor geen meter werkt.

Transgaming: Heel erg kutsysteem dat code jat van Wine, traag en veel te buggy.

En ja, dat zijn nou eenmaal de meeste Mac games.
Ik heb de steam versie van o.a. Assassins Creed 2 op mijn mac gespeeld onder windows 7 en mac os x en beide liepen vrijwel even goed.
27" iMac i5 4850HD 4GB DDR3 1GHz
mac games zijn niet sneller/beter omdat het ports zijn van windows naar mac, en ports zijn meestal niet sneller, waarschijnlijk worden de nodig aanpassingen aan toegevoegd en dat is het, word niet geoptimaliseerd voor mac en is daarom net zo als op windows of zelfs nog minder
Voor al het overige zijn er dan betere alternatieven zoals bijv. booten van een USB stick om zo je favoriete spel te kunnen spelen zonder de overhead van Windows.
dat heb ik me al vaker afgevraagd, kunnen ze niet wat software ontwikkelen zodat je een game als een live disc opstart (zoals knoppix ofzo). Dan haal je het hele windows ertussen uit. Of iets in de trant van een simpel steam OS.
dan ga je dus richting de consoles, die werken ongeveer op de zelfde manier en daardoor zou je dus veel beter games kunnen spelen dan op je console omdat pc hardware over het algemeen sneller is dan consoles:P

maar ja dat is dus weer moeilijk en microsoft zal er alles aan doen omdat te voorkomen omdat je dan geen windows meer nodig hebt dus je bijvoorbeeld op ubuntu kan draaien, aangezien er veel windows gebruikers op windows zitten om te kunnen gamen
Dit wordt niet gedaan omdat dan elk spel dan alle drivers moet hebben voor elk mogelijke combinatie hardware die er bestaat.
Anoniem: 273970 @earvaag21 maart 2011 02:01
Dan kom je terecht in hoe het vroeger was: DOS met memory management driver, netwerk/cdrom driver, geluidsdriver en in het geval waar het in dit draadje om gaat een grafische standaard waar men zich aan moet houden aan zowel de hardware als de software kant, wat in die tijd VESA was. Werkte iets niet? Even VESA driver laden en 10 tegen 1 dat het dan wel werkte. Die tijd hebben we dus lang geleden achter ons gelaten. En teruggaan naar die tijd zal niet gebeuren denk ik, maar ik denk wel dat er een soort van "hybride" achtig iets ontwikkelt zal worden. De hardware boeren willen het blijkbaar en de ontwikkelaars ook. Als MS slim is gaan ze erin mee op een bepaalde manier door met ze rond de tafel te gaan zitten en een soort "hybride" systeem te ontwikkelen. Zo prijst niemand zich uit de markt en wordt toch vooruitgang behaalt.
tja maar multitasken is daarmee onmogelijk en om nou iedere keer te rebooten als je even een game wil spelen....
in principe hoef je niet te rebooten, als je besturingssysteem gewoon in hibernate stand gaat of so, en dat dan je game start. als je dan klaar ben je je game exit en gewoon je windows er bijna direct weer is, vermoed dat ze ongeveer dezelfde techniek gebruiken op de xbox 360
xbox en PS3 hebben een OS met een kleine footprint die naast het spel op de achtergrond in het geheugen blijft draaien.

Windows 7 bijv. heeft idle letterlijk een paar honderd keer meer geheugen nodig dan een gestript Linux OS waarvan de desktop manager geheel uitgeschakeld kan worden tijdens het spelen van een spel. Je hebt het dan over minder dan 10MB geheugengebruik en een miniem aantal processen die op de achtergrond draaien waar die onder Windows niet makkelijk tot een minimum te beperken zijn.

Als we kijken naar de videokaarten van de afgelopen 3 jaar, dan hebben we het met AMD en nVidia gecombineerd maar over ongeveer 6 verschillende architecturen met zeer kleine onderlinge verschillen.

Het mag dus niet moeilijk voor ontwikkelaars zijn de videokaarten direct aan te spreken, wat ook betekent dat een spel tegelijkertijd voor zowel Windows, Linux als OS X uit kan komen. Dat opent een zee aan mogelijkheden en kan de OS-markt meer openbreken zodat we niet eeuwig aan Windows blijven hangen.

Op dit item kan niet meer gereageerd worden.