Dat is idd echte (lossy) compression waarbij een blokje van 2x2 of 4x4 pixels worden opgedeeld in kleinere data. De hardware kan deze compressie in real-time uitpakken tijdens het renderen.
Wat hier besproken wordt is eigenlijk helemaal geen compressie. In plaats van een array van pixels op te slaan, wordt nu opgeslagen hoe die texture tot stand is gekomen. Een "teken lijn van (1, 1) naar (54, 63) met kleur (255, 0, 0)" commando kost bijvoorbeeld veel minder data dan het uiteindelijke plaatje.
Het nadeel is wel dat de textures echt met dit programma gemaakt moeten worden - het is niet mogelijk om bestaande textures met deze techniek te "comprimeren". Daarnaast mag het duidelijk zijn dat je met ongecomprimeerde textures een stuk meer vrijheid hebt, niet alles is nou eenmaal efficient te beschrijven met commando's en formules
Bij de claim
makers claimen dat het opbouwen van textures met hun software sneller gaat dan het uitlezen van ongecomprimeerde graphics van 'courante' harde schijven
heb ik echter sterk mijn twijfels, en ik vraag me af hoe ze dat gemeten hebben. Het duurt wellicht langer om de data van disk te halen dan zelf die textures op de CPU te genereren, maar ze vergeten daarbij voor het gemak even het feit dat data lezen van disk parallel loopt aan de CPU. Je kunt dus een leescommando geven en verder je ding doen, en zodra de data binnen is daar gebruik van maken. Deze manier is ideaal voor streaming content, omdat het game gewoon door kan lopen terwijl de data langzaam binnenkomt. Ik vraag me af of deze techniek nog steeds nuttig blijkt in een game als san andreas waar gigantisch veel real-time gestreamed wordt - volgens mij zorgt het berekenen van de textures uiteindelijk alleen maar voor extra stalls.
Wat natuurlijk wel handig is is dat de data maar één keer omgezet hoeft te worden, zodat het voornamelijk voordelig is voor downloads - je download minder data, maar bij de install of het eerste keer runnen van je game worden de textures uitgepakt en weggeschreven naar disk.
Het duurt wellicht langer om de data van disk te halen dan zelf die textures op de CPU te genereren, maar ze vergeten daarbij voor het gemak even het feit dat data lezen van disk parallel loopt aan de CPU. Je kunt dus een leescommando geven en verder je ding doen, en zodra de data binnen is daar gebruik van maken
Bij SCSI schijven of bij de S-ATA schijven met commandqueue-tagging zoals de WD Raptor wel ja. Normale IDE schijfjes belasten de processor toch echt nog steeds hoor door deze met interrupts te bestoken. SCSI en Raptors vallen overigens zeker niet onder de noemer 'courante' schijven; het moge duidelijk zijn waarom
Overigens, het is natuurlijk allemaal verkooppraat en als tegenargument voor de PS3/XBox360 en PC's kunnen we melden dat we binnenkort Blu-Ray of HD-DVD hebben en dus ook ruimte genoeg voor opslag. Voor online games heeft meneer wel een goed punt maar is die markt niet erg klein?
Wat ik bedoel is dat "leescommando geven, wachten op data, iets doen met die data, voer onafhankelijke operatie X uit" langer duurt dan "leescommando geven, voer onafhankelijke operatie X uit". Natuurlijk kost lezen van disk tijd, maar het is heel goed te parallelliseren, ookal krijg je tussendoor interrupts.
Markt groeit wel
EA Downloader
Steam
Beide programma's bieden toch ook al enorm grote games aan
toch denk ik dat dit wel degelijk sneller is, de meeste games hebben straks een dualcore cpu, en een 10000rpm s-ata schijf als het mee zit. Als je dan maar 280KB ipv 80MB van je disk moet lezen dat scheelt een heet stuk tijd. Je CPU maakt dat makkelijk goed.
Volgens de claim duurt het uitpakken maar enkele seconden,
toch een stuk sneller dan van een cd-rom of alles raw van de harde schijf lezen.
Verder kun je besparen op kosten,
een dvd kost duurder dan een cd-rom. Eentje is weer goedkoper dan twee.
Detail, maar in dergelijke oplages telt het wel even.
Daarnaast wordt steeds vaker de mogelijkheid geboden om via internet extra levels te downloaden, of zelfs complete episodes.
Jan met de pet op is denk ik blijer met een bestand van 50 MB die op een 2Mb lijntje enkele minuten duurt dan een bestand van enkele 100den MB wat weer minimaal een kwartier duurt. Ook kost het gewoon minder GB, klinkt ook onnozel,
maar het komt geregeld voor dat spellen legaal mbv bittorrent worden verspreid omdat de bandbreedte niet alleen ontoereikend is, het kost ook gewoon geld.
Volgens de claim duurt het uitpakken maar enkele seconden
Als je
niets aan het doen bent ja. Tijdens het laden wel mooi, maar voor streaming data geen optie
. Overigens vond ik het 2e CPU argument wel een goede, die staat nu vaak ongebruikt te zijn en kan daar uitstekend voor ingezet worden.
Kost duurder? Het is duurder of iets kost meer...
(Reactie op lblies)
@lblies
kost meer of is duurder
@.oisyn:
Het is inderdaad efficienter doordat je ongebruikte core(s) gebruikt voor het berekenen van die textures. DVD/BR is toch relatief traag mbt het ophoesten van grote blokken data, en je kunt zo dus meer parallel doen.
Ik moet er wel bij zeggen dat het er wel vanaf hangt wat voor textures je maakt. Hoe meer bewerkingen voor 1 texture, hoe trager (duh) en ik denk dan ook dat er een 'sweet spot' zit tot wanneer je kunt gaan met hun systeem.
Het is wel nuttig in games waarbij in grote werelden toch veel content gedistribueerd moet worden, en dit is ook de reden waarom in Spore ze deze technieken gaan gebruiken (ook voor models). Weet niet zeker of ze de Farbrausch boys' code hebben ingekocht daarvoor, wel dat ze duitsers daarvoor hadden ingehuurd, lijkt me dat er niet zoveel zijn naast Farbrausch die dit tot in de finesses beheersen.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
16:29
14:47
Door 
)
