Bagaimana mereka membuat layar bergerak di Dangerous Dave?

14

Saya telah membuat game di BASIC ketika saya masih kecil, dan saya ingin tahu tentang bagaimana grafis dilakukan dalam versi 1988 Dangerous Dave dibuat di C ++; terutama karena mereka tidak memiliki paket grafik yang berharga saat itu. Ingat bagaimana ketika Dave mencapai tepi layar, seluruh grafik layar digunakan untuk bergerak ke kiri dalam gerakan menyapu? Saya ingat pernah membaca bahwa Romero telah menggunakan teknik khusus untuk melakukan itu. Saya ingin membuat sesuatu seperti Dave, dan bertanya-tanya

  1. paket / metode grafis apa yang mereka gunakan untuk Dave?
  2. dan bagaimana membuat seluruh grafik bergerak seperti yang mereka lakukan?
graphics Nav
sumber
1
Ini adalah salah satu permainan yang saya ingat sebagai hadiah dari masa kecil saya
Wisnu
Untuk video gim ini yang sedang beraksi untuk melihat efek gulir yang dibicarakan Nav, lihat dosgamesarchive.com/download/dangerous-dave
Tim Holt

Jawaban:

18

Dangerous Dave versi 1988 saya adalah versi Apple II. Pengguliran dilakukan dengan menggerakkan semua byte layar kemudian menggambar ubin baru di tepi layar - ulangi 20 kali untuk pergeseran layar penuh. Versi Apple II ditulis semuanya dalam 6502 bahasa assembly.

Pada PC, versi 1990, saya menulis kode grafis dalam bahasa assembly 80x86 untuk semua mode video pada saat itu: CGA, EGA, VGA. Dangerous Dave PC adalah satu-satunya game yang saya tahu memiliki semua 3 mode video di dalamnya dan dapat diubah kapan saja (F2), bahkan di tengah lompatan!

Untuk menggulir layar dengan cepat, semuanya dalam bahasa assembly dan saya menggunakan teknik yang sama seperti yang saya gunakan dengan versi Apple II - dengan cepat memindahkan byte dalam memori video dan menggambar ubin di sisi kanan. Dalam EGA itu lebih sulit karena untuk melakukan apa pun dengan cepat dalam mode EGA diperlukan penggunaan Mode Latch untuk memori bergerak. Saya ingat mengajar Todd Replogle bagaimana melakukannya sehingga Duke Nukem 1 akan menjadi permainan yang menyenangkan (Duke Nukem yang lambat tidak akan keren).

Kode permainan untuk Dangerous Dave PC ditulis dalam bahasa C, dalam Borland C 3.0 IDE. Kebanyakan debugging dilakukan di Turbo Debugger pada monitor kuning 12 "yang ditancapkan ke kartu Hercules.

user42604
sumber
Wow! senang mendapatkan info dari seseorang yang benar-benar bekerja pada mode video tersebut dalam perakitan!
Nav
@Nav ehm ... Anda sebenarnya berbicara dengan Romero sendiri :-)
Gianluca Ghettini
@GianlucaGhettini Ya, itu adalah pengguna dengan foto Romero yang tersedia di internet. Apakah John Romero akan membuat akun hanya untuk menjawab satu pertanyaan? Tidak bisa sepenuhnya yakin :-) Ini agak aneh, bahwa Anda berkomentar hanya satu hari setelah saya bermain Dangerous Dave setelah waktu yang sangat lama.
Nav
@Nav menurut tweetnya di sini: twitter.com/romero/status/679769135681826817 dia benar-benar memberi tahu Todd Replogle cara melakukan pengguliran halus EGA untuk Duken Nukem, yang persis seperti yang dia nyatakan dalam jawaban ini. Saya ragu seseorang yang berpura-pura tahu tentang hal itu .. :-)
Gianluca Ghettini
Artikel ini mengkonfirmasi bahwa user42604 memang Romero gamasutra.com/blogs/DavidLightbown/20170223/289955/…
mastazi
13

Ah saya ingat teknik ini dari masa DOS saya. Memindahkan RAM video dengan blitting untuk melakukan scrolling akan menghasilkan scroll yang tersentak-sentak. EGA memperkenalkan register panning piksel vertikal dan horizontal yang dapat digunakan untuk mengatur asal layar (di mana dalam memori video kartu video mulai menampilkan data dari). Karena tidak ada penyalinan memori yang terjadi ini hampir instan dan dapat digunakan untuk pixel yang sangat halus dan cepat dengan menggulir piksel pada EGA dan VGA jika Anda memiliki akses langsung ke register perangkat keras. Sebagian besar scrollers di DOS akan menggunakan ini, dan bagian kode ini mungkin ditulis dalam bahasa assembly untuk secara langsung mengakses register perangkat keras. Metode ini tidak benar-benar valid lagi. Untuk mencapai efek yang sama sekarang, Saya pikir pada perangkat keras grafis modern Anda mungkin bisa melakukannya cukup cepat hanya menggambar ulang seluruh layar setiap frame. Metode lain yang bisa saya pikirkan adalah menggunakan OpenGL atau DirectX dan rendering tekstur ke quad dua kali lebar layar dan memindahkannya. Entah bagaimana rasanya tidak sesenang memanipulasi register hardware :)

Madeyes
sumber
3
"Entah kenapa itu tidak menyenangkan seperti memanipulasi register perangkat keras :)" - Benar :)
Nav
4

Sunting: Berikut adalah tautan ke artikel dari Dr. Dobbs yang membahas tentang pengguliran ke samping. Mungkin metode yang digunakan untuk efek ini.

http://www.drdobbs.com/184408045

Sulit untuk menilai dengan tepat bagaimana ini dilakukan, tetapi pertimbangkan bahwa game ini ditulis untuk spesifikasi perangkat keras yang sangat spesifik - DOS dengan kartu video EGA (640x480 piksel). Kode tersebut mungkin melakukan manipulasi memori video yang cukup rendah untuk membuat gulir terjadi dengan lancar.

Berikut adalah situs web yang membahas tentang pemrograman grafis DOS yang mungkin memberi Anda gambaran tentang bagaimana rasanya ...

http://www.phatcode.net/res/224/files/html/index.html

Tim Holt
sumber
Game ini akan menggunakan mode video 320x240.
Skizz
Skizz saya juga memikirkan itu, tetapi saya menemukan beberapa tangkapan layar dari game yang berukuran 640x400 - resolusi EGA. Ada beberapa versi permainan, dan saya kira yang awal adalah 320x200.
Tim Holt
4

Metagun (game yang dikembangkan oleh Markus aka Notch alias MineCraft guy) memiliki nuansa gulir yang sama seperti yang Anda cari.

Game ini Open-Source dan ditulis dalam Java.

Semoga Anda akan belajar dari melihat kode.

は る と
sumber
1
Dan jika Anda ingin melihat timelapse dari dia membuat permainan: youtube.com/watch?v=ZV-AFnCkRLY
は る と
1
-1, meskipun terlihat sama, itu jelas tidak menggunakan metode yang sama sekali.
2
Saya sadar bahwa ini bukan metode yang tepat yang digunakan John Romero pada tahun 1988. Tetapi karena @Nav ingin membuat sesuatu yang serupa, saya tidak kecuali dia memprogramnya menggunakan Applesoft BASIC pada komputer Apple II. Kode yang saya tautkan, jelas mendapatkan pekerjaan yang sama seperti yang Anda tunjukkan.
は る と
Terima kasih Joe, tetapi Eibx benar bahwa saya juga mencari cara alternatif.
Nav
2

Saya dapat memikirkan dua cara ini telah dilakukan:

  1. Brute force: gambarkan adegannya saja
  2. Mode-X dan register panning. Gambarlah bit yang akan digulir ke tampilan dan sesuaikan register panning untuk menggulir adegan. Anda perlu menggambar ulang area tampilan atas setiap frame, tetapi itu lebih sedikit pekerjaan daripada menggambar area bermain utama. Anda tidak perlu menggambar ulang area bawah karena ada register di perangkat keras yang akan menyebabkan video DAC dibaca dari alamat 0 pada baris pemindaian yang diberikan (jadi area bawah akan di alamat 0 dalam ram video dan bagian atas akan dimulai setelah area bawah) * .

Saya mungkin akan pergi dengan 1) karena tidak banyak yang terjadi secara grafis, mungkin ada beberapa kode yang dihasilkan sendiri untuk blit dan klip gambar di tepinya. Salah satu teknik yang mungkin dilakukan oleh kolega saya saat itu adalah sprite penulisan sendiri, yaitu, data sprite bukan data, itu kode. Ini berarti tidak ada pemeriksaan transparansi dan pembacaan data blit secara efektif gratis (ini pada 386 di mana setiap instruksi dibaca dan kemudian diterjemahkan sehingga bukannya membaca kode -> membaca data -> menulis data, itu hanya membaca kode - > tulis data). Ini bekerja sangat baik - kami mendapat banyak sprite besar pada beberapa layer paralaks yang berjalan pada 25fps +.

Tapi kita berbicara tentang Romero di sini dan mungkin ada sedikit kegembiraan yang terjadi tentang teknik.

  • Saya benar-benar melakukan ini dalam permainan DOS utama pertama saya, dan ada bug di beberapa perangkat keras di mana pengaturan ulang alamat terjadi terlalu cepat sehingga Anda akan memiliki piksel setengah tinggi antara dua bagian.
Mendesis
sumber