Sony PlayStation
Kisah PlayStation dimulai pada tahun 1988 ketika Nintendo dan Sony mulai bekerja bersama pada pembaca CD-ROM opsional untuk konsol SNES. Berdasarkan ketentuan perjanjian, Sony dapat secara mandiri mengembangkan game untuk platform ini dan mempertahankan kendali format Super Disc - dua konsesi yang tidak biasa oleh Nintendo.Proyek ini dikembangkan sebelum pameran CES '91, di mana Sony mengumumkan kolaborasi di Play Station. Hari berikutnya, di pameran yang sama, Nintendo, yang mengejutkan Sony, mengumumkan bahwa mereka malah menandatangani perjanjian kemitraan dengan Philips (dengan syarat yang jauh lebih menguntungkan). Sony yang loyal dan dipermalukan di depan umum mencoba mengajukan banding ke dewan direksi Sega, yang segera menolak gagasan itu. Dalam sebuah wawancara dengan 2013, CEO SEGA Tom Kalinske mengingat keputusan dewan.“Ini ide yang bodoh, Sony tidak tahu cara mengembangkan peralatan. Mereka tidak tahu cara menulis perangkat lunak. Mengapa kita mengacaukannya? ” - Dewan Direksi SEGA
Dan mereka tidak salah, Sony benar-benar memiliki sedikit pengalaman dalam bekerja dengan game. Dia hampir tidak menunjukkan minat pada mereka, dengan pengecualian atas inisiatif satu orang - Ken Kutaragi. Dari saat dia melihat putrinya bermain di Nintendo Famicom, Ken telah meyakinkan Sony bahwa dia harus memasuki pasar ini. Terlepas dari rekomendasi wakil presiden Sony, ia bahkan mengembangkan chip audio (SPC700) untuk Nintendo yang digunakan di SNES.Sebagian besar eksekutif Sony menganggap ini taruhan berisiko, tetapi Kutaragi menemukan dukungan dalam diri CEO Sony Norio Oga. Pada Juni 1992, Ken diizinkan untuk mulai membuat sistem permainan dari awal. Untuk menenangkan dewan direksi, "bapak PlayStation," sebagaimana mereka kemudian memanggilnya, dipindahkan ke perusahaan induk independen Sony Music, dan ia mulai mengerjakan apa yang pada akhirnya akan menjadi "PlayStation" (sudah tanpa spasi dalam nama).Awalnya, pengembang tidak dapat memutuskan apakah arsitektur harus fokus pada grafik 2D sprite atau grafik 3D poligon. Namun, keberhasilan game Virtua Fighter yang dirilis pada Oktober 1993 oleh Sega di mesin arcade Jepang menghancurkan semua keraguan: PSX akan mengikuti jalur 3D.Puncak dari proyek ini datang dua tahun kemudian, ketika Sony Computer Entertainment dibuat pada 3 Desember 1994 dan konsol dirilis di Jepang. Itu meraih kesuksesan instan dan dijual pada hari pertama dengan sirkulasi 100 ribu perangkat, 2 juta perangkat setelah enam bulan, dan 102 juta perangkat sepanjang hidup mereka.Sony PSX (PS1, PlayStation). Foto: WikipediaArsitektur
Inti dari mesin ini adalah prosesor MIPS 32-bit RISC R3000A dengan frekuensi 33.8688 MHz [3] dalam kombinasi dengan 2 MB DRAM. Patut dicatat bahwa chip ini juga memiliki Motion Decoder (MDEC), yang menyediakan pemutaran video dengan resolusi 320x240 pada frekuensi 30 fps. Di sebelah MDEC, kita melihat koprosesor Geometry Transform Engine (GTE), yang digunakan untuk melakukan operasi matematika fixed-point cepat pada vektor dan matriks. Sistem secara keseluruhan tidak dapat bekerja dengan angka floating point.GPU adalah "kotak hitam" yang dikendalikan oleh prosesor pusat menggunakan "perintah". Ini memiliki 1 MB VRAM, tidak tersedia untuk CPU. Dalam banyak hal, karyanya menyerupai karya mode Immediate OpenGL yang luar biasa: ia menggambar poligon bertekstur yang dapat "diarsir" menggunakan warna titik. Pipa grafik diperbaiki dan tidak dapat diprogram. Tidak ada buffer Z (buffer kedalaman).Unit pemrosesan suara, Unit Pemrosesan Suara (SPU), seperti GPU, adalah kotak hitam. Ini dapat memproses 24 saluran, memiliki 512 KB SRAM untuk menyimpan audio (dalam format ADPCM) dan mampu mencampur trek audio CD-ROM dengan saluran audio-nya. Singkatan SRAM tidak berarti "RAM Statis", tetapi "RAM Suara".Keputusan insinyur Sony yang paling berani adalah pilihan pembawa data. Mereka memilih bukan kartrid, tetapi modul CD-ROM dua kecepatan, yang mengurangi biaya permainan dan secara signifikan meningkatkan volume yang tersedia (hingga sekitar 650 MB). Kerugiannya adalah kecepatan transfer yang rendah (300 KB / dtk) dan waktu pemasangan head yang sangat besar (300 ms).Tidak ada blitter di konsol. Model pemrograman mesin adalah bahwa pengembang tidak menyentuh besi "telanjang". Namun, ada pengontrol DMA untuk mentransmisikan data dari CD / DRAM ke VRAM / SRAM.Sistem video
Terlepas dari kenyataan bahwa sistem video mendukung warna 24-bit, sangat sedikit game yang menggunakannya (dengan pengecualian latar belakang Heart Of Darkness [4] ). Dalam praktiknya, dapat dikatakan dengan hati nurani yang baik bahwa sebagian besar game menggunakan warna 16-bit dengan topeng 1-bit.Ruang warna PSX dengan kedalaman 15 bit per pikselFitur menakjubkan dari sistem video adalah organisasi VRAM, yang sepenuhnya bergantung pada pengembang. 1 MB VRAM dianggap sebagai array 1024 x 512 x 16 bit yang dapat digunakan secara bebas. Penerapan buffering ganda atau tripel dilakukan dengan cara yang sepele, karena area tersebut cukup untuk menyimpan, menggambar, dan mentransfer ke sistem output. Tekstur juga dalam VRAM, di sebelah buffer bingkai. Untuk menulis ke buffer bingkai, perintah GPU untuk rendering segitiga bertekstur / segi empat diluncurkan.Tekstur dapat memiliki berbagai format. Ada dua sumber langsung warna 16-bit dan 24-bit, serta sumber-sumber berdasarkan palet yang disebut Color Look Up Table (CLUT). CLUT 8-bit dan 4-bit didukung.Dalam hal resolusi, konsol ini terbatas pada standar televisi NTSC dan PAL. Untuk pasar AS dan Jepang, pengembang dapat memilih resolusi horizontal 256, 320, 384, 512, atau 640 piksel. Resolusi vertikal adalah 240 piksel (saat melewati setiap baris raster kedua), atau 480 piksel saat berganti-ganti. Kedua mode vertikal dioperasikan pada frekuensi 60 Hz. Satu-satunya perbedaan antara NTSC dan PAL adalah peningkatan resolusi vertikal (256/512 bukannya 240/480) dan kecepatan refresh yang lebih rendah (50 Hz).Mode NTSC (60Hz) PAL (50Hz) Catatan
=================================================== ========
0 256 x 240 256 x 256 Non-interlaced
1 320 x 240 320 x 256 Non-interlaced
2 512 x 240 512 x 256 Non-interlaced
3 640 x 240 640 x 256 Non-interlaced
4 256 x 480 256 x 512 Disisipkan
5 320 x 480 320 x 512 Disisipkan
6 512 x 480 512 x 512 Disisipkan
7 640 x 480 640 x 512 Disisipkan
8 384 x 240 384 x 256 Non-interlaced
9 384 x 480 384 x 512 Disisipkan
Perhatikan mode dengan resolusi horizontal 384 piksel (8 dan 9), yang, dilihat dari id mereka, ditambahkan kemudian.DOOM di PSX
DOOM diangkut ke PSX oleh Williams Entertainment dengan dukungan dari id Software. Dibutuhkan tim yang terdiri dari lima orang sedikit kurang dari setahun [5] [6] untuk port engine, mengubah sumber daya dan memodifikasi game sehingga semuanya bekerja "hanya" pada 3,5 MB RAM.“Grafiknya telah terdegradasi: ukuran tekstur, sprite, monster dan senjata juga berkurang. [...] Terkadang kami memotong bingkai animasi. " - Harry Tisley
Hasil akhirnya dirilis pada 16 November 1995. Ini dianggap sebagai port konsol terbaik dari permainan, dan beberapa aspek bahkan melampaui versi PC karena warna puncak dan musik berkualitas CD."Sejauh ini, ini adalah DOOM terbaik!" - John Romero
Rencana belajar
Karena sifat pengembangan, struktur DOOM didasarkan pada kernel yang menggunakan enam subsistem untuk I / O. Sebagian besar waktu saya mempelajari tiga bagian yang saya temukan paling menarik, yaitu sistem file berbasis CD-ROM, audio berbasis SPU, dan video berbasis GPU, karena mereka unik dengan arsitektur PSX.Kode sumber DOOM untuk PSX tidak pernah dipublikasikan, tetapi ternyata tidak ada masalah sama sekali. Informasi yang tersedia sudah cukup.Sumber pertama adalah PSY-Q SDK yang mengagumkan, yang merupakan alat "resmi" yang digunakan oleh pengembang PSX saat itu. Ada banyak dokumentasi di dalamnya, disajikan sebagai satu set file PDF. Banyak sekali informasi yang hanya mengkonfirmasi semua kebaikan yang saya dengar tentang keramahan PSX kepada pengembang. Perpustakaan (mis., Libcd, libds) yang dikembangkan oleh Psygnosis juga didokumentasikan dengan baik. Sangat menyenangkan melihat penjelasan yang jelas, terutama dibandingkan dengan kurangnya informasi tentang konsol lain yang hampir lengkap (ya, saya berbicara tentang SNES).Sumber informasi lain adalah banyak alat eksternal yang tersedia saat ini. ISOBuster memungkinkan saya untuk membuka konten CD. PSound membantu memindai file LCD. Kemampuan yang menakjubkan dari emulator no $ PSX untuk melacak perintah GPU dan SPU telah menjadi emas nyata.Tapi mungkin saya paling terkesan dengan cinta besar DOOM untuk PSX dari komunitas penggemar. Rekayasa permainan yang lengkap telah dilakukan. PSXDOOM-RE menonjol terutama karena itu adalah basis kode C yang dapat dikompilasi menggunakan PSY-Q SDK ke dalam game PSX penuh. Kode ini sangat andal karena diperoleh dengan menulis ulang setiap fungsi kode mesin dalam C.Dunia CD yang menakjubkan
Sebelum mulai mempelajari implementasi sistem file, saya melakukan perjalanan singkat untuk lebih memahami dunia CD yang indah.Selama 20 tahun, dari 1980 hingga 2000, beberapa volume spesifikasi telah dirilis yang mengungkapkan topik ini. Bersama-sama, mereka disebut "Buku Pelangi." Buku pertama dalam seri, "Buku Merah," berisi spesifikasi untuk audio compact disk (CD). "Buku Kuning" adalah pelengkap dari "Buku Merah", ini menambahkan spesifikasi data untuk CD-ROM dan ISO-9600. The Orange Book telah menambahkan spesifikasi untuk CD-DA, CD-R (Recordable) dan CR-WR (Rewritable). Buku Putih didedikasikan untuk Video-CD (VCD). Green Book berbicara tentang CD-Interactive (CD-I). Blue Book menyajikan data Enhanced-CD (ECD) untuk dukungan multimedia. The Scarlet Book didedikasikan untuk Super Audio (SACD), yang menambahkan audio definisi tinggi. The Purple Book mencantumkan spesifikasi Double Density CD (DDCD), yang telah meningkatkan kapasitas disk dari 650 MB menjadi 1,3 GB. Akhirnya,Cyan Book merinci 9660 spesifikasi sistem file[7] .Rainbow Books berisi semua yang kita ketahui tentang CD.Sebagai minimum absolut, kita perlu memahami bahwa CD PSX biasanya terdiri dari sektor, yang masing-masing berisi 2048 byte data. Sektor dikelompokkan ke dalam trek (yang mungkin berupa data atau suara). Trek dikelompokkan dalam sesi. Informasi trek data dapat diatur menggunakan sistem file ISO-9660 standar, namun, gim ini juga dapat memiliki alamat sektor hardcoded.Di dalam CD game DOOM
Jika Anda melihat ke dalam CD-ROM menggunakan ISOBuster, Anda dapat melihat bahwa DOOM terdiri dari satu sesi yang berisi delapan trek [8] . Tujuh di antaranya adalah trek suara berkualitas CD yang diputar di antara misi dan di adegan terakhir. Lagu terakhir (# 7) bahkan menggunakan suara setan digital. Track nomor 6 sangat penting karena tampaknya diambil langsung dari rave party. Ternyata ini adalah musik yang diputar pada kartu super-rahasia 59 "Club DOOM" (kartu rahasia yang hanya dapat diakses dari kartu rahasia) [9] . Biarkan saya membiarkan Anda menghargai kegilaannya. Sebelum memulai, periksa volume suara.Lagu yang tersisa (nomor 1) adalah ISO-9660, yang berisi mesin permainan dan sebagian besar sumber daya. Setelah menjelajahi banyak port DOOM, saya dengan naif mengharapkan sebuah mesin bernama DOOM.EXE, file sumber daya PSXDOOM.WAD, dan mungkin manifes. Saya sangat keliru. 287 file [10] [11] ditemukan di trek , termasuk 60 .WAD, 120 .IMG dan .LCD yang tak terhitung jumlahnya.Data disusun berdasarkan level (lima file per kartu).Deskripsi Nama File
=================================================== =====
MAPDIR0 / MAP01.WAD Standar Geometri (BSP / Tolak / ...)
MAPDIR0 / MAPTEX01.IMG Tekstur bidang / dinding
MAPDIR0 / MAPSPR01.IMG Semua sprite dibuat oleh HAL
MUSIC / MUSLEV1.LCD Musik yang Dapat Diputar
SNDMAPS1 / MAP01.LCD Semua suara dibuat oleh HAL
Ketika ditanya mengapa semuanya diatur dengan cara baru, pengembang Crash Bandicoot Andy Gavin menjawab sebagian dalam sebuah wawancara dengan Ars Technica. [ terjemahan di Habré]"Dibutuhkan sekitar 1/3 detik untuk memindahkan kepala ke titik mana pun pada CD."
Karena kenyataan bahwa kecepatan pemosisian head hampir 300 ms (yang dikonfirmasi oleh dokumentasi PSY-Q [12] ), para pengembang di Williams Entertainment tidak dapat menyimpan arsitektur yang jelas dari mesin DOOM, yang menyimpan semua sumber daya dalam satu file (misalnya, DOOM.WAD) dan mengunduhnya berdasarkan permintaan. Di PSX, ini akan menyebabkan frame rate yang mengerikan.Pengembang memecahkan masalah dengan melemparkan jumlah byte yang tampaknya tak berujung pada CD. Semua sumber daya yang diperlukan untuk tingkat disimpan dalam lima file yang berisi geometri peta, tekstur. sprite, efek suara dan musik. Ini sangat mahal, tetapi menghilangkan kebutuhan untuk mengakses CD selama proses permainan.Fakta yang menarik:dalam daftar file di trek data ada file yang disebut PSXDOOM.WAD (4 806 088 bytes), tetapi hanya digunakan untuk memuat palet dan beberapa gambar menu. Mungkin lebih aktif digunakan dalam proses pengembangan.Ambil peta pertama sebagai contoh: jumlah total data yang diunduh telah berkurang dari 4 MB menjadi 900 KB.Ukuran Nama File (dalam byte)
=====================================
MAPDIR0 / MAP01.WAD 28 196
MAPDIR0 / MAPTEX01.IMG 90 744
MAPDIR0 / MAPSPR01.IMG 590 344
MUSIC / MUSLEV1.LCD 61 232
SNDMAPS1 / MAP01.LCD 143 632
=====================================
Total: 914.148
Mengetahui bahwa sumber daya menempati 914 KB, Anda mungkin berpikir bahwa ada banyak DRAM yang tidak digunakan tersisa. Tetapi Anda harus ingat bahwa itu juga harus sesuai dengan file yang dapat dieksekusi dari 428 KB, serta tumpukan yang berubah pada saat dijalankan. Faktanya, hanya sekitar 1 MB DRAM yang tersedia saat runtime.Fakta menarik: ketika memeriksa kode sumber PSXDOOM-RE, saya menemukan fungsi P_LoadBlocks, yang mencoba membaca dari CD hingga empat kali [13] , setelah itu ia menyerah. Ini adalah salah satu kesenangan bekerja dengan media yang mudah tergores.Saya tidak berharap waktu pemasangan kepala CD-ROM akan mempengaruhi arsitektur game begitu banyak. Beberapa game, seperti Crash Bandicoot, dibuat dari awal dengan sistem halaman untuk streaming data dari CD saat runtime. Dalam kasus DOOM, mesin tidak mampu melakukan ini. CD tidak digunakan selama pertandingan, dengan pengecualian satu lagu tertentu (ya, dari level Klub DOOM).Orang-orang id Software tidak pernah menjadi penggemar pertukaran antara kapasitas dan kecepatan yang ditawarkan CD-ROM.« - . , CD. - , Crash 'n Burn — ? . , CD , 3DO . - CD- DOOM, „ DOOM“. , . .
, CD. ». — (ATARI EXPLORER ONLINE, 22 1994 )
Fakta menarik: peristiwa di dalam game DOOM dipicu menggunakan "stretch mark." Ketika melintasi garis dengan properti khusus, fungsi khusus dipanggil. Dalam versi "lawas" dari mesin tidak ada properti yang memungkinkan Anda untuk memutar lagu. Untuk memainkan Club DOOM, tindakan linedef khusus telah dibuat (nomor 142) [14] . Sungguh menakjubkan betapa banyak upaya ekstra yang diperlukan untuk menciptakan level ini. Mungkin para pengembang benar-benar senang bersenang-senang.Kasus Archvile yang Hilang
Melakukan penelitian untuk Game Engine Black Book saya, saya tidak bisa sepenuhnya memahami frasa ini oleh desainer Harry Teesley:“Archvile memiliki bingkai animasi dua kali lebih banyak daripada monster lainnya, dan kami tidak bisa memasukkannya ke dalam PSX. Baik serangannya maupun efek kebangkitannya tidak bisa hilang. Dia terlalu besar. " - Harry Tisley (desainer) dalam sebuah wawancara dengan doomworld.com
Jelas bahwa masalahnya bukan kapasitas 650 megabyte CD, tapi saya tidak mengerti apa faktor pembatas - DRAM atau VRAM.Setelah memahami keterbatasan CD-ROM, saya menyadari bahwa masalahnya bukan pada menyimpan sprite pada CD, atau bahkan mentransfernya dari DRAM ke VRAM. Masalahnya adalah untuk memasukkan semuanya ke dalam DRAM.Fakta menarik: ArchVile sepenuhnya dihapus dari kode sumber PSXDOOM-RE. Bahkan #DEFINE-nya dikomentari [15] .#define CC_ZOMBIE "Zombieman"
#define CC_SHOTGUN "Shotgun Guy"
#define CC_HEAVY "Heavy Weapon Dude"
...
#define CC_HELL "Hell Knight"
#define CC_SPIDER "The Spider Mastermind"
#define CC_CYBER "The Cyberdemon"
#define CC_HERO "Our Hero"
Pemrograman SPU
Chip SPU hanya memahami satu format, yaitu ADPCM. Ia mampu mencampur hingga 24 saluran (termasuk trek audio CD) dan memiliki fungsi manipulasi audio yang kuat.Untuk menjinakkan binatang buas ini, DOOM PSX menggunakan perpustakaan libWESS (Williams Entertainment Sound System), yang ditulis oleh sound engineer Scott Patterson. Perpustakaannya cukup kuat, mampu menciptakan kembali sistem MiDI, di mana bank besar catatan (disebut font suara) dikendalikan oleh skor musik yang memakan sedikit ruang. Itu juga dapat memanipulasi atribut suara waktu nyata seperti volume, nada, kecepatan nada, dan fungsi ADSR (Serangan, Pembusukan, Mempertahankan, dan Melepaskan). Semua musik yang dimainkan selama bermain game dihasilkan menggunakan libWESS. Dengan satu pengecualian, Anda dapat menebaknya, ini adalah Club DOOM, yang dimainkan dari CD track nomor 6.WESS menggunakan dua format file berpemilik. Ini adalah file .WMD yang berisi skor musik dan efek suara, dan file .LCD, yang merupakan format PSX VAG (tanpa judul) dan berisi sampel ADPCM. Ketika DOOM dimulai, pustaka libWESS memuat semua efek suara (SFX, 89 buah) dan skor musik (19 buah) yang disimpan dalam file kecil (55 KB) yang disebut DOOMSND.WMD. Dia juga memuat sampel SRAM "selalu digunakan" yang diterbitkan oleh karakter, pintu, dll.MUSIC / DOOMSFX.LCD -> SRAM
MUSIC / DOOMSND.WMD -> DRAM
Setelah memuat peta, libWESS membuka MUSIC / MUSLEV% .LCD, yang berisi sampel ADPCM yang digunakan dalam musik kartu ini, dan SNDMAPS% / MAP %%. LCD, yang berisi sampel ADPCM yang diperlukan untuk musuh di level ini. Semua sampel ADPCM dimuat langsung ke SRAM dan tidak memakan ruang dalam DRAM.DOOM di PSX: GPU
Di bidang pembuatan video, Williams Entertainment perlu menyelesaikan dua masalah: sejumlah kecil VRAM (kami akan kembali ke sini nanti) dan kurangnya pemetaan tekstur yang benar dengan mempertimbangkan perspektif.“Aaron Siler dan saya mengerjakan versi untuk Nintendo 64 (game ini sangat berbeda) dan untuk Playstation. Ini adalah versi pertama yang tidak ditulis pada logam kosong, karena Sony dan Nintendo memaksa pengembang (setidaknya yang pihak ketiga) untuk menulis API dan tidak memberikan mereka dokumentasi pada register perangkat keras. Pada awalnya, budaya SGI terutama pengembang terbatas, tetapi secara bertahap Nintendo melonggarkan cengkeramannya.
Sebuah cerita lucu tentang mengembangkan versi untuk Playstation: Aaron dan saya mulai dengan arsitektur mesin yang berbeda, yang menjadikan segitiga dunia, karena konsol memberi mereka akselerasi perangkat keras penuh. Dalam kasus N64, ini bekerja dengan sempurna, karena rendering perspektif-benar dengan akurasi subpixel (hasil dari pengaruh SGI), tetapi pada Playstation pemetaan tekstur affine dilakukan dengan koordinat bilangan bulat, sehingga segitiga dinding dan lantai yang besar tampak LUAR BIASA. ” - John Carmack (Game Engine Black Book: DOOM)
Untuk memahami bagaimana "mengerikan" itu terlihat, di bawah ini saya menunjukkan tiga dinding yang diberikan dengan tekstur affine dan prospektif benar.Perspektif TexturingAffine (PSX)Perhatikan bahwa tidak ada masalah dengan dinding lurus, dan ketika sudut pandang meningkat, distorsi menjadi lebih terlihat.Masalah persepsi yang sama dihadapi pengembang Rage Software ketika porting DOOM ke SEGA Saturnus.« , id Software. , WAD Saturn, , 3D-. , , 3D- . , PC. , , : SH2 , PC, 68000 .
, » — ( DOOM Saturn) RetroGamer №134.
Mungkin, karena pengembang PSX memiliki lebih banyak waktu, mereka dapat menyelesaikan masalah pemetaan tekstur yang prospektif dengan mengubah renderer poligon GPU menjadi renderer garis."Aku berkata: backup semuanya (maka belum ada sistem kontrol versi!), Kami akan membuat game yang sama sekali berbeda." Kami menggunakan peralatan yang menghasilkan segitiga yang mewakili kolom atau baris selebar satu piksel, seperti dalam kode assembler pada PC, dan itu berfungsi dengan baik. Ternyata solusi yang lebih umum di Playstation adalah penghentian geometri di sepanjang dua sumbu, tetapi saya benar-benar menyukai bahwa Doom tampak kurang "gugup" daripada kebanyakan game untuk Playstation saat itu. "- John Carmack (Game Engine Black Book: DOOM)
Berkat proyek PSXDOOM-RE [16], kita dapat mengetahui bagaimana itu diterapkan. Pipa rendering telah sepenuhnya ditulis ulang dan dibagi menjadi dua tahap. Ini akan dibahas secara lebih rinci di bawah ini, tetapi kita benar-benar dapat melihat bahwa fungsi rendering R_Render_Wall mentransmisikan perintah menggambar dengan kode keras dengan lebar 1 piksel.void R_Render_Wall(...) {
.
int x1 = ... ;
int x2 = ... ;
.
while(x1 < x2) {
.
setRGB0(wallpoly);
setXY3(wallpoly,
x1 , ypos1 - 1,
x1 + 1, ypos2 + 1,
x1 , ypos2 + 1);
setUV3(wallpoly,
upos, v0,
upos, v1,
upos, v1);
.
x1 += 1;
}
}
Dinding diberikan dalam satu kolom lebar piksel. Lihat API, yang menyerupai mode Segera di OpenGL.Fakta menarik: perancang perangkat keras Sony mempertahankan i-cache prosesor MIPS, tetapi menonaktifkan d-cache untuk mengubahnya menjadi 1K scratchpad kecepatan tinggi. Prosedur render dinding / bidang menggunakan papan alas ini secara ekstensif.Manajemen GPU VRAM
Untuk mempelajari bagaimana kontrol VRAM dilakukan, saya memilih cara yang aneh: Saya menggunakan fungsi melihat emulator VRAM real-time no $ PSX. Fungsi ini menampilkan seluruh array piksel 1024 x 512 x 16 bit (meskipun dalam bentuk terdistorsi). Fungsi tampilan juga menunjukkan seluruh daftar instruksi GPU yang dikirimkan oleh prosesor pusat di setiap frame.No $ PSX - Tuhan mengirimi kami sebuah emulator yang memungkinkan Anda untuk melihat ke dalam GPU.Sebuah studi yang cermat tentang frame pertama VRAM memungkinkan Anda untuk belajar banyak.Frame pertama dari game ditampilkan dengan No $ PSX.Yang paling jelas adalah dua area 256 x 240 x 16 bit di sudut kiri atas, yang merupakan buffer bingkai (karena itu, permainan menggunakan buffering ganda). Perlu dicatat bahwa 256x240 adalah resolusi serendah mungkin pada PSX.Di bawah bingkai buffer adalah seperangkat piksel penuh warna - palet CLUT. Perhatikan warna merah, artinya saat layar berubah merah saat pemain mengalami kerusakan, palet yang dihitung sebelumnya digunakan.Di sudut kanan atas kita melihat tekstur yang anehnya dikompresi secara horizontal dan memiliki warna "salah". Itu terjadi karena tekstur menggunakan indeks 8-bit dari CLUT yang dijelaskan di atas.Mari kita bicara tentang kebakaran di DOOM di PS1 lagi
Pada tahun 2018, saya mempelajari bagaimana efek api disadari [17] [ terjemahan tentang Habré]. Senang rasanya bisa kembali lagi kepadanya ketika menjelajahi perintah GPU. Perhatikan bahwa tidak ada $ PSX menandai area target dari setiap perintah dengan warna merah.Tahap 1: nyala diperbarui dalam RAM dan dimuat ke VRAM (perintah CpuToVram).Tahap 2: tekstur api digambar empat kali di sepanjang layar (perintah QuadTex). Tekstur nyala memiliki lebar 32 texels, tetapi GPU digunakan untuk menggambarnya dengan lebar 64 piksel. Penyaringan Bilinear tidak dimungkinkan di sini, sampel terdekat diambil.Tahap 3: pelat DOOM Final (perintah QuadTex) digambar di atas segalanya.Bingkai penuh, tim demi tim
Sebuah studi tentang perintah yang dikirimkan dalam bingkai menunjukkan bahwa mesin benar-benar berbeda dari versi PC. Di dalamnya, dunia berputar dari jarak pendek ke jarak jauh. Pertama, semua dinding diberikan. Pada lintasan kedua, celah vertikal terisi di antara mereka (pesawat terbang) (termasuk langit). Dalam bagian ketiga (terakhir), sprite diberikan, dimulai dengan yang terjauh. Semua ini dilakukan dengan nol redrawing pixel.Di PSX, rendering sedikit lebih kasar. Semuanya dirender dalam satu pass, dilakukan mulai dari jauh. Sistem visplane yang digunakan PC untuk mengisi kekosongan di antara dinding tidak ada di sini. Berkat konsep baru yang disebut "daun," pesawat dan dinding diberikan dalam urutan subsektor. Operasi seperti itu dalam "true 3D" menjadi mungkin karena penggunaan aktif fungsi proyeksi matriks GPE. Sprite juga diberikan secara bersamaan dengan dinding / pesawat tanpa tumpang tindih dan cek pemotongan, yang menghasilkan sejumlah kecil menggambar ulang.void R_RenderPlayerView(void) {
R_BSP();
R_RenderSKY();
for (all subsectors from phase 1) {
R_RenderAll(subsector)
}
R_Render_Hud_Weapons();
}
Mari kita lihat setiap langkah secara terperinci, dimulai dengan langit, yang pertama kali dirender menggunakan CopyRectRaw. no $ PSX menunjukkan VRAM pada saat frame selesai, tetapi memungkinkan Anda untuk kembali melalui sejarah perintah. Pixel langit hanya dapat dilihat karena tidak ada $ PSX yang mengalami masalah dalam memahami retasan ini dengan kolom satu piksel lebar (emulator lain, seperti ePSXe, tidak dapat mengatasi yang lebih baik [18] ), tetapi semua piksel ini akan ditulis ulang. Perhatikan bahwa di bawah tekstur langit semua penanda kunci pintu dikumpulkan dalam atlas.Kemudian BSP dilalui secara berurutan dari jauh ke dekat. Untuk setiap subsektor, semua dinding / bidang / sprite diberikan. Jika Anda terbiasa dengan DOOM BSP, maka mungkin ingat bahwa kompiler doombsp hanya menyimpan segmen subsektor yang solid. Untuk memastikan rendering pesawat, konsep baru "daun" ditambahkan ke versi PSX, di mana segmen pemisahan BPS (tidak terlihat) disimpan. Segmen ini diproyeksikan ke ruang layar untuk menghasilkan batas-batas pesawat. Ini adalah pendekatan yang lebih "bersih", karena memungkinkan Anda untuk menyingkirkan retasan dengan ruang layar dan bug, misalnya, dari "jejak siput" yang terkenal.Dalam bidikan VRAM berikutnya, pesawat dari subsektor yang sama dengan dinding yang kita lihat di atas dirender sebagai segitiga setinggi 1 piksel. Juga perhatikan tekstur dinding / pesawat, mereka semua memiliki ukuran yang sama. Fitur ini menyederhanakan pemilihan tekstur VRAM dan menghindari fragmentasi.Kami masih berada di subsektor yang sama. Sekarang sprite dirender sebagai quadrangles (Quad). Sprite ini termasuk musuh, kerang, dinding sebagian transparan.Untuk bersenang-senang, kami akan menunjukkan kulit plasma.Kami sedang mendekati akhir dari perintah rendering. Di sini, dengan mencampur persegi panjang, senjata dirender.Langkah Terakhir: Interface Rendering (HUD).VRAM meluap!
Bekerja dengan GPU adalah latihan dalam mengalokasikan ruang di VRAM. Dalam hal buffer bingkai, CLUT, konten statis (antarmuka), dan bahkan dinding / pesawat, tugasnya adalah dasar, karena mereka semua memiliki ukuran yang sama. Tetapi dengan sprite, hal-hal sedikit lebih rumit.Karena fakta bahwa sprite memiliki ukuran yang berbeda, mereka menyebabkan fragmentasi. Selain itu, tekstur dapat menutupi area layar yang luas dan berulang, dan sprite seringkali unik dan sejumlah besar yang tidak terduga mungkin diperlukan di setiap frame. Dalam kasus terburuk, sebuah bingkai membutuhkan sejumlah sprite yang tidak dapat ditempatkan di VRAM. Ini disebut Texture Cache Overflow, dan masalah ini tidak dapat diselesaikan. Ketika ini terjadi, game mengalami crash dan menampilkan pesan kesalahan samar [19]mengingatkan sebagian dari kita tentang "No more visplanes" yang tidak menyenangkan.Semakin banyak sprite yang Anda lihat pada saat yang sama, semakin banyak VRAM digunakan.Perbedaan antara PAL dan NTSC
Sebagai kesimpulan dari bab video, saya memutuskan untuk melihat bagaimana NTSC dikonversi ke PAL. Sayangnya, seperti di banyak game lain, DOOM PSX tidak memperhitungkan peningkatan resolusi vertikal. Saat memainkan DOOM di PS1 di Eropa, Anda melihat gambar yang dikompresi secara vertikal dengan batas hitam yang terlihat.Setelah saya belajar tentang prinsip-prinsip VRAM, sulit bagi saya untuk menyalahkan para pengembang. Jika Anda memperhatikan skema VRAM di NTSC, Anda akan melihat bahwa meningkatkan resolusi vertikal dari frame buffer melanggar seluruh struktur alokasi data. Tidak mungkin menyimpan tekstur di bawahnya. Atau Anda harus memindahkan CLUT ke lokasi lain. Terlalu banyak biaya dengan manfaat yang relatif sedikit, dan meskipun fakta bahwa perbatasan hitam mengganggu permainan, saya setuju bahwa itu tidak sepadan.Ucapan Terima Kasih
Terima kasih kepada Eric Vazquez (penulis PSXDOOM-RE), Samuel Villarreal (salah satu pengembang PSXDOOM-RE) dan Dan Leslie (pengembang profesional game untuk PlayStation 1) karena telah berbagi pengetahuan mereka dengan saya.