Jak již tady padlo tak paměť nežere binárka ale grafická a zvuková data. To je taky mj jeden z důvodů proč se začalo používat různých kompresních formátů na obrazová a zvuková data. pk3 a podobné legrácky na zmenšení místa zabíraného místa nadisku je jedna věc, ale dá se poměrně snadno udržovat i čisto přímo v paměti. třeba uchovávat i v paměti obrazová data v komprimované podobě a dekomprimovat až při použití (viz S3TC apod.) Jenomže spíš na tohle je spousta programátorů líná. Protože to znamená uzpůsobit na to jádro nebo knihovny, aby s tím uměly pracovat. Což znamená připsat kus kódu. Pokud používáte licencované cizí jádro máte docela složák.
Jen drobný detail, je sice krásné že to či ono má tak procesoru XXX GHz a podobně ale nezáleží pouze na kapacitě paměti a taktu procesoru. Problém je v tom, že celá tahle hračka je limitovaná svým nejužším hrdlem tj. pokud máte tak na procesoru 3GHz a na pamětech 400MHz se dvěma kanály, tak za před komunikace mezi CPU a RAM bude probíhat jak rychle? Podle procesoru? Ani omylem. V tomhle případě je limitujícícm faktorem takt paměti, pokud to stíhá sběrnice (3GHz procesor s FSB 400MHz je fakticky 400MHz CPU!, navenek z něj větší rychlost nevymlátíte i kdyby čert na koze jezdil) Pokud k tomu započtete i přesun dat RAM a disk pak je PATA IDE 133MHz jednoznačně ještě pomalejší.
A v neposlední řadě fault(halt) on zero pokud máte dlouhou pipelinu a procesor vám zkousne halt on zero, k čemuž zákonitě dřív či později dojde, a dochází k tomu až příliš často, vysype vám celou pipelinu a musí jí zaplnit znova.
Problém je v tomto případě v architektuře, nevím jak u PS??? ale u klasických 32bitPC CPU to bylo motání v začarovaném kruhu. A koneckonců pokud je 64bit zpětně kompatibilní s 086 tak jsme tam, kde jsme byli.
Jen drobný detail, je sice krásné že to či ono má tak procesoru XXX GHz a podobně ale nezáleží pouze na kapacitě paměti a taktu procesoru. Problém je v tom, že celá tahle hračka je limitovaná svým nejužším hrdlem tj. pokud máte tak na procesoru 3GHz a na pamětech 400MHz se dvěma kanály, tak za před komunikace mezi CPU a RAM bude probíhat jak rychle? Podle procesoru? Ani omylem. V tomhle případě je limitujícícm faktorem takt paměti, pokud to stíhá sběrnice (3GHz procesor s FSB 400MHz je fakticky 400MHz CPU!, navenek z něj větší rychlost nevymlátíte i kdyby čert na koze jezdil) Pokud k tomu započtete i přesun dat RAM a disk pak je PATA IDE 133MHz jednoznačně ještě pomalejší.
A v neposlední řadě fault(halt) on zero pokud máte dlouhou pipelinu a procesor vám zkousne halt on zero, k čemuž zákonitě dřív či později dojde, a dochází k tomu až příliš často, vysype vám celou pipelinu a musí jí zaplnit znova.
Problém je v tomto případě v architektuře, nevím jak u PS??? ale u klasických 32bitPC CPU to bylo motání v začarovaném kruhu. A koneckonců pokud je 64bit zpětně kompatibilní s 086 tak jsme tam, kde jsme byli.
Odpovědět0 0
Samozřejmě, že je bump mapping U3 pokročilejší, pokud by nebyl, tak by bylo něco špatně.
Co se týká vrhání stínů dynamickými a nedynamickými světly tak je problém v tom, že nativně není nastaveno bCastShadows na TRUE, ale je na FALSE. Pokud někdo vrhání stínů zapne pak i v U1 tohle funguje. viz. Thievery (www.blackcatgames.com).
Všechna dynamická světla. Hm no a proč by nešlo udělat i v U1 všechna světla dynamická. Je to jen otázka nastavení. Koneckonců jakýkoli zdroj světla v UX může být z principu dynamický viz paramery Light Effect a Light ... (teď si zrovna z hlavy nevzpomenu na jméno toho druhého), které umí to různé poblikávání a pod.
Jen tak na okraj k systémovým nárokům: zkoušel jsem Seven Bullets (SP modifikace do Ut s Oldskool od Red Nemessis Team) se zapnutými prakticky veškerými efekty renderování co jdou na následující konfiguraci:
Athlon 3000+XP, ASUS A7N8X-E FSB:333MHz, 512(768)MB DDR333, ASUS 9570GE (NV5700chipset), SB 5.1 Live! player, HD WDC 40GB 7200.ot,SegagateIV 80GB 7200.ot, obé s cache a UATA 100(možná 133 teď si nejsem jistý), OS: WinXP sp2 (udržovaný, čistý systém) UT 4.36, Oldskool 2.39.
Nebudu nic nalhávat, při kombinaci rozlehlých prostor, přítomnosti mlhy, dynamických světel a zapnuté baterky, dostal počítač, který je na takovéto staré jádro dostatečně výkoný, těžce zabrat a v některých situacích i začal cukat.
Problém je holt v tom, že výkonost dnešního HW roste po logaritmické křivce, a my se pohybujeme někde nad 1, takže přírůstek je malý.
Co se týká vrhání stínů dynamickými a nedynamickými světly tak je problém v tom, že nativně není nastaveno bCastShadows na TRUE, ale je na FALSE. Pokud někdo vrhání stínů zapne pak i v U1 tohle funguje. viz. Thievery (www.blackcatgames.com).
Všechna dynamická světla. Hm no a proč by nešlo udělat i v U1 všechna světla dynamická. Je to jen otázka nastavení. Koneckonců jakýkoli zdroj světla v UX může být z principu dynamický viz paramery Light Effect a Light ... (teď si zrovna z hlavy nevzpomenu na jméno toho druhého), které umí to různé poblikávání a pod.
Jen tak na okraj k systémovým nárokům: zkoušel jsem Seven Bullets (SP modifikace do Ut s Oldskool od Red Nemessis Team) se zapnutými prakticky veškerými efekty renderování co jdou na následující konfiguraci:
Athlon 3000+XP, ASUS A7N8X-E FSB:333MHz, 512(768)MB DDR333, ASUS 9570GE (NV5700chipset), SB 5.1 Live! player, HD WDC 40GB 7200.ot,SegagateIV 80GB 7200.ot, obé s cache a UATA 100(možná 133 teď si nejsem jistý), OS: WinXP sp2 (udržovaný, čistý systém) UT 4.36, Oldskool 2.39.
Nebudu nic nalhávat, při kombinaci rozlehlých prostor, přítomnosti mlhy, dynamických světel a zapnuté baterky, dostal počítač, který je na takovéto staré jádro dostatečně výkoný, těžce zabrat a v některých situacích i začal cukat.
Problém je holt v tom, že výkonost dnešního HW roste po logaritmické křivce, a my se pohybujeme někde nad 1, takže přírůstek je malý.
Odpovědět0 0
