PCTuning fórum

Pri počítaní plávajúceho priemeru vždy s ďalším snímkom jedna hodnota odpadne a druhá pribudne, čiže totožný plávajúci priemer pre dva po sebe nasledujúce snímky bude iba výnimočne a to vtedy, keď hodnota ktorá pribudne bude totožná s hodnotou ktorá odbudne (čiže ak hodnoty x-2 a x+3 sú totožné, pričom x je poradie aktuálneho snímku). Pozri si stĺpec B v prvom príklade, je tam vidno že sa neustále mení.

To že sa pri po sebe nasledujúcich snímkoch opakujú 4 hodnoty z 5 je zámer, je to podstata plávajúceho priemeru, ide nám o vyhladenie priebehu grafu aby sme približne zistili priemernú náročnosť danej scény. Nesmie ich byť ani príliš málo lebo sa nám z rozptylu čiastočne stratí vplyv microstutteringu (príklad 2, aj keď tam je to dané hlavne rozdielom medzi periodicitou a počtom snímkov pre plávajúci priemer - keby sme do plávajúceho priemeru brali párny počet snímkov tak rozptyl vyjde rovnako ako z celkového priemeru), ale ani príliš veľa, lebo nám aj zmeny v náročnosti scény budú zvyšovať rozptyl (príklad 1 s celkovým priemerom).

yuri.cs - čo sa týka presného počtu snímkov ktoré budú reprezentatívne, to bude najlepšie zistiť experimentálne s viacerými hrami a kartami, poskúšať 3, 4, 5, 6...
Nepárne majú tú výhodu že berieme rovnako veľa snímok pred aj po aktuálnom snímku a berieme do úvahy aj hodotu aktuálneho snímku. Párne zase lepšie spriemerujú periodické výchylky (príklad 2, tam vidno že nepárny počet snímkov takéto periodické zmeny nespriemeruje práve najlepšie), len treba zistiť či bude lepšie zobrať o hodnotu viac vzadu, o hodnotu viac vpredu alebo vynechať hodnotu aktuálneho snímku (čiže napr. pri nastavení 4 snímkov by bralo dva snímky pred a dva snímky za, pri 5 by bralo dva snímky pred, aktuálny snímok a dva snímky za).

Tak jsem narychlo ale zběžně nastudoval plovoucí průměr a musím říct, že to opravdu vypadá velmi dobře

@xwing: Udělal bych to tak, jak říkáš.

1. Uživatelské nastavení délky klouzavých průměrů
2. Pokud by to bylo liché číslo, pak je to jasné
3. Pokud by to bylo sudé číslo, pak bych bral půlku nad a půlku pod aktuální pozicí (aktuální středová pozice by byla vynechána z výpočtů)
4. Projít takto všechny záznamym, sumarizovat rozptyly a vydělit jejich počtem
6. Odmocnit na směrodatnou odchylku

Zapomněl jsem na něco?

Myslím že nie, už iba vyskúšať ako to dopadne na reálnych dátach.

Ještě není hotovo, ale zatím to vypadá velmi nadějně

PS: Určení počtu vzorků se mi zatím jeví jako nejlepším řešením vzít nějakou časovou hranici viditelného micro-stutteringu třeba 40ms (25Mhz/fps), vydělit ho průměrnou latencí a zaokrouhlit na celé číslo.

Příklad pro průměrnou latenci 16ms: 40 / 16 = 2,5 => 3 snímky (vzorky pro klouzavý průměr)
Nějaká jiná idea?

chlapi pekná práca , klobúk dole

@dexterav: Díky, ale vidíš, že se na tom nepodílím sám

@xwing, yuri.cz a ostatní
Takže definitivně už můžu říct, že to, co xwing navrhl ohledně zjištění hodnoty micro-stutteringu funguje a to celkem parádně

Raději ještě vysvětlím o co jde na příkladu:
Mám naměřené latence gpu: 24, 22, 25, 23, 22. Při hodnotě vzorku 3 procházím soubor po 3 měřeních a počítám rozptyl následně:

Klouzavý průměr: (24 + 22 + 25) / 3 = 23,6666
Odchylka středu: 22 - 23,6666 = 1,6666 ms
Posunu se o jedno měření vpravo
Klouzavý průměr: (22 + 25 + 23) / 3 = 23,3333
Odchylka středu: 25 - 23,3333 = 1,6666 ms
Posunu se opět o jedno měření vpravo
Klouzavý průměr: (25 + 23 + 22) / 3 = 23,3333
Odchylka středu: 23 - 23,3333 = 0,3333
Zprůměruju odchylky: (1,6666 + 1,6666 + 0,3333) / 3 = 1,2221
Výsledná odchylka tedy je 1,2221 ms

Vlastně klouzavým průměrem křivku "vyhladíme" a počítáme proti němu odchylky jednotlivých bodů. Tato výsledná odchylka nám potom ukazuje míru micro-stutteringu.

Je tam však několik úskalí, které bude nutno vyřešit. Je to především určení hodnoty pro specifikování rozsahu klouzavého průměru vůči kterému se vypočítává odchylka. Je to ten počet hodnot, ze kterých se vypočítává onen klouzavý průměr.

Doprogramoval jsem do aplikace takové testovací okénko pro zjištění odchylek při různě stanoveném počtu vzorků pro klouzavý průměr.


Můžete počítat odchylku buďto jednotlivě, nebo je projít ve smyčce a ukázat na grafu.

Testováním jsem zjistil následující:
1. U sudých čísel je malý problém, protože nemají střed.
Pokud bych použil ten příklad, tak pro číslo 2 (počet vzorků):
Klouzavý průměr: (24 + 22) / 2 = 23
Odchylku pak nejde počítat vůči středu (není tam středová hodnota)!

Na sudá čísla by se tedy musely použít vzorky o jedničku větší a neprůměrovat středovou hodnotu:
Klouzavý průměr: (24 + 25) / 2 = 24,5
Odchylka: 22 - 24,5 = 2,5 ms
Jak patrné, ono by to takto šlo, ale vypočtené odchylky jsou pak extrémnější!
Průběh vidíte na tom obrázku. Zatímco u sudých čísel se zvyšováním hodnoty odchylky klesají, u lichých naopak odchylky stoupají. Otázka tedy zní, můžeme tedy vůbec sudá čísla pro velikost vzorků použít?

2. Bude nutné určit (testováním) jaká hodnota této MS odchylky bude ukazovat na hranici, po které již následuje viditelný MS.

No, vyzkoušet a otestovat si to můžete sami. Výpočet MS odchylky najdete v testovacím okně, které spustíte v okně "Průběh latencí" - nahoře je tlačítko s červeným textem "Test micro stuttering podle xwing >>".

Upravenou aplikaci stahujte zde (link zrušen nstahujte) >>

Micro stuttering podle xwing ještě nemám dodělaný, ale aby řeč nestála, tak dávám do placu malý závdavek, jako to bude asi vypadat.

Analýza micro-stutteringu

Pozn.: Ta korona nad vyhlazenou křivkou latencí udává odchylky jednotlivých snímků - (micro) stuttering.

Závěrečná analýza křivky naměřených latencí


Nějaká idea, jak to lépe zobrazit?

Program vypadá stále lépe a lépe, to měření stutteringu a microstuteringu podle xwinga dává docela smysl, dobrej způsob na detekci té "chlupatosti" - což je vlastně míra microstutteringu. Stuttering jsou pak vlastně ty náhodné skoky na třeba 3x delší framy.

Ale bude to opravdu zajímavé porovnání až tímhle proti sobě někdo prožene nějakou grafiku od AMD vs nvidie a bude se snažit je podle všech výsledků co z toho vylezou objektivně ohodnotit.

Ache píše:Ale bude to opravdu zajímavé porovnání až tímhle proti sobě někdo prožene nějakou grafiku od AMD vs nvidie a bude se snažit je podle všech výsledků co z toho vylezou objektivně ohodnotit.

No tohle se bude muset (resp. Vy budete muset, protože já hry moc nehraju) otestovat jestli to výsledné skóre bude odpovídat realitě. Z matematického hlediska asi ano, ale bůh ví, co se z toho vyklube v praxi.

Jinak, ta analýza podle xwinga opravdu funguje, co ale přinesla konkrétně mě? No, ohromný nárůst požadavků na výpočty, který při výpočtu stutteringu u "naducaných" souborů dat (více jak 30 tisíc) "drtí" mojí i5-ku

Nezbývá tedy nic jiného, než aplikaci upravit pro zpracovávání dat vícero thready.
Jedno vlákno bude na pozadí zpracovávat výpočty a druhé vlákno pak zobrazovat výsledky na grafu.
U průběhu latencí a výpočtu stutteringu je již hotovo a zbytek dodělám v brzké době. Pokud bude čas, tak bude hotovo v příštím týdnu vše.

PS: Rád bych taky upozornil na pěkný prográmek od chlapíka s nickem havli, který řeší něco podobného, ale pro více grafik najednou.
http://pctforum.tyden.cz/viewtopic.php? ... 9#p8449079

Takže po delším čase něco nového.

Nová verze aplikace obsahuje:
1. Analýzu stutteringu podle xwinga
2. Finální vyhodnocení křivky latencí a pokus o ohodnocení gpu
3. Aplikace kompletně přepracována na multi-vláknové zpracování dat
4. Oprava několika chybek

Stahovat můžete zde >>

PS: Omlouvám se, ale v poslední době není moc času. Jakmile se nějaká volná chvilka objeví, budu pokračovat v popisu funkcí aplikace. Ještě zbývají percentily, nově pak stuttering, vyhodnocení gpu a na závěr snímková frekvence. Snad kromě těch percentil by to pro vás mohlo být celkem i zajímavé (tedy doufám v to )

Jo, je to hodně zajmavé. Už to má i pěknou ikonu. Vypočítává to snad téměř vše možné co lze z průběhem framů dělat. Dobrá práce.

Postupně si zkusím vygenerovat více frametimes průběhů z různých her jestli někde přece jen nenarazím na něco podivného.

@Ache: OK, díky za každý test.

Ačkoliv se mi do toho moc nechce, tak budu pokračovat v popisu aplikace - tentokrát o percentilech. Vzhledem k tomu, že už jsme tu o nich diskutovali, tak jen zběžně.

Pecentily


Tento průběh je grafickým vyjádřením 50-té až 99-té percentily. Jak se X-tá percentila vypočítává už tu bylo, tak snad jen krátce.
Máme soubor dat (naměřených latencí):
24, 22, 25, 23, 22, 24, 24, 23, 23, 23, 23, 28
Ty si seřadíme vzestupně podle velikosti zleva doprava:
22, 22, 23, 23, 23, 23, 23, 24, 24, 24, 25, 28
99th pecentila se nachází na 99% pozici v řadě
99th = (99 * 12) / 100 = 11,88 (pozice), zaokrouhleno na nejnižší celé číslo - 11 (pozice)
Na 11 pozici zleva doprava leží hodnota 25 (25 je tedy 99-tou percentilou)
50th percentila se nachází na 50% pozici v řadě
50th = (50 * 12) / 100 = 6, zaokrouhlovat tentokrát nemusíme - 6 (pozice)
Na 6 pozici zleva doprava leží hodnota 23 (23 je tedy 50-tou percentilou)

Vlastně by se dalo říci (nepřesně), že u 99th percentily zahodíme 1% nejhorších výsledků a zbylý nejhorší výsledek je právě ta 99th percentila.

Promítnuté percentily


Tady nejde o nic jiného nežli o to, že vypočítané percentily (50,60,70,80,90 a 99th) označíme na grafu průběhu latencí abychom viděli, z jakých částí grafu vlastně pocházejí.

Závěr:
Osobně musím říct (opakuji se už po sté) , že se mi poměřování gpu podle 99th percentily moc nelíbí, ale netvrdím, že to je něco zvrhlého. Něco to opravdu ukazuje, jen si nemyslím, že moc přesně
Hodně webů nyní porovnává gpu i cpu podle 99th percentily a aby toho nebylo málo, některé weby (tomshardware) dokonce podle 75th percentily (horní kvartily).
Je jasné, že jsou percentily lepším způsobem porovnávání, než holé průměrné fps, ale myslím, že se tady postupně dopídíme k sofistikovanějším způsobům porovnávání gpu. Ale o tom snad příště

PS: Nezapomeňte, všechny vaše připomínky a náměty jsou zde vítány

Abych nějak pokročil, tak dneska se dostaneme k další funkci aplikace FrapsCut a doufám, že to pro vás bude už zajímavější čtení než minule o percentilách

(Micro)Stuttering


Na obrázku vidíte klasický průběh latencí gpu (tady to je konkrétně HD7870 v BF3). Ta "chlupatost" křivky je způsobena opakovaným střídáním nižších a vyšších latencí. Latence je doba, za kterou gpu vyrenderuje jeden snímek. Ideálním stavem by bylo, kdyby gpu renderovala všechny snímky se stejnou latencí. Výsledkem by pak byla krásná vodorovná přímka v grafu podobná (totožná) přímce průměrné latence (ve výše uvedeném obrázku žlutá čára). V praxi tomu tak však není ani náhodou. Stuttering sice na grafu vidíme už teď, ale jak ho vyjádřit nějakým číslem, které bychom mohli následně porovnávat vůči jiným gpu?

Pokud bychom středem té "chlupaté" křivky vedli po celé délce grafu čáru (pomyslný střed křivky), viděli bychom jednak, že se tento střed křivky kroutí jak had kolem přímky průměrné latence, ale také bychom mohli vypočítávat odchylky jednotlivých bodů (latencí) od tohoto pomyslného středu u každého vyrenderovaného snímku (zjistili bychom míru stutteringu).
Prvním úkolem tedy je "vyhladit" tu "chlupatou" křivku průběhu latencí tak, aby nám vznikla ona jednolitá čára v jejím středu. Druhým úkolem je pak vypočítat odchylky jednotlivých bodů od této "vyhlazené" čáry, což už je brnkačka. Průměr těchto vypočtených odchylek nám pak dá číslo, kterým můžeme operovat při porovnávání stutteringu různých gpu.

1. Vyhlazení "chlupatosti" - klouzavý průměr
Díky xwing a jeho příspěvku zde máme nyní nástroj, pomocí kterého můžeme krásně vyhladit onu "chlupatou" křivku na její střed - klouzavý průměr. O co jde:
Jednoduše budeme procházet všechny latence a postupně průměrovat X sousedících latencí.
Máme následující naměřené latence a jako X zvolíme 5:
24, 16, 23, 18, 20, 19, 24, 20, 25, 18
Postupně procházíme latence a počítáme průměr z 5 sousedících hodnot (2 zleva, střed a 2 zprava).
(24+16+23+18+20) / 5 = 20,2
(16+23+18+20+19) / 5 = 19,2
(23+18+20+19+24) / 5 = 20,8
(18+20+19+24+20) / 5 = 20,2
(20+19+24+20+25) / 5 = 21,6
(19+24+20+25+18) / 5 = 21,2
dál už počítat nemůžeme (chybí další data)
Kdybychom výsledky zanesli do grafu vznikne nám ona středová křivka. Čím vyšší číslo použijeme pro hodnotu X, tím bude výsledná křivka hladší.

2. Odchylky od klouzavého průměru (stuttering)
Teď, když máme vypočteny klouzavé průměry (středovou křivku), můžeme počítat odchylky jednotlivých bodů od této vyhlazené středové křivky (počítáno v absolutních číslech).
23 - 20,2 = 2,8
18 - 19,2 = 1,2
20 - 20,8 = 0,8
19 - 20,2 = 1,2
24 - 21,6 = 2,4
20 - 21,2 = 1,2

Průměrná odchylka = (2,8 + 1,2 + 0,8 + 1,2 + 2,4 + 1,20) / 6 = 1,6 (ms)

A takto nějak to vypadá graficky vyjádřeno v aplikaci:


Ta červená křivka znázorňuje onu "vyhlazenou" středovou křivku, vypočtenou klouzavým průměrem s použitým X (počtem vzorků) 51 sousedících hodnot. Jak dobře je tato červená křivka vyhlazena můžete porovnat s "chlupatou" křivkou na prvním obrázku
Modrá "korona" nad červenou křivkou znázorňuje odchylky jednotlivých bodů (latencí) od této červené křivky. Průměrná hodnota ze všech odchylek je pak uvedena v legendě grafu (jako Average deviation).

Výsledky
Dosavadní testy na reálných datech ukazují, že výsledková hodnota stutteringu funguje zatím dobře, ale chce to ještě hodně dalších testů.
Pokud se tento výpočet osvědčí, máme tu krásnou, matematicky vyjádřenou, hodnotu pro poměřování "stutteringových pindíků" mezi různými gpu
Speciální poděkování zde patří xwingovi, bez kterého by tenhle výpočet asi nevznikl. No a když to fungovat nebude, aspoň to mám na koho shodit
Stejně tak "special thx" patří Achemu, který to vše testuje.

PS: Tu čevenou čáru na druhém obrázku aplikace normálně nevykresluje. Dodal jsem jí tam pouze pro lepší vysvětlení.

Jo tahle metoda by asi mohla pro porovnání míry microstuteringu posloužit dobře.

Možná by se tímhle způsobem dala i zjistit početnost stutteringu - těch delších záseků. Prostě že by se třeba 5x větší špičky než průměr zaznamenávaly zvlášť (třeba jejich počet za sekundu a pod.)... ale i teď to jasně ukazuje rozdíly mezi tím co je méně a více "chlupaté".

Zatím nejvíce u mě failuje moje oblíbená hra SR3:


- ale i přes to běží krásně plynule.

webwalker:

Vypada to opravdu dobre.
Schvalne jsem zkusil analyzovat dve svoje mereni - Bioshock na HD2900XT single a CF. V merene scene CF skaluje skoro 100%, ale taky je pritomen masivni MS. Tvoje analyza dava podobne vysledky, jako moje.... tedy, ze v tomhle konkretnim pripade je realna hratelnost na obou resenich stejna (i pres dvojnasobek fps na CF). Na slozitejsim prubehu by ale moje vysledky byly zrejme vzdalenejsi od reality. Muj pristup neni zdaleka tak vedeckej.

Ache:

Muzes pls nekde uploadnout tenhle log z obrazku vyse? Rad bych se na to podival detailneji. Pokud mozno oba soubory (*fps.csv a *frametimes.csv). Diky


2900XT


2900XT CF


2900XT


2900XT CF

@Ache: Myslím, že odchylka 1,9 ms sice není nic extra dobrého, ale zas na druhou stranu nic příšerného
Když si to zprůměrujeme tak odchylka 2 ms je vlastně střed (dejme tomu) z hodnot 0 a 4ms nad průměrem. Odchylky jsou vyjádřeny kladným číslem, takže následující (sousedící) odchylka může být zase průměrem od 0 do -4ms pod průměrem. Takže to tam může lítat v průměru od -4ms do +4ms což je rozdíl nějakých průměrných 8ms.
Způsobí 8ms micro-stuttering? Těžko říct, bude zde zase záležet v jaké oblasti to bude. Pokud někde kolem 50-60 fps tak asi ano, pokud to bude u vysokých fps tak asi ne, nevím. Kdybych to měl říct nějak "lišácky", tak žádný výsledek stuttering deviation ti asi neukáže, zda tam nějaký viditelný MS opravdu je, jen ti naznačí, že karta s vyšší odchylkou stutteringu bude mít pravděpodobnost výskytu MS vyšší než-li karta s nižší hodnotou této odchylky
Jinak u každého grafu je ještě kontextové menu, které aktivuješ klikem pravého tlačítka na graf. Menu obsahuje ještě nějaké funkce, které s tím grafem můžeš dělat. Konkrétně u analýzy stutteringu si třeba můžeš zarovnat odchylky k čáře průměrné latence. Přehledněji tam pak uvidíš kde je jaký typ a velikost stutteringu.
Jinak souhlas s Havli, hoď do placu tenhle frametimes.csv (navíc já ani nevím co SR3 vůbec je )

@havli: Hm, pěkné měření CF

U toho prvního grafu jsem až překvapen tou celkem vysokou odchylkou stutteringu, když to na grafu tak nevypadá. Že by to tam dělalo těch několik velkých propadů?
U toho CF je to pak jasné, tam musí být micro-stuttering i kdyby Klaus na Zemanovi jezdil

K těm celkovým skóre musím říct, že tam mám jednu záměrnou a trochu "nefér" věc (možná i chybu).
On je tam v tom celkovém skóre (součtu průměrné letence, odchylky křivky a odchylky stutteringu) započítán stuttering vlastně hned dvakrát.
Jednou nepřímo v odchylce křivky a jednou přímo v odchylce stutteringu.
Matematicky správnější by asi bylo, kdybych odchylku křivky počítal z té "vyhlazené" křivky klouzavým průměrem (vyloučil bych pak ten stuttering). Ale co, jen ať náchylné gpu ke stutteringu trpí

Jen by mě zajímalo, z tvých zkušeností, jestli opravdu je "herní zážitek" u CF stejný jako s jednou kartou (což to výsledné skóre naznačuje)?

PS: Hoď sem ty tvoje naměřené frametimes.csv a fps.csv taky, ať si to můžu vyzkoušet i na tvém programu.

Sleduju tohle vlákno už od začátku a musím k tomu říct jen svůj vlastní poznatek. Při vší úctě k práci autorů těchto programů,tyto programy jsou sice fajn fajn, protože jsme konečně schopni naměřit nějakou míru stutteringu či mikrostuteringu. Problémem ale stále zůstává fakt, že naměřené/vypočítané hodnoty neodrážejí reálnou situaci (tedy hratelnost) nýbrž čistý matematický průměr z průměru, jestli se to takto dá s nadsázkou říct. Celý problém "správného měření" framerates a latencí je totiž mnohem komplexnější než se na první pohled může zdát. Ve výsledku to je stále jen "číslo" kterému chybí "další rozměr". Jsme tedy schopni říct, že v určitých situacích trpí určité karty stutteringem víc než jiné, ale ve výsledném efektu jsme se nikam dál neposunuli, bohužel...

webwalker:

Tady jsou komplet moje namerena data: http://hw-museum.cz/data/Prubehy_fps_benchmark_VGA3.rar vcetne nakonfigurovanyho prohlizece. Muzes si z toho vybrat.
Ty screenshoty vyse pochazeji z Bioshock - maximum -> HD2900XT (CF) -> 1920x1200 noAA.

Ty propady se bohuzel vyskytuji skoro vsude. Tezko rict, jestli to je nejaka chyba v systemu, nebo to ty grafiky proste obcas generuji...

Co se tyce realny hratelnosti, tak si nepamatuju, jak plynuly to na single/CF vlastne bylo. Ono to uz je vic nez rok zpatky, co jsem to meril.... a taky tech mereni je opravdu hodne.
Ale dobre si pamatuju chovani v Oblivionu. Nejspis je zabugovana hra samotna, nebo ovladace.... ale to neni dulezity pro tenhle priklad. Vsechny Radeony HD chovaji naprosto opacne, nez by bylo prirozeny. Single karty maji obrovsky MS, CF naopak jedou normalne. Single ma 36,1 fps avg, CF ma 42,4. Prepocitany "real fps" jsou ovsem 15 pro single a 29 pro CF. A je tam opravdu na prvni pohled videt, ze na single jsou silny zaskuby, kdezto na CF ne. Ale jak rikam, tohle je opacna situace, nez nastava v 99% pripadu. Jeste jeden priklad si pamatuju z doby, kdy jsem pouzival HD3850 CF jako hlavni herni platformu. Hral jsem tehdy GTA IV a diky CPU limitaci to jelo kolem 35 fps. Zdalo se mi to ok, protoze jsem nevedel, jak vypada plynulost na single karte. Nedlouho potom jsem koupil GTX460.... a rozdil byl hned patrnej. Fps se sice nezmenily (CPU limit), ale plynulost uplne o necem jinym. Frapsem jsem to nemeril, ale odhaduju, ze na CF byly propady pod tech 35fps, kdezto na GTX ne. Tehdy jsem prave pochopil, ze AFR-based multi GPU je opravdu nepouzitelny.

Jinak, predpokladam, ze v Bioshocku to bude s hratelnosti +/- nastejno. Resp mozna na CF o chloupek lepsi, precejen to vygeneruje par fps navic. Obecne muj nazor na SLI/CF je ten, ze dve stejny karty jsou lepsi nez jedna.... ale jakmile je dostupne single GPU reseni s vykonem treba o 20% lepsim, dal bych prednost tomu.


del42sa:

Jak se to vezme, neni program jako program. Ja jsem se prave pokusil nejakym zpusobem odvodit "realnou hratelnost" z namerenych dat. A myslim si, ze to do jisty miry funguje. Samozrejme je to taky jen cislo... ale ono to jinak snad ani nejde. Nahodim sreenshoty z Oblivionu, jak jsem psal vyse:

Jen pro uplnost, takhle vypadaji klasicke prubehy.


Takhle vypadaji fps podrobne na single karte. Je zde pritomny masivni MS (sice diky nejakymu bugu, ne karte samotny... ale to nevadi). Z techto dat jsem prave spocital tech 15fps. Je to skoro minimum, takze se to da prohlasit za realnou plynulost. Kdyby to nebylo 15, ale treba 50 fps (se stejnym prubehem) - byla by to perfektne plynula hra, i pres MS.


A nakonec CF. Sice je tady taky MS, hlavne v prvni polovine prubehu. Ale vetsinu casu se fps drzi nad vypocitanou hranici 29 fps. Takze dejme tomu, ze by se to dalo hrat.