Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

STEAM - co z wersją dla Linuksa?

Witam, postaram się nie rozpisać za bardzo (wiem, że nie każdy lubi zbyt długie teksty), a jednocześnie opowiedzieć jak to było z tym STEAMem dla Linuksa.

Oferta pracy

Wszystko zaczęło się od oferty pracy na stanowisko Senior Software Engineer w którym jednym z zadań było tworzenie Linuksowego portu gier napisanych dla Windows.

Link do oferty:http://www.valvesoftware.com/job-SenSoftEngineer.html

Archiwalnie zrzut ekranu:http://img145.imageshack.us/img145/3649/valvesoftwareengineer.png

Pojawiło się pełno teorii jako, że Valve Software zamierza wydać oficjalnego klienta jednej z największych platform do grania - STEAM.

Przeportowanie STEAM dla MacOSX

MacOSX tak samo jak systemy oparte o Linuksa używają X11 oraz OpenGL dlatego sprawa z tymi dwoma rzeczami już jest załatwiona, co jeszcze stanęło na drodze portu dla Linuksa?

Oto lista podobieństw oraz głównych różnic tych dwóch systemów: - Inna biblioteka graficzna (GTK/QT dla Linuksa, "Cocoa/Carbon?" dla MacOSX) - Inne jądro - Inny domyślny podsystem graficzny w MacOSX + Ten sam podsystem wyświetlania grafiki 3D, mowa o OpenGL + Obydwa systemy są Uniksopodobne, podobne założenia, "wszystko jest plikiem" + To samo środowisko skryptowe czyli bash jako domyślna powłoka stąd jeden launcher dla dwóch systemów

Jednym z ważnych dowodów na to, że Valve "po cichu" tworzy klienta dla Linuksa był kod skryptu uruchamiającego STEAM dla MacOSX napisany w bashu.

#!/bin/bash # figure out the absolute path to the script being run a bit # non-obvious, the ${0%/*} pulls the path out of $0, cd's into the # specified directory, then uses $PWD to figure out where that # directory lives - and all this in a subshell, so we don't affect # $PWD STEAMROOT=$(cd "${0%/*}" && echo $PWD) #determine platform UNAME=`uname` if [ "$UNAME" == "Darwin" ]; then PLATFORM=osx32 # prepend our lib path to LD_LIBRARY_PATH export DYLD_LIBRARY_PATH="${STEAMROOT}"/${PLATFORM}:$DYLD_LIBRARY_PATH elif [ "$UNAME" == "Linux" ]; then PLATFORM=linux32 # prepend our lib path to LD_LIBRARY_PATH export LD_LIBRARY_PATH="${STEAMROOT}"/${PLATFORM}:$LD_LIBRARY_PATH fi if [ -z $STEAMEXE ]; then STEAMEXE=steam fi ulimit -n 2048 # and launch steam cd "$STEAMROOT" STATUS=42 while [ $STATUS -eq 42 ]; do ${DEBUGGER} "${STEAMROOT}"/${PLATFORM}/${STEAMEXE} $@ STATUS=$? # are we running osx? if [ $STATUS -eq 42 -a ${PLATFORM} == "osx32" -a -f Info.plist ]; then # are we running from in a bundle? exec open "${STEAMROOT}"/../.. fi done exit $STATUS

Powyższy kod jest jednoznacznym dowodem na to, że STEAM był testowany pod Linuksem a także, że Linux jest platformą wpisaną w planach tak jak MacOSX.

Wczesne wersje plików binarnych skompilowanych dla Linuksa

Przez bardzo krótki okres czasu były publicznie dostępne pliki binarne klienta STEAM dla Linuksa pod tym adresem, sam zdążyłem je pobrać pamiętam, że miałem te pliki na pendrive lecz aktualnie już ich nie posiadam dlatego nie jestem w stanie udostępnić ;-)

Wyjście w konsoli klienta STEAM:

yjwong@yjwong-laptop:~/Documents/steam$ ./steam.sh [ 0%] !!! Fatal Error: Failed to determine download location for universe 0 [----] Verifying installation... [ 0%] Downloading Update... [ 0%] !!! Fatal Error: Failed to determine download location for universe 0 unlinked 0 orphaned pipes CellID: Fetching server list from CSDS. . . CellID: CSDS returned 168 servers. CellID: Connecting to 62.118.240.140:27031. . . CellID: Connect to 62.118.240.140:27031 took 524 MS CellID: New Best! CellID: Connecting to 209.197.6.226:27031. . . Shutting down. . . CellID: Connect to 209.197.6.226:27031 took 326 MS CellID: New Best! CellID: Connecting to 203.77.185.186:27031. . . CellID: Connect to 203.77.185.186:27031 took 286 MS CellID: New Best! CellID: Connecting to 69.28.153.109:27031. . . CellID: Connect to 69.28.153.109:27031 took 380 MS CellID: Connecting to 79.141.161.2:27031. . . CellID: exiting! unlinked 2 orphaned pipes CAsyncIOManager: 0 threads terminating. 0 reads, 0 writes, 0 deferrals. CAsyncIOManager: 1657 single object sleeps, 0 multi object sleeps CAsyncIOManager: 0 single object alertable sleeps, 1 multi object alertable sleeps yjwong@yjwong-laptop:~/Documents/steam$

Warto zauważyć, że na wyjściu z konsoli nie ma charakterystycznych dla Wine wpisów.

Lecz abyście Mi uwierzyli pokażę zrzuty ekranu czy nawet film wideo w którym widać proces uruchamiania STEAM dla Linuksa.

@edycja 14.02.2011:
Dodaję także kilka ważniejszych zrzutów ekranu które pominąłem:Główne okno STEAMOkno nowościWbudowany czat

Źródła:http://www.phoronix.com/scan.php?page=news_item&px=ODIzMAhttp://www.phoronix.com/scan.php?page=news_item&px=ODIyOQ

http://www.youtube.com/watch?v=VPWEX23osn0

Drukowalne ciągi znaków odnalezione w kliencie beta dla MacOSX

Przy pomocy narzędzia strings odnaleziono ciągi "Linux" w becie klienta dla MacOSX:

ReadToken overflow WIN32 VISTA WIN7 POSIX LINUX X360 Assertion Failed: kv windows macos linux unknown macos104 macos1058 macos106 linux22 linux24 linux26

Co oznacza, że zapewne w kodzie znajdują się pewnego rodzaju instrukcje być może dla kompilatora pokazujące który kod jest przeznaczony dla jakiego systemu(mało prawdopodobne?) bądź dla statystyk popularności danego systemu wśród użytkowników STEAM.

Odnośnie windowsowej wersji klienta nie znaleziono już tego co pod MacOSX, wyniki bardziej wskazują na hlds, lecz jest jedna wzmianka o kliencie:

webnull@webnull-gentoo-desktop /media/Disk/Gry/STEAM $ strings Steam.exe |grep ux 9uxr uxWP ux9u f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\auxdata.cpp german-luxembourg french-luxembourg Bad eCurrentLinuxClientVersion field in CClientConfigRecord Bad eCurrentLinuxHldsUpdateToolVersion field in CClientConfigRecord Bad eBetaLinuxHldsUpdateToolVersion field in CClientConfigRecord Empty eBetaLinuxHldsUpdateToolPassword in CClientConfigRecord Luxembourg uxyKNOGJKHKK|

Z tego co widać, że jest wersja klienta Linuksowego (STEAM?) oraz wersja klienta Linuksowego serwera dedykowanego (HLDS - bądź jego aktualizatora?).

Gry w sklepie STEAM dostępne dla platformy Linux

W sklepie STEAM pojawiły się gry które w minimalnych wymaganiach sprzętowych miały podanego Linuksa obok Windowsa i MacOSX - a to dziwne, Valve nie dopuściło by czegoś takiego skoro STEAM nie byłby dla Linuksa przecież nie można okłamywać potencjalnych klientów.

Oficjalna informacja od producenta

There's no Linux version that we're working on right now.
to słowa wypowiedziane przez przedstawiciela Valve Douga Lombardiego, oznaczają one, że nie ma aktualnie w planie żadnej wersji STEAM dla Linuksa nad którą by teraz Valve pracowało.

Oczywiście publiczna wypowiedź przedstawiciela Valve nie oznacza, że klienta Linuksowego nie ma w planach.

Osobiście jestem przekonany, że Valve przynajmniej zamierzało wydać klienta STEAM dla Linuksa - czym może być spowodowana nagła zmiana?

Może Valve specjalnie skłamało aby pozytywnie zaskoczyć społeczność?

Co jeżeli ktoś podłożył te wszystkie dowody? (najmniej prawdopodobne - pliki klienta były dostępne na serwerach oficjalnych platformy STEAM, sam pobrałem te pliki kiedyś - szkoda, że do dziś ich nie posiadam).

Pamiętam kiedyś jak pobierałem pliki binarne klienta Linuksowego to dostępne były także pliki binarne klienta Windowsowego i tego dla MacOSX.

Przykładem dawniej to było:
http://store.steampowered.com/public/client/steam_client_linux # 403 (zablokowano)
http://store.steampowered.com/public/client/steam_client_windows # 404 (brak)
http://store.steampowered.com/public/client/steam_client_macosx # 404 (brak)

Dziwnym trafem akurat katalog steam_client_linux zablokowano, a pozostałe nie istnieją - zostały skasowane. Jakby Valve coś ukrywało w tym jednym katalogu.

@edycja - 12.02.2011
Być może to nie były plotki, a większa firma jak Microsoft opłaciła wycofanie się Valve z tworzenia klienta dla konkurencyjnego systemu operacyjnego?

To jest całkowicie możliwe ponieważ natywny klient mógłby spowodować nagły wzrost popularności Linuksa, bardzo znaczący wzrost...

Zapraszam do udziału w dyskusji na temat STEAMa.

 

Komentarze

0 nowych
XeonBloomfield   5 #1 11.02.2011 22:48

Ciekawy temat.

Swojego czasu też widziałem dużo news'ów jakoby Valve miał pracować nad Steam'em dla systemów opartych o jądro Linux.

Jednak zaraz po tym pojawiły się oficjalne zaprzeczenia takich działań.

webnull   9 #2 11.02.2011 22:54

@XeonBloomfield
Ja miałem binarki w rękach, uruchomiłem ekran logowania, sama aplikacja była kompletnie pusta nawet zalogować się nie mogłem wtedy.

Dziwne, że tak nagle przerwali prace nad klientem - a może w ogóle nie przerwali tylko tak mówią? - To jest dopiero zagadka.

  #3 11.02.2011 23:52

Pewnie jakieś cięcia, uznali że się nie opłaca na obecnym etapie i zamrozili.

  #4 12.02.2011 00:01

Zablokowany i nie usunięty katalog na stronie Steam.
Ciekawe co w nim teraz jest.

Temat jest interesujący.

@webnull:
Tylko ekran logowania był i nic więcej?

przemo_li   11 #5 12.02.2011 07:13

Spiskowe Teorie dziejów!

Ja ja je lubie!

Ale mówiąc poważnie X11 NIE JEST domyślnie instalowany w makach!

Jest gdzieś na standardowych płytkach instalacyjnych, ale doinstalować go trzeba samemu!

Za to sam STEAM dla MacOSX już robi dobrze ideii gier na Linuksa.

Jeśli tylko twórcy gier zaczną stosować biblioteki, języki, i narzędzia dostępne i na Maki i na Wingrozy (i jeszcze konsole), to te narzędzia będą też obsługiwały Linuksa lub niewiele trzeba będzie zmienić aby dodać taką obsługę.

A jak w każdym biznesie dobre jest to co przyniesie więcej kasy niż się w nie włoży. Wymóg kompatybilność gier pod Wingroze i Maka, obniża koszt dodania do tej listy Linuksa.

przemo_li   11 #6 12.02.2011 07:15

PS 2 obrazek 2 screen, mi wygląda na graficznego klienta STEAMa, który był tylko fanowską próba. A nie przedsięwzięciem Valve. I dotyczy on innej aplikacji niż 1 i 2 screen.

webnull   9 #7 12.02.2011 10:42

@przemo_li
"PS 2 obrazek 2 screen, mi wygląda na graficznego klienta STEAMa, który był tylko fanowską próba. A nie przedsięwzięciem Valve. I dotyczy on innej aplikacji niż 1 i 2 screen"

Mogę się nie zgodzić - pliki binarne były dostępne przez jakiś czas na serwerze, po prostu te zrzuty ekranu zostały wykonane w różnych odstępach czasowych kiedy aplikacja wyglądała znacznie inaczej.

@Anonim (niezalogowany) | 12.02.2011 0:01
Niestety tylko ekran logowania z samymi przyciskami ;-)

webnull   9 #8 12.02.2011 10:47

@przemo_li, Anonim
Być może to nie były plotki, a większa firma jak Microsoft opłaciła wycofanie się Valve z tworzenia klienta dla konkurencyjnego systemu operacyjnego?

To jest całkowicie możliwe ponieważ natywny klient mógłby spowodować nagły wzrost popularności Linuksa, bardzo znaczący wzrost...

- Być może wcale nie cięcie kosztów.

"Ale mówiąc poważnie X11 NIE JEST domyślnie instalowany w makach!"

Wybacz, mało wiem o Makach lecz słyszałem, że Maki używają X11 albo czegoś bardzo podobnego.

XeonBloomfield   5 #9 12.02.2011 12:14

Link do informacji z 12 maja 2010 informującej, że Valve portuje Steam oraz Source Engine na systemy oparte o jądro Linux:

http://www.phoronix.com/scan.php?page=article&item=valve_steam_announcement&...

Link do informacji z 23 sierpnia 2010 przeczącej takiemu działaniu:

http://www.engadget.com/2010/08/23/valve-denies-having-a-linux-version-of-steam-.../

Coś w tym jednak było.

webnull   9 #10 12.02.2011 12:27

@XeonBloomfield
"Coś w tym jednak było."

Też tak uważam.

XeonBloomfield   5 #11 12.02.2011 12:52

@webnull | 12.02.2011 12:27:

"Coś w tym jednak było."

Pytaniem jednak jest "Czy nadal jest?".

webnull   9 #12 12.02.2011 13:21

@XeonBloomfield
No cóż, skoro katalog został i jest zablokowany dla ludzi z zewnątrz to zapewne plan nie został wrzucony do kosza tylko zamrożony bądź jest nadal aktywny tylko, że "po cichu" ;-)

przemo_li   11 #13 12.02.2011 15:49

Apple rozwija własne rozwiązanie nie mające nic wspólnego z X11.

Za to do celów zgodności rozwija też własnego forka X.orga. Na przykład Xorg Apple w ogóle nie posiada sterowników, zamiast tego polega na sterownikach dostarczanych przez Apple dla całego systemu.

Efekt jest taki, że dla zwykłych aplikacji X11 jest dostępne, ale Apple zaleca korzystanie z jego własnych rozwiązań, jako lepiej zintegrowanych z resztą systemu.

PS Apple certyfikowało MacOSX jako pełnoprawnego Unixa, tzn. wszystkie bajery/standardy jak POSIX czy X11 są dostępne. Ale tworząc silnik gry działający na Maku, niekoniecznie trzeba z nich korzystać.

Dlatego Mac obniża koszta przeportowania gry na Linuksa, ale ich nie znosi całkowicie.



Dalej jestem pewien, że 2 obrazek 3 screen jest wzięty z całkiem innej aplikacji, która nic nie miała wspólnego z Valve. Nie mówię, że Valve nie miała gdzieś, kiedyć klienta linuksowego, a tylko, że ten konkretny screen nie przedstawia tego klienta. (Wpadka jak z podaniem screena LXDE jako screena XP :D ).

przemo_li   11 #14 12.02.2011 16:03

A co do całej "teorii spiskowej".

To myślę, że Valve musiało rozważyć wejście na rynek Linuksowy, wtedy gdy rozważano wsparcie dla Maka.
Jeśli nie na poważnie, to choćby jako wstępny rekonesans.

Poza tym Valve musi dbać o zyski, oraz przekonywać, że usługi Valve przyniosą zyski twórcom/dystrybutorom gier, gdy wybiorą usługi Valve.
Dlatego najrozsądniejsze co może zrobić Valve to wejść najpierw na rynek "mniejszego ryzyka", przekonać firmy stojące za tytułami AAA, że Mak się opłaca.
Stworzyć całą infrastrukturę, zachęcić Apple do współpracy i większego zaangażowania w aspekty ich systemu które są najważniejsze dla graczy, oraz wprowadzić narzędzia do tworzenia wieloplatformowych gier.

Dodatkowo Valve mogło by przegrać gdyby nie udało się przekonać dużych firm do publikowania tytułów równocześnie! Zwłoka pomiędzy wydaniem wersji na Win a na Mac spowodowała by, że część osób wybrała by wersję Win (Win działa na sprzęcie Apple!), oraz zwiększyła by koszty promocji (z powodu drugiej premiery gry). Co oznacza, że Valve musi poczekać na wydanie tytułów AAA, które tworzone były by od początku i na Winy i na Maki. Czyli gdzieś do H1Y2011. Oraz na twarde wyniki finansowe.

Nie bez znaczenia jest również ekosystem OpenGLa pod Wingrozą, który po prostu śmierdzi. Co oznacza, że Wingrozowa przestrzeń dalej będzie zdominowana przez DX, czyli nici z taniego portowania.

Podsumowując. Valve to firma, którą interesują zyski. Klientami Valve są inne firmy, które patrzą też tylko na zyski.
Gdyby Valve źle podeszło do sprawy całość mogła by się okazać fiaskiem. Wybranie 2 systemów było by tylko proszeniem się o kłopoty!

Oraz oczywiście desktopowy Linuks może mieć za mały udział w rynku aby Valve opłacało się inwestowanie. (A dzięki przygodzie z Makami będą w stanie to dość dokładnie ocenić).

Co nie zmienia faktu, że parę tytułów AAA/indie i tak jest dostępnych dla Linuksa :)

przemo_li   11 #15 12.02.2011 16:04

się rozpisałem...
Chyba przerobie swoje przemyślenia we wpis na blogu.

webnull   9 #16 12.02.2011 16:16

"Dalej jestem pewien, że 2 obrazek 3 screen jest wzięty z całkiem innej aplikacji, która nic nie miała wspólnego z Valve. Nie mówię, że Valve nie miała gdzieś, kiedyć klienta linuksowego, a tylko, że ten konkretny screen nie przedstawia tego klienta. (Wpadka jak z podaniem screena LXDE jako screena XP :D )."

Słyszałem, że ten screen pochodzi od jednego z deweloperów Valve który testował klienta pod zwirtualizowanym Ubuntu używając jako hosta MacOS X.

webnull   9 #17 12.02.2011 16:19

@przemo_li
Moim zdaniem powinien zaistnieć jeden wielki framework do którego wtyczkami byłyby OpenGL i DirectX - taka niby warstwa pośrednia w każdej aplikacji aby był jeden interfejs do dwóch bibliotek.

  #18 12.02.2011 19:22

"Moim zdaniem powinien zaistnieć jeden wielki framework do którego wtyczkami byłyby OpenGL i DirectX - taka niby warstwa pośrednia w każdej aplikacji aby był jeden interfejs do dwóch bibliotek."
Do niczego takiego nie dojdzie bo:
a) DX to kluczowa technologia windowsa i wedle MS powinna nie mieć żadnej konkurencji (xbox jest nawet dx only)
b) Reszta świata ma tylko opengl
c) niby na jakim poziomie miałoby to być realizowane?
d) wydajność mogłaby być nieco niższa
d) jakie jest zapotrzebowanie na takie rozwiązanie gdy są dostępne silniki graficzne zdolne do wykorzystywania zarówno dx jak i opengl?

XeonBloomfield   5 #19 12.02.2011 19:44

@webnull | 12.02.2011 16:19:

Jądro i moduły, co?

Tak programowanie stałoby się dużo prostsze, jednak nikt nie chce tego wprowadzić z powodu "zbyt dużych zmian".

webnull   9 #20 12.02.2011 19:47

@XeonBloomfield
Dokładnie, ja programuję według modelu "Kernel + moduły" i wydaje Mi się to najlepszym rozwiązaniem.

webnull   9 #21 12.02.2011 19:48

@herr
"d) jakie jest zapotrzebowanie na takie rozwiązanie gdy są dostępne silniki graficzne zdolne do wykorzystywania zarówno dx jak i opengl?"

Mniej więcej o coś takiego Mi chodziło jak silnik obsługujący równocześnie DX i OpenGL.

Ryan   15 #22 12.02.2011 20:06

-- "Być może to nie były plotki, a większa firma jak Microsoft opłaciła wycofanie się Valve z tworzenia klienta dla konkurencyjnego systemu operacyjnego?"
Jasne, bo Valve desperacko potrzebuje kasy z szemranych umów. Ech...

-- "Mac obniża koszta przeportowania gry na Linuksa"
Zgodność Makówek z POSIX czy X11 obniża koszty portowania Z Linuksa, a nie na niego. Pisane na Makówki gry nie używają X11 jako backendu renderującego. To szalenie niewygodne i niewydajne rozwiązanie. X11 jest przeraźliwie archaiczne i stara się pośredniczyć w masie rzeczy, których dzisiaj nikt normalny przez X11 by nie pchał. To właśnie frustracja takim stanem rzeczy doprowadziła do powstania Waylanda.

-- "Moim zdaniem powinien zaistnieć jeden wielki framework do którego wtyczkami byłyby OpenGL i DirectX - taka niby warstwa pośrednia w każdej aplikacji aby był jeden interfejs do dwóch bibliotek."
Przeważnie silniki graficzne mają bardzo cienką warstwę abstrakcji pozwalającą na podmianę niskopoziomowego renderera. Ale nie są to wtyczki a wkompilowywane moduły.

Poza tym mamy dziś "żywych" API o wiele więcej niż DX/OGL. PS3 używa libGCM, Xbox 360 używa DirectX 9X niedostępnego na PC, większość gier PC stara się oferować renderer DX11 obok "starego" DX9 (a DX11 jest wystarczająco różne od DX9 czy DX9x, żeby trzeba było cały renderer pisać od nowa). Fajnie byłoby, gdyby kanapowi eksperci przestali majaczyć o DX na Windows i OGL dla reszty świata. Rzeczywistość jest dużo bardziej skomplikowana.

A i portowanie na Linuksa to dużo większy koszt, niż się Wam wydaje. Tu nie chodzi o przepisanie kawałka kodu pod kątem nowej platformy. Dochodzi kwestia testowania aplikacji na docelowym systemie - pochłaniający poważną część kosztów deweloperki element. Złożoność testowania na Linuksie jest zbliżona do testowania na PC: masa różnych wersji systemu, różnorodny sprzęt...

Dodanie Mac OS X do listy testowanych SKU to dla producentów stosunkowo niewielki wydatek. To jak dodanie konsoli: stabilny i przewidywalny hardware, mała różnorodność softu, który leży pod kodem gry (systemu i sterowników). Do tego stosunkowo wysoka popularność systemu wśród ludzi z "luźną kasą", którzy mogą gry kupować. Z drugiej strony Linux, którego demografia jest dużo bardziej różnorodna, strasznie pofragmentowany horyzont oprogramowania i sprzętu, potencjalne problemy z DRMem,... Koszmar. Jeśli uda się wzmocnić pozycję Ubuntu na rynku, to może zobaczymy STEAM na Linuksie. IMO tylko Shuttleworth może zrobić Wam dobrze. :)

nintyfan   10 #23 12.02.2011 20:33

@przemo_li | 12.02.2011 16:03 :
Ja nigdy nie patrzyłem się na kod source i innych bibliotek od Valve, lecz wierzę, że skoro dystrybuują programy drogą elektroniczną, to gry mogą/powinny całkiem zapominać o systemie operacyjnym.

nintyfan   10 #24 12.02.2011 20:36

@Ryan (redakcja) | 12.02.2011 20:06 :
Też tego nie biorę na serio, ale nikt nie pisał o desperacji. Widocznie dostali do łap utajnioną dokumentację, opis pewnych adresów w pamięci do napisania systemu DRM lub przyśpieszenia pracy aplikacji, albo dostali na tyle kasy, że zdecydowali się nie wypuszczać wersji na GNU/Linux.

nintyfan   10 #25 12.02.2011 20:39

@Ryan (redakcja) | 12.02.2011 20:06 :
IMHO, strach przed otwaroźródłowym jądrem, co pozwala na kontrolowanie swojej maszyny i procesów, może być zbyt duży, więc nawet Canonical niczego nie zmieni.

webnull   9 #26 12.02.2011 20:55

@Ryan (redakcja)
Tak czy inaczej MacOSX jest zgodny z POSIX jak Linux - obydwa są Uniksami co w jakimś stopniu ułatwia portowanie - a o OpenGL już nie mówiąc.

"Dochodzi kwestia testowania aplikacji na docelowym systemie - pochłaniający poważną część kosztów deweloperki element."

Wydaje Mi się, że nie potrzeba do tego stu komputerów a wystarczy kilka z różnymi podzespołami graficznymi np. 1 x NVIDIA, 1 x ATI, 1 x INTEL.

"masa różnych wersji systemu"

Tutaj nie trafiłeś kompletnie.
To, że system różny się menadżerem pakietów, innym położeniem (nie ważnych dla gry) plików konfiguracyjnych czy inne środowisko graficzne nie oznacza, że system używa innych bibliotek - każdy system oparty o Linuksa używa tych samych bibliotek bazowych, tego samego jądra itp.

webnull   9 #27 12.02.2011 21:00

@nintyfan
Może w pewnym momencie odkryli, że można jakoś z konta root przechwycić ich sekretny klucz DRM z pamięci ;-)

Ryan   15 #28 12.02.2011 21:57

-- "skoro dystrybuują programy drogą elektroniczną, to gry mogą/powinny całkiem zapominać o systemie operacyjnym"
Co ma niby wspólnego przenośność kodu z platformą dystrybucji?

-- "Widocznie dostali do łap utajnioną dokumentację, opis pewnych adresów w pamięci do napisania systemu DRM lub przyśpieszenia pracy aplikacji, albo dostali na tyle kasy, że zdecydowali się nie wypuszczać wersji na GNU/Linux."
Ręce opadły mi i nie jestem w stanie odpisać. X_x

-- "Tak czy inaczej MacOSX jest zgodny z POSIX jak Linux - obydwa są Uniksami co w jakimś stopniu ułatwia portowanie - a o OpenGL już nie mówiąc."
Super, ale wciąż ignorujesz to, że pisanie kodu jest tanie. Testowanie kosztuje. :) Dam Ci prosty przykład: Batman Arkham Asylum to 13 programistów i ponad 70 członków QA (test). Nawet przy stosunkowo dużych dysproporcjach zarobków (~$100k dla programisty i ~70k dla testera) koszt kodu jest dużo, dużo niższy niż koszt testów. Bo niestety, ale WYDAJE CI się, że testowanie wymaga kilku zestawów. Testuje się przeważnie na pełnej gamie wspieranych kart graficznych i procesorów z uwzględnieniem współpracy konkretnego CPU i GPU. Często coś tak pomijalnego jak chipset płyty - a więc komponent związany z CPU - ma wpływ na charakterystykę wydajnościową kodu. Bugi z dostępem do pamięci zależne od sterownika pamięci. Można tak wymieniać w nieskończoność. Kod jest tani, programiści też. Drogie są pipeline, content i testowanie.

-- "Tutaj nie trafiłeś kompletnie."
Ależ oczywiście, że trafiłem. Różne wersje libc, różne systemy plików domyślnie używane przez system, różne wersje sterowników oferowane z dystrybucją - to wszystko ma kluczowe znaczenie dla działania i stabilności kodu gry.

Trywialny przykład z ostatniego GDC: kod Avalanche Studios odpowiedzialny za IO działa kilkunastokrotnie szybciej na systemie z ext3 niż na systemie z innym FS (czy to Linuksowym czy dowolnym innym).

Serio, rzeczywistość jest dużo bardziej złożona niż Ci się wydaje. :)

webnull   9 #29 12.02.2011 22:35

"różne wersje sterowników oferowane z dystrybucją"

Musiałyby to być na prawdę różniące się o rok wersje sterowników..

"różne systemy plików domyślnie używane przez system"

To nie wiele ma do rzeczy.

"Dam Ci prosty przykład: Batman Arkham Asylum to 13 programistów i ponad 70 członków QA (test)."

Ale po co aż 70 testerów skoro producentów układów graficznych można policzyć na palcach od jednej ręki tak samo z procesorami.

webnull   9 #30 12.02.2011 22:37

"Super, ale wciąż ignorujesz to, że pisanie kodu jest tanie. Testowanie kosztuje"

Gdyby dali szansę, to społeczność Linuksowa sama by się zatrudniła do testowania klienta i było by kilka tysięcy testerów od razu za darmo zamiast tych marnych 70.

nintyfan   10 #31 12.02.2011 23:32

@webnull | 12.02.2011 22:37 :
Testerzy, co nie umieją debugować i programować?

  #32 12.02.2011 23:51

@nintyfan | 12.02.2011 23:32:

Podałeś dobry przykład. Mało kto zatrudnia testera "z ulicy" przy dużych projektach.

Zawsze jest tak, że programiści kodują, a potem testerzy testują i proponują udoskonalenia w zamkniętej becie.

Dopiero kawał czasu od tego gdy testerzy wewnętrzni zakończą testy otwierany jest program otwartej bety.

TestamenT   11 #33 13.02.2011 00:20

@nintyfan z umiejętnościami programowania i debugowania są programiści a nie testerzy.

Jest tani sposób na testowanie gier a mianowicie otwarte beta testy.

Ryan   15 #34 13.02.2011 00:42

-- "Musiałyby to być na prawdę różniące się o rok wersje sterowników.."
Nie, bo nawet przyrostowe wersje potrafią rozwalić kawałek kodu. Przykład, którego doświadczyłem na własnym kodzie: far clipping plane, jaki się ustawia w kodzie, jest granicą otwartą albo zamkniętą, zależnie od wersji sterownika. Czyli jeśli ustawisz go na (powiedzmy) 100.0f i wyrenderujesz tło na quadzie z przetransformowanym Z 100.0f, to zależnie od wersji sterownika będzie to tło widoczne, bądź nie. Przykładów tego typu są setki.

-- "To nie wiele ma do rzeczy."
Ma w aplikacjach, w których wydajność ma znaczenie. Takich jak np. kod Avalanche Studios, które tworzy gry z otwartym światem i streamuje dane w locie.

-- "Ale po co aż 70 testerów skoro producentów układów graficznych można policzyć na palcach od jednej ręki tak samo z procesorami."
Bo istotne są kombinacje, a nie same komponenty w izolacji. Bo obok różnego sprzętu ważne są wersje sterowników. Bo różnice w wersjach dynamicznie linkowanych bibliotek mogą powodować crash kodu.

-- "Gdyby dali szansę, to społeczność Linuksowa sama by się zatrudniła do testowania klienta i było by kilka tysięcy testerów od razu za darmo zamiast tych marnych 70."
Bzdura. Nie liczy się ilość, tylko jakość. Testowanie to nie używanie aplikacji (to dogfood) a systematyczne weryfikowanie różnych fragmentów kodu. To nie przyjemność a wyczerpująca praca. Społeczność nie zastąpi profesjonalnych testerów.

@TestamentT: Niespecjalnie jest to prawdą. Otwarte beta testy wymagają już dopracowanego kodu. Większość ludzi pobierających tego typu soft wyrabia sobie opinię o produkcie i otwarta beta z kodem o jakości wewnętrznych buildów testowych to strzał w stopę. Wiem to z doświadczenia - nawet ludzie, którzy pracują nad produktem nie chcą używać niestabilnych buildów, jeśli nie jest to absolutnie niezbędny aspekt wykonywanej pracy.

webnull   9 #35 13.02.2011 00:53

"Bzdura. Nie liczy się ilość, tylko jakość. Testowanie to nie używanie aplikacji (to dogfood) a systematyczne weryfikowanie różnych fragmentów kodu. To nie przyjemność a wyczerpująca praca. Społeczność nie zastąpi profesjonalnych testerów."

Właśnie, że zastąpi - nie muszą testować pojedynczego fragmentu kodu, jeżeli masa będzie po prostu używać aplikacji to brudy wyjdą w praniu.

Najlepiej by było stworzyć inicjatywę tworzenia klienta STEAM dla społeczności Linuksowej gdzie to społeczność by była testerami - proste, sami geekowie, programiści by się zgłosili.

Ryan   15 #36 13.02.2011 01:03

Testowania gier nie da się crowdsource'ować. Społeczność nie stworzy kompletnego planu testów funkcjonalnych i nie będzie go wykonywała każdego dnia. Dogfood to nie są testy funkcjonalne. Sam dogfood nie umożliwi Ci osiągnięcia spójnej aplikacji na czas. Wiem to nie dlatego, że jestem fotelowym ekspertem, a dlatego, że pracowałem nad kilkunastoma projektami o różnorodnej złożoności. Możesz mi wierzyć, albo powtarzać jak mantrę coś, co podważy każdy pracujący od przynajmniej kilku lat nad kodem człowiek.

Draqun   9 #37 13.02.2011 01:29

Więc jaki problem aby Valve wspierało którąkolwiek dystrybucję. Jeśli ktoś będzie chciał grać pod Linuksem to sobie ją zainstaluje. Zresztą masa ludzi korzystających z Linuksa niejednokrotnie ma na swoim komputerze więcej jak jednego Linuksa :)

GL1zdA   11 #38 13.02.2011 01:31

@Ryan, jak ty nie ogarniasz. Przecież na UNIXach to prostsze.

TestamenT   11 #39 13.02.2011 02:27

Chyba już łatwiej było by inwestować w rozwój wine albo ReactOS niż liczyć na natywne porty.

Gdyby android zdominował wszystkie urządzenia w tym PC to niezależnie od urządzenia można było by uruchamiać te same programy. Oczywiście teoretycznie.

nintyfan   10 #40 13.02.2011 08:23

@Ryan (redakcja) | 13.02.2011 0:42 :
Napiszę tyle. Najwięcej błędów i tak wykrywanych jest przez końcowych użytkowników, niezależnie od aplikacji. Jednak trzeba mieć na uwadze, że zwykły użytkownik jest mniej wartościowy jako beta-tester niż taki profesjonalny beta-tester.
Właśnie dlatego wymaga się niekiedy od beta-testerów m.in umiejętności programowania, choć nie musi ona być na wysokim poziomie - musi po prostu wiedzieć, co robi jakaś funkcja, i jak wypełnić raport o błędzie.

nintyfan   10 #41 13.02.2011 08:24

@Ryan (redakcja) | 13.02.2011 0:42 :
Proszę zwrócić uwagę, że w "społeczności" na pewno są ludzie, którzy wiedzą, jak testować programy. Jednak faktycznie ważna jest jakość.

nintyfan   10 #42 13.02.2011 08:32

@TestamenT | 13.02.2011 2:27 :
Nie prawda. Natywne porty gier są i istnieją. Problemem jest tylko to, że ich twórcy robią to po godzinach, a za swoją pracę nie dostają wynagrodzenia, tylko drobny procent ze sprzedaży przy jednocześnie wyprodukowaniu często tylko jednej serii płyt - czyli mają za to marne pieniądze.
Natomiast z działaniem natywnych gier nie miałem problemu. Raz tylko trafiłem na program, który nie rozumiał, iż istnieje takie coś, jak multilib, i instalator sprawdzał wersję systemu przy uruchamianiu. Musiałem go okłamywać poleceniem linux32, ale to jedyny taki przypadek.
Jeżeli chodzi o silnik grafiki, to sportowanie go jest pryszczem. Do nie dawna większość gier i tak było jednowątkowych i nie dostosowanych do maszyn wieloprocesowych, więc sportowanie takiej gry wg. mnie nie powinno stanowić problemu.
Problemem są faktycznie błędy w sterownikach. Pod Windows pewna gra miała problemy(nie renderowała pewnych rzeczy niekiedy), co było problemem ze sterownikiem. Tunkuska nie działa na kartach graficznych niektórych producentów, co masz napisane na opakowaniu. Ogólnie, to sterowniki graficzne, niezależnie na jaką platformę, to często jeden wielki bubel. Autorzy gier po prostu wybierają te najmocniejsze karty graficzne, nie wykorzystują często dodatkowych funkcji wspieranych przez układ, a następnie optymalizują gry pod te najpopularniejsze.

przemo_li   11 #43 13.02.2011 10:37

@Ryan

Yeap! X11 suck!
Ale postęp się dokonuje, X11 coraz bardzie schodzi na bok. (TMM, GEM, KMS w jądrze Linuksa, etc.).

Za to OpenGL nie idzie przez X11 pod Makie, od tego Apple ma własne biblioteki. Ale dalej OpenGL jest ten sam. To co jest inne to cała reszta operacjie I/O, obsługa sieci, urządzeń wejściowych, wielu monitorów, etc.

Za to pisanie i na Wingrozę i na Maka wymusza, ocenę czy jakieś biblioteki są dostępne na obie platformy, oraz czy ułatwią one pisanie kodu od początku działającego na obie platformy.

Co oznacza, że gry będą/są pisane na nieco wyższym poziomie abstrakcji. Twórcy kart graficznych będą się bardziej przykładać do OpenGLa, Apple będzie się bardziej starało ułatwić nie tyle portowanie, co tworzenie kodu, który od początku jest przenośny etc.

A to oznacza, że łatwiej będzie pisać kod, który będzie działał i na Linuksie. Bo duża część bibliotek, które działają i na Maka i na Wingrozę, działa i na Linuksa. Dodatkowo Linuks skorzysta z rozwoju ekosystemu OpenGLa na Maka.

webnull   9 #44 13.02.2011 10:40

@przemo_li
Dobra uwaga - gdyby pisano aplikacje najpierw pod Linuksa to z portowaniem na Windowsa i Maka nie było by większych problemów bo przecież większość bibliotek Linuksowych będzie działać pod Windowsem i Makiem.

nintyfan   10 #45 13.02.2011 11:07

@przemo_li | 13.02.2011 10:37 :
OpenGL od dłuższego czasu nie idzie przez X11 pod Linuksem. Od tego jest to całe DRI, itd. Oczywiście - jest też GLX, które pozwala na przesyłanie poleceń OGL po sieci.

nintyfan   10 #46 13.02.2011 11:09

@przemo_li | 13.02.2011 10:37 :
Od jakiegoś czasu słychać o natywnym DX pod Linuksa - pisząc natywny mam na myśli nie wymagający WineLib, a jedynie Gallium3D. Twórcy Mesy tworzą tą bibliotekę. W takim razie, to co do przenośności kodu, to być może za niedługo będzie dało się przenieść lepiej grę z Windows na Linuksa niż z Windows na Maka, choć na dzień dzisiejszy nie widzę tego.

nintyfan   10 #47 13.02.2011 11:10

@webnull | 13.02.2011 10:40 :
Jasne. Dodatkowo obsługa wątków przez PThreads lub inną bibliotekę do obsługi wątków, i wszystko działa tak samo wszędzie.

GL1zdA   11 #48 13.02.2011 11:53

@webnull
"Dobra uwaga - gdyby pisano aplikacje najpierw pod Linuksa to z portowaniem na Windowsa i Maka nie było by większych problemów bo przecież większość bibliotek Linuksowych będzie działać pod Windowsem i Makiem."

Bo nikt nie chce tracić czasu na portowanie aplikacji. Zakładając, że pisze się tak samo długo na każdą platformę, to lepiej jest wydać grę szybko na Windows, niż czekać kolejne miesiące na jej wydanie z powodu portowania z Linuxa.

Ave5   8 #49 13.02.2011 14:08

Steam w wersji dla Linuksa może się pojawi, problem to same gry. Mam dziwne wrażenie, że tylko tytuły robione z gruntu jako multiplatformowe byłyby wystawiane dla Pingwina, bez żadnych konwersji. Naturalnie możliwe, że Valve odwali robotę nad wszystkimi grami, ale skoro nie potrafią zrobić szybko i bez afer publicznego klienta, to jakoś nie wierzę w taki rozwój wypadków...

TestamenT   11 #50 13.02.2011 14:27

Konsole mają tą właśnie zaletę że mają te same bebechy w środku. Jednak ja osobiście nie lubię konsol.

Zawsze uważałem i uważam tak nadal że jeżeli obmyśli się wszystko na etapie projektowania to tworzenie portów na różne platformy jest łatwiejsze i tańsze. Ale mam wrażenie że po prostu developerzy się rozleniwili i im się nie chce, bądź lepiej by pasowało "bo im się nie opłaca".

Ryan   15 #51 13.02.2011 17:04

-- "Dobra uwaga - gdyby pisano aplikacje najpierw pod Linuksa to z portowaniem na Windowsa i Maka nie było by większych problemów bo przecież większość bibliotek Linuksowych będzie działać pod Windowsem i Makiem."
Wciąż ignorujesz koszt testów i zachwycasz się tanim kodem. Poza tym warstwa POSIX-owa na Windzie jest wolna, a w grach AAA wydajność ma znaczenie kluczowe. Co więcej na 360 warstwa POSIX-owa w ogóle nie istnieje (bo i po co?). Tak jak OGL nie jest odpowiedzią na wszystkie problemy, tak portowanie z Linuksa wcale wiele nie rozwiąże.

-- "Dodatkowo obsługa wątków przez PThreads lub inną bibliotekę do obsługi wątków, i wszystko działa tak samo wszędzie."
Nikt rozsądny w gamedevie nie będzie używał pthreads.

Zasadniczo odnoszę wrażenie, że kompletnie pomijacie w tej dyskusji kwestię wydajności kodu. Nie po to przy produkcji wysokobudżetowych gier inwestuje się w mikrooptymalizacje, żeby cała uzyskana wydajność poszła w piach z powodu warstw translacji różnej maści. Szczególnie jeśli wsparcia dla konkretnej rzeczy na docelowej platformie nie ma (np. POSIX na Xboksie 360 czy wyjątki w C++ na praktycznie każdej konsoli). Gry to nie aplikacje biurowe, rządzą się zupełnie innymi prawami. To, że OOo sprawdza się w modelu "wszyscy tworzą, wszyscy testują, wszyscy używają" nie znaczy, że da się to przenieść na grunt game devu.

TestamenT   11 #52 13.02.2011 17:26
TestamenT   11 #53 13.02.2011 17:32

@Ryan problemy developerów końcowego użytkownika mało co obchodzą.
Wydaje mi się że jest zapotrzebowanie gier na Linuksa może nie tak duże i nikt kokosów na tym nie zarobi ale jednak jest i możliwe że będzie rosło.

Ryan   15 #54 13.02.2011 17:37

Wiesz, problemy użytkowników Linuksa mało co obchodzą producentów komercyjnego oprogramowania. :) Można odbijać tak piłeczkę? Można. Póki coś się nie opłaca, nie będzie robione (albo nie będzie robione na szeroką skalę). Jeśli obok zainteresowania Linuksem na desktopach będzie odpowiednia grupa docelowa - gry się pojawią. Portowanie gier dla samego portowania to marnowanie kasy. Ja, jako konsument, który za gry płaci (i to słono, bo gram na konsolach) nie zgadzam się, by pieniądze, które za grę płacę, były wydawane na port na platformę, która się sama nie jest w stanie finansować. Mają być wydane na polerowanie gry na moją platformę. Co mnie obchodzą Twoje problemy? - parafrazując raz jeszcze. :]

  #55 13.02.2011 20:46

Z wypowiedzi kolegi Ryana odnoszę wrażenie, że wprowadzenie DirectX nie rozwiązało do końca problemów z programowaniem gier. Idea odchodzenia od dosowych produkcji była przecież taka, że programista nie musi martwić się o rodzaj karty graficznej u użytkownika bo to "załatwia" system operacyjny. Ciekaw też jestem jakich narzędzi używa się do tworzenia gier na konsole i komputery. Może ktoś kiedyś pokusi się o napisanie jakiegoś artykułu na ten temat.

  #56 13.02.2011 21:05

"ponieważ natywny klient mógłby spowodować nagły wzrost popularności Linuksa"
hehe sam używam windowsa i jedyne co mnie w nim trzyma to steam a dokładniej cs, xDD czyli jeśli będzie steam na linuxa, będę miał spore zmiany xD oby czym prędzej.

Ryan   15 #57 13.02.2011 22:46

@bitx: DX rozwiązało część problemów. Na DX składają się dwie części: jedna publiczna, opiewająca interfejsy dla programistów; druga dostępna wyłącznie dla producentów sprzętu opiewająca wymagania wobec nich. Ta druga z czasem "uszczelniana" jest, żeby producenci nie szli po linii najmniejszego oporu i utrudniali życie deweloperom.

Część procesu certyfikacji sterowników to zbadanie zgodności kombinacji sprzętu i sterownika ze specyfikacją. Niestety dwu największych producentów potrafi wydać sterowniki, które oszukują w procesie certyfikacji i "podkręcają" swoje działanie w pewnych aplikacjach (topowych grach i benchmarkach). Póki taka nieczysta konkurencja ma miejsce, żadne API problemu kompatybilności nie rozwiąże. :/

TestamenT   11 #58 13.02.2011 23:52

@piotrekr|KW (niezalogowany) mnie również na Windowsie trzyma Steam jednak posiadam gry nie tylko od valve.


Tych problemów nie ma na konsolach odnośnie sprzętu i sterowników ale producenci gier traktują konsolowych graczy jak mleczne krowy i doją ile wlezie.

  #59 14.02.2011 03:25

Kolejna teoria spiskowa Linuksiarzy zawierająca stek bzdur.

"- Inna biblioteka graficzna (GTK/QT dla Linuksa, "AQUA?" dla MacOSX)"
Cocoa, ewentualnie mocno niezalecany obecnie Carbon (brak wsparcia dla aplikacji 64-bitowych).
Nie ma bindingów Cocoa do C++. Jeśli chcemy tworzyć programy naprawdę dobrze integrujące się z Mac OS X musimy skorzystać z tandemu Objective-C i Cocoa. Na upartego można korzystać z Qt, ale aplikacja nie będzie się zbyt dobrze integrować z OS X.

"- Inne jądro"
A jakie to ma znaczenie? Przecież nie chodzi o sterowniki.

"(Darwin w MacOSX?)"
Mac OS X bazuje na Darwinie. Darwin to system operacyjny a nie jądro. Jądrem Darwina jest jądro hybrydowe XNU łączące mikrojądro Mach 3 z elementami BSD i frameworkiem I/O Kit (API do sterowników).

"+ Identyczny podsystem graficzny (okienka, sterowniki itp.) X11?"
Kompletna bzdura.
Środowiskiem graficzny w Mac OS X jest Aqua, która nie ma nic wspólnego z X11.
Serwer X11 nie jest nawet preinstalowany (aczkolwiek jest dołączony na płycie z systemem). Równie dobrze można zainstalować Cygwin/X w Windows.
Tylko znowu: jakie to ma znaczenie? Przecież i tak korzysta się frameworków i bibliotek graficznych.

"+ Ten sam podsystem wyświetlania grafiki 3D, mowa o OpenGL"
Tworząc aplikacje pod Mac OS X wykorzystuje się Cocoa, Quartz, Core Foundation w skład którego wchodzi Core Animation, Core Audio, Core Data, Core Graphics, Core Image, Core Location, Core OpenGL, Core Services, Core Text czy Core Video.
Ponadto - w zależności od aplikacji - korzysta się innych API, bibliotek i frameworków, chociażby Search Kit. Aplikacje dla Mac OS X korzystają z masy rozwiązań specyficznych dla tej platformy. Przykładowo sporo aplikacji dla Mac OS X do wyświetlania dymków korzysta z Grwola, który jest niedostępny dla Linuksa.
Uprzedzam pytanie: nie, GNUStep nie wystarcza, żeby stworzyć port aplikacji desktopwej Mac OS X na Linuksa.

"+ Obydwa systemy są Uniksopodobne, podobne założenia, "wszystko jest plikiem""
Bla bla bla. Jakie to ma znaczenie gdy mowa o aplikacjach desktopowych i grach? Bo przecież nie chodzi o programy konsolowe operujące na plikach czy przetwarzające dane ze standardowego wejścia i dające odpowiedź na standardowe wyjście.

"+ To samo środowisko skryptowe czyli bash jako domyślna powłoka stąd jeden launcher dla dwóch systemów""
Niesamowite. Szkoda tylko, że preinstalowanie Basha w Mac OS X i popularnych dystrybucjach Linuksa ma tutaj przyzerowe znaczenie.

Po prostu gadasz bzdury nie mając zielonego pojęcia o Mac OS X, bibliotekach graficznych, jak i inżynierii programowania i tworzeniu systemów informatycznych.

przemo_li   11 #60 14.02.2011 08:15

@Ryan

Nie pisałem o POSIX, raczej o takich rozwiązaniach jak SDL, OpenAL, etc. Czasami stosuje się je i w produkcjach AAA pod Wingrozę, ale i też, zastosowanie takich bibliotek skróca czas tworzenia na dwie platformy równocześnie.

Owszem pomijam "testowanie", ale testowanie to mniej więcej koszt stały na danej platformie. Za to koszt portowania może być ogromy, nie mówiąc o zwłoce z wydaniem klienta na inne platformy a co za tym idzie z utraceniem efektu marketingowego towarzyszącego premierze na oryginalną platformę. Dlatego obniżanie nakładu jaki jest nieunikniony przy pisaniu od podstaw na kilka platform, umożliwia obsługę nowych platform. Szczególnie jeśli "niechcący" dostajemy obsługę platform na których nie musimy zmieniać kodu.
Inna sprawa to określenie jaki kawałek z danej platformy nas interesuje (np. czy wydajemy grę na iPhona 3G, czy może już tylko 3GS, czy może i ten jest "za słaby", etc.), oraz jakie były by koszty testowania/reklamy/dystrybucji.

To co dokładnie piszę to, że prawo synergii, działa i dla reklamy i dla pisania przenośnego kodu! Valve za to ma unikalną okazję aby dodać do tego dystrybucję. (więc zostaje tylko testowanie, jak sam słusznie zauważyłeś).

"OpenGL od dłuższego czasu nie idzie przez X11 pod Linuksem. Od tego jest to całe DRI, itd. Oczywiście - jest też GLX, które pozwala na przesyłanie poleceń OGL po sieci."

Przecież o tym piszę! A teraz to już jest DRI2 :), a GLX dalej jest stosowane do "inicjalizacji" OpenGLa, choć można też użyć EGLa, tak jak na mobilne platformy.

przemo_li   11 #61 14.02.2011 08:16

Postal III dalej wychodzi na Linuksa!

http://www.phoronix.com/scan.php?page=news_item&px=OTEwMQ

Source Engine jest dostępny na Linuksa.

Ryan   15 #62 14.02.2011 10:29

@Anonim: Trzeba przywyknąć. Przecież w Linuksie to łatwe. ;)

@przemo_li: Nikt nie używa SDL pod Windows. Jest niewiele OSS-owego kodu wykorzystywanego w poważnej deweloperce gier. Vorbis do kompresji audio i sporadycznie OGRE (przykładowo Torchlight jest na OGRE). Generalnie jednak większość wymienianych tutaj bibliotek, z OpenAL włącznie, nie nadaje się do multiplatformowej deweloperki.

I ponownie upierasz się, że portowanie jest niesamowicie kosztowne. Tak, bo trzeba port testować. Programistów silnika specyficznych dla platformy w każdym studiu jest niewielu - dwóch-trzech. Pisanie kodu nie jest drogie. Serio.

webnull   9 #63 14.02.2011 11:31

@przemo_li
Może dzięki Postalowi będzie Source Engine a wtedy dla Valve będzie miało mniej roboty i jakoś znowu powróci do prac nad klientem STEAM ;-)

TestamenT   11 #64 14.02.2011 12:08

@Ryan (redakcja) SDL jest używany pod Windowsem przez wiele gier jednak niewiele z tego jest tytułów komercyjnych.

Co do Postala 3 to czas pokaże.

Wolfgar   7 #65 14.02.2011 12:29

Moim zdaniem to STEAM mógłby jeszcze poprawić wersje dla Windowsa. Bo jak trzeba być wielki debilem aby wymyślić instalacje gier tylko i wyłącznie na partycji na której STEAM się znajduje. To woła o pomstę do nieba!

webnull   9 #66 14.02.2011 12:33

@Wolfgar
Zgadzam się, to bardzo denerwujące.
Pod Linuksem jest na to rozwiązanie:
Należy przenieść daną grę na inną partycję i utworzyć dowiązanie symboliczne.

webnull   9 #67 14.02.2011 12:34

@TestamenT
"Co do Postala 3 to czas pokaże."

Dokładnie, mam nadzieję, że za nie długo będzie ten Postal ;-)

webnull   9 #68 14.02.2011 12:43

@Anonim
"Kolejna teoria spiskowa Linuksiarzy zawierająca stek bzdur."

Szkoda, że ta teoria spiskowa posiada dużo mocnych dowodów.

TestamenT   11 #69 14.02.2011 13:26

Co do STEAM na Windowsie to nie mam z tym problemów bo STEAM można zainstalować w dowolnym miejscu.

przemo_li   11 #70 14.02.2011 14:25

"Co do STEAM na Windowsie to nie mam z tym problemów bo STEAM można zainstalować w dowolnym miejscu."

Więc zgodzi się, że i fajnie było by instalować gry w DOWOLNYM miejscu.

przemo_li   11 #71 14.02.2011 14:28

@Rayan

Wpakuj I/O oparte na Win32API a później portuj to na Maka :D
Załóż zarządzanie pamięcią jak dla Win+DX później portuj na dowolną konsolę. Załóż cokolwiek specyficznego dla danej platformy nie dodaj warstwy abstrakcji, i już jesteś ugotowany.

I tak koszty portowania są duże, a mogą być małe.

PS OpenAL jest stosowany w różnych tytułach AAA :/ więc kawałka oni nie rozumiem.

przemo_li   11 #72 14.02.2011 14:30

http://en.wikipedia.org/wiki/OpenAL

między innymi idTech4, Unreal Engine 3, etc. To nie są małe projekty, biednych programistów.

webnull   9 #74 14.02.2011 17:42

@przemo_li
Enemy Territory używa OSS ale może także używać SDL (ja używam SDL w ET aby unikać kolizji z innymi programami używającymi dźwięku)

Wolfgar   7 #75 14.02.2011 17:57

@TestamenT - A co jak masz z jakiegoś powodu małe partycje ? Mam za każdym razem odinstalować grę żeby zainstalować nową? Przemo_li też ma rację!

TestamenT   11 #76 14.02.2011 18:52

@Wolfgar
W tedy pobawił bym się z dowiązaniem symbolicznym powszechnie stosowany w systemach uniksopodobnych http://www.searchengines.pl/Linki-symboliczne-Polaczenia-punktow-NTFS-t84302.html

  #77 14.02.2011 22:31

Przy dobrym pomyśle można zrobić w bibliotece szablony funkcji działające na każdym systemie i użyć zdefiniowanych w tej bibliotece funkcji.

Przy używaniu między-systemowych API bez dużego nakładu środków można zrobić to prosto i szybko.

Wolfgar   7 #78 14.02.2011 23:26

@TestamenT - No dobrze, Ty tak zrobisz. Ja tak zrobię bo zobaczę to od Ciebie. A co z resztą użytkowników? To chyba jeden z najgłupszych rozwiązań jakie ostatnio spotkałem w programach komputerowych.

webnull   9 #79 15.02.2011 00:20

@Wolfgar
Uwierz Mi - w windowsach dowiązania symboliczne nie są na porządku dziennym ale pod systemami opartymi o Linuksa można to zrobić z GUI tak prosto jak przeciągnij i upuść.

TestamenT   11 #80 15.02.2011 00:55

@Wolfgar
No cóż ja nic na to nie poradzę.
Gdyby tak sporo osób wysłało zapytanie do valve czy mogli by wprowadzić taką funkcjonalność. To możliwe że coś by to dało.
Bo w końcu zadowolenie klientów powinno być dla nich ważne.

@webnull
Ale to nie znaczy że Windows pod tym względem jest gorszy.
Po prostu większość użytkowników Windowsa nie zna jego możliwości.

Co nieco nauczyłem się dzięki Gnu\Linux i FreeBSD. I o dziwo czasem ta wiedza przydaje się na Windowsie.

przemo_li   11 #81 15.02.2011 07:38

@webnull

SDL nie jest konkurencją dla OSS! Jest całościowym pakietem.

przemo_li   11 #82 15.02.2011 07:54

@wolfgar

Przez MAŁE "p".

@TestamenT

Ehh, podaj procent użytkowników Wingrozy mających STEAMa i wiedzących co to dowiązanie symboliczne.

Wolfgar   7 #83 15.02.2011 14:30

@TestamenT - No cóż ja nic na to nie poradzę.

Wiem i przecież Cię za to nie obwiniam. Jednak od takiej platformy jaką jest STEAM wymagam większej elastyczności.

@webnull - Ale mnie Linuks absolutnie nie obchodzi. No bo chyba nie o to chodzi żebym zmieniał platformę jak mi 1 program nie chodzi najlepiej. (proszę tego nie odczytywać jako krytyki Linuksa, po prostu z 7 jest mi dobrze)

nintyfan   10 #84 16.02.2011 14:38

@TestamenT | 13.02.2011 14:27 :
Konsole mnie powoli irytują. Zdarzały mi się ostatnimi czasy zawieszki, przycięcia, błędy w grach konsolowych. Problem pod konsolami jest taki, że trudniej zrobić Update do gier, choć jest światełko nadzieji, bo zwyczajnie granie na komputerze uznaję za mniej wygodne.

nintyfan   10 #85 16.02.2011 14:45

@Ryan (redakcja) | 14.02.2011 10:29 :
Właśnie mnóstwo niskobudżetowych gier korzysta z otwartych formatów lub otwartych bibliotek. Dla przykładu: Puzzle Quest: Challange of the Warlords, Word Of Goo, itd.

webnull   9 #86 16.02.2011 23:36

@nintyfan
Wolne formaty wydają się lepsze, nie trzeba płacić za ich używanie, dokumentacja jest wszędzie, support z resztą też...

nintyfan   10 #87 17.02.2011 10:40

@Ryan (redakcja) | 13.02.2011 17:04 :
Całkowicie się nie zrozumieliśmy. Napisałem tak samo wszędzie mając na uwadzę również szybkość działania.

webnull   9 #88 20.02.2011 11:30

@nintyfan
"Konsole mnie powoli irytują. Zdarzały mi się ostatnimi czasy zawieszki, przycięcia, błędy w grach konsolowych. Problem pod konsolami jest taki, że trudniej zrobić Update do gier, choć jest światełko nadzieji, bo zwyczajnie granie na komputerze uznaję za mniej wygodne."

Aktualizacje są wymuszane przed startem gry online w Playstation Network dlatego producentowi nie trudno zaaktualizować miliony konsol.

A zawieszki, cóż - Mi nigdy się nie zdarzały...

  #89 09.04.2012 20:23

Ludzie !
Mamy desure na linuxa !
Wreszcie jakaś platforma do gier !

Steam może kiedyś...