Izvrsno pitanje Dion! Odgovorit ću na to, i to ne samo zato što ste moj novi šef, već zato što je to dobro pitanje. (ali i zato što ste moj novi šef.)
Ovdje bih ipak želio nešto jasno objasniti: zapravo ne uspoređujemo jabuke s jabukama, pa definirajmo prvo neke tehnologije.
Kako Mario radi
Pa razgovarajmo o tome kako je originalna Super Mario igra funkcionirala iz perspektive imovine.
Izvorna NES konzola dizajnirana je samo za prikazivanje slika širine 256 x 240; što znači da je konačna slika koju je trebalo prikazati na zaslonu bila velika 180 kb.
Osim toga, NSZ je imao samo 2 kb RAM-a. Sama patrona može sadržavati 8k do 1mb podataka o igrama. Dakle, nije bilo načina da se čitav sadržaj igre stavi u glavnu memoriju. U osnovi, podskup podataka uloška od 1 MB mora se učitati u RAM od 2 kb i koristiti za generiranje zaslona od 180 kb. Kako se to postiže?
SpriteSheets.
Sprite listovi sadrže male pločice grafike, koje se iznova koriste. Na primjer, dolje je remake originalnog lista spritea super mario:
Svaki mali kvadrat od 16x16 piksela predstavlja "pločicu" i umjetnici bi ih povezali da bi stvorili stvarne razine. Sami nivoi upravo su postali divovski 2D niz indeksa u listu spritea. (O tome govorim puno detaljnije u lekciji 3 mog tečaja za HTML5 razvoj igara @ Udacity ili u svojoj knjizi HTML5 Insights Development Game.) Primijenite neko kodiranje u dužini ili neki osnovni LZ77 i dobit ćete prilično kompaktan format za razine.
Dakle, s konceptima poput listova pločica i sprite listova, možemo koristiti mali skup slika za stvaranje velikih scena i svjetova. To uglavnom funkcionira u većini igara. Čak će i 3D igre imati skup uobičajenih tekstura koje se primjenjuju više puta i na svim mjestima u samoj igri.
Sada razgovarajmo o generičkoj kompresiji slike.
Kako se komprimiraju slike
Evo " ne poštenog " dijela ove usporedbe. Generički algoritmi za kompresiju slike nemaju znanje o domeni o pikselima unutar sebe. JPG, PNG, WebP svi su dizajnirani za fotografije i ne toliko za zaslone igara . Rezultat je taj da za zadani blok od 16x16 piksela ovi algoritmi pretpostavljaju da je jedinstven među slikom; Osim neke kvantizacije boja, nije dodana prava logika koja bi odredila bi li još jedan blok 16x16 mogao biti točan duplikat trenutnog. To općenito znači da postoji donja granica komprimiranja datog bloka podataka.
Na primjer, JPG razbija zadanu sliku u blokove od 8x8 piksela, pretvara prostor RGB boja u verziju YCbCr, a zatim na njih primjenjuje diskretnu kosinusnu transformaciju. Tek nakon ovog koraka dolazi koder bez gubitaka i provjerava može li se podudarati s uobičajenim duplikatima pomoću DPCM-a ili RLE-a.
Dakle, jedino mjesto na kojem bi se dva bloka mogla zbiti u 1 blok jest ako je njihova verzija nakon DCTd-a identična, a RLE može dati preporuke za iskorake. To se ne događa tako često.
Unatoč ostalim manama, PNG je u tom pogledu puno bolji. Kompresija PNG-a u potpunosti je bez gubitaka (tako da je kvaliteta slike visoka, ali ušteda kompresije niska) i temelji se na DEFLATE kodeku, koji uparuje LZSS zajedno s aritmetičkom kompresijom. Rezultat je to što se duge serije sličnih piksela mogu na kraju smanjiti na znatno manju veličinu. Zbog toga će slika s vrlo jednolikom pozadinom uvijek biti manja kao PNG umjesto JPG-a.
Slika u nastavku je PNG datoteka od 5,9 KB, dok je JPG slika od 106 KB
Jabuke protiv Dragonfruita
Moja poanta ovdje je da je pomalo nepravedno uspoređivati sadržaj igre s jednom slikom na Internetu.
Sa strane igre započinjete s malim skupom pločica za višekratnu upotrebu i indeksirate ih kako biste stvorili veću sliku, to možemo učiniti, jer znamo kako će igra nastati. S druge strane, JPG / PNG / WebP samo pokušava stisnuti podatke koje može pronaći u lokalnim blokovima, bez stvarne želje za podudaranjem ponovljenog sadržaja. Kompresija slike ovdje je očito u nepovoljnom položaju, budući da oni nemaju predznanje o svom podatkovnom prostoru, ne mogu zapravo očekivati o tome.
Mislim, uzmite u obzir Demo scenu koja je super za takve stvari. Oni mogu strpati 30 minuta cijelog 3d strijelca u 64 kb, jer razumiju i znaju puno više o svojim podacima.
To samo pokazuje, s pravom količinom predznanja o svojim podacima, sa kompresijom možete napraviti velike stvari.
Veselim se.
Očito smo odrasli od prikaza 256x240 dana NSZ-a. Telefon u mom džepu ima 1920 x 1080 piksela zaslona @ veličine je 5,2 ”, što daje ~ 423 piksela po inču gustoće. Za usporedbu s istim brojem piksela to je ~ 33 super-mario zaslona, odnosno 8 MB pikselnih podataka. Mislim da nikoga ne čudi što se razlučivosti zaslona povećavaju, ali uz to dolazi i potreba za više podataka .
To je nešto na što se već neko vrijeme namučujem. Iako dobivamo veće zaslone, sadržajni kanali moraju povećati izlazne razlučivosti kako bi i dalje izgledali dobro na našim postavkama veće gustoće (inače dobivamo mutnoću skaliranja ..). To naravno uzrokuje da naši paketi videoigara postaju sve veći, naše web stranice povećane, pa čak i naše YouTube streaming videozapise sve veće. U osnovi, više podataka šaljemo manjim uređajima jednostavno zbog razlučivosti zaslona. Što je za sljedeće 2 milijarde ljudi na tržištima u nastajanju, na 2G vezama, kao najgora ideja ikad.
Ali odstupam. To je drugi post.