Mistä kaikki tavut tulevat?

Suuri kysymys Dion! Vastaan ​​siihen, eikä vain siksi, että olet uusi pomo, vaan siksi, että se on hyvä kysymys. (mutta myös siksi, että olet uusi pomo.)

Haluan kuitenkin asettaa jotain selkeää tässä: emme oikeastaan ​​vertaa omenoita omenoihin, joten määritellään ensin jotkut tekniikat.

Kuinka Mario toimii

Joten puhutaan siitä, miten alkuperäinen Super Mario -peli toimi varallisuuden näkökulmasta.

Alkuperäinen NES-konsoli on suunniteltu vain 256 leveän ja 240 korkean kuvan tuottamiseen. mikä tarkoittaa, että lopullinen kuva, joka oli näytettävä näytöllä, oli 180 kt.

Sen lisäksi NES: llä oli vain 2 kt RAM-muistia. Itse patruuna voisi olla 8–1 MB pelidataa. Joten ei ollut mitään tapaa sovittaa koko pelin sisältöä päämuistiin. Pohjimmiltaan 1 Mt: n kasettidatan osajoukko on ladattava 2 kt: n RAM-muistiin ja sitä on käytettävä 180 kt: n näytön renderointiin. Kuinka yksi saavutetaan?

SpriteSheet.

Sprite-levyt sisältävät pieniä grafiikkalaattoja, joita käytetään uudestaan ​​ja uudestaan. Esimerkiksi alla on remake alkuperäisestä super mario sprite -arkista:

Jokainen pieni 16x16 pikselin neliö edustaa "ruutua", ja taiteilijat sitovat ne yhteen luomaan todelliset tasot. Itse tasoista tuli juuri jättiläinen 2D-indeksijoukko sprite-levylle. (Puhun tästä paljon yksityiskohtaisemmin HTML5-pelikehityskurssini @ Udacity oppitunnissa 3 tai kirjassa HTML5 Game Development Insights.) Napsauta joitain Run-Length-Encoding -ominaisuuksia tai joitain perustietoja LZ77: stä, ja saat melko kompakti muoto tasoille.

Joten käsitteiden, kuten laatta- ja sprite-levyt, avulla voimme luoda pieniä kuvasarjoja suurten kohtausten ja maailmojen luomiseen. Näin useimmat pelit toimivat yleensä. Jopa 3D-peleissä on joukko yleisiä tekstuureja, joita käytetään useita kertoja ja paikkoja koko pelissä.

Puhutaan nyt yleisestä kuvan pakkaamisesta.

Kuinka kuvia pakataan

Tässä on " ei oikeudenmukainen " osa tästä vertailusta. Yleisillä kuvan pakkausalgoritmeilla ei ole tietoa alueiden sisällä olevista pikseleistä. JPG, PNG, WebP on suunniteltu valokuville eikä niinkään pelinäytöille . Tuloksena on, että tietyllä 16x16 pikselilohkolla nämä algoritmit olettavat, että se on ainutlaatuinen kuvassa; Jonkin värikvantisoinnin lisäksi ei ole lisätty todellista logiikkaa sen määrittämiseksi, voisiko toinen 16x16-lohko olla tarkka kopio nykyisestä. Tämä tarkoittaa yleensä sitä, että tietyn tietolohkon pakkauksessa on alaraja.

Esimerkiksi JPG jakaa tietyn kuvan 8x8 pikselilohkoksi, muuntaa RGB-väriavaruuden YCbCr-versioon ja käyttää sitten niihin erillistä kosini-muunnosta. Se on vain , kun tämä vaihe, ei häviötön kooderi tullut pitkin, ja katso jos se voi sovittaa yhteistä kahtena ryhmiä käyttäen DPCM tai RLE.

Joten ainoa paikka, jossa kaksi lohkoa saatetaan tiivistää yhdeksi lohkoksi, on, jos niiden DCTd-jälkeinen versio on identtinen, ja RLE voi antaa edistysaskeleita. Tätä ei tapahdu niin usein.

Muista puutteistaan ​​huolimatta PNG on tässä suhteessa paljon parempi. PNG-pakkaus on täysin häviötön (joten kuvanlaatu on korkea, mutta pakkaussäästösi ovat alhaiset) ja perustuu DEFLATE-koodekiin, joka yhdistää LZSS: n ja aritmeettisen pakkauksen. Tuloksena on, että pitkät samanlaisten pikselien sarjat voivat päätyä leikata paljon pienempään kokoon. Siksi kuva, jolla on hyvin yhtenäinen tausta, on aina pienempi kuin PNG JPG: n sijasta.

Alla oleva kuva on 5,9 kt PNG-tiedosto, kun taas JPG-kuva on 106 kt

Omenat vs. Dragonfruit

Totean tässä, että on melko epäreilua verrata pelisisältöä yhteen kuvaan Internetissä.

Pelin puolelta aloitat pienellä joukolla uudelleenkäytettäviä ruutuja ja indeksoit ne rakentamaan suuremman kuvan, voimme tehdä tämän, koska tiedämme, kuinka peli tehdään. Toisaalta JPG / PNG / WebP vain yrittää pakata paikallisista lohkoista löytämänsä tiedot ilman todellista halua sovittaa toistuvaa sisältöä. Kuvan pakkaus on tässä selvästi epäedullisessa asemassa, koska heillä ei ole ennakkotietoa datatilastaan, he eivät voi oikeastaan ​​tehdä siitä mitään odotuksia.

Tarkoitan The Demo Scene -ohjelmaa, joka on erittäin iso tällaisissa asioissa. He voivat täyttää 30 minuutin koko 3D-ampujasta 64 kt: iin, koska he ymmärtävät ja tietävät paljon enemmän tiedoistaan.

Se vain osoittaa, että oikean määrän ennakkotietoja tiedoistasi, voit tehdä suuria asioita pakkaamalla.

Odotan innolla.

Olemme tietysti kasvaneet NES-päivien 256x240 näytöistä lähtien. Taskussani olevalla puhelimella on 1 920 x 1 080 näyttöpikseliä, sen koko on 5,2 tuumaa, mikä antaa sille ~ 423 pikseliä tuumaa kohti. Vertaamaan sitä samassa pikselimäärässä, joka on ~ 33 super-mario-näyttöä tai pikemminkin 8 Mt pikselidataa. Mielestäni kukaan ei ole yllättynyt siitä, että näytön tarkkuudet kasvavat, mutta siihen liittyy myös lisätietojen tarve .

Tätä olen harrastanut jo jonkin aikaa. Vaikka saamme isompia näyttöjä, sisältökanavien on lisättävä tarkkuustuloksiaan, jotta ne näyttävät silti hyvältä tiheämmillä asetuksillamme (muuten saat skaalautuvan epäselvyyden ..). Tämä tietysti saa videopelipakettimme kasvamaan, verkkosivumme kasvamaan ja jopa YouTube-suoratoistovideomme kasvamaan. Lähetämme periaatteessa enemmän tietoa pienempiin laitteisiin yksinkertaisesti näytön tarkkuuden vuoksi. Mikä 2G-yhteyksillä seuraaville 2 miljardille kehittyvillä markkinoilla olevalle ihmiselle on kuin kaikkien aikojen pahin idea.

Mutta olen poikennut. Se on erilainen viesti.