Як вони змусили екран рухатись у Dangerous Dave?

Я в дитинстві робив ігри в BASIC, і мені було цікаво, як було зроблено графіку у версії Dangerous Dave 1988 року в C ++; тим більше, що в ті дні вони не мали гідних графічних пакетів. Пам'ятаєте, як Дейв досяг краю екрана, вся графіка екрану використовувалась для переміщення вліво в рух, що рухається вліво? Я пам'ятаю, як читав, що Ромеро використовував для цього спеціальну техніку. Я хотів створити щось на зразок Дейва, і мені було цікаво

1. який графічний пакет / метод вони використовували для Дейва?
2. і як змусити весь графічний рух так, як вони?

Моя версія "Dangerous Dave" 1988 року була версією Apple II. Прокрутка була зроблена шляхом переміщення всіх байтів екрана, після чого намалювавши нову плитку на краю екрана - повторіть 20 разів протягом повного зсуву екрана. Версія Apple II була написана всіма на мові складання 6502.

На ПК, версія 1990 року, я написав графічний код 80x86 мовою складання для всіх режимів відеосигналу в той час: CGA, EGA, VGA. Dangerous Dave PC - це єдина гра, про яку я знаю, що має у своєму розпорядженні всі 3 режими відеозйомки і перемикається в будь-який час (F2), навіть посеред стрибка!

Щоб швидко прокрутити екран, це все було мовою складання, і я використав аналогічну техніку, як і у версії Apple II - швидко переміщуйте байти у відеопам'ять і малюйте плитку з правого боку. У EGA це було складніше, оскільки для швидкого виконання чого-небудь в режимі EGA потрібно використовувати режим засувки для переміщення пам'яті. Я пам’ятаю, як навчав Тодда Реплогле, як це зробити, тож герцог Нукем 1 був би цікавою грою (повільний герцог Нукем не був би крутим).

Код гри для ПК Dangerous Dave був написаний на C, в ID ID Borland C 3.0. Найбільше налагодження було зроблено в Turbo Debugger на 12-дюймовому бурштиновому моніторі, підключеному до карти Геркулеса.

Ах, я пам'ятаю ці методики з моїх днів DOS. Переміщення відео оперативної пам’яті навколо блиску для виконання прокрутки призвело б до ривкового прокручування. EGA представила вертикальні та горизонтальні регістри панорамування пікселів, які можна використовувати для встановлення походження екрану (де у відеопам'яті відеокарта почала відображати дані з). Оскільки копіювання пам'яті не відбувається, це майже миттєво і може використовуватися для отримання дуже плавного та швидкого пікселя шляхом прокрутки пікселів на EGA та VGA, якщо у вас є прямий доступ до апаратних регістрів. Більшість скролерів у DOS використали б це, і ця частина коду, ймовірно, була б написана мовою збірки для прямого доступу до апаратних регістрів. Однак ці методи вже не дійсні. Щоб досягти подібного ефекту зараз, Я думаю, що на сучасному графічному обладнанні ви могли, ймовірно, зробити це досить швидко, просто перемалювавши весь екран кожен кадр. Іншим способом, про який я можу придумати, є використання OpenGL або DirectX і надання текстури в чотири рази в ширину екрану і переміщення цього. Це якось не здається цікавим, як маніпулювати апаратними регістрами :)

Редагувати: Ось посилання на статтю доктора Доббса, де йдеться про прокручування боком. Це може бути метод, що використовується для цього ефекту.

http://www.drdobbs.com/184408045

Важко судити, як це було зроблено, але врахуйте, що ця гра була написана для дуже специфічної технічної специфікації - DOS з відеокарткою EGA (640x480 пікселів). Код, ймовірно, робить досить малі маніпуляції з відеопам'яттю, щоб прокрутка проходила безперебійно.

Ось веб-сайт, який розповідає про програмування графіки DOS, яка може дати вам уявлення про те, що це буде ...

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

Метагун (гра, розроблена Markus aka Notch aka MineCraft guy) має те саме прокручування, яке ви шукаєте.

Гра з відкритим кодом та написана на Java.

• Гра: http://www.mojang.com/compo/metagun/
• Джерело: http://www.mojang.com/compo/metagun/metagun-source.zip

Сподіваюся, ви дізнаєтесь, подивившись на код.

Я можу придумати два способи цього:

1. Груба сила: просто намалюйте сцену
2. Mode-X і регістри панорамування. Намалюйте біт, який потрібно прокрутити, і відрегулюйте регістри панорамування, щоб прокрутити сцену. Вам потрібно буде перемалювати верхню область відображення кожного кадру, але це менше роботи, ніж малювання основної ігрової зони. Вам не потрібно буде перемальовувати нижню область, оскільки в апараті був реєстр, який би спричинив зчитування відео ЦАПів відео з адреси 0 в заданій лінії сканування (тому нижня область буде знаходитись за адресою 0 у відеораматі та верхній розпочнеться після нижньої області) ^* .

Я, мабуть, пішов би з 1), оскільки в графічному процесі не так вже й багато, може бути який-небудь самостійно згенерований код, який підсвічуватимуть та вирізати зображення по краях. Однією з можливих методик, над якою працювала моя колега тоді, було спрацьовування самопису, тобто дані спрайту не були даними, це був код. Це означало, що не було перевірки прозорості, і дані, прочитані в бліді, були фактично безкоштовними (це було на 386, де кожна інструкція була прочитана, а потім розшифрована, тому замість прочитаного коду-> прочитати дані-> записати дані, це було просто зчитування коду- > записувати дані). Це спрацювало напрочуд добре - у нас було багато величезних спрайтів на декількох шарах паралакса, які працюють на 25 кадрів в секунду +.

Але ми говоримо про Ромеро тут, і, мабуть, йдеться про трохи перебільшення щодо техніки.

• Я фактично робив це в своїй першій великій грі DOS, і в деяких технічних засобах є помилка, через яку скидання адреси сталося скануванням занадто рано, щоб у вас був піксель на піввисоти між двома секціями.