@P@pi
1) Jde o to, ze zadne API neda uzivateli (-programu, ne toho API) nic (primo). Proto DX10 v tomto IMO nemuze byt horsi nez kterekoli jine. Naproti tomu, pokud posuzujete neprimy uzitek (vyplatu v pulce dalsiho mesice), pak je a) obrovsky, i kdyz neni zatim videt; b) stejny, jako u jinych povedenych API, protoze vzdy ho nejdrive musi vyuzit programatori, nez se vysledky dostavi k uzivateli (v kazdem zamestnani dostanete penize az dalsi mesic, takze kvuli tomu nebudete jedno zavrhovat). Screenu bude jiste jiz v pristim roce dost, ackoli o celoplosnem rozsireni se nebude dat mluvit jeste asi radu let. 5) Prave ta veta, kterou jste sem nyni vlozil, dava smysl. Staci ji prelozit. Nemluvi se v ni totiz vubec o "narustu pametove narocnosti" - ten se objevil ve chvili, kdyz poprve programator vyuzil 128bitovy format textury, ne tehdy, kdyz mu nekdo slibil (DX10.1), ze s ni muze delat povedene kousky a budou fungovat vsude. Tohle je neprijemny dopad (uprimne ci dobre myslene) snahy fakta pri prekladu z cizich materialu "okecat", pritom to puvodni sdeleni je spravidla jasne, vystizne a presne... 3) Dekuji, uz me to nerajcuje :) Vlastne me to uz vubec nerajcuje, ve skutecnosti jsem si tu vubec nechtel s nekym dopisovat :) Pouze muj pohar tolerance nepresnosti ve vyjadrovani a faktickych, gramatickych ci slohovych chyb pretekl prave u Vaseho clanku, ackoli zrovna ten by si to zaslouzil mene, nez mnohy jiny tady i jinde (prinejmensim po gramaticke strance:). Takze jsem se nechal trochu unest (omlouvam se) a hnidopissky to vsechno zkritizoval.
@P@pi
1) Pokud berete v uvahu neprimy vytezek, pak je ten Vas vyrok prinejmensim kratkozraky, protoze uzivatele (predevsim hraci) z toho budou tezit obrovskou merou ve chvili, kdyz native DX10 tituly zaplavi trh. Vzdyt to je jako tvrdit, ze z chozeni do prace nic nemate, protoze vyplatu dostanete az v pulce dalsiho mesice... 5) Ne tak docela. To co tam (i nyni) pisete, by znamenalo, ze prechod na DX10.1 prinese vetsi pametove naroky kvuli nutnemu pocitani s FP32. Jenomze tak to neni - naroky na pamet jsou pro DX 10 i 10.1 stejne a odpovidaji volbe formatu textury. Pouze s 10.1 ma programator garantovano, ze kdyz pouzije 32bitovy format textury, tak mu to pobezi na kazde karte stejne. 6) Spatna interpretace - "64bit integer pixel format" je format textury, kde kazdy kanal je celociselny a 16bitovy (napriklad R16G16B16A16_SINT). VYPOCTY, ktere zminujete, budou 16bitove. 3) Kdyby se micky chovaly nezavisle, tak vypocty muzete idealne paralelizovat (nezavisle operace jsou novodobym snem programatora :)) a na 1000 vypocetnich jednotkach si spocitate 1000 micku za cenu jednoho. "Nezavisle" a "musime serializovat" nejsou pojmy, ktere by sly dohromady.
Ackoli je to obecny trend vsech ceskych internetovych IT magazinu, tady mi to neda a musim vytknout uroven clanku: 1) "Po nepříliš úspěšném DirectX 10, jenž koncovým uživatelům nic moc nepřineslo, se nikdo nemůže divit" -- tahle veta postrada smysl. Ktere API kdy co prineslo uzivatelum? API je pro programatory a uzivatele se to muze dotknout pouze neprimo diky jejich produktum! DX10 je revolucni skvele navrzene API a az vejde v obecnou platnost (=bezna podpora low-end HW), tak se to ZATRACENE odrazi na kvalite her, protoze programatorovi usetri pekny ranec trablu. 2) "Multi-sample buffer reads and writes - obecně kvalitnější FSAA" -- zvlastni vystrel do tmy. Tohle je ale specifikum uz DX10. U DX10.1 se pouze pridala ta sama podminka pro depth buffer. 3) "Totiž kolize míček - míček je zcela pochopitelně věc počítaná sériově, každý míček se chová "nezávisle" a nelze přesně určit, co se stane v dalším okamžiku." -- aha! Takze protoze micky se chovaji nezavisle, tak se pocitaji seriove? :) 4) "Je stanoven minimální požadavek na 4 vzorky MSAA (minimální podpora 4x MSAA) - to vše samozřejmě ve spojení výpočtu s shadery jak je vyžadováno u DirectX 10." -- ve spojeni vypoctu s shadery? To je nejaky dramaticky preklad ci co? Co tim chtel vlastne basnik rici? 5) "Nutnost počítání čísel v plovoucí desetinné čárce pomocí FP32 (což je dvakrát tak náročný výpočet oproti dosud převážně používané FP16). ..." -- cely tento odstavec je nesmysl. Jedine co se v tomto smeru pridalo, je povinna podpora FILTRACE FP32 textur, vsechno ostatni zustava stejne. Jeste stale jsou podporovany (a nejblizsi desetilieti jiste budou) FP16 textury a rozhodne tedy neni 16bitovym flatum konec. Proto take zminovane "vetsi naroky na pamet" postradaji smysl - porad mate sirokou volbu texturovych formatu a kazdy ma sve pametove naroky! (Tedy, dobre, abych to neprehanel - posledni veta o HDR je rozumna :).) 6) "Výpočty s pevnou desetinnou čárku při "míchání"/spojování textur (blending) musí nutně být typu Int16, tedy 64-bitové výpočty." -- ne, nemusi, a nejsou 64bitove. Stejne jako v pripade FP32 filtrace - povinna je pouze podpora, programator ma stale moznost vyuzit jine formaty textur s nizsi presnosti. Mimochodem, Int16 textura obnasi 16 bitu na kanal (prekvapive), takze vypocty jsou 16bitove (v pripade 4kanalove textury to znamena ctyri 16bitove vypocty - docela rozdil). ... ja vim, ze rychly (nesmyslny) preklad odstavcu ze zahranicnich clanku je levnejsi, ale casto takovy clanek pak postrada prakticky vyznam!
