Waarom niet implementeren van DirectX 9 ?

[ProgrammerX]

In deze tijd dat de hardware elkaar zo snel opvolgt hoor je mensen wel vaker zeggen, dat de hardware die je nu koopt pas door de software over een jaar ofzo wordt gebruikt (ff als voorbeeld dan).

Nu zit ik mij af te vragen waarom de functionaliteit van de directx9 kaarten van nu nog niet gebruikt wordt.

Is het niet mogelijk dan om een engine te maken die eerst de functies van de kaart analyseert (a.d.h.v. de chipset) en dan vervolgens een aantal "switches" omgooit in de engine zodat de volledige directx functionaliteit gebruikt kan worden. Dit zal waarschijnlijk wel betekenen dat een aantal functies van de engine specifiek voor een versie van directx zullen moeten worden herschreven (dus bijv. een DrawLine voor dx8 en een DrawLine voor dx9). Zou het dan niet mogelijk zijn om nu al spellen te maken die directx 9 functionaliteit hebben en toch compatible met machines die dit niet hebben ?

Het enige dat ik kan bedenken waarom spellenmakers dit niet zouden doen is vanwege de extra tijd dat het kost. In dit geval zou een gezamenlijk project misschien een optie zijn (zoiets als unitedlinux maar dan voor de grafische markt) ?

[JeroenB]

Het probleem zit hem erin dat er allerlei partijen betrokken zijn die zo min mogelijk van elkaar afhankelijk willen zijn. Bedrijf X wil een spel maken en heeft nu specs van Microsoft van alle versies van DirectX die beschikbaar zijn en misschien (als ze goeie connecties hebben) ook al van versie 10. Tegen de tijd dat hun spel af is echter is de kans groot dat DirectX 11 beschikbaar is.

De reden is simpelweg dat de hardwaremakers voor een groot deel bepalen wat er mogelijk is op het gebied van betaalbare en effectieve hardware acceleratie, Microsoft dat vervolgens moet omzetten in een API voor een versie van DirectX en het nieuws dan de ontwikkelaars bereikt dat ze ermee aan de slag kunnen met de wetenschap dat het op korte termijn supersnel in hardware aanwezig is. De ontwikkelingen aan de kant van nVidia, ATI en consorten gaat echter zo snel dat het nu nog niet bekend is wat er over ruim een jaar aan nieuwe hardware accelerated features beschikbaar is - maar games developers gaan wel nu alvast programmeren aan spellen die dan uitkomen. Conclusie: Loopt niet netjes synchroon. En dat is dus wat we de afgelopen jaren steeds hebben gezien.

[ Voor 1% gewijzigd door JeroenB op 23-12-2002 11:43 . Reden: typo ]

[Zoijar]

Het kost veel tijd, zorgt voor bugs die alleen op bepaalde systemen voorkomen, en je bereikt er maar een heel klein deel van je doelgroep mee. Het wordt wel in meer of mindere mate gedaan al trouwens. Vaak heb je een optie voor pixel shaders.

[Glimi]

DirectX zal er toch voor zorgen als een kaart hardwarematig iets niet ondersteund, dit softwarematig uitgevoerd zal worden? Of is dat alleen zo bij een beperkt aantal functies?

[JeroenB]

Overigens, om je voorbeeld aan te grijpen, als je queried naar de beschikbaarheid van een DirectX-interface, je de nieuwste pakt en daarop de DrawLine() aanroept, dan krijg je de nieuwste - dat kan er eentje zijn die nog niet beschikbaar was toen je je code schreef. Dus in principe kan wat je wilt allang (en is het altijd al mogelijk geweest, als onderdeel van COM.)

[Janoz]

Glimi schreef op 23 December 2002 @ 11:45:
DirectX zal er toch voor zorgen als een kaart hardwarematig iets niet ondersteund, dit softwarematig uitgevoerd zal worden? Of is dat alleen zo bij een beperkt aantal functies?

Dat kan wel, maar gaat enorm ten koste van je framerate. De software implementatie is altijd een stuk langzamer dan de hardware implementatie.

[Janoz]

ProgrammerX schreef op 23 december 2002 @ 11:12:
In deze tijd dat de hardware elkaar zo snel opvolgt hoor je mensen wel vaker zeggen, dat de hardware die je nu koopt pas door de software over een jaar ofzo wordt gebruikt (ff als voorbeeld dan).

Nu zit ik mij af te vragen waarom de functionaliteit van de directx9 kaarten van nu nog niet gebruikt wordt.

Is het niet mogelijk dan om een engine te maken die eerst de functies van de kaart analyseert (a.d.h.v. de chipset) en dan vervolgens een aantal "switches" omgooit in de engine zodat de volledige directx functionaliteit gebruikt kan worden.

Je kunt gewoon met een functie van DirectX opvragen wat de functionaliteiten zijn die de kart heeft. Je moet al helemaal niet gaan proberen om voor elke kaart appart een interface te gaan schrijven. Dan ben je meer met het maken van drivers bezig dan met het spel. Worden we weer 15 jaar terug in de tijd gegooid (denk aan het kiezen van een printer in WP5.1)

Dit zal waarschijnlijk wel betekenen dat een aantal functies van de engine specifiek voor een versie van directx zullen moeten worden herschreven (dus bijv. een DrawLine voor dx8 en een DrawLine voor dx9). Zou het dan niet mogelijk zijn om nu al spellen te maken die directx 9 functionaliteit hebben en toch compatible met machines die dit niet hebben ?

Over het algemeen is de boel wel backward compatible. Anders zouden zodra je DX9 hebt geinstaleerd alle bestaande spellen het niet meer doen. Een nieuwe DX heeft meestal meer functionaliteit. De dingen die ze eruit halen worde gewoon deprivated.. Je kunt ze dan nog wel gebruiken, maar dat is alleen voor de backward compatibiliteit (denk aan Directdraw in DX7 die eruit is gehaald)

[Glimi]

Janoz schreef op 23 December 2002 @ 11:47:
Dat kan wel, maar gaat enorm ten koste van je framerate. De software implementatie is altijd een stuk langzamer dan de hardware implementatie.

Mjah, dan is het toch geen probleem om tegen de nieuwste (of al pre-known) DirectX API aan te programmeren. Kaarten die de features niet ondersteunen hebben dan toch gewoon pech gehad

[Zoijar]

Glimi schreef op 23 december 2002 @ 11:58:

[...]

Mjah, dan is het toch geen probleem om tegen de nieuwste (of al pre-known) DirectX API aan te programmeren. Kaarten die de features niet ondersteunen hebben dan toch gewoon pech gehad

Zo werkt het dus helaas niet als je aan een commercieel product bezig bent... je uitgever wil heel erg graag dat de systeem eisen zo laag mogelijk zijn. Er wordt altijd geprogrammeerd voor de kleinst gemene deler, omdat je dan zo'n groot mogelijke groep potentiele klanten hebt.
Neem als voorbeeld splinter cell voor de PC. Thermal vision ziet er strak uit op een kaart die hardware pixel shaders ondersteund. Maar ze zijn nu dus nog steeds bezig met geforce2 support, wat een behoorlijk probleem bleek te zijn. Thermal vision zal dus ook geimplementeerd moeten worden zonder gebruik te maken van pixel shaders.
En ja ach, de "nieuwste" hardware features in je spel... hoeveel mensen kopen er nou elke paar maanden een nieuwe videokaart van zo'n 300 a 400 euro? Er zitten veel meer potentiele kopers van je spel met een "oude" gf3, of gf2mx oid. Dat kleine groepje mensen met de allernieuwste hardware doet er niet zo veel toe. En die kopen je spel toch wel. Vaak weten mensen niet eens wat die nieuwe features dan wel precies zijn, alleen dat ze "het nieuwste en duurste" hebben.

[.oisyn]

Glimi schreef op 23 december 2002 @ 11:58:
Mjah, dan is het toch geen probleem om tegen de nieuwste (of al pre-known) DirectX API aan te programmeren. Kaarten die de features niet ondersteunen hebben dan toch gewoon pech gehad

Hardware features zijn maar in mindere mate te emuleren. Meestal werkt het maar tot aan de rasterizer, vanaf daar is het geheel afhankelijk van de onderliggende hardware implementatie, omdat de cpu zich daar gewoon simpelweg niet mee kan bemoeien. Transform & lighting is wel met de cpu te doen, daarna gaan de polygonen naar de rasterizer die vervolgens de dingen op het scherm tekent (inclusief texture mapping en dergelijke). In feite is dit ook wel door de CPU te doen, maar dat scheelt echt (ruw geschat) een factor 100 kwa snelheid, niet aan te raden dus.

Dit probleem heb je dus bij de pixel shaders die bijvoorbeeld op een oudere kaart niet werken (omdat het niet aanwezig is of omdat ie een oudere versie van de pixelshaders ondersteunt), of bijvoorbeeld de grotere kleur-precisie die DX9 kaarten wel ondersteunen maar DX8 kaarten niet.

Als je een PC-spel bouwt (wat ook steeds minder gebeurt overigens) moet je rekening houden met verschillende soorten hardware, en zorgen dat jouw implementatie op al die verschillende hardware draait. Ok, je moet natuurlijk wel een minimale systeem spec. opstellen omdat het nooit op alle hardware kan draaien, maar je moet dan nog steeds rekening houden met veel verschillende hardware.

Neem bijvoorbeeld Doom III 3d engine, de next-gen engine van id software. Die werkt prima op mijn gf2, zij het wat langzaam. Toch maakt Doom III ook gebruik van heel veel features van de nieuwere kaarten.

Gelukkig kent zowel opengl als directx functies om de capabilities van een videokaart op te vragen, kijken naar de chipset is dus gelukkig niet nodig. Aan de hand van die capabilities kun je een rendering strategy opzetten. Zo zit het ook in de 3d engine waar ik momenteel mee bezig ben... daarmee kun je oneindig veel texture lagen op een model plakken, echter hoe het gerenderd wordt hangt volledig af van het aantal texture units dat die kaart ondersteund. Nou is de oplossing hiervoor redelijk simpel, maar je zult dus altijd fallback strategies moeten implementeren als een bepaalde hardware feature niet beschikbaar is (tot op zekere hoogte natuurlijk)

De vraag waarom directx9 features nog niet ondersteund worden is echter een iets andere vraag, met een ander antwoord: namelijk dat DirectX9 nog maar net uit is. Een spel bouwen dat van DirectX9 gebruik maakt was dus niet echt een optie, aangezien nog lang niet iedereen DirectX9 op z'n systeem heeft staan. En jammer genoeg kent DirectX8 geen features om van bepaalde extensies gebruik te maken, dus met de DirectX8 API zul je nooit gebruik kunnen maken van de features die niet in dx8 maar wel in dx9 zitten. Dit in tegenstelling tot OpenGL die dat wel kent, en dus ben je niet afhankelijk van de standaard API om de nieuwste features aan te spreken