Honnan származik az összes bájt?

Nagy kérdés Dion! Válaszolok rá, és nem csak azért , mert te vagy az új főnököm, hanem azért is, mert ez jó kérdés. (hanem azért is, mert te vagy az új főnököm.)

Valami világosat szeretnék itt megadni: valójában nem hasonlítjuk össze az almákat az almákkal, ezért először határozzunk meg néhány technológiát.

Hogyan működik Mario

Tehát beszéljünk arról, hogyan működött az eredeti Super Mario játék, eszköz szempontból.

Az eredeti NES konzolt csak 256 széles és 240 magas kép kinyomtatására tervezték; vagyis a képernyőn megjelenítendő végső kép mérete 180 kb volt.

Emellett a NES-nek csak 2 kt RAM-ja volt. Maga a kazetta 8 000–1 MB játékadatot tudott tárolni. Tehát nem volt mód a játék teljes tartalmának a fő memóriába való beillesztésére. Alapvetően az 1 MB-os kazettaadatok egy részhalmazát be kell tölteni a 2kb RAM-ba, és felhasználni kell a 180kb-os képernyő megjelenítéséhez. Hogyan lehet ezt elérni?

SpriteSheets.

A Sprite lapok kis grafikai csempéket tartalmaznak, amelyeket újra és újra felhasználnak. Például az alábbiakban bemutatjuk az eredeti super mario sprite lap remake-jét:

Minden kicsi, 16x16 pixeles négyzet „csempét” jelent, és a művészek ezeket összefűzve hozzák létre a tényleges szinteket. Maguk a szintek csak egy hatalmas 2D-s indextömb lettek a sprite lapba. (Sokkal részletesebben beszélek erről a HTML5 játékfejlesztési kurzusom @ Udacity 3. leckéjében, vagy a HTML5 játékfejlesztési betekintés című könyvemben.) Tegyen egy kis Run-Length-Encoding-et vagy néhány alapvető LZ77-et, és kap egy meglehetősen kompakt formátum a szintekhez.

Tehát olyan fogalmakkal, mint a csempe-lapok és a sprite-lapok, kis képkészletet használhatunk nagy jelenetek és világok létrehozásához. A legtöbb játék általában így működik. Még a 3D-s játékok is tartalmaznak egy sor közös textúrát, amelyeket többször és több helyen alkalmaznak az egész játék során.

Most beszéljünk az általános képtömörítésről.

Hogyan tömörítik a képeket

Íme ennek az összehasonlításnak a „ nem fair ” része. Az általános képtömörítési algoritmusok nem rendelkeznek tartományi ismeretekkel a bennük lévő pixelekről. JPG, PNG, WebP összes tervezték fotók , és nem annyira a játék képernyőn . Ennek az az eredménye, hogy egy adott 16x16 pixeles blokk esetében ezek az algoritmusok feltételezik, hogy egyedülálló a kép között; Némi színkvantálás mellett nincs hozzáadva valódi logika annak megállapításához, hogy egy másik 16x16-os blokk lehet-e a jelenlegi pontos mása . Ez általában azt jelenti, hogy egy adott adatblokk tömörítésének alsó határa van.

Például a JPG egy adott képet 8x8 pixeles blokkokra bont, az RGB színteret YCbCr verzióvá alakítja, majd diszkrét koszinusz transzformációt alkalmaz rájuk. Ez csak miután ezt a lépést, nem veszteségmentes kódoló jönni, és hátha tud egyezni a közös ismétlődő csoportok segítségével DPCM vagy RLE.

Tehát az egyetlen hely, ahol két blokk 1 blokkba tömörülhet, az az, ha a DCTd utáni verziójuk megegyezik, és az RLE lépésről lépésre ajánlásokat tehet. Ez nem fordul elő olyan gyakran.

Egyéb hibái ellenére a PNG ebben a tekintetben sokkal jobb. A PNG-tömörítés teljesen veszteségmentes (tehát a képminősége magas, de a tömörítési megtakarításai alacsonyak), és a DEFLATE kodek alapján készült, amely az LZSS-t párosítja az aritmetikai tömörítéssel. Ennek az az eredménye, hogy a hasonló képpontok hosszú futása sokkal kisebb méretre vágható. Ezért egy nagyon egységes háttérrel rendelkező kép mindig kisebb lesz, mint PNG, JPG helyett.

Az alábbi kép egy 5,9 kb méretű PNG fájl, míg a JPG kép 106 kb

Alma kontra Dragonfruit

Itt állítom, hogy meglehetősen igazságtalan a játék tartalmát egyetlen képpel összehasonlítani az interneten.

A játék oldaláról kezdve egy kis újrafelhasználható csempe készlettel kezdje el, és indexelje őket a nagyobb kép felépítéséhez, ezt megtehetjük, mert tudjuk, hogy a játék hogyan fog készülni. A másik oldalon a JPG / PNG / WebP csak megpróbálja tömöríteni a lokális blokkokban talált adatokat, anélkül, hogy valódi vágy lenne az ismételt tartalom összehangolására. A képtömörítés itt egyértelműen hátrányos helyzetben van, mivel nincsenek előzetes ismereteik az adattérükről, nem igazán tudnak ezzel szemben elvárásokat támasztani.

Úgy értem, vegye figyelembe a Demo Scene-t, amely szuper nagy az ilyesmiben. Az egész 3D lövöldözős 30 percet be tudják tömni 64 KB-ba, mert sokkal többet értenek és tudnak az adataikról.

Ez csak azt mutatja, hogy megfelelő mennyiségű előzetes tudással rendelkezik az adatairól, a tömörítéssel nagyszerű dolgokat tehet.

Várakozás.

Nyilvánvalóan felnőttünk a NES napok 256x240-es kijelzői óta. A zsebemben lévő telefon 1920 x 1 080 kijelző pixel @ 5,2 ”méretű, így ~ 423 pixel / hüvelyk sűrűségű. Összehasonlítva ugyanabban a pixelszámban, ami ~ 33 szuper-mario képernyő, vagy inkább 8 MB pixeles adat. Szerintem senki sem lepődik meg azon, hogy a képernyőfelbontás növekszik, de ez további adatok szükségességével is jár .

Ez az, amin már egy ideje hárfázom. Míg nagyobb kijelzőket kapunk, a tartalmi csatornáknak meg kell növelniük a felbontási kimenetüket annak érdekében, hogy továbbra is jól nézzenek ki a nagyobb sűrűségű beállításoknál (különben méretező homályosságot kapunk ..). Ez természetesen a videojáték-csomagjaink méretének növekedését, a weblapjaink méretét, sőt a youtube streaming videóink méretét is növeli. Alapvetően több adatot küldünk kisebb eszközökre, egyszerűen a képernyő felbontása miatt. Ami a feltörekvő piacokon következő 2 milliárd ember számára a 2G kapcsolatokon keresztül valaha volt legrosszabb ötlet.

De kitérek. Ez egy másik bejegyzés.