Kita telah
melihat bagaimana hardware merupakan faktor pembatas utama untuk pengembangan
game. Jelas, coding Quake(game) pada 48KB terdengar seperti tantangan yang
bagus. Tapi permainan 2D menggunakan struktur data sederhana dan lebih kecil,
dan sedikit sebab rutinitas daripada lebih dari judul 3D yang sudah maju.
Sekarang kita akan mempelajari elemen-elemen pokok dari klasik permainan 2D.
Mendefinisikan struktur untuk tiga
elemen kunci di sini adalah hal yang penting yaitu:
1. Cara
untuk menyandikan grafis karakter
2. Cara
untuk mengkodekan gambar latar belakang
3. Cara
untuk menyimpan peta permainan
Sprite
Berbasis Karakter
Mari
kita lihat kembali pada saat bagaimana karakter diwakili di awal-awal dari industry
animasi. Pada keseharian Walt Disney, setiap frame masing-masing karakter
dilukis pada lembaran plastic transparan
di mana karakter akan "bergerak" . Untuk menghasilkan ilusi animasi,
gambar berlapis dan gerakan disimulasikan dengan menukar frame dari animasi
masing-masing. Teknik ini dikenal sebagai animasi cel, dari lembaran plastik
digunakan di dalamnya.
Analog
dengan lembaran plastik, game 2D menyimpan setiap karakter dalam, persegi
panjang grafis bitmap, sehingga dapat ditarik dengan cepat pada layar.
Informasi tambahan memungkinkan kode game untuk mendeteksi daerah-daerah yang
transparan, sehingga karakter kita berbaur mulus dengan latar belakang. Kemudian,
hardware dan software yang lebih spesifik akan digunakan untuk merender ini ke layar. Masing-masing bitmap (dengan
keterbukaan informasi yang terkait) adalah disebut sprite. Nama berasal dari awal
terbentuknya game 2D. Karena permainan yang paling terlibat adalah tentang hantu,
sprite, dan ksatria, grafis jadi nama tersebut diadopsi dari nama itu.
Sprite
dapat disimpan dalam berbagai cara tergantung pada perangkat kerasnya. Seperti di
Sebuah ponsel yang hanya memiliki warna hitam
and putih, 200x150 piksel, sedangkan beberapa game sprite lebih baru pada PC
dapat berjalan pada 800x600, 24-bit warna dengan efek alfa. Sekali lagi, memori
dan kinerja CPU adalah faktor pembatas. Yang pertama akan menempati 30.000 bit
(hitam putih memerlukan satu bit per piksel saja), yaitu sekitar 4 KB. Opsi
terakhir akan lebih dari 1MB.
Selanjutnya,
saya akan membahas beberapa format yang telah populer selama bertahun-tahun.
Format pertama menyimpan sprite dalam warna hitam dan putih (atau dua warna
yang diberikan), dan membatasi ukuran sprite untuk kelipatan delapan. Beberapa
ponsel, serta 8-bit mesin seperti Spectrum, mendukung format ini. Hal ini
membuat sangat nyaman karena setiap pixel dalam sprite bisa disimpan dalam satu
bit, dan ukuran tetap kelipatan delapan membuat sprite lebih mudah untuk
menyimpan dalam bytes. Spectrum, misalnya, digunakan 8x8, dua warna sprite. Latar
depan dan warna latar belakang dipilih dari palet 16-warna, sehingga setiap
dari mereka memerlukan 4 bit, untuk jumlah byte tambahan.
Secara
keseluruhan, format ini menggunakan 9 byte per sprite saja. Karena frame buffer
adalah 256x176 pixel, atau 32x23 sprite, buffer seluruh frame menempati sekitar
6KB (jika sprite "Diratakan" sehingga kita memiliki gambaran layar). Untuk efisiensi meningkat, banyak 8-bit mesin
tidak memiliki frame buffer, tetapi bisa bekerja dengan tempat yang rata dan buffer memegang hanya pengidentifikasian
sprite. Ini adalah halnya dengan NES (lebih pada arsitektur dapat ditemukan
dalam Bab 1, "Kronologi aksi Pemrograman ") Dengan asumsi resolusi
yang sama sebagai Spectrum dan satu byte untuk setiap sprite. Ini sistem
perwakilan hanya membutuhkan 736 byte (plus memori sprite). Apapun metode yang
Anda pilih, jejak memori rendah datang pada biaya. Setiap persegi 8x8 hanya
bisa menampung dua warna, secara signifikan merendahkan kekayaan visual.
Sebuah
pilihan yang lebih terlibat dapat digunakan jika Anda bekerja pada sebuah
display adapter yang mendukung palet dari 16 warna, langsung mappable untuk
setiap pixel (sehingga Anda dapat menampilkan lebih banyak situasi, setiap
pixel dapat dikodekan untuk 4 bit, dan setiap dua piksel mengambil satu byte
demikian. dalam hal ini, pembatasan ini
adalah bahwa ukuran sprite perlu menjadi kekuatan 2 (8, 16, 32, 64 ...). Sebuah
sprite 8x8 maka akan membutuhkan sebanyak 32 byte. Sekali lagi, layar 256x176
akan mengambil 23KB, sekitar empat kali lebih banyak ruang dari kasus
sebelumnya. Tapi kita bisa mewakili adegan jauh lebih kaya. Bangunan pada
pendekatan terakhir, kita dapat mengkodekan sprite mendukung sampai 256 warna
per pixel. Warna-warna biasanya datang dari palet tetap atau palet secara bebas
didefinisikan oleh pengguna. Ini adalah kasus
dengan popular 320x200 PC format, di mana setiap entri palet dapat mengkodekan
sebuah triplet 24-bit RGB. Mengingat pembatasan ini, dari 8x8 sprite diambil hanya 64 byte,
layar dengan resolusi layar Spectrum akan mengambil 46KB, dan
bingkai PC
penyangga berjalan pada 320x200 mengambil persis 64.000 byte. Tambahkan ruang
yang diperlukan untuk palet tabel (256 warna 24 bit masing-masing, 768 total
bytes), dan keseluruhan akan cocok dengan sempurna di 64KB ditemukan di salah
satu memori segmen PC tercinta.
Bergerak
naik dalam skala warna yang kita dapat mengkodekan tinggi warna sprite (16 bit
per pixel). Di sini, dua pilihan yang tersedia. Pertama, Anda dapat memilih
untuk encode menggunakan 5-5-5-1 (lima byte untuk merah, hijau, dan biru,
ditambah satu untuk alfa). Kedua, Anda dapat mengkodekan menggunakan 6-5-5 dan
encode warna transparansi sebagai salah satu warna kombinasi yang Anda tidak
benar-benar menggunakan, seperti dalam sebuah pendekatan kunci kroma. Dalam
dunia ideal, Anda bisa menggunakan warna asli sprite, baik dalam 24 atau 32 bit
jika Anda ingin bekerja dengan alpha
pencampuran.
Sangat mungkin, 8 bit untuk alfa akan terlalu banyak, tapi ini memiliki
keuntungan bahwa setiap pixel dapat ditransfer dalam satu double word (32 bit),
yang nyaman. Namun, pada saat Anda mulai bekerja dengan warna asli sprite,
platform perangkat keras Anda akan dukungan grafis 3D yang paling mungkin. Jadi
itu alasannya mengapa game 2D menggunakan warna yang benar jauh lebih populer
daripada 8-bit “teman-teman” mereka.
Sekarang,
kita perlu bicara tentang transparansi. Spritenya perlu berbaur mulus dengan
latar belakang, jadi perlu cara untuk menyandikan bagian sprite yang harus
meninggalkan latar belakang terpengaruh. Beberapa pendekatan telah digunakan
untuk mencapai efek ini. Salah satu alternatif yang populer adalah dengan
menggunakan masker 1-bit yang terpisah untuk mengkodekan zona transparan.
Masker ini digunakan dalam proses transfer untuk memastikan campuran tersebut
dilakukan dengan benar. Pada Gambar 11.1, topeng dikalikan dengan latar
belakang, meninggalkan hitam di daerah yang nantinya akan ditempati oleh
sprite. Kemudian, dengan menambahkan sprite ke latar belakang langsung,maka pencampuran
tercapai.
Gambar 11.1. Mask dan sprite.
Pendekatan
ini sederhana untuk kode, tetapi metode mask mengambil sejumlah besar memori,
terutama dalam animasi sprite. Untuk, sprite 32x32 256-warna (yang dengan
sendirinya membutuhkan 1KB), kita akan membutuhkan 128 byte ekstra untuk metode
mask. Ada alternatif untuk teknik ini: pemesanan satu entri warna dalam palet
kami sebagai "transparan" warna dan menyimpan hanya piksel yang
menyandi warna transparan. Dalam palet 256-warna, hilangnya satu warna akan
masuk akal. Tapi pada platform yang lebih rendah-warna, seperti palet 16-warna,
kehilangan satu warna demi transparansi mungkin tidak dapat diterima, dengan
demikian, pendekatan masking akan disukai.
Untuk
menghasilkan ilusi animasi, sprite perlu berlapis-lapis di layar dengan cepat.
Sedikitnya 25 layar update per detik diperlukan, tetapi jumlah lebih dari 50
yang tidak biasa. Ini pengoperasian layering sprite pada layar disebut
blitting. Nama berasal dari "blit," kata yang merupakan kontraksi
"memblokir transfer gambar." Beberapa platform, seperti konsol game
awal, digunakan hardware yang spesifik untuk melakukan blits ini. Mesin
Blitting biasanya dimodifikasi oleh rutinitas memori penyalin, karena layar 2D biasanya
dipetakan ke dalam array memori linier.
No Response to "Struktur Data untuk Games 2D"
Posting Komentar