Valve L4D2: 6 FPS-től 315 FPS-ig Linux alatt

 ( trey | 2012. augusztus 2., csütörtök - 8:03 )

A Valve linuxos fejlesztői nemrég kezdtek blogolni munkájukkal kapcsolatban. Az első technikai blogbejegyzésükben - amely tegnap született - rendkívül érdekes témával foglalkoznak. A teljesítménnyel. A Left 4 Dead 2-t (L4D2) portolják Linux-ra és közben méréseket végeznek. A portolási munka során egy baseline-t állítottak fel egy Intel Core i7 3930k, NVIDIA GeForce GTX 680, 32 GB RAM paraméterekkel rendelkező vason.

Windows 7-en, Direct3D driver használata mellett 270.6 FPS sebességet mértek a Left 4 Dead 2-vel. Ezután Linux-on mértek. A kezdeti verzióból mindössze 6 FPS-t tudtak előcsalogatni. Ahogy írták, ez teljesen normális egy új platformra való portolási munka elején. Nekiálltak optimalizálni.

Módosítottak a Source engine-en, csökkentették az OpenGL-lel kapcsolatos overhead-eket, kiegészítették a renderer-t. Ezután a játék 315 FPS sebességre gyorsult Linux alatt. Együttműködtek a munka során a hardvergyártókkal is. Érdekességként érdemes megemlíteni, hogy a munka hozadékaként Windows alatt is gyorsult az OpenGL implementációjuk, így a Left 4 Dead 2 (OpenGL) most 303.4 FPS-sel fut Windows alatt.

Felmerült a kérdés, hogy vajon miért fut Windows 7 alatt a játék OpenGL-es verziója gyorsabban, mint a Direct3D-s? A fejlesztők már tudják, hogy a hardver képes többre. Most azt keresik, hogy hogyan tudnák a D3D-s overhead-et kiküszöbölni.

A blogbejegyzés további jó hírt is hoz a játékosok számára. A Valve - ahogy az várható volt - együttműködik az NVIDIA, AMD és Intel mérnökeivel annak érdekében, hogy javuljanak a grafikus eszközmeghajtó-programok teljesítményei Linux alatt.

A részletek elolvashatók itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"After this work, Left 4 Dead 2 is running at 315 FPS"

Mindezt 32 biten, Linux alatt, OpenGL-lel, a fos X11-en????!!! Kihagytam valamit?

--
trey @ gépház

Szar a linugz... a legfontosabb jelzőt :-)

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Nem hiszem, hogy a 32GB-os konfigra 32bites OS-t tettek vagy még a PAE overheadet is be kellett vetni, hogy ne alázza meg nagyon a D3D-t. :)

Télleg 32bit...

Pedig de...

"We are using a 32-bit version of Linux temporarily and will run on 64-bit Linux later."

--
trey @ gépház

Egen, azé szerkesztettem. :) Nem hittem, hogy ekkora konfigon 2012-ben még felmerül a 32bit, de hát biztos oka volt.

Meg jo, h a echte nv driverben az x11 if gyakorlatilag csak wrapper, igy "a fos X11-en" kikuszobolheto. :)

---
pontscho / fresh!mindworkz

Az eredmenyek orvendetesek, de en nem ertem ezt a nagy csodalkozast. Mar 2004-ben egy olyan "sikertelen es nevesincs" jateknal, mint az UT2004 voltak hasonlo erdemenyek. A Linux/OpenGL kombinacio nagyobb FPS-t hozott, mint a Windows/D3D ill. a Windows/OpenGL. Biztos a fejlesztok nem toltak anno ezt a jatekot, vagy ha megis, akkor nem kulonbozo plattformokon ;)

A játékgyártásnál nem az az elsődleges köveletmény, hogy "több" FPS-t hozzunk ki a platformból, hanem az, hogy minél olcsóbban elfogadható FPS-t hozzunk ki belőle.

Egyelőre az van, hogy a DirectX egy átfogóbb, könnyebben használható, barátságosabb játékfejleszői platform, mint az OpenGL. Egyszerű példa: a DirectX-ben van hangkezelés is, az OpenGL-ben meg nincs.

Ez persze egyáltalán nem baj, meg lehet OpenAL-t használni, vagy SDL-t vagy akármit, de bonyolultabb (==költségesebb) így összelegózni valamit, mint a DirectX-et használni.

Azért én szurkolok a Valve-nak, hátha használhatóvá teszik a linuxot is előbb-utóbb :-p

D3D-ről volt szó.
OpenGL mellett meg használhatod a DX audio szolgáltatását...

Persze hogy használhatod, de miért használnál opengl-t ha utána a directx-hez kötöd magad a directsounddal?

senki sem kötelezi a játékgyártókat, hogy dx-et használjanak :)

Mégis használják. :)

észt nem adhatok, nekem is kevés van :)

ez tetszik :D)


Szerinted mit használok? Wi... neeem! Na, na, na? Hát blackPanther OS v12.0(beta)-t * blackpantheros.eu

Manapság már ott tartunk, hogy csak akkor csökkenthető elfogadhatóan egy fejlesztés kockázata, ha multiplatform fejlesztésben gondolkodsz az első pillanattól kezdve. Ehhez pedig az OpenGL+OpenAL sokkal jobb választás, mint a DirectX. Persze ha van pénz, idő az engine fejlesztésre, akkor lehet külön D3D, OpenGL renderert fejleszteni a különböző platformokra, de minek?!

Hat nemtom, ha en egyszerer fejleszthetnek win32re es xboxra (DirectX, ugye) az sokkal potensebb crossplatform strategianak tunik mint win32+linux crosspaltformsagot figyelni (tobbi OS/hw-t meg sztm bele se vegyuk, mert a PS3 meg tok mas.)
Bar lehet h xboxon az opengl is sima ugy, nem ertek a lovakhoz.

Win: DirectX, OpenGL
Mac: OpenGL
Linux: OpenGL
iOS: OpenGL
Android:OpenGL
PS Vita: OpenGL
PS3:OpenGL
XBox360: DirectX

s/csodálkozás/álcsodálkozás

Már akkor játszottam jó sebességgel Linux alatt 3D-s játékokat, amikor a legtöbb fikázó még ált. isk.-ba járt. :)

--
trey @ gépház

pentiumon 4MB ram mellett 2-3 doom is elfutkosott.

Azért jó látni, hogy az eredmények nem roszabbak, főleg nem sokkal, mint Windows alatt.
---------------------------
Oszt jónapot!

LOL. Melyik filmet nézed?

--
trey @ gépház

Csak olvastam párszor, hogy Linux alatt roszabbak az OpenGL eredmények, mint Winen. Most itt az FPS számokban nem mutatkozik ki, sőt!
---------------------------
Oszt jónapot!

"az eredmények nem roszabbak, főleg nem sokkal, mint Windows alatt"

Annyira nem sokkal rosszabbak, hogy jobbak mint Windows alatt. Linux alatt 315 FPS (nyilván OpenGL), Windows alatt 303.4 FPS (OpenGL) és 270.6 FPS (D3D).

--
trey @ gépház

12 fps ilyen nagysagrendnel mar nem szignifikans. Az lett volna fura, ha az nvidia binaris driverevel rosszabb erteket kaptak volna, mint windows-on. UDM ota nagyjabol ugyanaz a kodbazis van minden platformon az nv driverben. Ez a masik ok, h ha valaki hasznalhato gfx-et akar non-windows rendszeren, akkor ahhoz nvidia kell.

---
pontscho / fresh!mindworkz

Legyen stabil és fusson 30 FPS-sel (többet úgysem tud felfogni az emberi agy), aztán kezdjenek foglalkozni a következő játékkal :)


Androbit.org - Az informatika érdekes oldala

Ha a Source engine-t sikerül megfelelő sebességre hozni, a többi, erre az engine-re épülő játék portolása már gyk. készen van.

--
trey @ gépház

Izgalmas akkor lesz ez szerintem, ha már lesz AMD/INTEL teszt is és nemcsak FPS szempontból nézik a dolgot.


No rainbow, no sugar

Majd akkor jól rakunk egy bugot a kernelbe, az X-be, az opengl-be vagy valamelyik opensource játszótérbe, 2338 új feature címszóval! Ezeket a híreket én már úgy kezelem, hogy szerencsés véletlenek!


Szerinted mit használok? Wi... neeem! Na, na, na? Hát blackPanther OS v12.0(beta)-t * blackpantheros.eu

próbáld ki hogy játszol 120 és/vagy 60 fps-el, aztán játszál 30-al. :) utána gondold újra a kommented.

Nem szoktam jatszani, ezert nem is ertem ... igazabol ezt konkretan sose ertettem: mitol jo a 120fps? Az emberi szem nem kepes kovetni a kulonbseget - legalabbis _szerintem_ - ugy kb 30 ftps utan, teljesen felesleges tobbet. Vagy mit tudok rosszul, valaki arulja mar el.

A szemnek a 25-30 fps nem a felső limit, hanem az alsó. Ilyen képkocka számot látsz már(!) folyamatos mozgásnak. Azonban 60 fps fölött válik igazán tökéletessé, folyamatossá a mozgás.

+1, olyannyira, h a 60 fps-t mar-mar termeszetellenesen sima mozgasnak latni. Plusz tegyuk hozza, h sok jatekban a fizika/stb szimulacio annal simabb, minnel magasabb az fps. :)

---
pontscho / fresh!mindworkz

Mondjuk a fizika szimulációt nem kötelező 1-1ben a kirajzolt képkockákhoz kötni. Meg lehet csinálni, hogy a szimulációt végigfuttatod akkor is, ha a kirajzolásból kimarad 1-2 kocka. Így - elméletileg - reprodukálható minden futtatás - az input megfelelően időbélyegezett rögzítése mellett.

Valoban, de nagyjabol egy kezemen meg tudom szamolni hany eve divat a multithread a jatekfejlesztesben.

---
pontscho / fresh!mindworkz

Nem kell hozzá multithread. Elég egy logikai óra, amit képkockáknál és inputnál szinkronizálunk a render (valódi) órához.

Nem ertem en sem a tul sok fps hozzaszolast, hiszen lassitani sosem volt gond a jatekokat, meg odarakunk egy palmafat a sivatagba, vagy egy egy tevet, es oroszlant az eszakisarkra es felezodik az fps... :)

A monitorodnak is van egy "framerate-je" (nem pont az, de sok tekintetben olyan). Ha a játék framerate-je nem egész számú többszöröse ennek, akkor szaggatott lesz a gyors mozgás, kivéve, ha eléggé nagy a framerate, mert akkor eltűnik ez az effektus. Ezt a jelenséget egyébként a méregdrága cinemacity mozikban is meg lehet figyelni, ahol valami iszonyat gagyi vetítőket használhatnak, ugyanis minden filmben ugrabugrálnak a gyorsan mozgó dolgok.

Másrészről (bár ez kicsit source engine-specifikus), ha magasabb a framerate-ed, akkor jobbak az esélyeid multiplayerben, mert egységnyi idő alatt több parancsot tud a kliens a szerver felé továbbítani (vagyis például el tudsz ugrani a feléd repülő rakéta elől tf2-ben).

Vagy bekapcsolod a vsync-et, ekkor 1-2 fps árán kiküszöbölöd ezt az effektust.

Van olyanja, ok, hivjuk ugy, de en mindig ugy gondoltam, hogy annak minnel nagyobb erteke csupan azert fontos, mert klasszikus CRT eseten zavarja a szemet a villogas, amivel a kepfelepites jar (ahogy az elektronsugar vegigfut ugye, 100Hz-es CRT-s TV sem attol jobb a szememnek mert "folyamatosabb" - ok ott eleve az adas is ua amit vesz -, csak nem villog annyira). Pont ezert pl LCD-nel mar nem is ertettem miert lenyeges ez egyaltalan, tekintve, hogy mas elven muxik mint a CRT es ilyen effekt nem lep fel, ami zavaro [kepfrissitesi frekvenciatol fuggetlenul].

A masodik reszt nem teljesen ertem: attol hogy X fps-sel jelenik meg a "scene", attol meg lehet ettol fuggetlen, hogy milyen latency-vel, sebesseggel stb tud a szerver es a kliens kommunikalni, az fps csak a megjelenites szempontjabol jon a kepbe, hogy jon ide a halozati kommunikacio?

Mondjuk tenyleg soha nem jatszottam ilyesmikkel, szoval ezert van, hogy hulysegeket kerdezek :)

A játék élménye miatt. Nem mindegy, hogy pár tizedmásodperccel később vagy hamarabb veszed észre hogy valaki épp a sarokban sunyul. :)

Ugyanis, ha a géped le van foglalva a rendereléssel, akkor lelassul(hat) a bejövő adatok - pl. feléd repül egy rakéte - feldolgozása, ez pedig életbe kerülhet. :)

OK, latom tenyleg az a gond, hogy sose jatszottam ilyesmivel, ezert nem is ertem, miert fontos ez :)

Sajnos mára teljesen elbutulni látszik a játék társadalom ezért manapság a konzolon dzsojsztikkel játszott FPS esetén bőven jó a 60fps is.

De voltak idők amikor az FPS játékot még igazi férfiak játszották és ott bizony minden miliszekundum számított :)
http://www.youtube.com/watch?v=jADCNfe_aYo

--
maszili

NoobZ! :)

Látványos de én nem komálom az excessive modot mert szerintem a sok feltápolt értelmetlen fegyver és képesség megöli a játékot :)

--
maszili

"A masodik reszt nem teljesen ertem: attol hogy X fps-sel jelenik meg a "scene", attol meg lehet ettol fuggetlen, hogy milyen latency-vel, sebesseggel stb tud a szerver es a kliens kommunikalni, az fps csak a megjelenites szempontjabol jon a kepbe, hogy jon ide a halozati kommunikacio?"

:)

Klasszikus játékfejlesztési modell, egyszerűsítve:

while (true)
{
  Input();
  GameLogic();
  Render();
}

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"attol hogy X fps-sel jelenik meg a "scene", attol meg lehet ettol fuggetlen, hogy milyen latency-vel, sebesseggel stb tud a szerver es a kliens kommunikalni, az fps csak a megjelenites szempontjabol jon a kepbe, hogy jon ide a halozati kommunikacio?"

Jó gondolod. Valóban nincs köze a network sebességének közvetlenül a renderelés sebességére, de még a game logic és a fizika részére sem mindig. Pl. ha egy FPS-ben a magas network latency miatt nem jön a többi játékostól új mozgásvektor, akkor egy motion predictionnek hívott dolgot alkalmazunk, aminek az a lényege, hogy az új pozíciót és orientációt a korábbi mozgásból próbáljuk meg megbecsülni. Aztán amikor megjön a szükséges info, akkor persze pontosítunk. Ez okozhat kisebb gondokat, de még mindig jobb, mintha szaggatna a játék a hiányos network információk miatt.

Aki kíváncsi arra, hogy ezt kódban hogy is lehet megoldani, annak nyugodt szívvel tudom ajánlani a Xonotic forrásának olvasgatását, ugyanis pontosan ezt csinálja az is.
Eredmény: 160-as pinggel is még viszonylag zavartalanul tudok USA-beli szervereken is játszani (és ez "verseny" helyzetben is jól működik, az első 1v1 kupán egy német és egy amerikai csapott össze a döntőben, az egyik pályát az amerikai srác vitte, szóval a rendszer szépen vizsgázott.)

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Gyors mozgások esetén (pl tenisz) amit látsz 30 FPS-sen és a valóságban:
* 30 FPS: 3 helyen felvillan a labda a képernyőn
* 60 FPS: 6 helyen felvillan a labda a képernyőn
* 60 FPS plusz motion blur: 6 helyen csík darabot látsz, amik nem illenek egymásba (közelítések miatt)
* 120 FPS plusz motion blur: 12 helyen csík darabok, amik jobban passzolnak, a valóságoshoz közeli az élmény
* valóság: elmosódott csíkot látsz, amit az agyad persze labdának érzékel a röppályájának az érzetével együtt
* film: a gyors mozgások "gyárilag" motion-blur-özöttek.
** kamera: a szemhez hasonlóan időben integrálja a látottakat
** CGI: Akár 120 FPS felett is renderelik a filmet, majd a 25-30 kockát ezekből mossák össze. Így a végső hatás közelebb lesz a valósághoz.

Ok, ezt persze gondoltam, nekem inkabb az nem volt vilagos, hogy latom-e a kulonbseget a "3 helyen" es a "6 helyen" felvillano labda kozott, vagy nekem ugyanugy labda-labda lesz a velemenyem :) Lehet, ki kene probalnom inkabb az ertetlenkedes helyett :)

A 15-30-60-120 (monitoron is megjelenő) FPS között biztosan látod a különbséget. Olyat szerintem nem csináltak még kereskedelmi játékban, hogy a videokártya valódi kirenderelt képeket összemosott volna - pl 240->120 FPS formában. De talán az is érzékelhető javulást hozna.

Ez egy interaktív, valós idejű játék, és nem egy film. Az emberi agynak tényleg elég a 30 fps, viszont ilyen körülmények között többre van szükség.

--
http://neurogadget.com/

De ahhoz azért ne kelljen egy 130000-es VGA (GTX 680), meg egy 150000-es proci (i7 3930).

Lehet, hogy úgy vannak vele, hogy mire a projekt beélesedik, ez lesz az alsó középkategória...

Azért annyi ideig nem fog a Steam és a L4D2 portolása sem tartani. :)

a tied, lehet hogy nem

Popcorn, kóla bekészítve. Kezdhetitek! :)

Hát igen, ez elég magas labda volt :)

Vegul is ilyen aprosagok mar trey szerint nem fontosak: Windows 7 Service Pack 1 64-bit vs. Ubuntu 12.04 32-bit. Micsoda meglepetes.
A jatekre nem irtak semmit. De azert nem mindegy, hogy 32 vagy 64-bites. Igy aztan lehet am osszehasonlitast csinalni.

64 biten jó eséllyel picivel gyorsabb lehet a PAE hiánya és a 64 bitnyi szóhossz miatt. Ami az érdekes, hogy ugyanazzal a vassal, ugyanolyan videókályhából mit tudtak kihozni eltérő OS és driver mellett.

Ne hozd zavarba ;)

--
trey @ gépház

Elobb probalj meg irni ugy egy bejegyzest, hogy nem ferditesz.

"Windows 7 Service Pack 1 64-bit vs. Ubuntu 12.04 32-bit. Micsoda meglepetes.
A jatekre nem irtak semmit. De azert nem mindegy, hogy 32 vagy 64-bites."

Innen folytassuk, mert látszólag keményen érint téged ez a kérdés. Szerinted miért nem mindegy? Fejtsd ki. Arra utalsz, hogy csalás a Valve tesztje, mert a 32 bites Ubuntu alatt PAE-vel (vagy nélkül) gyorsabban fut a L4D2, mint a 64 bites Windows 7-en? Jól értem?

--
trey @ gépház

"látszólag keményen érint téged ez a kérdés"
Engem nem. Viszont te vagy az aki meg egy pontos bejegyzest se tud irni. Csak felhivtam a figyelmet erre. Ez nem egy ertekelheto teszt eredmeny.

"Arra utalsz, hogy csalás a Valve tesztje"
En ilyet nem irtam.

Azon kene elgondolkodni, hogy miert nem rogton a 64-bites ubuntu-t valasztottat 32gb ram-hoz.

Szépen kikerülted a kérdést. Utaltak itt többen arra, hogy a 64 bites Ubuntu valószínűleg gyorsabb lesz (de lassabb az majdnem kizárt). Ne akard, hogy azzal is teszteljenek, mert lehet, hogy még kormosabb pofa lesz az eredménye.

Ubuntu 12.04 LTS: 32-bit vs. 64-bit Performance

OpenArena-ban semmit sem számít, hogy 32 vagy 64 bit. A többiben meg a 64 elveri a 32 bitet.

--
trey @ gépház

Tehat te sem tudod, csak talalgatsz. Eleve azzal kellett volna kezdeni.

Mi lenne, ha a kérdésekre válaszolnál és nem mellébeszélnél? Több teszt is azt mutatja, hogy vagy nem számít, hogy 32 vagy 64 bites az Ubuntu, vagy a 64 bites a gyorsabb.

OpenArena, Nexuiz, Unigine engine. Keress rá az interneten. Majd gyere vissza, ha sikerült.

Ráadásul rá se akarok mutatni a saját magaddal szemben megfogalmazott ellentmondásodra, miszerint "Aki meg 32gb memoria mennyiseghez 32-bites operendszert valaszt, az idiota." Azt választották és _még így is_ jobb eredményt csináltak.

--
trey @ gépház

Ugye tudod, hogy a 64 bit mit jelent a 64 bites archokon a memória címzésen kívül?

Az is lehet, hogy windowson teljesít rosszabbul a 64 bites driver (gondolom erre nincs phoronix benchmark).

Bruhahahahaha. Eddig az volt az évtizedes mondás, hogy a linuxos driverek - beleértve az NVIDIA és az AMD drivereit - milyen szarok a windowsosokhoz képest. Kérlek, ennyire ne csússzatok már le a porba.

--
trey @ gépház

Szerintem én soha nem állítottam ilyet (sőt), inkább Pontscho-nak hiszek.

hat nem erted, hogy jobb a GNU/Linux mint a winfo$?
hadd oruljenek mar a hupperek, hogy ok ezt mindig is tudtak!

--
NetBSD - Simplicity is prerequisite for reliability

Csak nem megint egy savanyú netBSD-s?

-----
Puppy linux felhasználó

A jateknal nem irtak oda, hogy hany bites. Pedig az is fontos lenne. Ha mar csinalunk egy osszehasonlitast, akkor vegyuk mar a faradtsagot, hogy a legminimalisabban terjenek el. Mert ugy lesz ertekelheto az eredmeny. Aki meg 32gb memoria mennyiseghez 32-bites operendszert valaszt, az idiota.

Technikai dolgot is fogsz említeni, vagy ezek csak afféle megérzések? Leírták, hogy hol a probléma:

"We have been doing some fairly close analysis and it comes down to a few additional microseconds overhead per batch in Direct3D which does not affect OpenGL on Windows."

Azt is, hogy dolgoznak rajta:

"Now that we know the hardware is capable of more performance, we will go back and figure out how to mitigate this effect under Direct3D."

--
trey @ gépház

Most az fáj akkor, hogy a binugzos portolásnak köszönhetően a win-es változatot is optimalizálták? Vagy csak a szokásos farokméregetésnél van most az, hogy a szőrszálakat egyenként nyálazgatod végig, hátha befolyásolták a mérést? Nemábazz...

Épp arról ment a múltkor a találgatás, hogy mennyivel lesz szarabb a portolt változat, hát ezek szerint versenyképes, amin persze lehet bosszankodni is.

Régi Windows-huszár FUD-ok látszanak megdőlni. Az látszik, hogy minimális akarattal lehet akár Linux-ra is játékot fejleszteni. Nem kell más ehhez, mint egy-két szakképzett programozó, egy elkötelezett fejlesztőcég és együttműködés a hardvergyártókkal.

Kíváncsi leszek, hogy mi lesz a vége ennek. Ha összejön a Valve-nak, azt hiszem, hogy sok hozzáértő Windows huszár próbálja majd elásni régi fórumkommentjeit ebben a témában.

--
trey @ gépház

"Régi Windows-huszár"
LOL! Ez kedves, de messze nem. Nem biztos, hogy a kommentekbol pontos kepet kapsz. De mivel te azt hiszed, hogy mindent tudsz...

Miért az az igazság, hogy régen is jók voltak a linuxos driverek csak nem fejlesztettek rá játékot? :)


No rainbow, no sugar

A linuxos játékfejlesztés és karbantartás elsődleges akadályai nem a driverekben vagy azok teljesítményében keresendőek, hanem a "linux" sokszínűségében.

Ha elolvasod a korábbi bejegyzéseket a Valve linuxos blogjából, akkor láthatod, hogy egy konkrét Ubuntu verzióra (12.04 azt hiszem) készítették el a programokat. Ez azt jelenti, hogy egy adott driververziót, kernelverziót, glibcverziót, rosszabb esetben SDL meg hasonlóverziót használtak.

A rossz rész akkor fog jönni, amikor megjelenik a 13.04-es Ubuntu, és akár a felhasznált API-k, akár az ABI-k változnak. Ezekhez hozzá kell majd igazítani a programot (ami várhatóan nem nagy munka), és mögé kell tenni a kiszolgáló infrastruktúrát: új verziók a játékból, azok letölthetővé tétele, annak elmagyarázása a felhasználóknak, hogy pontosan melyik változatot töltsék le a játékból... Ez utóbbi a nagy falat, sok munkába kerül.

(Gondolj bele, hogy mennyit szenvedtek/szenvednek az Ubuntu honlapján azzal, hogy a telepítő CD-ből a 32 vagy a 64 bites változat legyen a default... Brr... Na, ilyen problémákból van sokkal-sokkal több egy játékkal.)

A Valve pont az, akinek a Steam képében ez rendelkezésre áll ehhez az infrastruktúra, úgyhogy hajrá nekik, de simán el tudom képzelni, hogy más cégek számára egyszerűen nem termelné vissza a költségeket egy-egy játék linuxos kiadása.

"annak elmagyarázása a felhasználóknak, hogy pontosan melyik változatot töltsék le a játékból... "

Steam elindít, játék kibök, downloadra rábök.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezt mondta ő is.

--
trey @ gépház

"A Valve pont az, akinek a Steam képében rendelkezésre áll ehhez az infrastruktúra..." - tudom...

Az id ás más fejlesztők Linuxos portjai köszönik szépen jól vannak, szóval erős a gyanúm, hogy ez a kérdés is túl van misztifikálva...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Eddig sem azért nem készültek játékok Linuxra, mert technikailag teljesen megoldhatatlan lett volna.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ebben 100%-ig biztos voltam már 2004-ben is. Nekem felesleges bizonygatnod.

--
trey @ gépház

Igazandibol meg az lehet a kerdes, hogy ugyanolyan textura-reszletesseget, plusz effekteket, etc. hasznaltak-e a direct3d-nel mint a gl-nel.

Amugy az id mar regatota meg tudja csinalni kvazi szepen platformfuggetlenre a c kodjait, nem lehetlen ez. Nyomtam q3arenaval linuxon en is. Ami viszont gaz volt, hogy par dist-upgraddel kesobb az installer mar nem volt hajlando felpakolni a jatekot:P Ez is egy fontos aspektus, a bolondbiztos es idotallo installer/futtato kornyezet - erre kell meg ragyurni, pl repobol installalhato jatekok...ubuntu appstore? vagy most lesz valve appstore vegulis a steam-mel.

-- dupla --

> Aki meg 32gb memoria mennyiseghez 32-bites operendszert valaszt, az idiota.

IMHO meglévő játékot portolnak, amit valószínűleg eleve a 4GB címtér limittel terveztek, mivel a vevők többsége 1-2 éve még ilyen géppel nyomult. Így aztán a 64 bit nekik felesleges.

Így aztán a 64 bit nekik felesleges.

Igazabol nem felesleges itt sem a 64 bit, leven a vilag joforman egyetlen 64 bites architekturaja az x86, ahol a valtas ekkora teljesitmenynovekedessel jart, mert volt lehetoseg par tornazsak kirugasara, mint pl. az, h x86-on modern os alatt 5 szabadon hasznalhato regiszter van, mikozben a legputterebb arm-on is ott figyel a 2-3-szorosa.

Inkabb kodkompatibilitasi kerdesek miatt ragadtak le a 32 bitnel. Ki a halalnak van kedve idonkent tobb eves - sokszor szarul megirt kodokat - atfaragni, az endian vadaszat a legputterebb melo a vilagon.

---
pontscho / fresh!mindworkz

Menedzselt nyelvek esetén (Java, C#) a pointerek növekedése miatt mérhető memória foglalás növekedést és lassulást (mem sávszélesség miatt) okozhat a 64 bites átállás. Az alkalmazáson sok múlik, a játékok persze tipikusan nem ilyenek szoktak lenni.

Termeszetesen nativ kodrol volt szo.

---
pontscho / fresh!mindworkz

Annyira örülök, amikor elavult ismeretekkel osztják az észt:
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop

Az UseCompressedOops paraméter kb. 4 éve létezik, Java6u23 óta default be van kapcsolva.

gondolom az lehetett a 64 bites windows valasztasanak oka, hogy a 32 bitesek kozul egyik $home kornyezetbe szant verzio sem kezel ennyi memoriat. a 32 bites ubi meg siman.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx

De nincs rá Photoshop!!! :P

:)

Ezt a hozzászólásom a photoshoppal szerkesztettem!

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

De kár! :)

Olyan édes, amikor valakinek az fáj, hogy az általa nem használt rendszerhez/rendszeren fejlesztenek valamit.
Mind Windows, mind Linux oldalról.

Avagy subscribe, jó kis flame lesz ebből a topicból, már várom :-).

+1 :)

A 30 versus 120 fps szálhoz egy gondolat, vagy inkább merengés.

Nem szimplán arról van szó, hogy ez az érték az egész rendszer teljesítményének a korlátja? Azaz ha 30 fps-t tud a vas/oprendszer a játékkal, akkor ott bármiféle plusz terhelés (pl. komolyabb fizikai számítások, hálózat kezelés, multiplayer, satöbbi) már érezhetően, szaggatósra terheli a rendszert, míg ha 120 fps-nél van a határ, akkor ha plusz terhelést kap, akkor még 60 fps-nél is komoly tartalékokkal, egyenletesen, jitter, ugrálás, kihagyás nélkül megy a rendszer?

Nem.

:)

sub :)

+1

Nagyszerű hír! Tegyenek bele framerate limitert is. Elég nekem 40-60 FPS is. Ne melegedjen és ne zabáljon a gép feleslegesen.

A HUPra pedig Flamerate (de)limitert. :)

Source engine része.

fps_max X

X = érték

Végre ilyeneket is olvasni.
Remélem sikeres lesz ez a projekt, és folytatják gyengébb vasakon is a tesztelést.
Engem mondjuk az is érdekelne mit tudnak kihozni egy sima i5, i7 "gpu"-ból.

Az Intel mérnökeivel is együtt dolgoznak, így elég valószínű, hogy ott is lesz előrelépés.

Nagy újdonság...
Annak idején (főleg)azért szoktam át a linux desktopra, mert a Quake3 Aréna több fps-sel futott debian woody/sarge alatt, mint windows xp-n. És pont az a különbség kellett a játszhatósághoz.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

azt nem tudjátok hogy ezek az opengl-t érintő változtatásokat vajon már tartalmazzák-e az új patchek? mert kb hetente 2x szoktak frissítések jönni (nekem legalább is ilyen gyakorisággal frissíti a steam kliens a source motoros játékokat, és a hír óta már megint volt egy 200 mb-os frissítés)...

Miért nem kérdezed meg tőlük?

kikre gondolsz??? :)
egyébként most néztem és a team fortress 2 beállításai között nem lehet váltani a directx és az opengl között (legalább is én ilyen opciót nem találtam win7 64bit alatt)

Steam supportra. Az ilyen kérdések miatt is vannak. :)

volt itt valahol szo team fortress 2 rol?
ps

--
http://blog.sartek.net | https://twitter.com/sartek

team fortress 2-t ugyanúgy source engine hajtja mint a L4D2-t
ha a L4D2-vel az engine portolásra kerül akkor a valve szakembereinek nem lesz nehéz az összes ilyen motoron futó játékot átírni
és nem kevésről van szó :D
http://en.wikipedia.org/wiki/Category:Source_engine_games
és akkor még a hl2 modokat és a source sdk-t nem is említettem:
http://store.steampowered.com/mods/220/
de ez még mindig nem az összes mert az "Age of Chivalry"-t, "Synergy"-t és még sok más modot nem listázza ki a steam (nem tudom miért) pedig ezek is húzó címek

>team fortress 2-t ugyanúgy source engine hajtja mint a L4D2-t

haaat, azert ez nem 100%osan van igy, l4d2-et ujabb(mas) verzio hajtja

--
http://blog.sartek.net | https://twitter.com/sartek

LGB: "Nem szoktam jatszani, ezert nem is ertem ... igazabol ezt konkretan sose ertettem: mitol jo a 120fps? Az emberi szem nem kepes kovetni a kulonbseget - legalabbis _szerintem_ - ugy kb 30 ftps utan, teljesen felesleges tobbet. Vagy mit tudok rosszul, valaki arulja mar el."

Ezért próbálják magyarázni azok, akik szoktak játszani és értik.
Szerinted nem képes az emberi szem követni a különbséget 30FPS fölött. Ez már önmagában is megdöbbentő, mert a 30 FPS olyan triviálisan kevés, hogy éppen hogy elfogadható, az alatt már kifejezetten szaggatós, szar.
Ha 60FPS-t írtál volna, akkor azt mondom, hogy csak tapasztalatlan vagy, mert sokak szerint annál nem kell több, mert nem látható.
Ha jól látom a hozzászólók közül többen meg tudnak erősíteni abban, hogy a 60 FPS fölött is érezhető a különbség (=javulás), én magam egészen biztosan a 100 FPS-t jelölném meg, ami fölött már (TALÁN) tényleg nincs jelentősége, de hadd mondjam el neked, hogy én nem csak a 60 és 72 vagy 80 FPS között látok lényeges különbséget, hanem a 90 és 100 FPS között is érezhető a javulás.
Hogy mi a javulás? Írták mások is kicsit konkrétabban: 3 labda helyett 6-ot vagy 10-et látsz, nem igazán értetted miért jó ez. Ennek az az oka, hogy olyan játékokkal játszottál, vagy olyan kezdő módon játszottál (és ez nem lenézés, nem pejoratív itt, és nem bántás, mert mindenki ilyen míg nem ér el egy bizonyos szintet egy csomó idő után), szóval olyannal és/vagy úgy és/vagy olyanokkal játszottál, ahol lényegtelen. Amíg az átjárókban akadozol, vagy kerülgeted azt amit át lehet ugrani addig mindegy. Észre sem veszed.
Ha elég jó játékos vagy és elég jó ellen játszol, akkor észre fogod venni, hogy egyforma erősen is nagyon kikapsz, mert előbb lát meg, előbb lő: ennyi elég: mindig kicsit előbb lát - nagyon megver. Mellesleg folyamatosabb és szebb is az élmény.
Ha érdekel még érdekességként: ha komoly játékos vagy, akkor nem 30 ms (30 ezredmásodperc = 0.030 mp) késleltetésbeli különbséget, hanem 5 azaz öt ms (0.005 mp) késleltetésbeli különbséget érzékelni lehet, az érzékelni lehet padig azt jelenti, hogy ha 5-10 ms-mal nagyobb a késleltetés akkor érezhetően szarabbul tudsz játszani mások ellen.
Hidd el ezek nem csúsztatások, nem túlzások, csak van aki még ezeket nem fedezi fel, és persze nem pasziánsz-versenyről beszéltem és nem pókerről.
30 FPS esetén 33 ms-omként jönnek a képek. 100 FPS esetén 10 ms-mal. 23 (!!!) ms - óriási különbség már önmagában. Persze ehhez tartozik még 500 vagy 1000 Hz-es mintavételi frekvenciával dolgozó egér is.
Nézd csak meg a valaki által belinkelt Quake3 CTF videókat: ezek nem a véletlen, vagy szerencse művei, bár nyilván a szebb részek vannak a videóban, de (nekik) egy átlag meccs hasonló (volt).
Ezért jobb egy 100-120Hz-es CRT monitor a 60 Hz-es LCD/TFT-nél játékra (hiába a 2 és 5 ms, amit ráírnak, ha 60 vagy 72 Hz a képfrissítési frq).

Amit meg hozzatennek a CRT vs LCD temakorhoz: ami szerintem meg igen hangsulyos, az az input lag, ami nem keves tud lenni. Pl. ott a Dell 2408WFP-m, nagyon jo kis monitor, de azert erezhetoen van input lagja. (Talan teszteken 2 fps-t irtak anno...) Ezt anno, mikor Half-Life-ban toltam DM-et, elegge eszre is vettem.

Azonban miutan egy jatekbol sem kivanok versenyszeruen jatszani, csupan kikapcsolodasbol, inkabb egy jo TFT, mint egy CRT.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Én mértem ilyen monitort, a 2 fps az a minimum lag, átlagban megvolt 5 fps is. ( Többek között például ezért jobb a 100 fps, mint a 30, ha az input lagot levonjuk, akkor 95/25 az arány, és erre még rájön az ingadozás. )


Puppy linux felhasználó