Piekło zamarza, a fani czterech kółek już niedługo będą mogli migrować na Linuksa. Na parę miesięcy przed premierą, deweloperzy ze studia Slightly Mad znaleźli wydawcę dla swojego najnowszego projektu: Project CARS, po czym ponownie potwierdzili premierę dla SteamOS i Linuksa. Realistyczna gra wyścigowa będzie stanowić konkurencję wobec dotychczasowych symulatorów z górnej półki.
Brytyjski zespół specjalizuje się w tworzeniu gier wyścigowych od paru lat. W portfolio firmy znajdziemy między innymi wysokobudżetowe gry pokorju Need for Speed: Shift czy Test Drive: Ferrari Racing Legends. Jednak w odróżnieniu od nich, Project CARS tworzony jest w dużej mierze przez zwykłych graczy i amatorów motoryzacji, zrzeszonych na platformie World of Mass Development.
Współpraca ze społecznością jest dość innowacyjna i daje nadzieje na spory sukces. Tysiące testerów zagrywa się we wczesne wersje gry, zgłaszając napotkane błędy i przesyłając swoje sugestie odnośnie dalszego rozwoju. Dzięki temu tytuł ma być zoptymalizowany zarówno pod potrzeby profesjonalistów i weteranów, jak i nowicjuszy.
W grze znajdziemy aż dziesięć trybów, w tym oczywiście rywalizację przez internet w pojedynkach jeden na jednego lub tworząc własne zawody. Najbardziej rozbudowany tryb stanowi naturalnie kariera. Rozpoczynając od wyścigów gokartami zaznajamiamy się ze środowiskiem i zdobywamy doświadczenie, by później wziąć udział w zawodach z prawdziwego zdarzenia. Co ważne, twórcy oddali w nasze ręcę kilkanaście ścieżek rozwoju, różniących się typem wyścigów czy warunkami jazdy. Każdy powinien znaleźć coś dla siebie, niezależnie od tego, czy jest fanem prestiżowego 24h Le Mans czy woli rozbijać się w rajdach po bezdrożach.
Zważywszy na to, że do wyboru mamy całą masę skrajnie odmiennych dyscyplin, liczba pojazdów jest dosyć duża. Do naszej dyspozycji oddano zarówno superszybkie bolidy, jak również samochody turystyczne i sportowe. Każdy z nich ma indywidualne właściwości i sposób jazdy, co jest nie lada fenomenem. Jak na symulator przystało, każdą maszynę możemy również modyfikować – możliwości zmian nie ograniczają się tylko do koloru naszego rumaka, ale także jego szczegółowych parametrów. Jako hołd dla wiernych zapaleńców, w grze znalazły się również rzeczywiste tory, jak chociażby Brands Hatch czy Connecticut Hill. Przeniesione co do najdrobniejszych detali z naciskiem na nawierzchnię.
Poza zaawansowaną fizyką i sandboksowym klimatem, Project CARS może pochwalić się również świetną oprawą audiowizualną. Co najważniejsze gra oddaje poczucie prędkości, pogoda zmienia się dość dynamicznie, a załączone do gry pojazdy do złudzenia przypominają ich odpowiedniki – z zewnątrz jak i wewnątrz. Premiera planowana jest na listopad tego roku na PC, SteamOS i konsole Playstation 4 oraz XBox One.
Michał Patejko liked this on Facebook.
Krzysztof Hajd liked this on Facebook.
Gra zostanie wydana również na Wii U.
Symulator wyścigów Project CARS zostanie wydany na Linuksa | OSWorld.pl http://t.co/QhMh5Fg82S via @OSWorldpl
Aż boję się o wymagania sprzętowe (szczególnie w przypadku mniej wydajnych środowisk jak Unity) :-) Hmm…może to też skrzywienie z poprzednich lat, ale zastanawiam się też, czy sterowniki graficzne będą na tyle dopracowane, aby ruszyły te cudo :-) Dopiero Steam pokazał, jakie tyły siedziały w tej materii :-/
Co ma środowisko do wydajności? Jeśli tylko umie wyłączyć efekty 3D (jak KDE, które wykrywa aplikacje pełnoekranowe i zawiesza na ten czas kompozycję), to gra będzie działać wszędzie tak samo.
Steam(OS) pokazał, że nVidia dostarcza świetne sterowniki i działa na Linuksie identycznie jak na Windowsie, a reszta producentów daje dupy i olewa swoich klientów. Nie uogólniaj, bo kłamiesz.
No ma sporo do wydajności – nie wiem jak teraz, na tę chwilę, w tym momencie, na najnowszym wydaniu Unity (Ubuntu), ale niejeden post w sieci jest w stylu „gra na Unity się tnie, na KDE jest OK – co robic?”. Nie brakowało też na Phoronixie tematów, że wydajność Unity miast wzrastać, to minimalnie maleje (gry). Ale to czasy 2011-2013 i podkreślę, że nie wiem, jak dziś. Mnie samemu gra X potrafi działać gorzej niż pod GNOME3 (a ten typ też wali efektami). Natomiast KDE4 też nie miało od zawsze bodaj opcji zawieszania efektów przy aplikacjach pełnoekranowych ;-) Jednak zgoda – wyłączanie efektów podnosi wydajność i to fakt.
O ile sobie przypominam, to portując Left 4 Dead 2 na Ubuntu, Valve niejednokrotnie kontaktowało się z NV w celu poprawy driverów pod grę. Więc to nie jest tak, że NV od zawsze miało dobre sterowniki i nie trzeba było żadnych poprawek. Pewnie, że było trzeba, ale tak działa ta machina. AMD jest sinusoidą (niektórzy twierdzą, że działa), Intel rewelacją nie był i rewolucji też nie ma (po prostu działające sterowniki i tylko tyle, bo nikt też nie kupuje IntelHD z myślą o hardcorowym graniu). Oczywiście zgodzę się z tym, że chcąc grać, to NVidia bez dwóch zdań. Dla casuala (jak dla mnie) Intel starczy i pozwoli pograć w coś tam ;-) Posiadanie ATi (2 układy) wspominam właśnie najgorzej – póki były Catalysty było OK, otwarte do dziś kuleją w grach ;-P
Słowo „kłamiesz” w argumentach zawsze mnie bawiło – to statystycznie chyba jedno z najczęściej występujących słów w przypadku sprzeczek linuksowych ;-) A jedynej, „prawdziwej prawdy” nie ma, bo każdy ma własny punkt widzenia, bliższy niż dalszy stanowi faktycznemu, który też ma wiele czynników na niego wpływających ;-)
Unity nie znam więc się nie wypowiem. Pod KDE moje projekty jak i inne wykorzystujące OpenGL działają wydajniej niż pod Windowsem. Więc dla użytkowników KDE (lub SteamOS bez środowiska włączonego na starcie) powinno być lepiej niż na windowsie (jeśli jeszcze atuty OpenGL zostaną wykorzystane to Windows będzie dużo gorszą platformą do grania w tą grę).
Portując L4D2 do OpenGL (nie na ubuntu, bo to nie miało znaczenia), Valve kontaktowało się z Nvidią, AMD i Intelem. Głównym powodem było to, że programiści byli zieloni w OpenGL i łatwiej im się uczyło mając kontakt do twórców sterowników do obrania optymalnej ścieżki (a i tak od niej byli ostatecznie daleko). Taki kontakt to nic dziwnego, bo przy każdej większej firmie kontakt z producentem sterowników jest bezpośredni również w sprawie sterowników DX. Sam mam kontakty do twórców sterowników OpenGL Nvidii, AMD i Intela (stery zamknięte na Windowsa).
Dlaczego mówisz, że póki były Catalysty? Przecież dalej są (chyba, że mówisz o starym sprzęcie, który do gier i tak się nie nadaje więc nie powinno się nawet o nim wspominać w kontekście nowej gry, wyciskającej 7dme poty z najnowszych GPU) i co więcej są dobre – ofc są miejsca gdzie nie trzymają się specyfikacji, ale są dużo lepsze niż jeszcze kilka lat temu i obecnie nawet nowości wspierają (łącznie z bindless textures od Nvidii).
Sterowniki Nvidii (wzorcowe) i AMD (dobre) dają radę i są to te same sterowniki co na Windowsie (dosłownie ten sam kod sterownika co do linijki tylko podpięcie pod jądro inne).
Za to Intel pod Linuksem (pod Windowsem jest taki sobie, ale pod linuksem jest tragedia) i otwarte sterowniki AMD/Nvidia są zupełnie do niczego – nawet nie ma co o nich wspominać, bo wsparcie dla nowości nie istnieje (dobrze nie wspiera nawet OpenGL 5 lat wstecz), są wolne i mają masę bugów.
Podsumowując mamy dwie firmy z zamkniętymi sterownikami, które do gier się nadają (te same sterowniki dokładnie wykorzystują też pod Windowsem jak Rage czy Wolfenstein: The New Order i inne korzystające z OpenGL) i otwarte (niezależnie od firmy), które nie nadają się do niczego w 3D. W praktyce odpadają integry Intela i bardzo stare karty, ale te twórcy gier i tak olewają.
Miałem 2 generacje ATi:
– 7500 Mobile: podobno nigdy nie było własnościówek. Do roku 2012 (potem sprzedałem tego lapka) – drivery otwarte ledwo ruszały Unreal Tournament 99 (na zmniejszonych detalach). Pod Windows grałem na tej karcie w Mount&Blade, Half-Life 2, GTA III, BloodRayne itd. Układ był starty, to prawda, ale maksymalnie dam 40% w porównaniu do Windows
– ATi X1250. Nabyłem w 2007 ze stacjonarką. Fajny układ nie narzekałem – integra, ale DOOM’a 3 pociągnęła nawet na Ultra (nieco mniej FPS, ale bez problemu). Nie miałem zastrzeżeń – Catalysty co prawda sprawiały, że czasem obraz migotał podczas włączania czegoś (Catalysty 9.3), ale było spoko. W 2009 układ wpadł do Legacy i od tego czasu – nawet dziś w Super Tux Kart potrafią znikać tekstury albo pojawiał się wielobarwne, tęczowe plamy. O czymś bardziej zaawansowanym jak Half-Life 2 nie ma mowy (na Catalystach przez Wine czy Windows, bez problemu). Układ swój wiek ma, ale to nie robota, żeby gonić tylko za najnowszymi układami z driverami otwartymi, żadnego nie doprowadzając do ładu.
Teraz mam Intela HD (jedne źródła podają, iż mam HD 2500, inne 3000). W sumie gry działają, choć miałem 2 zaciachy. Anomaly 1 – podobno wspiera Intel HD, a ja nie widzę tesktur, tylko brązowe tło. Anna: Extended Edition natomiast niby nie wspiera Intel HD, pod Linuksem schrzaniony obraz a pod Windows śmiga (co świadczy o tym, że tam drivery są zwyczajnie lepsze). Czy naprawdę te drivery są aż tak złe? :-(
Podstawowy problem jaki masz to to, że traktujesz otwarte sterowniki jako jakąkolwiek opcje, a tak nie jest. 7500 nie miał wsparcia pod Linuksem i tyle – równie dobrze mogłeś na sterownikach vesa pracować. Catalisty za czasów tak odległych były żenująco słabe, ale były. Otwarte sterowniki nie są żadną opcją… opcją lepszą jest używanie ostatnich catalistów jeśli chcesz grać (niestety wiąże się to ze starym kernelem i Xami). Nie licz na to, że otwarte sterowniki będą opcją dla graczy, bo nie będą.
To jakiego HD masz zależy od procesora – jeśli jest z rodziny SandyBridge (seria 2k) to mają HD2000 lub HD3000, jeśli jest to seria IvyBridge (seria 3k) to jest to HD2500 lub HD4000, a jeśli jest to Haswell to HD4x00 (x równe lub większe od 2), HD5000 lub seria GPU Iris.
Anomaly nie wspiera Intelów pod Linuksem (otwarte stery) podobnie jak większość innych gier. Intel ma działające (może dobre nie, bo gorsze niż Nvidii czy AMD… ale lepsze niż Apple) zamknięte sterowniki OpenGL pod Windowsem, ale ich nie chce udostępnić (nawet w zamkniętej formie na Linuksa – po prostu Intel postanowił, że gracze są tylko na Windows, a Linuksowe sterowniki są dobre kiedy da się zobaczyć konsolę). Intel postanowił wspierać jedynie sterowniki pod Windowsem, a Linuksa olać (tzn oddelegować kilka osób, które posklejają sterowniki z kilku „gotowych” projektów (jak Mesa – parodii implementacji OpenGL) i będą mogli mówić, że sterowniki są).
PS. tu masz co jakiś czas aktualizowany status sterowników do których Christophe Riccio dodał ostatnio testy Mesy (Intel Linux – ale dotyczy to też innych sterowników otwartych (bo wszystkie się na mesie opierają)). Powiedzieć, że to sterowniki słabe to jakby skłamać – sterowniki słabe to ma Apple które doprowadzają programistów do furii. O otwartych sterownikach OpenGL najlepiej powiedzieć, że ich wcale nie ma (bo to jest bliższe prawdy).
http://www.g-truc.net/doc/OpenGL%20status%202014-05.pdf
Z jakich dokładnie sterowników otwartych korzystałeś źe masz aż tak złe zdanie o nich?
Niestety za dużo ze względu na wykonywany zawód (programista silnika graficznego OpenGL) – Intel HD3000, Intel HD4000, Radeon HD5k, Radeon HD8k (GCN), Nouveau (Fermi, Kepler). Dodatkowo oparte o ten sam kod otwarte sterowniki mobilne – Lima (ARM Mali), Freedreno (Adreno).
O żadnym z tych sterowników dobrego słowa powiedzieć nie można.
Za to ja od strony end usera mam o r600g nie najgorsze zdanie. Przeszedłem na nich Metro Last light. I grałem w kilka innych gier. Niedługo sprawdzę czy poprawili spadki fps podczas ruszania się w Painkiller. Alę ci muszę przyznać to to że poprawne przełączanie stanów gpu dopiero „niedawno” naprawili. radeonsi także radzi już sobie nie najgorzej. Te dwa to chyba najlepsze otwarte sterowniki. Także mógłbyś im się znowu przyjrzeć ;D. http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt w tym roku powninna (przynajmiej dla intela) wpaść obsługa opengl4.0+
Z R600g miałem nieprzyjemność wczoraj, a z RadeonSI tydzień temu (co dwumiesięczna analiza czy jest sens się z tymi sterownikami babrać – dalej nie ma to sensu). Co do tego linku to właśnie tak to wygląda – napiszą, że coś działa bo papier przyjmie wszystko… ba nawet sterowniki zgłaszają, że dane rozszerzenie wspiera, ale co z tego, gdy chcesz użyć to okazuje się że nic nie działa, albo działa ale niezgodnie ze specyfikacją i trzeba robić hacki „jeśli to Mesa to nie rób tego w OpenGL a po „Mesajańsku””
Metro LL jest ogólnie śmiesznym portem – tragicznie napisane shadery OpenGL, słaba wydajność, wykorzystanie OpenGL rodem z serii 2.x… (jeśli dobrze pamiętam nie wykorzystuje nawet instancingu (otwarte sterowniki zwracają, że obsługują… ale niestety błędnie i na poprawnym kodzie się wywalają)… przyznasz, że rozszerzenie z 2006 roku i wymagające OpenGL 2.0 to coś co przydałoby się już wspierać poprawnie?) i wszystko po to, aby otwarte sterowniki jako tako dawały radę… hell yeah.
Jakie distro i wersja mesy?
Distro nie ma znaczenia, ale r600g slackware, a radeon si na Arch. Mesa 10.2.2.
O nie!!! Czy to oznacza koniec dla Tux Racera????????
Nie. To tylko zdrowa konkurencja. Raczej ma małe szanse wygryźć TuxRacera z rynku, ale dobrze, że jest, bo wzajemnie będą napędzać swój rozwój.
Torcs też może się schować, idą dla niego chude lata ;-) Vdrift pewnie też ;-)
TuxRacer to w ogóle dziwnie się ostatnio zachował w kwestii silnika. Zamiast użyć jakiegoś dostępnego na rynku, to zaczęli nie wiadomo po co pisać od podstaw własny. Zero w tym logiki, a ile zasobów i się marnuje niepotrzebnie :/
Może goście, którzy to pisali to ten sam typ co wielu czytelników Warsztatu ;-) . Zamiast użyć gotowych rozwiązań, wymyślają koło od nowa i nie dość, że tracą czas, to ich własne „rozwiązania” chodzą gorzej niż te gotowe.
Oj tam, Warsztat to produkcja silników, a nie gier :) Zresztą zawsze mnie ciekawi dlaczego tacy ludzie nie zbiorą się razem i nie zrobią jednego porządnego, wieloplatformowego silnika. No ale jak widać, niektórzy tak lubią.
To brak pewności siebie. Tacy ludzie boją się, że używając innych rozwiązań nie zostaną wystarczająco docenieni.
Taki przykry syndrom degradujący możliwość osiągnięcia celu normalnym kosztem.
Dotyka ludzi z kiepskim dzieciństwem, albo absolwentów polskich placówek oświatowych ;-).
Raczej jest wręcz przeciwnie – za mozolne pisanie tak niskiego poziomu nie dostaje się pochwał, ani oklasków. To po prostu inna droga kariery – programista silnika zarabia więcej niż programista skryptów (a do tego się sprowadza korzystanie z silnika gotowego). Wykorzystanie gotowego silnika to szukanie szybkiej chwały, a programowanie silnika to nauka która procentuje po latach i to bez aplauzu.
OFC w wypadku ludzi którzy chcą zrobić grę pisanie silnika jest podejściem niezbyt mądrym. Dla kogoś kto chce za to napisać silnik (a takich osób jest chyba nawet więcej niż tych pierwszych wśród programistów, bo tworzenie gry mniej bawi programistę niż tworzenie silnika) wykorzystywanie gotowego jest jeszcze mniej sensownym krokiem (warto po prostu wiedzieć co się chce robić).
A kogo obchodzi tux racer? :P
Andrzej Sitkiewicz liked this on Facebook.
Co oznacza wyrażenie „sandboksowym klimatem” ? Co ta gra ma sandboxowego ?