Одакле долазе сви бајтови?

Сјајно питање Дион! Одговорит ћу на то, и не само зато што сте мој нови шеф, већ зато што је то добро питање. (али и зато што сте мој нови шеф.)

Овде желим да појасним нешто: заправо не упоређујемо јабуке са јабукама, па хајде да прво дефинишемо неке технологије.

Како Марио ради

Дакле, хајде да разговарамо о томе како је оригинална Супер Марио игра радила, из перспективе имовине.

Оригинална НЕС конзола дизајнирана је само за приказивање слика ширине 256 пута 240; што значи да је коначна слика коју је требало приказати на екрану била 180кб.

Поред тога, НСЗ је имао само 2 кб РАМ-а. Сама касета може да прими 8к до 1мб података о играма. Дакле, није било начина да се целокупан садржај игре стави у главну меморију. У основи, подскуп података од 1МБ кертриџа мора бити учитан у РАМ од 2кб и искоришћен за приказивање екрана од 180кб. Како се то постиже?

СпритеСхеетс.

Сприте листови садрже мале плочице графике, које се поново користе изнова. На пример, доле је ремаке оригиналног сприте листа супер марио:

Сваки мали квадрат од 16к16 пиксела представља „плочицу“ и уметници би их повезали да би створили стварне нивое. Сами нивои су управо постали џиновски 2Д низ индекса у листу спритеа. (О томе говорим много детаљније у лекцији 3 мог ХТМЛ5 курса за развој игара @ Удацити, или у својој књизи ХТМЛ5 Гаме Девелопмент Инсигхтс.) Упознајте се са неким Рун-Ленгтх-Енцодинг, или неким основним ЛЗ77, и добићете прилично компактан формат за нивое.

Дакле, са концептима попут плочица и сприте листова, можемо да користимо мали скуп слика да бисмо створили велике сцене и светове. Тако углавном функционише већина игара. Чак ће и 3Д игре имати скуп уобичајених текстура које се примењују више пута и на местима током саме игре.

Хајде сада да разговарамо о генеричкој компресији слике.

Како се слике компресују

Ево „ неправедног “ дела овог поређења. Генерички алгоритми за компресију слике немају знање о домену о пикселима у себи. ЈПГ, ПНГ, ВебП су сви дизајнирани за фотографије и не толико за екране игара . Резултат је тај да за дати блок од 16к16 пиксела ови алгоритми претпостављају да је јединствен међу сликом; Поред неке квантизације боја, није додата права логика која би утврдила да ли би други блок 16к16 могао бити тачан дупликат тренутног. То обично значи да постоји доња граница како се компримује дати блок података.

На пример, ЈПГ разбија задану слику у блокове од 8к8 пиксела, претвара РГБ простор боја у верзију ИЦбЦр, а затим на њих примењује дискретну косинусну трансформацију. Тек након овог корака долази кодер без губитака и проверава да ли се може подударати са уобичајеним дупликатима помоћу ДПЦМ-а или РЛЕ-а.

Дакле, једино место где би се два блока могла збити у један блок је ако је њихова верзија након ДЦТд идентична, а РЛЕ може да даје препоруке корака. То се не дешава тако често.

Упркос другим манама, ПНГ је у овом погледу много бољи. ПНГ компресија је у потпуности без губитака (тако да је ваш квалитет слике висок, али уштеда компресије мала) и заснива се на ДЕФЛАТЕ кодеку, који упарује ЛЗСС заједно са аритметичком компресијом. Резултат је то што се дуге серије сличних пиксела могу на крају смањити на много мању величину. Због тога ће слика са врло уједначеном позадином увек бити мања као ПНГ уместо као ЈПГ.

Слика у наставку је ПНГ датотека од 5,9 кб, док је ЈПГ слика од 106 кб

Јабуке против Драгонфруит-а

Моја поента је овде да је некако неправедно упоређивати садржај игре са једном сликом на Интернету.

Са стране игре започињете са малим сетом плочица за вишекратну употребу и индексирате их да бисте створили већу слику, то можемо учинити, јер знамо како ће игра бити направљена. С друге стране, ЈПГ / ПНГ / ВебП само покушава да саже податке које може пронаћи у локалним блоковима, без стварне жеље да се поклапа са поновљеним садржајем. Компресија слике је овде очигледно у неповољном положају, будући да они немају предзнање о свом простору података, не могу заиста очекивати о томе.

Мислим, узмите у обзир Демо сцену која је супер велика за такве ствари. Они могу да стрпају 30 минута целокупне 3д пуцачине у 64кб, јер разумеју и знају много више о својим подацима.

То само показује, с правом количином предзнања о вашим подацима, можете са компресијом учинити велике ствари.

Очекујем.

Очигледно смо одрасли од приказа 256к240 у НСЗ данима. Телефон у мом џепу има 1.920 к 1.080 пиксела на екрану @ величине 5,2 ”, што му даје ~ 423 пиксела по инчу. Да упоредимо то у истом броју пиксела, то је ~ 33 супер-марио екрана, тачније, 8 МБ података пиксела. Мислим да нико није изненађен што се резолуције екрана повећавају, али то долази и са потребом за више података .

Ово је нешто на шта се већ неко време намучујем. Иако добијамо веће екране, садржајни канали морају да повећају излазне резолуције како би и даље изгледали добро на нашим поставкама веће густине (у супротном добијамо замућеност скалирања ..). То наравно доводи до тога да наши пакети видео игара постају све већи, наше веб странице све веће, па чак и наши ИоуТубе стреаминг видео снимци све већи. У основи, више података шаљемо мањим уређајима само због резолуције екрана. Што је за наредне 2 милијарде људи на тржиштима у настајању, на 2Г везама, најгора идеја икад.

Али одступам. То је други пост.