Valve získalo dalšího významného vývojáře (diskuse)

[D.A.Tiger]

Hmmm... takže to vypadá opravdu vážně...

[dad]

bohužel

[Mrkva]

s/dad/rms?

[vain]

Používáš distribuci, kde to bude předinstalováno a nepůjde to odinstalovat? Chudáku!

[Ravensun]

Bohudík

[Redi]

Not sure if...

[D.A.Tiger]

... a proč?

[petr_p]

Proto se v poslední době do SDL tlačí podpora GLX a EGL ;)

[Jardík]

Podpora GLX? Tu už SDL přece mělo, jinak by asi nevytvořilo gl context. Spíš by mě potěšilo pořádná podpora vstupních zařízení, obzvláště gamepadu. Aktuální API je totálně k ho*nu, protože nepočítá s připojením, popř. odpojením gamepadu, prostě se při startu udělá néjakej seznam a dále máte smůlu. Přitom naprogramovat to není problém, alespoň na linuxu, kde stačí chytat události od udevu.

[Václav HFechs Švirga]

No SDL neumí (nebo aspoň neumělo, co jsem se o to zajímal) na Linuxu akcelerovat. Což by umět mohlo, protože pro spoustu 2D věcí se musí sáhnout (zbytečně) po OGL (v kombinaci se SDL, ale už jen pro eventy a tak), jinak se to seká.

[Jardík]

Proč by neumělo SDL akcelerovat? Vždyť je to jen wrapper nad opengl a nad platformě závislími fcemi pro vytváření opengl contextu (a dalšími věcmi). Co jsem se díval kdysi do zdrojáku (tuśím nějaké verze 1.2, už je to déle), tak to normálně vytvářelo opengl context přes GLX fce včetně nastaveného True pro direct rendering.

[Václav HFechs Švirga]

Kdyby byl vždycky v SDL akcelerovany bliting (SDL_BlitSurface), tak by asi nevznikly věci jako glsdl (http://olofson.net/mixed.html). Jak je to ale v SDL 2.x netuším.

A k OpenGL kontextu, to se vytváří jen když nastavíš flag u videomode SDL_OPENGL ne? Pak už kreslíš v OpenGL a máš to je samozřejmě akcelerované, ale SDL funkce pro grafiku už nepoužíváš. Já jen, jestli se bavíme o tom stejném, šlo mi akcelerovaně kreslit jen pomocí SDL funkcí (což glsdl řešilo tak, že zachovalo SDL api, ale renderovalo přes opengl).

Na windows SDL kreslí přes direct, který akcelerovaný je. Na Linuxu, co jsem googlil aspoň verze 1.2 přes X11, k verzi 2.0 jsem nic nenašel a zdrojáky se mi teď zkoumat nechce.

Jinak moje zkušenosti jsou takové, že u čeho SDL render žere třeba stabilně 20 % CPU a víc (nějaký posunující se obrázek po obrazovce -> tedy přemazání, bliting a UpdateRect v cyklu) při použití SDL v kombinaci s OpenGL žere 0-5 % CPU. A autoři supertuxu (vždyť je to typické 2D) asi po OpenGL taky nesáhli náhodou. Ale možná to prostě neumím .

Jinak nevýhoda kreslení rovnou přes OpenGL pak byla v tom, že když akcelerace nebyla, tak sw render OpenGL byl na CPU náročnější než sw render v SDL (co se týče CPU, je SDL optimalizované velmi dobře -> i v asm a tak), ale dneska to asi nemá cenu řešit (akcelerace je téměr všude a pokud ne, dnešní procesory utáhnou i sw render opengl (pro 2D účely) naprosto v pohodě).

[Jardík]

No já SDL vždy používal prakticky jako multiplatformí způsob vytvoření opengl kontextu a vstupu z klávesnice/myši a tam taky moje zkušenosti s SDL končí, takže se teda omlouvám ^^.

[Václav HFechs Švirga]

No ja už to dělám stejně, po těch špatných zkušenostech . U OpenGL máš u 2D jako bonus minimálně zadarmo věci jako rotaci a zooming, takže paráda... (o nějakých částicových / haló efektech nemluvě, to se taky v OpenGL děla lépe).

[petr_p]

Co je v SDL-1.2, je slabý odvar, co všechno je v SDL-1.3, respektive SDL-2 (sami neví, jak to pojmenovat). A není to jenom GLX. Hodně dělali na podpoře Quartzu, před pár dny si se začali lidi zajímat o Metro (protože tam OpenGL není, je tam jen nějaké přepsané D3D).

Ale je pravda, že na nějakou lepší intergraci pečou. Třeba když si zkompilujete SLD-1.3 s GLX in EGL, tak není možné použít GLX. Není možné rozumně enumerovat podporavaná rozlišení. Hotplug jste zmínil. Pak jsou tam problémy se zbytečným zamykáním fokusu klávesnice a tak dále.

A samozřejmě mizerná 2D akcelerace, jak se rozvádí níže. Třebaže si požádáte, aby byl surface ve videopaměti, tak tam není. Takže obyčejný klasická smyčka blit–redraw furt tahá bitmapy z hlavní paměti do grafiky. S GL kontextem je to trochu lepší, ale ne o moc.

SDL je bohužel takový moc futuristický projekt. Vývojáři neustále přidávájí nové funkce, ale k opravovaní stávajících se nemají.

[Luboš Doležel (Doli)]

Nemůžu se dočkat. Pár let nazpátek vycházelo titulů pro Linux docela dost a teď je mrtvo.

[vain]

Taky se nemůžu dočkat, mám na Steamu spoustu her, ale hlavně i věci na Source enginu (nepočítám, že se kvůli Steamu budou portovat věci jako Company of Heroes atd... co mám koupené) a teď jsem za babku koupil Portal + Portal 2, bylo by super, kdybych nemusel pořád restartovat do zavaděče Steamu (Windows), ale pustil to z pohodlí hlavního OS. I kdyby to mělo být jen těch pár her na Source engine případně od id Software.

A upřímně, pokud Steam pro Linux opravdu bude, budu při nákupu dávat přednost multiplatformním titulům před těmi jen pro Windows.

[trekker.dk]

a) dokud nedohraju HL2 na Linuxu, tak na žádný port nevěřím. Slibovali, přetahovali vývojáře a vždycky ticho po pěšině.

b) nezáleží na tom, jestli Steam pro Linux bude, ale taky jak. Jestli z toho udělají krám, který se dá spustit jenom pod rootem nebo něco na ten způsob, tak ani náhodou. To budu radši dál používat zavaděč na hry, než abych si rozes*al systém, který mám na práci.

[michi]

dokud nedohraju HL2 na Linuxu

Tak to bych skoro zabalil rovnou I kdyby do půl roku spadlo nebe (ale s portem Source problém snad není, ukázky L4D2 na Ubuntu už proběhly), bez HL2E3/HL3 je to příběh bez konce )

[Pavel Čejka]

Obávám se, že HL2 pro Linux portován nebude, resp. pokud ano, tak nějaký prasopsí bundle s Wine pod nímž chodí zcela bez problémů (dohrál jsem ve Wine celý Orange Box - tj. HL2 + datadisky a Portal 1, Team Fortress jsem zatím nezkusil, a Portal 2 nemám). Jinými slovy, proč portovat něco, co už bez problémů funguje? Kvůli jiným platformám než x86? Asi ne, zdrojáky nebudou. Kvůli Androidu? Navzdory tomu, že VM Dalvik a zbytky linuxového jádra, na kterém Dalvik běží?

[j AM]

Taky je tu možnost že si to blbě vysvětlujete a realita je jiná, třeba už ho Linux začal srát a teď programuje Windows aplikace

[D.A.Tiger]

"Linuxová divize herní společnosti Valve získala dalšího významného vývojáře. Tentokrát je jím Sam Lantinga,..."

Tak nevím, jestli u pojmu "Linuxová divize herní společnosti Valve" si mám představit, že bude programovat Widloidní aplikace...

[pepe_]

+1

[Vykook]

Třeba to bude jako s tím ministerstvem lásky...

[vain]

No a je někde oficiálně dohledatelná nějaká "Linuxová divize" na stránkách Valve, nebo to je "Phoronix like" výmysl?

[Anonymous]

B je správně.

[vain]

Od včerejška to vypadá možná i na A.

[j AM]

"Linuxová divize" taky může být divize bývalých linuxáků

[D.A.Tiger]

No.... nevím jestli by se mi na jeho místě, potom chtělo drbat s WinApi a DirectX

[Jardík]

Mě by zajímalo, jestli ty hry poběží opravdu na všech linuxových platformách, nebo jestli valve má v hlavě linux = linux@x86-64. Doufám, že je ani ve snu nenapadne, že linux = linux@x86-32, ... já si kvůli nim 32bit šmejďárny instalovat nebudu.

[cita]

no ja jim zase kaslu na x86_64.... fandim x32

[Jardík]

Pro mě je to jen další volba k vypnutí při kompilaci kernelu ^^

[hmm]

Nechapu co se tu vztekate nad tim jestli to bude 64bit nebo 32bit. Muzeme byt radi za cokoliv co se Valve uraci poskytnout a oficialne to podporovat. Je hodne malo takovych spolecnosti co by do toho sly... Myslite si snad, ze vsechny hry, ktere se distribuuji jsou 64bit? Steam je jen nastroj k jednoduche instalaci a hrani. Je uplne jedno jak toho dosahnou, hlavne aby to fungovalo a nebyly s tim problemy. Proc to uzivatelum jinych systemu nevadi? To jen linuxaci jsou tak divni a za to, ze nekdo projevi snahu dostat na tenhle nepopularni system popularni herni platformu, se odvdeci vykriky a neadekvatnim chovanim?

[Jardík]

Imho half life 2 pro windows je i v 64bit verzi, nebo teda alespoň býval v době, co jsem ho hrál, dokonce to tam i svítilo v rohu. S FarCry to byly první 64bit hry pro Windows. Bohužel od té doby se slehla země a vývojáři novou platformu prostě ignorovali a pořád vydávali 32bit šmejďárny. Bohužel za to může i MS, protože do Visty, Win 7 dal "neodstranitelné" 32bit součásti (někde se psalo, že Win Server 2008 R2 jde nainstalovat bez 32bit sraček), na co to přece předělávat, nebo na co se snažit opravovat bugy spojené s jinou velikostí datových typů (uvažování typu long "je přece stejně veliký jako pointer"), když to přece "funguje i v 64bit windows".

Nevidím smysl v tom vyvíjet prakticky nový SW pro nějakou platformu, která tu už s námi dávno není, neznám nikoho a pochybuju, že je někde ještě nějaký hráč, co chodí na nějakém pentiu 4 a paří na tom "nové" hry. Dneska má snad každé desktop PC doma x86-64 procesor, vytvářet 32bit binárku je prostě nesmysl, ale prostě vývojáři žijí v pravěku a drží se toho klacku (resp. kamene).

[Ravensun]

Třeba jim nechce zaměstnavatel pořídit lepší stroje :D

[pjoter]

ARMv8 ftw!

[tsLnox]

Jardíku, nikdo tě nenutí. Jó, svoboda, to je něco

[mikirc]

Opravdu jste si jist, ze v dnesnim svete ci nasem state tu svobodu mame?

[tsLnox]

Prosím, nevykat :)

Já myslel svobodu v GNU/Linuxu.

[j]

Mno ... ja bych to videl tak, ze pokud z toho vubec neco bude, tak to bude vypadat zhruba tak, ze se ti zaroven se steamem nahodi wine a oni tak maximalne posefuji to, aby to (pod wine) fungovalo bez toho, abys musel stahovat 150 obskurnich patchu. Samo, nekolik malo vyjimek mozna pobezi nativne.

Mno a na platformy mimo x86/amd64 asi rovnou zapomen.

[vain]

Mno a na platformy mimo x86/amd64 asi rovnou zapomen.

No on tak nějak jinou ani nezmiňoval ne?

Mimo to podle mě motáš věci dohromady, jaké výjimky poběží nativně a jaké pod wine? Tady je řeč o Steam klientu jako distribuci her, ta je nativní (předpokládám) v Mac OS X, takže hádám že nativní podpora pro Linux už nebude tak složitá. Pokud jde o hry to je úplně jiná pohádka a ve spojení s Valve se můžeme bavit tak maximálně o jejich hrách na Source enginu (a na těch se údajně pracuje také). Určitě se nebudou sr*at s podporou konkurenčních her přes Wine.

[Jardík]

No oni zmiňují "poběží to na linuxu", ale už neřeknou na jaké platformě. Můj dotaz byl právě na to. Na všech, nebo jen na x86-64, nebo jen na x86-32, nebo třeba jen na ARM, na PPC, na PPC64, sparc, a jánevímčemještě a tedy jestli zaměňují linux za linux@nějakánašeplatforma, aniž by to řekli, protože nepají páru, že existuje nějaká jiná.

[Rivon]

x86 a x86-64... Co by asi proboha jinýho podporovali?

[j]

Ale on je ti jaksi steam bez tech her tak nejak uplne khovnu ... Vazne nevim, k cemu by mi bylo mit steam nativne v tucnakovi (to samo predpokladam), kdyz mi jaksi nebude fungovat nic z toho, pro co ten steam pouzivam - tedy ty gamesky. A pokud pres to hodlaji distribuovat GPL gamesky, tak dik, ale portage mi funguje dobre a nepotrebuju dalsi bazmek.

[vain]

Ale to přeci není na vývojářích Valve, co na Steamu bude. To sis jako myslel, že se Steamem začnou najednou firmy jako Electronic Arts dělat hry pro Linux? To jsi víc naivní než já. Prostě možnost distribuce + hry na Source enginu. Kdo se přidá, jeho věc. Je to pro herní studia možnost, ne povinnost.

[michi]

ta je nativní (předpokládám) v Mac OS X

Předpokládáš špatně Můj poslední nedávný pokus o instalaci Steamu na Macu měl 2 kroky: 1) stahování knihoven a WINE, 2) čínskej čaj na obrazovce a la kernel panic. )

[vain]

No jestli to je opravdu s přibaleným Wine na Macu, tak jsem právě přišel o všechny iluze.

[Jix0]

Neni k tomu pribalovan wine.. Ja na OSX Snow Leopard si Steam nainstaloval primo jeho nativni verzi a pri podrobnejsim zkoumani obsahu baliku se zadny WINE nevyskytoval. Leda ze by jste si tam cpali Windows verzi

[vain]

Tak se ale chlapi dohodněte, já to nevyzkouším.

[knizmi]

Steam samotný je na OSX nativní a většina toho, co se přes něj dá koupit, také. Jedinou výjimkou je Witcher, který vyšel pár měsíců zpět, což byla malinko upravená win verze zabalená do wineskin wrapperu (taková moc šikovná utilita pro "portaci" aplikací na OSX s pomocí wine).

[vain]

Ok, tak mám zase trochu lepší mínění "multiplatformnosti" z pohledu Valve. Díky za info.

[hmm]

Je to vse nativni a nikdy jsem na OSX nemel problem se steamem ani hrami, bezi to velmi dobre a v OpenGL :)