OpenGL vs Direct3D (krótka historia) 23


Wszystkie portale internetowe, które chociażby w niewielkim stopniu interesują się cyfrową rozrywką, co i rusz przekazują nowe informacje od giganta gier komputerowych – firmy Valve, która ostatnimi czasy poczuła wielką miłość do Linuksa i nienawiść do Windows 8. Jednym z takich komunikatów, było niedawno stwierdzenie, że L4D2 po przeportowaniu na Linuksa działa wyraźnie szybciej, niż wersja na Windowsa (której swoją drogą poświęcili znacznie więcej wysiłku). To nie wszystko. Jeżeli na Windowsie skorzysta się z L4D2 wykorzystując port OpenGL, to działa szybciej, niż wersja posługująca się Direct3D (chociaż nigdy i tak nie dogania wersji na Linuksa). Po tym komunikacie internet zaczęły zalewać komentarze stwierdzające, że programiści w wielkich wytwórniach gier muszą być idiotami, że wykorzystują Direct3D. Nie dość, że poświęcają multiplatformowość, jaką niesie OpenGL (nawet niektóre telewizory mają zaimplementowane OpenGL ES), to jeszcze korzystają z API, które jest wyraźnie wolniejsze. Szerokie zastosowanie Direct3D w dzisiejszych czasach nie wynika jednak z zimnego przekalkulowania wad i zalet. Jest to wypadkowa pewnych wydarzeń historycznych, które chciałbym subiektywnie wam przybliżyć w tym artykule.

L4D2

Left 4 Dead 2 na Ubuntu wykorzystuje OpenGL

1. Wyłonienie się stron

Na samym początku lat 90-tych cyfrowa rozrywka była w stadium swojego wczesnego dzieciństwa. Popularność zyskały konsole takie jak SNES (w Polsce dominowała rosyjska podróbka konsoli NES znana jako Pegasus). Programiści tworząc gry kodowali je wprost pod odpowiednie układy tych urządzeń. Miało to sens, gdyż wszystkie konsole danego producenta zbudowane były z tych samych części. W owych czasach najpopularniejszym systemem operacyjnym na rosnące w siłę PC-ty był Microsoft DOS. Początkowo twórcy gier próbowali przenieść sposób tworzenia wprost z konsol na komputery i komunikować się bezpośrednio ze sprzętem. Było to problematyczne. Programiści musieli tworzyć pod różne konfiguracje sprzętowe, co było bardzo trudne. W wymaganiach gier często były wymieniane konkretne części do komputera, co ograniczało rozwój rynku. Problem ten dostrzegł też Microsoft. Ponadto korporacja nosiła się z pomysłem wprowadzenia graficznej nakładki na DOS-a zwanej jako Windows. Podczas gdy DOS pozwalał programistom robić ze swoimi graficznymi aplikacjami co tylko chcą, to Windows wymuszał wkomponowanie się w to środowisko. Zużywał też cenne zasoby, które mogły być wykorzystane przez grę. Żeby zachęcić do pisania gier pod Windowsa, Microsoft postanowił stworzyć jednolite API dla programistów, napisane w języku bardzo niskiego poziomu, żeby nie marnować zasobów komputera oraz zupełnie niezależne od sprzętu. Tak narodził się DirectX. Po roku prac powstał komponent do obsługi grafiki trójwymiarowej – Direct3D, stając się elementem DirectX v3.

W międzyczasie legendarny założyciel idSoftware oraz zwolennik otwartego oprogramowania i Linuksa – John Carmack – przyjrzał się dokładnie API oferowanemu przez Direct3D i stwierdził, że nadaje się ono na śmietnik. W związku z tym zaadoptował inne API, które zostało nazwane OpenGL (Open Graphics Library). Microsoft początkowo myślał, że OpenGL będzie wykorzystywane jedynie przez programy takie jak CAD, a nie gry komputerowe, więc nieświadomy tej potencjalnej konkurencji włączył je do Windowsa 95. Ponadto Microsoft pozwolił na to, że jeżeli karta graficzna ma sprzętowo zaimplementowaną obsługę OpenGL, to można z niej korzystać pomijając wszelkie mechanizmy Windowsa. I tak ku zaskoczeniu wszystkich w 1996 roku idSoftware zdecydowało się na wydanie prawdziwej gry komputerowej z wykorzystaniem OpenGL lekceważąc zupełnie Direct3D. I gra ta miała jak na owe czasy oszałamiającą grafikę. Mowa oczywiście o oryginalnym Quake. To wydarzenie spowodowało gwałtowny wzrost zainteresowania wydawców gier OpenGL. Opiekę nad OpenGL przejęła Architectural Review Board (ARB), która dbała o jego dalszy rozwój.

quake

Quake zwiastował huczne narodziny OpenGL

2. Pierwsza krew

Nadchodząca epoka Windowsa nie zaczęła się jednak od starcia między OpenGL, a Direct3D. W owym czasie firma 3Dfx, zaczęła sprzedawać układy zwane jako akceleratory grafiki 3D z serii Voodoo. Podłączało się je do komputera i karty graficznej i zajmowały się one czysto przetwarzaniem grafiki 3D. Zapewniały niesamowite nowe możliwości. Nie korzystały one jednak ani z Direct3D ani OpenGL. 3Dfx stworzyło własne API (będące de facto uproszczonym OpenGL) zwane jako Glide. Układu Voodoo (szczególnie Voodoo 2) stały się tak popularne, że wiele hitów danej epoki takich jak Turok: Dinosaur Hunter, wręcz wymagało konkretnie ich do działania. 3Dfx jednak nie przetrwało nadchodzących czasów. Glide było mieczem obusiecznym. Z jednej strony prosty interfejs był chętnie wykorzystywany przez programistów, jednak z drugiej szybko wyszły na jaw jego ograniczenia w porównaniu do pełnego OpenGL, dotyczące chociażby ilości wyświetlanych kolorów. Rynek zaczęły też podbojem zdobywać karty graficzne posiadające zintegrowaną obsługę 2D i 3D, które nie wymagały dodatkowych akceleratorów. Sytuacja stała się tak zła, że 3Dfx przed bankructwem ocaliło jedynie wykupienie przez młodego wilka na rynku – NVIDIA.

turok

Po lewej Turok: Dinosaur Hunter, po prawej akcelerator Voodoo 2 podłączony do karty graficznej

3. Początkowe zwycięstwa

Młody wilk rynku kart graficznych – NVIDIA była wielkim zwolennikiem OpenGL i bardzo aktywnie udzielała się jako członek ARB. Zapewniła więc, że wraz z premierą ich układów RIVA TNT w 1998 do specyfikacji OpenGL zostało włączone rozszerzenie GL_ARB_multitexture. W tym momencie zarówno grafiki NVIDIA, jak i OpenGL były zdolne do multiteksturowania, podczas gdy hucznie wydany DirectX 5 tego nie zapewniał. Był to poważny cios, ale tym razem Microsoftowi się upiekło. Multiteksturowanie nie zyskało szybko popularności, gdyż wydajność gier sporo cierpiała na stosowaniu tej technologii.

W 1999 roku NVIDIA wyprodukowała genialną kartę graficzną GeForce 256, która nie miała konkurencji na rynku masowym i była wręcz rozchwytywana. Jedną z ważniejszych funkcji tego układu była sprzętowa akceleracja wierzchołkowych transformacji i świateł (vertex transform and lighting – T&L). Operacje te były już zawarte w specyfikacji OpenGL, po prostu przeniesiono je z programowego przetwarzania na sprzętowe. Microsoft nareszcie wydał DirectX w wersji 6. API było już zdolne do multiteksturowania, ale brakowało mu T&L…

W międzyczasie na rynku gier pojawił się kolejny hit – Unreal Tournament. Grę tę można było uruchomić korzystając zarówno z Direct3D, jak i OpenGL. I co się okazało? Na OpenGL gra wyglądała o niebo lepiej. Z tego powodu kiedy gracz decydował się na zakup karty graficznej patrzył na poziom implementacji OpenGL olewając zupełnie Direct3D.

unreal

Unreal Tournament dobitnie pokazywał wyższość OpenGL

4. Późniejsze porażki

W efekcie swoich porażek Microsoft zrobił coś, czego się nikt nie spodziewał. Osobiście wybrał się do wytwórców kart graficznych, zapytał ich jaką funkcjonalność planują umieścić w swoich produktach i zaczął ją implementować. Zaowocowało to jednoczesną premierą GeForce 3 oraz Direct3D 8. Tym razem nie dość, że API w pełni obsługiwało możliwości tego układu, to jeszcze nadgoniło zaległości względem OpenGL.

Natomiast w obozie OpenGL sprawy przestały malować się tak różowo. ATI wchodziło na masowy rynek układów graficznych ze swoim Radeon 8500 w 2001 roku i też chciało obsługiwać OpenGL. Niestety wiele rozszerzeń tego API było specyficznych dla układów NVIDIA. Co w związku z tym zrobiła ARB? Dodała do specyfikacji nowe rozszerzenia specyficzne dla ATI. W konsekwencji programista, który chciał napisać grę musiał oddzielnie kodować dla grafik NVIDIA i ATI. Spowodowało to pierwszą falę migracji do Direct3D, który pozostawał niezależny sprzętowo.

A że nieszczęścia chodzą parami, to OpenGL zainteresowała się też firma 3Dlabs. Produkowała ona drogie i potężne karty graficzne, ale panicznie bała się konkurencji tanich NVIDIA i ATI. Zaangażowała się ona więc w rozwój OpenGL mając nadzieję na rozszerzenie specyfikacji o możliwości, które będzie można w pełni wykorzystać tylko na jej układach. W konsekwencji tego po długim okresie prac opublikowano OpenGL 2.0. API to jednak nie rozwiązało problemu zależności sprzętowej, a za to wprowadziło język programowania shaderów GLSL. Shadery te pisze się w języku podobnym do C, co z jednej strony może być wygodne dla programisty, z drugiej strony wymagało kompilacji w locie na karcie graficznej, co w konsekwencji znacząco obniżało wydajność. Naturalnie słabsze grafiki ATI i NVIDIA kiepsko sobie z tym radziły, co miało być nadzieją dla 3Dlabs. W międzyczasie Microsoft wydał DirectX 9 i swój własny język shaderów HLSL. Jednak podejście było tutaj zupełnie inne. Korporacja dostarczyła kompilator, który prekompilował shadery na język asemblera. Tak prekompilowane shadery mogły być następnie wykorzystane przez D3D. Różnica była więc taka, że w czasie gry, układ graficzny nie musiał kompilować shaderów, co zapewniało bardzo dobrą wydajność. I to wywołało drugą falę migracji na technologię Microsoftu.

Co się stało z 3Dlabs? Obawy firmy się ziściły i mimo wszystkich tych wysiłków ATI i NVIDIA zupełnie wypchnęły ją z rynku. A teraz zaskakujący fakt. 3Dlabs tak na prawdę miała rację. Dzisiaj język GLSL jest powszechnie stosowany i lubiany właśnie dzięki wysokiemu poziomowi i przenośności. Po prostu technologia ta była zbyt wymagająca jak na ówczesne czasy. 3Dlabs tak bardzo patrzyła w przyszłość, że pokonała ją teraźniejszość.

5. Stagnacja

A więc mamy początki XXI wieku. Producenci gier kolejno odwracają się od OpenGL ze względu na jego wady. Jakkolwiek twórcy sprzętu zaimplementowali w końcu rozszerzenia specyficzne dla konkurencji (często przez emulację), to jednak bardziej to zaszkodziło niż pomogło. Teraz programista chcący skorzystać z OpenGL ma do wyboru kilka rozszerzeń robiących niemalże to samo i nie ma zielonego pojęcia jak jego wybór wpłynie na wydajność gry. OpenGL utraciło swoją główną zaletę – przestało być łatwe w użyciu. W 2006 roku ARB rozszerzyło standard o nowe możliwości publikując OpenGL 2.1, jednak niewiele to zmieniało. W związku z tym postanowiono totalnie przebudować API tak, żeby pozbyć się starych naleciałości wywołujących te wszystkie problemy. Wystartował projekt Longs Peak.

Jak na złość pod koniec 2006 roku Microsoft zaprezentował nowy system operacyjny – Windows Vista wraz z DirectX 10. Ważne jest, że ta wersja API nie została wstecznie przeportowana na bardzo popularnego Windowsa XP (oraz Xboxa 360). Twórcy gier chętnie więc skorzystaliby z innego API dającego możliwości D3D 10. Niestety takiej alternatywy nie było. ARB pracowało nad Longs Peak zupełnie przegapiając tę okazję. Nie pomogły też twierdzenia Microsoftu, że na Viscie nie będzie można korzystać z OpenGL (tuż przed premierą oświadczyli jednak, że tylko żartowali). W końcu zarzucono pracę nad Longs Peak i w 2008 roku opublikowano specyfikację OpenGL 3.0, która zrównywała się możliwościami z D3D 10. Jednak do tego czasu wszyscy wydawcy zauważyli, że programy pisane dla DirectX 9 świetnie działają też na platformie DirectX 10 i wcale nie potrzebują nowego API do robienia gier. Żeby było zabawniej, to mimo olbrzymiej ilości czasu zmarnowanej na tworzenie OpenGL 3.0, specyfikacja ta nadal dziedziczyła wszystkie wady poprzednich wersji.

6. Nowy początek

Wydarzenia ostatnich lat są jeszcze zbyt świeże, żeby spojrzeć na nie z odpowiednim dystansem. Trzeba jednak przyznać, że czas ubiegał raczej pod znakiem status quo. ARB zostało włączone do grupy Khronos zajmującej się pokrewnymi specyfikacjami (OpenCL, itp.). Microsoft wydał D3D 11 na co odpowiedzią był OpenGL 4.0 (też bez fundamentalnych zmian). Programiści olali obie specyfikacje równo, pisząc nadal pod DirectX 9.

Są jednak sygnały, że sytuacja ta może radykalnie się zmienić. Twórcy gier są już trochę zmęczeni ograniczeniami D3D 9 i OpenGL 4 wydaje się naturalną alternatywą zapewniającą kompatybilność nawet z Windowsem XP. Coraz więcej wydawców romansuje z tym API. Silnik Unigine został zaprojektowany tak, żeby wycisnąć siódme poty z najnowszego OpenGL, Blizzard przygotował porty Starcraft II i Diablo III na Maca korzystając z OpenGL, silnik Unity3D przeportowano na to API, idSoftware nigdy nie porzucił tej technologi, a teraz Valve jest zachwycone osiągnięciami Source na OpenGL. Google forsuje wdrażanie w sieci WebGL pozwalający na pisanie programów 3D z wykorzystaniem OpenGL, które będą się odtwarzać w przeglądarce, na co Microsoft nie ma w zasadzie żadnej odpowiedzi.

Jednak zwiastuna najpoważniejszych zmian należy szukać w rewolucji mobilnej, którą przechodzimy. Pamiętajmy, że OpenGL to nie tylko Linux, ale wszystkie platformy włączając w to Maca i inne iGadżety. Na rynku mobilnym Microsoft właściwie już nie istnieje i mimo dramatycznych działań korporacji nikt poważny nie spodziewa się radykalnych zmian. Rozrywka mobilna rozkwita, a firmy produkujące gry AAA na te platformy (takie jak Gameloft), piszą wyłącznie z wykorzystaniem OpenGL ES (ES oznacza Embedded Systems i jest to uproszczone OpenGL na urządzenia przenośne). Co więcej wszyscy się spodziewają, że na mającym się zacząć lada dzień SIGGRAPH 2012 grupa Khronos zaprezentuje specyfikację OpenGL ES 3.0, która zrówna potencjał urządzeń mobilnych z dzisiejszymi konsolami. Co do wad samej specyfikacji. No cóż najprawdopodobniej nigdy nie zostaną usunięte. Czemu? Co robi nowy programista, gdy zamierza nauczyć się pisać gry 3D? Zagląda on w otwarty kod silników idTech (różnej generacji) udostępnionych przez idSoftware i korzystających z OpenGL. Dzięki tym silnikom internet jest pełen poradników i przykładowego kodu jak korzystać z OpenGL. Naprawa pierwotnych problemów OpenGL oznaczałaby zerwanie wstecznej kompatybilności i utratę tego wszystkiego. Na coś takiego grupa Khronos nie może sobie pozwolić. Jeżeli chodzi natomiast o różne sposoby robienia w OpenGL tego samego, to idę o zakład, że metody stosowane w idTech są najwydajniejsze i programiści powinni się tego trzymać. Tak więc największe przekleństwa OpenGL stały się jego największymi zaletami.

Unigine

Unigine prezentuje niesamowite możliwości dzisiejszego OpenGL

A wy jak uważacie, co przyniesie przyszłość?

Źródło:
http://programmers.stackexchange.com/questions/60544/why-do-game-developers-prefer-windows



Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

23 komentarzy do “OpenGL vs Direct3D (krótka historia)

  • kwahoo

    OpenGL ES 3.0 i OpenGL 4.3 zostały właśnie zaprezentowane. Co ważne ES 3.0 całkowicie mieści się w GL 4.3. Teraz jedyne co brakuje w ES 3.0 to chyba tylko Geometry Shaders, no ale Adreno 3xx (Snapdragon S4 Pro) ich nie obsługuje, to trudno domagać się wprowadzenia do specyfikacji.

    Nie zgodzę się, że UT99 pokazywał wyższość OGL nad D3D. Były porównywalne a OGL miał status eksperymentalnego. Dopiero teraz OGL oferuje więcej, po wielu, wielu updatach. UT pokazywał wyższość niskopoziomowych API (Glide, MeTaL).
    W tym miejscu powinien być wspomniany pierwszy Serious Sam. Wspierał zarówno OGL jak D3D, ale w tym pierwszym przypadku liczba kl./s była jakieś 2x większa. Miał osobne profile dla każdej z kart graficznych i w moim odczuciu ośmieszył id Tech 3 pod względem wydajności jak i jakości grafiki (kto pamięta poziom testowy z czajniczkami?).

    Podejrzewał, że schyłek popularności OpenGL w grach widać najlepiej w latach 2003-2005:
    2003 – Unreal Tournament 2003, wspiera OpenGL, ale to Direct3D jest domyślny
    2004 – Far Cry, j.w.
    2004 – Doom 3, ostatni Mohikanin, wspaniała grafika na OpenGL, ale zapamiętany jako wymagający mocnego sprzętu, „plastikowy” i bez otwartych przestrzeni,
    2004 – Half-Life 2 na silniku Source (prezentacja z 2003 roku http://www.youtube.com/watch?v=4ddJ1OKV63Q ), wspiera wyłącznie Direct3D i oferuje to czego chcą gracze (mimo, że nie ma zunifikowanego oświetlenia jak w Doomie): niskie wymagania, otwarte przestrzenie, bardzo realistyczne modele,
    2005 – F.E.A.R. oferuje to samo co Doom, ale używając D3D.

    Jednak sytuacja nie jest taka zła. Obecnie OpenGL oferuje nieco więcej Direct3D 11.1, ma podobną wydajność (która zależy głownie od implementacji), a niemal każdy silnik (Unity 4, Cry Engine 3, Unreal Engine 3, Serious Engine 3.5, Source) ma przynajmniej eksperymentalne wsparcie OpenGL.

    Przy okazji anegdotka (mogę poszukać źródła): jeden z programistów Serious Engine 3 został zapytany, dlaczego jeszcze używają D3D9. Stwierdził, że D3D11 zachowuje się nieprzewidywanie, i musieliby zamrozić kod na kilka miesięcy przed premierą, na co mogą pozwolić sobie największe studia.

  • darekry

    ktoś może powiedzieć, jak wygląda sprawa kompatybilności na starszym sprzęcie? jeżeli jakaś funkcja nie jest obsługiwana przez kartę, to jest emulowana przez procesor/GPU? Czy po prostu starsza karta nie będzie obsługiwać OGL 4.xprocesor/GPU

    Czy wersja ES to tylko okrojona wersja pełnego API OpenGL? czy wszystkie wywołania z es znajdują się w pełnej wersji?

  • dweller

    [quote comment=”50579″]ktoś może powiedzieć, jak wygląda sprawa kompatybilności na starszym sprzęcie? jeżeli jakaś funkcja nie jest obsługiwana przez kartę, to jest emulowana przez procesor/GPU? Czy po prostu starsza karta nie będzie obsługiwać OGL 4.xprocesor/GPU

    Czy wersja ES to tylko okrojona wersja pełnego API OpenGL? czy wszystkie wywołania z es znajdują się w pełnej wersji?[/quote]

    W przypadku OS X, jeżeli karta nie obsługuje jakiś opcji OpenGL to shader jest automatycznie rekompilowany z zastosowaniem dostępnych rozszerzeń. Działa wolniej, ale w dalszym ciągu zachowuje kompatybilność.

  • kosmos

    Hmm… OpenGL 4.3 wydane, a Mesa go wspiera? Mesa nie wspiera jeszcze OpenGl 3:] A co do programowania gier. Problem były oczywiście patenty, i S3TC, który był jak garb na plecach. Dla mnie rewolucją jest wydane przez Khronossa ASTC, to jest rewolucja której brakowało. Ale M$ nie śpi, i dobrze, bo napędza to rynek.

  • Hemicuda

    Warto może wspomnieć o tym, że Microsoft całkowicie uniemożliwił użycia OpenGLa w WinRT (czyli Metro pod Win8) i jako jedyne słuszne API graficzne uznał DX11.1 i Direct2D. Oznacza to, że nie będzie aplikacji OpenGLowych na tablety/komórki z Win8.

  • Andy

    Co to za durna moda – rodem z jakichś Plotków itp – pytania w ostatnim zdaniu „A wy jak uważacie”? Przecież wiadomo po co są komentarze.

  • laybythesea

    [quote comment=”50591″]Co to za durna moda – rodem z jakichś Plotków itp – pytania w ostatnim zdaniu „A wy jak uważacie”? Przecież wiadomo po co są komentarze.[/quote]
    Bardzo nam przykro, ale niestety nie czytamy plotków i nie wiemy, że panuje tam taka durna moda.

  • MST

    Dobry art, jak za czasów starego CHIPa, gdy miał 2 razy więcej stron i był o połowę tańszy ;).
    Pamiętam fajny artykuł o właśnie rewolucji GeForce 256.

  • xxx

    [quote comment=”50586″]W trakcie czytania tego tekstu miałem uczucie Déjà vu.
    Nawet wiem czemu:
    http://programmers.stackexchange.com/questions/60544/why-do-game-developers-prefer-windows
    Dlaczego w tekście nigdzie nie ma o tym gdzie był oryginał?[/quote]

    Prawie od razu stwierdziłem to samo, bo mam ten artykuł w zakładkach. Ciekawe jak wytłumaczą się autor, a także założyciel serwisu. Doceniam wysiłek włożony w przełożenie, ale przypisywanie sobie autorstwa jest żałosne, chyba że to po prostu zwykłe niedopatrzenie. Czekam na sprostowanie i przeprosiny.

  • Zgred

    > wersja utylizująca Direct3D

    >Co proszę? http://sjp.pwn.pl/szukaj/utylizować

    >Tu nie chodzi o słowo „utylizowac” a o „utylitarny” pisze sie je tak samo ale maja rozne znaczenia. Jak juz podajesz linki to chociaz badz pewien ze odnosza sie one do zagadnienia. http://www.slownik-online.pl/kopalinski/A556A5EF62568DB4412565B1004FEEF5.php

    Nie pisze się tak samo! W takim razie musi być:
    UTYLITARYZUJĄCY a nie utylizujący
    UTYLITARYZOWAĆ a nie utylizować
    To błąd, może w angielskim pisze się tak samo, ale nie po polsku!
    Utylitaryzować = czynić dostępnym dla każdego, jednorodnym, ujednolicać, etc. (ale trochę to wygląda jak nowotwór słowny)
    Utylizować = czynić nieszkodliwym, unicestwiać, etc. np. śmieci.
    Po co słownik, tylko gramatyka to tłumaczy. Szkoła podstawowa…

  • Sanjuro

    Ale tu bzdur wypisanych… Mam wrażenie, że jakiś dzieciak pisał który nie pokwapił się aby poduczyć się historii akceleratorów i procesorów graficznych (vide upadek 3dfx’a, który w artykule jest stekiem bzdur i nie wiem co niby miał glide do upadku firmy…) i na dodatek przekonany że linux to jedyny słuszny system.

  • makson Autor wpisu

    @kwahoo
    Co do Unreal Tournament. Nie mogę znaleźć w necie screenów porównujących OpenGL i D3D. Jednak posłuchaj Ryana Gordona (przeportował na Linuksa między innymi Prey i większość HiBów):
    http://blip.tv/flourish-conference/gaming-on-linux-5005409
    38:45

    @azhag
    Chyba nie ma sensu, żeby połowa komentarzy dotyczyła tego jednego słowa, więc je zmieniłem.

    @dweller
    Wydania punktowe są na ogół implementowane w nowych sterownikach do obecnej generacji układów. Zupełnie nowe wersje OpenGL wymagają natomiast nowego sprzętu.

    @kosmos
    Mesa 8.0 znajdująca się w Ubuntu 12.04 wspiera OpenGL 3.0 (z pewnymi ograniczeniami związanymi z patentami, ale nie są one nie do obejścia). Natomiast wersja wprost z drzewa git wspiera już OpenGL 3.1. Więc otwarte stery nadganiają specyfikację. Swoją drogą nie przychodzi mi do głowy żadna gra na Linuksa, która miałaby minimalne wymagania większe niż OpenGL 3.0.

    @Hemicuda
    Nie wiedziałem o tym. Microsoft może jednak tak sobie bardziej zaszkodzić niż pomóc. Jeżeli jakaś firma będzie chciała wydać hit na tablety, to w pierwszej kolejności wykonają go na iPada (z wykorzystaniem OpenGL ES). Jeżeli będą potem problemy, żeby przeportować na Windows RT, to takiego portu się po prostu nie przygotuje.

    @Tomahawk
    Niedopatrzenie. Poprawiłem.

    @Potfur
    A jak uruchamiasz najnowszą grę, która korzysta z D3D na Windowsie XP, to którą wersję tego API wykorzystuje? Dodam jeszcze, że wszystkie najnowsze gry ciągle wspierają Windows XP.

  • Luki_2

    Ktoś tu sobie żartuje, czy faktycznie oczekuje tego, aby grać wydajnie na otwartych sterownikach?
    Od grania są sterowniki zamknięte 😉 Nieważne jak byłyby niedorobione – znacznie przeganiają wydajnością otwarte sterowniki.

  • wartosciowatresc

    Poniższy tekst jest to komentarz Damiana Szymańskiego z serwisu http://www.benchmark.pl z pod artykułu „Gra Left 4 Dead 2 na Linuksie i w OpenGL jest znacznie wydajniejsza niż na Windows w DirectX” link: http://www.benchmark.pl/aktualnosci/left-4-dead-2-gra-valve-linux-opengl-widows-directx-wydajnosc.html

    Może niekoniecznie był w tyle, ale mimo wszystko może nieznaczenie odstawał. Na jego spadek popularności duży wpływ miał Microsoft.
    Jeżeli ktoś nie pamięta to przypominam – rok 2005.
    Microsoft rozpoczął popularyzację swojego API, w dodatku kampanie dla Xboxa i Visty. MS dał wiele kasy na promocję i zbudował wizerunek, że jest to jeden i słuszny interfejs, działający najlepiej. Powstawało błędne koło, w dodatku MS rozpoczął rozsiewanie tzw. FUD. Czyli strach, niepewnej przyszłości i różnych wątpliwości w stosunku do OpenGL. Jednocześnie promując swój DX. To wywołało po prostu niechęć.

    Microsoft opuścił OpenGL Architecture Review Board, twierdząc, że ich interesy tu dobiegły końca i OGL nie ma przyszłości. Następnie z okazji premiery Visty, mieliśmy kłamstwo, ze Vista porzuci wsparcie dla OpenGL, zachowując jedynie wsteczną kompatybilność z OGL z XP – no i to wystarczyło aby pojawiła się panika wśród deweloperów OpenGL, którzy panicznie przerzucali się na DX, który oferował wówczas różne szkolenia i materiały pomocnicze. Wówczas doszło do tego, że zwolniło wsparcie producentów kart graficznych i stery stawały się powoli gorsze. Dodatkowo MS pokazywał slajdy z porównaniami DX do OpenGL w których D3D wypadał znacząco lepiej, graficznie i wydajnościowo – OGL przestawiano jako stary i archaiczny rupieć. Kiedy wyszła Vista okazało się, że to co robił MS było nieprawdą i Vista miała OpenGL, wówczas stowarzyszenie OGL rozsyłało sprostowania ale one już do nikogo nie trafiły bo MS

    Wówczas było już za późno bo wiele osób porzuciło OGL inni zaś stracili zaufanie po akcji MS, rozsiewającej FUD. Dzisiaj już jest nieco lepiej. Sytuacja się zmienia, jest grupa Khronos promująca standard. OGL oferuje podobne możliwości do DX, niektóre zostały wprowadzone jeszcze wcześniej niż w DX, jak chociażby tesselacja. Zauważcie w nowe DX nie działają w XP no bo? Się nie da. Tymczasem OGL działa ze wszystkimi efektami i tesselacją na XP.

    Sprawa jest prosta OGL znacznie szybciej renderuje i rysuje obrazy niż DX11, w dodatku pozwala na tworzenie dokładniejszych obrazów i to przy zachowaniu niższych wymagać sprzętowych.

    OpenGL jest w tyle, bo dużo ludzi od niego odeszło, spadło zainteresowanie, dev przerzucili się na DX i gry nie powstawały w OGL.

    Tutaj porównanie OGL VS DX
    http://www.youtube.com/watch?feature=player_embedded&v=HC3JGG6xHN8
    http://www.youtube.com/watch?feature=player_embedded&v=HZnua9zkraM