Na początku zacznijmy od wyjaśnienia, czym są w ogóle biblioteki graficzne i do czego się je stosuje. Większość z Was zapewne słyszała nie tylko o DirectX, ale również o OpenGL. Obydwa programy to tak naprawdę moduły interfejsu programistycznego API. W API zawarte są wszystkie procedury, funkcje i interfejsy umożliwiające komunikację z systemem operacyjnym, bibliotekami lub sterownikami zewnętrznymi w stosunku do korzystającej z API aplikacji. Innymi słowy, zarówno DirectX, jak i OpenGL pośredniczą w komunikacji między np. grą a sterownikami karty graficznej zainstalowanej w komputerze i jednocześnie unifikują polecenia i procedury związane ze wszystkimi aspektami tworzenia grafiki 3D. Istnienie takich bibliotek jest bardzo ważne z punktu widzenia programistów, gdyż korzystają oni wyłącznie z poleceń zawartych w API i nie muszą pisać kilku niekompatybilnych wersji tej samej gry, powiedzmy na karty NVIDII, ATI czy układy firmy Intel lub S3.
Tak wiec z jednej strony bibliotek graficznych mamy aplikację, z drugiej zaś sterownik karty. Do zadań drivera należy między innymi tłumaczenie ciągu instrukcji i danych płynących z interfejsu API na wewnętrzny język poleceń zrozumiały dla układu graficznego 3D. Wynika z tego, że sterownik karty graficznej powinien być dostarczony bezpośrednio przez producenta układu graficznego, gdyż tylko on najlepiej zna poszczególne funkcje układu i dokładnie wie, jak realizowane jest przetwarzanie potoku graficznego (ciągu następujących po sobie zdarzeń prowadzących do wygenerowania sceny 3D) wewnątrz GPU.
Dobrze zaprojektowany tandem: układ 3D–sterownik powinien działać tak szybko, jak to tylko możliwe. Co to oznacza w praktyce? Otóż driver powinien mieć jak najmniej do roboty, aby niepotrzebnie nie obciążać jednostki centralnej komputera. Źle napisany sterownik potrafi spowolnić pracę karty nawet o 30–40%! Z drugiej strony, aby driver działał sprawnie, powinien również jak najmniej ingerować w kod i dane przesyłane z interfejsu API. Aby spełnić ten warunek, inżynierowie projektujący układy 3D dążą do tego, aby ich procesory graficzne były jak najbardziej zgodne z graficznymi bibliotekami. Dzięki temu sterownik karty 3D nie będzie miał dużo do roboty (czyli nie będzie mocno obciążał CPU) przy przekształcaniu ciągu instrukcji na kod zrozumiały dla procesora 3D i przy formatowaniu danych dla niego.
Co ciekawe, zespoły projektantów z różnych konkurujących ze sobą firm bardzo ściśle współpracują nie tylko z programistami piszącymi graficzne API, ale również wymieniają się ze sobą szczegółowymi informacjami technicznymi. To od nich w dużej mierze zależy, jakie efekty graficzne wprowadzone zostaną w kolejnej odsłonie bibliotek graficznych i jak w pewnym przybliżeniu powinny być one realizowane na drodze sprzętowej. To przybliżenie drogi realizacji efektu 3D wynika stąd, że dokładna metoda jak dojść do tego, aby na ekranie uzyskać odpowiedni efekt graficzny zależy już wyłącznie od architektury układu i wewnętrznych funkcji zaimplementowanych w strukturze chipa – a takimi informacjami firmy niezbyt chętnie się już dzielą, tym bardziej, że z punktu widzenia projektowania graficznego API to, jak jest wewnętrznie realizowany efekt 3D, nie ma najmniejszego znaczenia.
To właśnie różnice w sposobie realizacji efektów 3D, mimo unifikacji wprowadzonej przez biblioteki graficzne, sprawiają, że obraz wygenerowany za pomocą różnych modeli kości 3D (nawet jeśli są one wyprodukowane przez tę samą firmę) może wyglądać nieco inaczej. O tym możecie przeczytać m.in. w artykule Z lupą w ręku, czyli rendering ATI i NVIDII pod kontrolą. Na szczęście odstępstwa te nie są zbyt duże i trudno je w praktyce dostrzec, tym bardziej, że projektanci wiedząc jak ma wyglądać dany efekt, dążą do tego, aby to co zobaczymy na ekranie, jak najbardziej zbliżone było do założonego wzorca. Co ciekawe, do tego aby karta 3D zgodna była z jakąś wersją bibliotek graficznych, wcale nie musi wykonywać wszystkich przewidzianych w specyfikacji instrukcji, ani obsługiwać wszystkich formatów danych. Okazuje się bowiem, że do osiągnięcia zgodności wystarczy obsługa podstawowych, wyszczególnionych w specyfikacji API funkcji oraz formatów danych. Bardziej zaawansowane instrukcje mogą być realizowane albo za pośrednictwem symulacji przeprowadzanych w sterownikach (tak realizuje się w niektórych układach zintegrowanych operacje werteksowe, np. w module Intel Graphics Media Accelerator 900 znajdującym się m.in. w chipsetach z serii i915 czy starszym Intel Extreme Graphics 2 z układów i865G) albo zastępowane są innymi operacjami, z którymi radzi już sobie dany model kości 3D. Niestety, w takich wypadkach końcowy obraz nie zawsze wygląda już tak dobrze, jak powinien.
Na powyższych zrzutach ekranowych z gry Halo widać wyraźnie różnice między obrazem generowanym przez układ z emulacją softwarową efektów 3D (u góry Intel GMA900) i kartą generującą obraz w całości sprzętowo (na dole ATI Radeon 9600). Dzięki uprzejmości www.fcenter.ru
Krótka historia DirectX
Wróćmy jednak z powrotem do bibliotek DirectX. Pierwsza ich wersja zadebiutowała w sierpniu 1995 roku wraz z premierą systemu Windows 95. DX 1.0 porządkowała sposób wyświetlania grafiki w ówczesnych zaawansowanych programach graficznych takich jak np. AutoCAD i wprowadzał możliwość pisania gier dla systemu Windows, a trzeba pamiętać, że ówczesne gry korzystały przede wszystkim z DOS-u i własnych procedur tworzenia grafiki. Z naszego punktu widzenia przełomowe okazały się dopiero biblioteki DirectX w wersjach 6.1 i 7.0. Obie zadebiutowały w 1999 roku – pierwsza w lutym, a druga we wrześniu. Dlaczego okazały się one przełomowe? Otóż wprowadzono w nich najważniejsze elementy klasycznego już dzisiaj modelu generowania trójwymiarowej grafiki, a mianowicie obsługę potoków renderujących oraz sprzętowe wspomaganie operacji geometrycznych i kalkulacji oświetlenia T&L (Transform and Lighting). Od momentu premiery bibliotek DX 6.1 i DX 7.0, i przede wszystkim zgodnych z nimi kart graficznych, można już mówić o akceleratorach 3D (dla porównania, słynny S3 ViRGE często nazywany był złośliwie "deceleratorem", bo w wielu grach zamiast przyspieszać... spowalniał grafikę 3D). Karty takie przejęły bowiem główne elementy procesu generowania grafiki 3D, odciążając jednocześnie procesor (CPU) od zadań związanych z tworzeniem trójwymiarowych scen.
Wraz z pojawieniem się obsługi T&L w DirectX 7.0 i premierą układu NVIDIA GeForce 256 ze sprzętowym wsparciem dla T&L, NVIDIA ukuła termin GPU – Graphics Processing Unit (analogicznie do akronimu określającego procesor - CPU, Central Processing Unit). Nazwa GPU dla układów graficznych miała sugerować, że są to już jednostki przetwarzające samodzielnie większość operacji strumienia graficznego (w gestii CPU – o czym za chwilę – pozostało ich tylko kilka).
Następną istotną wersją bibliotek DirectX była wersja 8.0. Zadebiutowała ona we wrześniu 2000 roku i wprowadziła shaderowy model przetwarzania grafiki. Co ciekawe, powstała ona przede wszystkim na potrzeby pierwszej wersji Xbox – konsoli Microsoftu do gier. Najważniejszą nowością w akceleratorach 3D zgodnych z DX 8.0 było pojawienie się programowalnych jednostek Vertex i Pixel Shader. Moduły te potrafią zmodyfikować szkielet sceny oraz użyte do jej budowy tekstury i pojedyncze piksele obrazu już w trakcie przetwarzania ich w potoku graficznym. Co więcej, modyfikacje obiektów mogą być również przeprowadzane na gotowej scenie 3D. Do zrealizowania takich operacji wykorzystuje się krótkie programy, nazywane programami shaderowymi. To, co ujrzymy na ekranie, zależy już od fantazji i umiejętności programisty piszącego grę. Za pomocą programów shaderowych można na przykład stworzyć własne efekty graficzne niedostępne w standardowych procedurach DirectX. Koniecznie trzeba tu zaznaczyć, że niezależnie od programów shaderowych, programiści cały czas mogą korzystać z gotowych funkcji zaimplementowanych w bibliotekach DirectX, a kolejne wersje bibliotek są zawsze, niezależnie od wersji, kompatybilne wstecz ze wszystkimi starszymi graficznymi interfejsami programowymi.
Kolejne wersje DirectX, a mianowicie 8.1, 9.0, 9.0a, 9.0b i 9.0c, wprowadzały ulepszenia do shaderowego modelu programowania kart 3D, a programiści zaimplementowali szereg nowych graficznych funkcji, niemniej sama architektura bibliotek DirectX nie uległa zmianie.
Czas na DX10
30 listopada 2006 roku oficjalnie zadebiutowały biblioteki graficzne DirectX 10, które znane były wcześniej również pod nazwami Windows Graphics Foundation i DirectX Next. Obecnie DirectX 10 dostępny jest jedynie z systemem operacyjnym Windows Vista, a Microsoft nie przewiduje wersji DX10 dla Windows XP. Co ciekawe, w DirectX 10 po raz pierwszy nie zachowano wstecznej kompatybilności z poprzednimi wersjami bibliotek graficznych, ale na szczęście ta niedogodność dotyczy jedynie warstwy sprzętowej – wszystkie obsługiwane dotychczas funkcje dalej są częścią nowego API. Co to oznacza w praktyce? Otóż wszystkie stare gry dalej będą poprawnie działać w nowym środowisku graficznym, ale żadna stara karta nie uruchomi się przy wykorzystaniu nowego DirectX. Spokojnie, nie ma obawy – Microsoft przewidział, że nie każdy użytkownik Visty kupi sobie od razu któregoś z GeForców z serii 8000 lub Radeona HD 2900 XT. W celu zachowania kompatybilności ze starszym sprzętem, w Vistę wbudowano drugi graficzny API, a mianowicie DirectX 9.0L (od ang. legacy czyli dziedzictwo). Oba DX są od siebie niezależne i należy je traktować jako dwa odrębne API – pierwszy wykorzystywany jest przez najnowsze karty, drugi zaś jest uruchamiany w chwili, gdy w systemie wykryta zostanie karta zgodna z którąś ze starszych wersji DirectX.
Rozdzielenie DirectX 10 i DirectX 9 ma bardzo głębokie uzasadnienie. Otóż przy pisaniu każdej kolejnej wersji DirectX programiści wykorzystywali kod z poprzedniej, uzupełniając go i poprawiając. Takie podejście ma oczywiście swoje zalety (program m.in. pisze się znacznie szybciej i nie trzeba za każdym razem implementować na nowo obsługi starszego sprzętu, gdyż w starym kodzie ona po prostu już jest), ale też i swoje wady, z których największą jest przenoszenie dotychczasowych błędów i ograniczeń w funkcjonowaniu aplikacji. Jak można się domyślić, tą metodą powstał DirectX 9.0L. DirectX 10 został natomiast napisany całkowicie na nowo, dzięki czemu uniknięto wielu błędów i zoptymalizowano kod, przystosowując go wyłącznie do nowych kart. Takie podejście pozwoliło zmniejszyć tzw. narzutu interfejsu API na proces tworzenia grafiki, określany angielskim terminem API overhead. Chodzi tutaj o moc obliczeniową CPU wykorzystywaną do obsługi bibliotek graficznych. Dotychczasowe biblioteki DX 9 zużywały ok. 40% cykli procesora przeznaczonych na tworzenie grafiki. W DX10 nakład ten zmniejszono do ok. 20%, dzięki czemu jednostka centralna ma więcej czasu na tworzenie bardziej realistycznej grafiki, bądź może być w tym czasie zaprzęgnięta do zupełnie innych zadań.
Przystosowanie kodu bibliotek DirectX 10 do obsługi wyłącznie nowych kart ma również istotny wpływ na szybkość generowania grafiki 3D. Dotychczas, podczas tworzenia sceny 3D, gry za pośrednictwem graficznego API wielokrotnie zwracały się z zapytaniami do karty, czy jest ona w stanie obsłużyć taki lub inny efekt graficzny. Sprawdzanie takie zajmowało sporo czasu. Teraz wystarczy już tylko raz odwołać się do procedur sprzętowych, aby biblioteki wiedziały, jakie instrukcje i formaty danych są dozwolone, a gra mogła zająć się wyłącznie generowaniem trójwymiarowej grafiki. Przy okazji zoptymalizowano także algorytmy zarządzania tablicami tekstur, rysowania z wyprzedzeniem (predicated draw) i wysyłania strumienia danych. Wszystkie te operacje wymagają znacznie mniejszej liczby interwencji procesora niż miało to miejsce w wypadku DirectX 9.
Nie tylko CUDA
Wraz z GeForem 8800 NVIDII zadebiutowała nowa zunifikowana architektura CUDA (Compute Unified Device Architecture). Bardzo podobne rozwiązanie o nazwie Unified Shaders, które znacznie wcześniej przetestowane zostało w Xenosie, układzie graficznym konsoli Xbox 360, znaleźć można również w Radeonie HD 2900 XT. Nie jest to przypadek, że najnowsze układy 3D konkurujących ze sobą firm korzystają w tym samym stopniu z ujednoliconej architektury procesorów geometrycznych. Takie rozwiązanie architektoniczne narzuca bowiem DirectX 10. W DX10 wszystkie operacje dotyczące przetwarzania wielokątów i pikseli realizowane do tej pory oddzielnie przez jednostki Vertex i Pixel Shader połączone zostały w jedną, wspólną fazę.
Architektura zunifikowanych modułów graficznych pozwala na wyeliminowanie opóźnień, spowodowanych pustymi cyklami jednostek Vertex i Pixel Shader; źródło: NVIDIA
Projektantów Microsoftu do połączenia w DirectX 10 wszystkich kalkulacji geometrycznych i operacji na pikselach skłoniło kilka przyczyn. Najważniejszą z nich było to, że w dotychczasowym modelu bardzo często zdarzało się, iż jednostki Vertex i Pixel Shader nie były równomiernie obciążone obliczeniami. Gdy jedne z nich pracowały na pełnych obrotach, drugie stały bezczynnie przez kilkanaście cykli zegarowych w oczekiwaniu na wyniki obliczeń tych pierwszych. W zunifikowanej architekturze nie ma miejsca na takie przestoje. Każda jednostka, w zależności od potrzeb, może zająć się jednym lub drugim typem obliczeń, zmniejszając tym samym liczbę pustych przebiegów i zwiększając wydajność układu. Drugą, być może ważniejszą przyczyną, leżącą u podstaw powstania zunifikowanej architektury, był pomysł na to, aby przyczynić się do stworzenia uniwersalnego układu graficznego, który byłby w stanie przejąć na siebie również kalkulacje związane z obliczeniami fizyki, animacją czy funkcjami związanymi z zarządzaniem sztuczną inteligencją w grze. Wszystkie te operacje łączą w sobie obliczenia, którymi do tej pory zajmowały się oddzielnie jednostki Vertex i Pixel Shader.
Oczywiście, nie każda karta graficzna zgodna z DX10 musi wykorzystywać zunifikowaną architekturę procesorów graficznych. Równie dobrze może być ona wykonana w tradycyjnej architekturze z oddzielnymi jednostkami Vertex i Pixel Shader. Wówczas odpowiednim rozseparowaniem operacji zajmie się sterownik urządzenia, co niestety dodatkowo obciąży jednostkę centralną komputera. Niestety to nie wszystko. Jeżeli karta wykorzystuje tradycyjną architekturę, wówczas DirectX 10 wymaga, aby w układzie 3D znajdowaly się dodatkowe jednostki shaderowe. Pomiędzy Vertex a Pixel Shaderem musi znaleźć się nowy moduł o nazwie Geometry Shader. Jednostka ta odpowiedzialna jest za operacje łączenia wierzchołków i wielokątów sceny w paski oraz bardziej złożone struktury geometryczne. Takimi operacjami w wypadku kart zgodnych z DX 9 zajmuje CPU – to są te nieliczne, wspomniane przez nas operacje w strumieniu graficznym, które pozostały na barkach procesora. Teoretycznie możliwa jest zatem symulacja Geometry Shadera przez sterowniki, ale przy bardziej skomplikowanych grach, procesor będzie już zbyt obciążony innymi obliczeniami, aby dał sobie radę z dodatkowymi przekształceniami, tym bardziej, że Geometry Shadery mają na tych złożonych, werteksowych strukturach modyfikować i przeprowadzać obliczenia fizyczne dotyczące ruchu pasków (np. falowanie trawy czy włosów) oraz generować dla nich cienie szablonowe. Co więcej, dzięki istnieniu Geometry shaderów, takie efekty jak mapowanie przemieszczeń (Displacement Mapping), wytłaczanie cieni szablonowych (Stencil Shadow Extrusion) czy tworzenie obiektów typu point-sprite będzie dla programistów znacznie łatwiejsze.
Shader Model 4.0
Model cieniowania 4.0 (Shader Model 4.0) zaimplementowany w DirectX 10 jest znacznie bardzie elastyczny niż jego poprzednik Shader Model 3.0 z DX 9. Programiści przy pisaniu programów shaderowych mają do dyspozycji znacznie więcej rejestrów. Liczba rejestrów stałych wzrosła z 256 do 65.536. Pogrupowane są one w bloki 16 buforów z 4096 rejestrami każdy. Liczba rejestrów tymczasowych wzrosła zaś z 32 do 4096. Zwiększono też rozmiar obsługiwanych tekstur. W DirectX 9.0c tekstury mogły mieć maksymalny rozmiar 4096×4096 pikseli, zaś w DX10 jest to wymiar 8192×8192 punktów. Zwiększona została też liczba obiektów, które mogą być jednocześnie renderowane techniką MRT (multiple render targets). Dotychczas można było nakładać tekstury na cztery obiekty, teraz tych obiektów może być osiem. Wprowadzono też tablice tekstur (texture arrays) mieszczące do 512 pojedynczych bitmap. Programiści mają tez do swojej dyspozycji mechanizm strumienia danych (stream out). Pozwala on wysłać w dowolnej chwili rezultaty pracy jednostek geometrycznych wprost do pamięci karty.
To nie koniec nowości wprowadzonych w SM 4.0. Nowe są również dwa formaty danych stosowane podczas renderingu HDR (High Dynamic Range). Pierwszy z nich używa cyfr o pięciobitowej dokładności, stanowiących wykładnik potęgi opisującej każdy kolor mantysą o dziewięciobitowej dokładności. Drugi, prostszy wykorzystuje tekstury o formacie R11G11B10. Zwiększono tutaj dokładność odwzorowania barwy czerwonej i zielonej do 11 bitów. Informacje o barwie niebieskiej w dalszym ciągu są zapisane z 10-bitową dokładnością.
DX8 SM 1.x | DX9 SM 2.0 | DX9 SM 3.0 | DX10 SM 4.0 | |
---|---|---|---|---|
Instrukcje Vertex | 128 | 256 | 512 | 64k |
Instrukcje Pixel | 4+8 | 32+64 | 512 | 64k |
Rejestry stałe Vertex | 96 | 256 | 256 | 16×4096 |
Rejestry stałe Pixel | 8 | 32 | 224 | 16×4096 |
Rejestry tymczasowe Vertex | 16 | 16 | 16 | 4096 |
Rejestry tymczasowe Pixel | 2 | 12 | 32 | 4096 |
Dane wejściowe Vertex | 16 | 16 | 16 | 16 |
Dane wejściowe Pixel | 4+2 | 8+2 | 10 | 32 |
Liczba renderowanych jednocześnie obiektów | 1 | 4 | 4 | 8 |
Liczba pobieranych przez moduł Vertex tekstur | Niedostępne | Niedostępne | 4 | 128 |
Liczba przetwarzanych przez moduł Pixel tekstur | 8 | 16 | 16 | 128 |
Rozmiar tekstur 2D | Brak | Brak | 2000×2000 pikseli | 8000×8000 pikseli |
Operacje wewnętrzne | Brak | Brak | Brak | Jest |
Pętle wewnętrzne | Brak | Brak | Brak | Jest |
Pochodne | Brak | Brak | Jest | Jest |
Kontrola przepływu operacji Vertex | Niedostępna | Statyczna | Statyczna/Dynamiczna | Dynamiczna |
Kontrola przepływu operacji Pixel | Niedostępna | Niedostępna | Statyczna/Dynamiczna | Dynamiczna |
W efektach 3D – trochę skromnie
W bibliotekach DirectX 10 znalazło się też kilka nowych efektów graficznych. Ich lista nie jest jednak imponująca w porównaniu ze zmianami, jakie były dokonywane w przeszłości. Ponieważ nie jest ich dużo, omówmy je po kolei.
Pierwszy z nowych efektów 3D to Alpha to Coverage. Technika ta służy do wygładzania krawędzi drobnych obiektów znajdujących się wewnątrz półprzezroczystych tekstur. Tekstury takie wykorzystuje się do rysowania siatek ogrodzeń, drutów, przewodów wiszących na słupach czy drobnych roślin – zwłaszcza źdźbeł trawy. Zaletą techniki Alpha to Coverage jest to, że pozwala ona szybko wygładzić krawędzie wspomnianych obiektów bez angażowania dużej mocy obliczeniowej. Antyaliasing wykonywany jest tutaj na małych obiektach wewnątrz tekstury przed nałożeniem ich na scenę 3D. Dzięki temu wygładzone już tekstury zawierające obiekty mogą być wielokrotnie nakładane na scenę. Co więcej, umieszczane są one w pamięci karty i stamtąd w razie potrzeby mogą być wyciągnięte i użyte do mapowania kolejnych scen.
W DX10 zaimplementowany też został ulepszony mechanizm rysowania obiektów w przypadkowych miejscach. Ta technika o nazwie instancing pojawiła już w bibliotekach DirectX 9. Niemniej, głównym usprawnieniem jest teraz to, że rysowane w przypadkowych miejscach obiekty nie muszą już zawierać tych samych tekstur. Podobny w działaniu jest mechanizm proceduralnej symulacji wzrostu (Procedural Growth Simulation). Dzięki tej technice można renderować rośliny należące do wodnych ekosystemów oraz, co ważne, symulować ich wzrost i zachodzące w nich zmiany za pomocą dosłownie kilku instrukcji obsługiwanych przez DirectX 10.
Nowym efektem wprowadzonym do DirectX 10 jest punktowe mapowanie przemieszczeń (Per-pixel Displacement Mapping). Jest to odmiana znanego już z DirectX 8 mapowania kierunkowego (Parallax Mapping). Na początku obliczana jest mapa wysokości, która obrazuje wszystkie nierówności i chropowatość powierzchni obiektu. Mapę tą łączy się następnie z nakładaną na przedmiot teksturą. Punktowe mapowanie przemieszczeń różni się od tradycyjnego mapowania kierunkowego tym, że odwzorowuje nierówności wyłącznie w tych miejscach, które są widoczne dla obserwatora. Dzięki temu jest ona znacznie szybsza, przy zachowaniu porównywalnego efektu końcowego.
Przy okazji efektów 3D warto wspomnieć o przełamaniu w DX10 istotnego ograniczenia, z jakim musieli się borykać programiści korzystający z dotychczasowych bibliotek graficznych. Tym ograniczeniem był limit 500 obiektów jednocześnie wyświetlanych na scenie 3D. Każdy przedmiot, pojazd, postać, roślina, kamień czy zwierzę traktowany jest jako jeden obiekt. W typowych grach nie ma to znaczenia, ale jeśli tylko chcemy odtworzyć gęsty las czy rój pszczół, zaczynają się problemy – liczba obiektów bardzo szybko przekroczy 500. Aby obejść to ograniczenie, programiści stosowali kopiowanie obiektów – kopia i jego obiekt traktowane są jako jeden obiekt, ale tak wygenerowany obraz traci na swoim realizmie. W DX10 nie ma już takich ograniczeń. Oznacza to, że programiści będą w stanie napisać znacznie bardzie realistyczne gry z ogromną liczbą obiektów wyświetlanych na ekranie, jednak aby skorzystać z tej możliwości, musi na to pozwolić wydajność karty 3D.
Trochę porównań
Przy okazji każdej premiery nowych bibliotek graficznych i zgodnych z nimi kart pokazywane są różnego rodzaju dema pokazujące, że na nowym sprzęcie i nowych bibliotekach wszystko będzie dużo ładniejsze i bardziej rzeczywiste. Nie inaczej było tym razem. Pod spodem kilka zrzutów z programów przygotowanych przez polską firmę Techland.
Oraz słynne już zrzuty ekranowe z gry Microsoft Flight Simulator X.
DirectX 9
DirectX10
Wszystkie te porównania są pewnego rodzaju nadużyciem. Równie dobre efekty wizualne można uzyskać na kartach graficznych korzystających z DirectX 9. Programy takie będą działały też z podobną wydajnością na tym samym typie karty zgodnej z DX10. Z punktu widzenia użytkownika nie ma więc różnicy, jakie zostały użyte przez programistę biblioteki. Natomiast duże różnice są właśnie od strony programowej. Po prostu żeby uzyskać ten sam efekt w DX10, programista musi się znacznie mniej namęczyć niż w wypadku DirectX 9. Program powstanie też szybciej. Reszta tak naprawdę jest już czystym marketingiem. Wyjątek stanowią tutaj tylko efekty fizyczne realizowane przez Geometry Shadery. Dużej liczby realistycznych interakcji między obiektami nie osiągnie się w rozsądnym czasie korzystając z mocy obliczeniowej procesora i bibliotek DirectX 9.
Najważniejsze są gry
Na koniec pooglądajmy trochę zrzutów z niektórych przygotowywanych pod DirectX 10 gier. Wszak to one stanowić będą o atrakcyjności dla użytkowników nowych kart graficznych i ewentualnego sensu przesiadki na Windows Vista.
Na początek kultowy już Crysis firmy Crytek (po kliknięciu na obrazkach pojawiają się screenshoty w wysokiej rozdzielczości).
World in Conflict zapowiadany przez Sierra Entertainment to gra, w której programiści na wielu scenach umieszczą znacznie więcej niż dozwolonych w DX 9 500 obiektów.
W Hellgate: London firmy Flagship Studios programiści skorzystali z nowego modelu renderingu HDR.
I na koniec Alan Wake firmy Microsoft Game Studios