Direct3D – między miłością a nienawiścią
Gdybyśmy zebrali dużą grupę programistów w jednym pomieszczeniu i wykrzyknęli „Direct3D!”, reakcje byłyby najróżniejsze. Jedni powiedzieliby: „Świetne narzędzie. Uwielbiam to!”, inni: „Do niczego się nie nadaje!”, a jeszcze inni stwierdziliby, że rządzi „OpenGL!”.
Na początek nieco historii. Gdy do programistów dotarła wersja 1.0 Direct3D, stosowali oni głównie API 3dfx Glide. Glide, z ich perspektywy, był narzędziem łatwym w użyciu. W Direct3D 1.0 posłużono się metodą zwaną buforami wykonawczymi (ang. execute buffers). Owe bufory są pakietami danych, zawierających kompletny opis sceny 3D oraz dodatkowe informacje dotyczące jej tworzenia. Jednak rozwiązanie takie było obce większości programistów gier czasów DOS-a, narzekań i zgrzytania zębami było więc co niemiara. Pozostali programiści przestawili się na Direct3D i zaczęli tworzyć pierwsze tytuły. Inny problem z Direct3D polegał na tym, że interfejs ten był potomkiem API Reality Lab, który został zakupiony przez Microsoft od brytyjskiej firmy RenderMor- phics. Rozwiązanie to było całkiem dobrej jakości programowym narzędziem renderują- cym, wykonującym wszystkie operacje 3D przy użyciu głównego procesora, jednak „nie rozumiejącym” zasad akceleracji sprzętowej, a wykorzystanie go do nowych zadań było trudne zarówno dla Microsoftu, jak i twórców gier, a także samych graczy. Teraz będziemy musieli nieco wytężyć uwagę. Przygotujmy się również na sporą dawkę terminologii, gdyż omawiać będziemy zasady pracy Direct3D. Oczywiście nie damy rady opowiedzieć tu o wszystkim, jednak poznamy podstawy funkcjonowania Direct3D, co z kolei pozwoli docenić trud wkładany przez programistów w napisanie gry 3D. Wykonanie takiej pracy wymaga bowiem średnio dwukrotnie większego wysiłku niż w przypadku gry 2D o podobnym stopniu komplikacji i złożoności akcji. Znając żargon będziemy mogli ponadto lepiej ocenić wymagania stawiane przez wytwórców sprzętu graficznego 3D.