Poligon Dunia Lain

Ada cara yang menarik untuk mempelajari arsitektur komputer masa lalu. Temukan program yang Anda kenal dan coba cari tahu bagaimana portingnya.


Pilihan yang bagus untuk ini adalah DOOM . Megahit tahun 1994 dari id Software diporting ke segala kemungkinan. Permainan ini dirancang di sekitar inti, jelas dibagi menjadi beberapa lapisan. Biasanya mudah untuk menemukan dan membaca implementasi dari enam subsistem I / O.


Pilihan lain adalah Another World 1991 dari Eric Chailly, yang lebih dikenal di Amerika Utara sebagai Out Of This World . Saya akan mengatakan bahwa sebenarnya lebih menarik untuk dipelajari daripada DOOM, karena grafik poligonal yang cocok untuk optimisasi liar . Dalam beberapa kasus, aksi sulit memungkinkan game untuk bekerja pada peralatan yang dibuat lima tahun sebelum rilis game.




  1. Poligon Dunia Lain.
  2. Poligon Dunia Lain: Amiga 500 .
  3. Poligon Dunia Lain: Atari ST .

Seri artikel ini adalah perjalanan melalui peralatan video game dari awal tahun 90-an. Dari Amiga 500, Atari ST, IBM PC, Super Nintendo, hingga Sega Genesis. Untuk setiap mesin, saya mencoba mencari tahu bagaimana Dunia Lain diterapkan.


Dalam kasus terbaik, saya berhasil menghubungi pengembang asli. Yang terburuk, saya harus mencari tahu kode yang dibongkar sendiri. Itu adalah petualangan yang menyenangkan.


Dunia Lain 101


Dunia lain memiliki sedikit kode. Versi awal untuk Amiga dilaporkan hanya panjang 6.000 baris. File yang dapat dieksekusi untuk DOS di bawah PC hanya 20 kB. Anehnya untuk gim yang sangat besar, yang datang dengan satu floppy disk 1,44 MiB. Itu karena sebagian besar logika bisnis diimplementasikan menggunakan bytecode. Eksekusi Dunia Lain sebenarnya adalah host mesin virtual yang membaca dan menjalankan opcodes uint8_t .




Mesin virtual di Dunia Lain mendefinisikan 256 variabel, 64 utas, 29 opcode, dan tiga framebuffer ( terjemahan dari PatientZero ). Itu saja. Jika Anda membuat host untuk mesin virtual yang dapat menangani ini, Anda dapat memulai gim. Jika Anda dapat membuat mesin virtual cukup cepat untuk berjalan pada 20 frame per detik, Anda sebenarnya dapat memainkan game.


Sistem grafik mesin virtual menggunakan sistem koordinat 320x200 dengan palet 16 warna. Batas palet mungkin mengejutkan, mengingat Amiga 500 mendukung hingga 32 warna. Ini dilakukan dengan sengaja, yang memungkinkan untuk menggabungkan grafik dengan platform besar lainnya pada waktu itu - Atari ST, yang hanya mendukung 16 warna.


Tapi tidak ada hikmahnya. Keterbatasan ini menyebabkan gaya yang unik, yang, selama bertahun-tahun, masih menyenangkan mata.














Bahkan ketika dimungkinkan untuk menggunakan palet khusus untuk adegan itu, Eric Shayi memutuskan untuk tidak melakukannya. Selama tabrakan dengan the Beast, hanya tiga warna yang digunakan untuk itu: hitam untuk tubuh, merah untuk mata dan krem ​​untuk gigi. Imajinasi melakukan sisanya.






Sistem serupa untuk palet sepenuhnya terungkap dalam adegan awal. Perubahan palet yang sangat murah membuatnya mudah untuk menggambarkan petir.










Mesinnya juga mampu menciptakan efek tembus cahaya jika hanya ada delapan warna.



Di sini warna disimpan dalam [0x0.0x8].






Sinar dari lampu depan Ferrari tembus cahaya. Mereka dicat dengan warna 0x10 khusus yang tidak ada, karena hanya 16 warna yang tersedia. Nilai khusus diartikan sebagai "baca indeks buffer bingkai, tambahkan 0x8 dan kembali." Bagian terakhir dari trik ini adalah memilih dengan cerdas 8 warna berikutnya dalam palet.


Transparansi tidak sering digunakan dalam game,


tetapi dapat dilihat lagi selama percobaan,


ketika kilat akan memindahkan Leicester ke Dunia Lain.






Tiga pembingkai bingkai


Dari ketiga pembingkai, dua digunakan untuk buffering ganda, sedangkan yang kedua digunakan untuk mempertahankan komposisi latar belakang (BKGD). Optimalisasi ini menghindari menggambar ulang semua poligon latar belakang statis demi operasi penyalinan sederhana.


Dalam video berikutnya, lihat bagaimana adegan baru diambil pertama di buffer BKGD. Setiap frame BKGD baru sepenuhnya disalin ke buffer ganda. Di sana elemen bergerak, seperti Leicester, ditarik. Harap dicatat bahwa setelah mobil "diparkir", itu juga digambar di buffer BKGD untuk meminimalkan jumlah poligon yang akan ditarik dalam bingkai berikutnya.



Juga perhatikan bagaimana komposisi menggunakan algoritma sederhana oleh artis , yang, meskipun sederhana, menyebabkan penggambaran ulang yang tidak perlu. Ini bukan masalah karena sebagian besar disusutkan oleh salinan BKGD.


Opcode mesin virtual


Tabel berikut menunjukkan 29 opcodes. Di sini Anda dapat menemukan opcode untuk flow control (THRD), manajemen framebuffer (FB) dan semua operasi manajemen register. Sebagian besar operasi “sederhana” untuk diterapkan, dengan pengecualian COPY FB, FILL, dan DRAW_POLY *, yang rumit dalam hal kinerja.




Kedua opcode DRAW_POLY_ * menjangkau lebih dari satu sel. DRAW_POLY_BACKGROUND menempati setengah dari ruang opcode - dari 0x80 hingga 0xFF . Sangat boros, tetapi ini adalah trik untuk menghemat ruang. Menggunakan semua operasi yang dimulai dengan bit "1" memungkinkan 7 bit lainnya ditransfer ke ruang opcode sebagai parameter rendering. Karena opcode ini digunakan untuk latar belakang dan sinonim, menghemat ruang sangat penting.


Versi SPRITE menggunakan semua opcode yang dimulai dengan bit "01", sedangkan 6 bit sisanya digunakan untuk menyandikan koordinat [x, y] dan memperbesar untuk menggambar "sprite" dari Leicester, teman dan musuh.


Apa selanjutnya


Seperti disebutkan sebelumnya, 26 dari 29 opcodes mudah diimplementasikan. Masalah sebenarnya ketika porting game ini adalah memanipulasi piksel dalam batas-batas bus dan bandwidth prosesor. Seri ini akan membahas bagaimana framebuffer dimanipulasi di pelabuhan dan bagaimana masalah opcode DRAW, FILL, dan COPY diselesaikan.

Source: https://habr.com/ru/post/id482872/


All Articles