Dari mana asal semua byte?

Pertanyaan bagus Dion! Saya akan menjawabnya, dan bukan hanya karena Anda adalah bos baru saya, tetapi karena ini pertanyaan yang bagus. (tetapi juga karena Anda adalah bos baru saya.)

Saya ingin memperjelas di sini: kita tidak benar-benar membandingkan Apel dengan Apel, jadi mari kita definisikan beberapa teknologi terlebih dahulu.

Bagaimana Mario Bekerja

Jadi mari kita bicara tentang cara kerja game Super Mario asli, dari perspektif aset.

Konsol NES asli hanya dirancang untuk menghasilkan gambar dengan lebar 256 kali tinggi 240; Artinya gambar akhir yang perlu ditampilkan ke layar berukuran 180kb.

Selain itu, NES hanya memiliki RAM sebesar 2kb. Kartrid itu sendiri dapat menampung 8k hingga 1mb data game. Jadi, tidak ada cara untuk memasukkan seluruh konten game ke dalam memori utama. Pada dasarnya, bagian dari data kartrid 1MB harus dimuat ke dalam RAM 2kb dan digunakan untuk membuat layar 180kb. Bagaimana seseorang mencapai itu?

SpriteSheets.

Sprite sheet berisi ubin kecil dari grafik, yang digunakan berulang kali. Misalnya, di bawah ini adalah pembuatan ulang sprite sheet super mario asli:

Setiap persegi 16x16 piksel kecil mewakili sebuah "ubin" dan seniman akan merangkai ini bersama-sama untuk membuat level sebenarnya. Levelnya sendiri, baru saja menjadi array indeks 2D raksasa ke dalam sprite sheet. (Saya membicarakan hal ini secara lebih mendetail di Pelajaran 3 kursus Pengembangan Game HTML5 saya @ Udacity, atau dalam buku saya Wawasan Pengembangan Game HTML5.) Tack beberapa Run-Length-Encoding, atau beberapa LZ77 dasar, dan Anda mendapatkan format yang cukup kompak untuk level.

Jadi dengan konsep seperti tile-sheets dan sprite-sheets, kita dapat menggunakan sekumpulan kecil gambar untuk membuat pemandangan & dunia yang besar. Ini biasanya cara kerja sebagian besar game. Bahkan game 3D akan memiliki sekumpulan tekstur umum yang diterapkan beberapa kali dan tempat di sepanjang game itu sendiri.

Sekarang mari kita bicara tentang kompresi gambar generik.

Bagaimana Gambar dikompresi

Inilah bagian yang " tidak adil " dari perbandingan ini. Algoritme kompresi gambar generik tidak memiliki pengetahuan domain tentang piksel di dalamnya. JPG, PNG, WebP semuanya dirancang untuk foto dan tidak banyak layar game . Hasilnya adalah untuk blok 16x16 piksel tertentu, algoritme ini menganggapnya unik di antara gambar; Selain beberapa kuantisasi warna, tidak ada logika nyata yang ditambahkan untuk menentukan apakah blok 16x16 lainnya bisa menjadi duplikat persis dari yang sekarang. Ini biasanya berarti ada batas bawah tentang cara suatu blok data dikompresi.

Misalnya, JPG memecah gambar yang diberikan menjadi blok 8x8 piksel, mengubah ruang warna RGB menjadi versi YCbCr, dan kemudian menerapkan Transformasi kosinus Diskrit pada gambar tersebut. Hanya setelah langkah ini, encoder lossless akan muncul, dan melihat apakah dapat mencocokkan grup duplikat umum menggunakan DPCM, atau RLE.

Jadi, satu-satunya tempat di mana dua blok dapat dipadatkan menjadi 1 blok, adalah jika versi pasca-DCTdnya identik, dan RLE dapat membuat rekomendasi langkah. Ini tidak sering terjadi.

Terlepas dari kekurangan lainnya, PNG jauh lebih baik dalam hal ini. Kompresi PNG sepenuhnya tanpa kerugian, (jadi kualitas gambar Anda tinggi, tetapi penghematan kompresi Anda rendah), dan berdasarkan codec DEFLATE, yang memasangkan LZSS bersama dengan Kompresi Aritmatika. Hasilnya adalah piksel yang sama dalam jangka panjang dapat dipotong menjadi ukuran yang jauh lebih kecil. Inilah sebabnya mengapa gambar dengan latar belakang yang sangat seragam akan selalu lebih kecil sebagai PNG, bukan JPG.

Gambar di bawah ini adalah file PNG 5.9kb, sedangkan gambar JPG 106kb

Apel vs. Buah Naga

Maksud saya di sini adalah agak tidak adil membandingkan konten game dengan satu gambar di internet.

Dari sisi permainan, Anda mulai dengan satu set kecil ubin yang dapat digunakan kembali, dan mengindeksnya untuk membangun gambar Anda yang lebih besar, kita bisa melakukan ini, karena kita tahu bagaimana permainan akan dibuat. Di sisi lain, JPG / PNG / WebP hanya mencoba mengompresi data yang dapat ditemukannya di blok lokal, tanpa keinginan nyata untuk mencocokkan konten yang berulang. Kompresi gambar jelas dirugikan di sini, karena mereka tidak memiliki pengetahuan sebelumnya tentang ruang datanya, mereka tidak dapat benar-benar membuat ekspektasi tentang hal itu.

Maksud saya, pertimbangkan The Demo Scene yang super besar untuk hal semacam ini. Mereka dapat menjejalkan 30 menit dari keseluruhan 3d shooter menjadi 64kb karena mereka memahami dan mengetahui lebih banyak tentang data mereka.

Ini hanya menunjukkan, dengan jumlah yang tepat dari pengetahuan sebelumnya tentang data Anda, Anda dapat melakukan hal-hal hebat dengan kompresi.

Sedang mencari.

Jelas, kami telah berkembang sejak tampilan 256x240 pada hari NES. Ponsel di saku saya memiliki tampilan 1.920 x 1.080 piksel @ ukurannya 5,2 ”, memberikan kepadatan ~ 423 piksel per inci. Untuk membandingkannya dengan jumlah piksel yang sama yaitu ~ 33 layar super-mario, atau lebih tepatnya, 8 MB data piksel. Saya rasa tidak ada yang terkejut dengan resolusi layar yang meningkat, tetapi juga disertai dengan kebutuhan akan lebih banyak data .

Ini adalah sesuatu yang saya bicarakan untuk sementara waktu sekarang. Meskipun kami mendapatkan layar yang lebih besar, saluran konten perlu menaikkan keluaran resolusinya agar tetap terlihat bagus pada penyiapan dengan kepadatan yang lebih tinggi (jika tidak, kami mendapatkan skala buram ..). Hal ini tentu saja, menyebabkan paket video game kami bertambah besar, halaman web kami bertambah besar, dan bahkan video streaming youtube kami bertambah besar. Pada dasarnya, kami mengirim lebih banyak data ke perangkat yang lebih kecil hanya karena resolusi layar. Yang, bagi 2 miliar orang berikutnya di pasar negara berkembang, dengan koneksi 2G, adalah ide terburuk yang pernah ada.

Tapi saya ngelantur. Itu pos yang berbeda.