Làm thế nào mà họ làm cho màn hình di chuyển trong Dangerous Dave?

Tôi đã làm game ở BASIC khi tôi còn nhỏ và tôi tò mò về cách đồ họa được thực hiện trong phiên bản 1988 của Dangerous Dave được làm trong C ++; đặc biệt là vì họ không có bất kỳ gói đồ họa đáng giá nào trong những ngày đó. Hãy nhớ làm thế nào khi Dave chạm tới mép màn hình, toàn bộ đồ họa màn hình được sử dụng để di chuyển sang trái trong một chuyển động quét? Tôi nhớ đã đọc rằng Romero đã sử dụng một kỹ thuật đặc biệt để làm điều đó. Tôi đã muốn tạo ra một cái gì đó giống như Dave, và đã tự hỏi

1. gói / phương pháp đồ họa nào họ sử dụng cho Dave?
2. và làm thế nào để làm cho toàn bộ đồ họa màn hình di chuyển như họ đã làm?

Phiên bản Dangerous Dave năm 1988 của tôi là phiên bản Apple II. Việc cuộn được thực hiện bằng cách di chuyển tất cả các byte màn hình sau đó vẽ một ô mới trên cạnh màn hình - lặp lại 20 lần cho một lần thay đổi toàn màn hình. Phiên bản Apple II được viết bằng ngôn ngữ lắp ráp 6502.

Trên PC, phiên bản 1990, tôi đã viết mã đồ họa bằng ngôn ngữ lắp ráp 80x86 cho tất cả các chế độ video tại thời điểm đó: CGA, EGA, VGA. Dangerous Dave PC là trò chơi duy nhất tôi biết có tất cả 3 chế độ video trong đó và có thể chuyển đổi bất cứ lúc nào (F2), ngay cả khi đang nhảy!

Để cuộn màn hình nhanh chóng, tất cả đều bằng ngôn ngữ lắp ráp và tôi đã sử dụng một kỹ thuật tương tự như tôi đã sử dụng với phiên bản Apple II - nhanh chóng di chuyển byte trong bộ nhớ video và vẽ một ô ở bên phải. Trong EGA, điều đó khó hơn vì để làm bất cứ điều gì nhanh chóng trong chế độ EGA cần phải sử dụng Chế độ Latch để di chuyển bộ nhớ. Tôi nhớ đã dạy cho Todd Replogle cách làm điều đó để Duke Nukem 1 sẽ là một trò chơi thú vị (một Duke Nukem chậm chạp sẽ không được mát mẻ).

Mã trò chơi cho PC nguy hiểm Dave được viết bằng C, trong Borland C 3.0 IDE. Hầu hết việc gỡ lỗi được thực hiện trong Turbo Debugger trên màn hình hổ phách 12 "cắm vào thẻ Hercules.

Ah tôi nhớ những kỹ thuật này từ thời DOS của tôi. Di chuyển RAM video xung quanh bằng cách làm mờ để thực hiện cuộn sẽ dẫn đến cuộn bị giật. EGA đã giới thiệu các thanh ghi panning pixel dọc và ngang có thể được sử dụng để đặt nguồn gốc màn hình (trong bộ nhớ video, thẻ video bắt đầu hiển thị dữ liệu từ đó). Bởi vì không có sao chép bộ nhớ đang diễn ra, điều này gần như ngay lập tức và có thể được sử dụng cho pixel rất mượt và nhanh bằng cách cuộn pixel trên EGA và VGA nếu bạn có quyền truy cập trực tiếp vào các thanh ghi phần cứng. Hầu hết các trình cuộn trong DOS sẽ sử dụng điều này và phần mã này có thể đã được viết bằng ngôn ngữ lắp ráp để truy cập trực tiếp vào các thanh ghi phần cứng. Những phương pháp này không thực sự hợp lệ nữa. Để đạt được hiệu quả tương tự bây giờ, Tôi nghĩ trên phần cứng đồ họa hiện đại, có lẽ bạn có thể làm điều đó đủ nhanh chỉ bằng cách vẽ lại toàn bộ màn hình mỗi khung hình. Phương pháp khác mà tôi có thể nghĩ đến là sử dụng OpenGL hoặc DirectX và hiển thị kết cấu thành một phần tư gấp đôi chiều rộng của màn hình và di chuyển nó. Bằng cách nào đó, nó có vẻ không thú vị bằng việc thao túng các thanh ghi phần cứng :)

Chỉnh sửa: Đây là một liên kết đến một bài viết từ Tiến sĩ Dobbs thảo luận về cuộn ngang. Nó có thể là phương pháp được sử dụng cho hiệu ứng này.

http://www.drdobbs.com/184408045

Thật khó để đánh giá chính xác cách thức này được thực hiện, nhưng hãy xem xét rằng trò chơi này được viết cho một đặc điểm kỹ thuật phần cứng rất cụ thể - DOS với thẻ video EGA (640x480 pixel). Mã có thể đang thực hiện một số thao tác bộ nhớ video ở mức khá thấp để giúp quá trình cuộn diễn ra suôn sẻ.

Đây là một trang web nói về lập trình đồ họa DOS có thể cho bạn cảm giác như thế nào ...

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

Metagun (trò chơi được phát triển bởi Markus aka Notch aka anh chàng MineCraft) có cùng cảm giác cuộn mà bạn đang tìm kiếm.

Trò chơi là Nguồn mở và được viết bằng Java.

• Trò chơi: http://www.mojang.com/compo/metagun/
• Nguồn: http://www.mojang.com/compo/metagun/metagun-source.zip

Hy vọng bạn sẽ học được từ việc xem mã.

Tôi có thể nghĩ về hai cách điều này đã được thực hiện:

1. Brute force: chỉ cần vẽ cảnh
2. Chế độ-X và thanh ghi panning. Vẽ bit để cuộn vào xem và điều chỉnh các thanh ghi panning để cuộn cảnh. Bạn sẽ cần vẽ lại khu vực hiển thị trên cùng mỗi khung hình, nhưng đó là công việc ít phải làm hơn là vẽ khu vực chơi chính. Bạn sẽ không cần vẽ lại khu vực phía dưới vì có một thanh ghi trong phần cứng sẽ khiến các bộ xử lý video video đọc từ địa chỉ 0 tại một đường quét nhất định (vì vậy khu vực phía dưới sẽ ở địa chỉ 0 trong ram video và trên cùng sẽ bắt đầu sau khu vực dưới cùng) ^* .

Tôi có thể đi với 1) vì không có nhiều đồ họa đang diễn ra, có thể có một số mã tự tạo để làm mờ và cắt hình ảnh ở các cạnh. Một kỹ thuật có thể mà một đồng nghiệp của tôi đã hoạt động trở lại sau đó là các sprite tự viết, đó là dữ liệu sprite không phải là dữ liệu, đó là mã. Điều này có nghĩa là không có kiểm tra độ trong suốt và việc đọc dữ liệu của blit hoàn toàn miễn phí (điều này là trên một nơi mà mỗi lệnh được đọc và sau đó được giải mã, thay vì đọc mã-> đọc dữ liệu-> ghi dữ liệu, nó chỉ đọc mã- > ghi dữ liệu). Nó hoạt động rất tốt - chúng tôi có rất nhiều họa tiết khổng lồ trên nhiều lớp thị sai chạy ở tốc độ 25fps +.

Nhưng chúng ta đang nói về Romero ở đây và có lẽ có một chút phấn khích đang diễn ra về các kỹ thuật.

• Tôi đã thực sự làm điều này trong trò chơi DOS lớn đầu tiên của mình và có một lỗi trong một số phần cứng, theo đó việc thiết lập lại địa chỉ đã xảy ra một đường quét quá sớm để bạn có một pixel nửa chiều cao giữa hai phần.