![IS]
H
Ч 30
fio
п
*
-К
у,старые игры,игровой автомат](http://img2.reactor.cc/pics/post/%D1%81%D1%82%D0%B0%D1%80%D1%8B%D0%B5-%D0%B8%D0%B3%D1%80%D1%8B-%D0%B8%D0%B3%D1%80%D0%BE%D0%B2%D0%BE%D0%B9-%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82-6521223.png "старые игры,игровой автомат")
Интересно, что, кинув в автомат четвертак, игроки покупали не отдельный раунд или несколько, а фиксированное время, в течение которого могли играть без ограничений.
Оригинал: https://silicondarwin.blogspot.com/2017/05/space-wars-1977.html
Продолжаю пилить свой роуглайк. Главной фичей новой версии будут события. Что это такое? Если по-простому, - миниатюрные текстовые квесты, которые активируются при первом посещении комнаты игроком. Для меня это в первую очередь нарративный инструмент, потому что через них можно вводить элементы лора, которые иначе пришлось бы распихивать по случайным бумажкам, забытым дневникам и секретным документам, что на мой взгляд звенящая пошлость. Кроме того, это возможность разнообразить геймплейную рутину и задействовать те навыки и параметры персонажа, которые сейчас недостаточно нагружены.
Дисклеймер: эта серия постов не про UEFI. Это не значит, что я не знаю о существовании UEFI. Про UEFI будет отдельная серия постов. Почему я не пишу про UEFI прямо сейчас? Потому что UEFI - это уровень абстракции над железом, а мне интересно именно железо и работа с ним.
Продолжаем? Сейчас наш загрузчик второго уровня работает в "немом" режиме - без возможности подать сигнал об ошибке или выполнении операции. Это необходимо исправить. Самое очевидное решение - вывод информации на дисплей. Мы уже условились, что на нынешнем этапе для работы нашей ОС будет необходима VGA-совместимая карта и дисплей, так что вправе рассчитывать на их наличие.
Программирование VGA-контроллера - сложная штука. Однажды мы ею обязательно займёмся, но сейчас, раз уж мы всё ещё в Реальном режиме, есть вариант попроще: функции BIOS. Функции, связанные с работой дисплея, доступны через прерывание 10h. Мы уже пользовались им для вывода текста в первичном загрузчике, но так как теперь мы не ограничены в размере программы, функционал можно будет расширить.
Первое, что нам стоит сделать - установить нужный видеорежим на случай, если BIOS этого не сделала. Кроме того, понадобятся функции считывания положения курсора, прокрутки экрана и вывода строки. Весь код, связанный с вводом/выводом будет храниться в отдельном файле. У меня он называется io.inc. Мы ещё не использовали подключаемые файлы, но ничего сложного тут нет: в TASM они объявляются директивой include, после которой идёт путь и имя файла. Единственная тонкость тут в том, что подключенный файл не будет вынесен в какую-то изолированную область памяти, как это делается в языках высокого уровня, а окажется в исполняемом файле именно там, где был объявлен. Поэтому лучше объявлять подключаемые файлы где-нибудь в конце, за пределами основного кода.
VGA имеет набор стандартных режимов отображения, с которым можно ознакомиться тут:http://www.columbia.edu/~em36/wpdos/videomodes.txt
Нас интересует режим номер 3 - 80х25 символов, 16 цветов. Для его включения создадим в файле io.inc процедуру set_vmode3. Её полный текст будет выглядеть так:
set_vmode3 proc
push ax
push bx
pushf
xor ax,ax
mov ah,0Fh
int 10h
cmp al,03h
je @@exit_good
mov ax,0003h
int 10h
xor ax,ax
mov ah,0Fh
int 10h
cmp al,03h
jne @@exit_bad
@@exit_good: mov byte ptr vmode,al
mov byte ptr vcol,ah
mov byte ptr vrow,19h
mov byte ptr vpage,bh
popf
clc
pop bx
pop ax
ret
@@exit_bad: popf
stc
pop bx
pop ax
ret
set_vmode3 endp
Начинается процедура, как и почти всегда у меня, с сохранения состояния используемых регистров в стеке. Это нетипичный для ассемблера подход. Обычно, создавая низкоуровневый код, программист стремиться максимально оптимизировать использование инструкций, по возможности обходясь без обращений к памяти, использования стека и вызова процедур. К сожалению, при работе над большим проектом это невозможно, и я на горьком опыте выяснил, что лучше потратить лишние циклы на инкапсуляцию процедуры, чем потом мучительно отлавливать баг, который появился из-за того, что какой-то регистр внепланово изменил значение.
xor ax,ax mov ah,0Fh
int 10h
cmp al,03h
je @@exit_good
Этот блок нужен для того, чтобы остановить выполнение процедуры, если режим 3 уже установлен. Сначала регистр AX обнуляется, чтобы мы точно знали его значение. Функция 15 (0Fh) прерывания 10h возвращает в регистре AL номер установленного режима. Далее мы сравниваем результат с нужным значением (3), и если они равны, то переходим к завершению процедуры, метка @@exit_good. Если режим 3 не установлен, продолжаем.
mov ax,0003h int 10h
Здесь мы опять вызываем прерывание 10h со следующими параметрами: AH = 0(функция 0, установка видеорежима), AL = 3(номер режима). После этого снова идёт проверка режима. Если AL всё ещё не равен 0 - вероятно, возникла проблема, которую мы не сможем решить. Переходим к метке @@exit_bad. Если AL равен 3, продолжаем от @@exit_good. Первым делом - сохраняем в переменные параметры режима, которые вернуло прерывание 10h. В AL - номер режима; в AH - количество колонок символов; в BH - активную страницу видеопамяти (об этом позже). Параметр vrow не возвращается, потому что технически количество символьных строк ограничено только объёмом видеопамяти, а не размером дисплея. После этого восстанавливаем сохранённые в начале регистры, устанавливаем CF (флаг переноса) в нужное положение и завершаем процедуру.
Готово. Теперь в основной модуль после call read_BPB добавляем call set_vmode3 и после этого jc panic. JC - инструкция условного перехода. Переход выполняется при установленном флаге CF. То есть, если наша процедура set_vmode3 завершилась неудачно, программа продолжится от метки panic. Так как невозможность установить видеорежим говорит либо о серьёзных неполадках, либо о несовместимом оборудовании, продолжать выполнение смысла нет. После метки panic останавливаем программу инструкциями cli и hlt.
Далее стоит вывести какое-нибудь приветствие или заголовок, просто чтобы уведомить пользователя о том, что программа работает. Для этого первым делом стоит узнать положение курсора, ведь на экране скорее всего уже есть какой-то текст от BIOS. Это тоже можно сделать с помощью прерывания 10h. Добавьте в io.inc процедуру get_cursor_pos:
get_cursor_pos proc push ax
push bx
push cx
push dx
pushf
mov ah,03h
mov bh,byte ptr vpage
int 10h
mov byte ptr cursor_X,dl
mov byte ptr cursor_Y,dh
popf
pop dx
pop cx
pop bx
pop ax
ret
get_cursor_pos endp
Про сохранение/восстановление используемых регистров объяснять больше не буду, а в остальном тут всё просто: вызываем функцию 3 прерывания 10h, в BH передаём активную страницу видеопамяти. Прерывание возвращает в DL позицию курсора по X, а в DH - по Y. Сохраняем в переменных. Готово. Далее нам понадобится процедура для прокрутки содержимого дисплея. Тут чуть сложнее, добавьте в io.inc:
scroll_up proc push ax
push bx
push cx
push dx
pushf
mov ah,06h
mov bh,CS_DEFAULT
xor cx,cx
mov dl,byte ptr vcol
dec dl
mov dh,byte ptr vrow
dec dh
int 10h
popf
pop dx
pop cx
pop bx
pop ax
ret
scroll_up endp
Функция прокрутки экрана BIOS требует, во-первых, цветовую схему, которой будут заполнены очищенные строки, а во-вторых, координаты верхнего левого и правого нижнего углов сдвигаемой области. Цветовая схема передаётся в регистре BH и состоит из цвета фона и цвета символа. Мы ещё не объявляли константы, давайте посмотрим, как это делается. Константы в отличие от подключаемых файлов можно объявлять где угодно, так как они нужны только на этапе компиляции и не попадают в исполняемый файл. В TASM для объявления констант используется инструкция equ. Вся конструкция выглядит так: ИМЯ КОНСТАНТЫ equ ЗНАЧЕНИЕ КОНСТАНТЫ. Так как в стандартной палитре третьего режима всего 16 цветов, уместно будет определить их в виде констант. Добавьте в код такую запись:
;Цвета фона.BC_BLACK equ byte ptr 00h
BC_BLUE equ byte ptr 10h
BC_GREEN equ byte ptr 20h
BC_CYAN equ byte ptr 30h
BC_RED equ byte ptr 40h
BC_MAGENTA equ byte ptr 50h
BC_BROWN equ byte ptr 60h
BC_LIGHTGRAY equ byte ptr 70h
;Цвета символа.
SC_BLACK equ byte ptr 00h
SC_BLUE equ byte ptr 01h
SC_GREEN equ byte ptr 02h
SC_CYAN equ byte ptr 03h
SC_RED equ byte ptr 04h
SC_MAGENTA equ byte ptr 05h
SC_BROWN equ byte ptr 06h
SC_LIGHTGRAY equ byte ptr 07h
SC_DARKGRAY equ byte ptr 08h
SC_LIGHTBLUE equ byte ptr 09h
SC_LIGHTGREEN equ byte ptr 0Ah
SC_LIGHTCYAN equ byte ptr 0Bh
SC_LIGHTRED equ byte ptr 0Ch
SC_LIGHTMAGENTA equ byte ptr 0Dh
SC_LIGHTBROWN equ byte ptr 0Eh
SC_WHITE equ byte ptr 0Fh
;Несколько готовых цветовых схем.
CS_DEFAULT equ BC_BLACK or SC_CYAN
CS_CLASSIC equ BC_BLACK or SC_LIGHTGRAY
CS_DARK equ BC_BLACK or SC_DARKGRAY
CS_BLUE equ BC_BLUE or SC_LIGHTBLUE
CS_ALARM equ BC_BLACK or SC_RED
CS_DEBUG equ BC_BLUE or SC_WHITE
CS_INVERT equ BC_LIGHTGRAY or SC_BLACK
CS_PANIC equ BC_RED or SC_BLACK
Как видите, для передачи цвета фона/символа используется один байт. Нижние 4 бита отвечают за цвет символа, верхние - за цвет фона и некоторые другие эффекты (подчёркивание, мигание), которые нам сейчас не нужны. Теперь разберёмся с рабочей областью. Мы хотим сдвинуть вверх весь экран, поэтому верхняя левая точка будет в (0,0), а правая нижняя - в (число символов по X-1,число символов по Y-1). Первая передается в CX, вторая - в DX. Таким образом, код процедуры расшифровывается так:
AH=номер функции (6)BH=цветовая схема
CX=верхний левый угол рабочей области (0,0)
DX=правый нижний угол
Вызвать прерывание 10h
Процедура принимает число строк, на которое нужно прокрутить экран вверх, в AL. Добавьте после jc panic такой код:
call get_cursor_pos mov al,01h
call scroll_up
Последнее, что мы рассмотрим сегодня - вывод строки. Это функция 19 прерывания 10h. В качестве параметров она требует: сегмент и смещение строки в ES:BP; цветовую схему в BL; активную страницу видеопамяти в BH; позицию начала вывода по X в DL; позицию начала вывода по Y в DH; длину строки в CX; режим вывода в AL. Номер функции как всегда передаётся в AH.
Зная всё это, давайте подумаем, как организовать процедуру. В принципе тут всё почти однозначно, но что\ делать с длиной строки? Заносить в CX вручную перед каждым вызовом процедуры? Можно, но зачем раздувать код. Лучше включить эту информацию в саму строку. Например, приняв, что первые 16 бит строки будут содержать число символов в ней. У меня строка с заголовком загрузчика выглядит так:str_title dw 31 ;Длина строки. db '=== Tardigrada Loader v.1.1 ===' ;Строка. Теперь давайте напишем саму процедуру в io.inc. print_string proc push ax Наша процедура будет принимать два параметра: смещение строки в BP и цветовую схему в BL. Практически весь код - это заполнение регистров для вызова прерывания. В основном модуле после call scroll_up добавим: mov bl,CS_DEFAULT mov bp,offset str_title Этот код выведет заголовок и прокрутит экран ещё на одну строку вверх. Если всё сделано правильно, должно получиться что-то вроде этого:
push bx
push cx
push dx
push bp
push es
pushf
mov ax,0050h
mov es,ax
mov ax,1300h
mov bh,byte ptr vpage
mov cx,es:[bp]
mov dh,byte ptr cursor_Y
mov dl,byte ptr cursor_X
add bp,0002h
int 10h
popf
pop es
pop bp
pop dx
pop cx
pop bx
pop ax
ret
print_string endp
call print_string
mov al,01h
call scroll_up
Исходники: https://drive.google.com/file/d/144cHXVlBskSiKt9zTAR1V535UQCeUyBL/view?usp=sharing
Bochs: https://drive.google.com/file/d/16k2Gpr7oPSekq4rAhmtBV0IPnIteDLlE/view?usp=sharing
Guided Missile -- выпущенная Midway игра, где два игрока соревнуются, кто набьёт больше очков за отведённый промежуток времени, пуская управляемые ракеты по проезжающим по экрану целям.
Ракеты запускаются из двух стационарных пусковых установок, и до достижения ими верхней точки траектории неуправляемы. Во время снижения курс можно отклонять влево или вправо.
В Hustle после столкновения игра не заканчивается, но
есть 90-секундный лимит времени.
Коробки с очками могут быть двух типов: с числом или тремя знаками вопроса. Первые всегда добавляют очки к финальному счёту, вторые при столкновении могут оказаться со знаком плюс или минус.
Что отличает Boot Hill от Western Gun?
- спрайты персонажей стали чуть меньше, что повредило детализации, зато усложнило перестрелки.
- появился режим для одного игрока. Вторым ковбоем теперь может управлять компьютер.
- неразрушимая повозка присутствует на экране с самого начала. В поздних раундах она начинает ездить снизу вверх, как и в Western Gun.
- в некоторых автоматах использовалась подложка с фоновым изображением, на которую проецировалась игра.
Фото Тони Уолдрона (Tony Waldron) для Killer List of Videogames
- в игре есть музыка! Перед началом дуэли играет что-то напоминающее Эннио Морриконе, а при попадании в цель - похоронный марш.
Пожалуй, единственный примечательный факт о Boot Hill -- автомат с ней засветился в фильме Джорджа Ромеро Рассвет мертвецов.
Оригинал статьи: https://silicondarwin.blogspot.com/2017/04/boot-hill-1977.html
Главные фичи версии 0.17:
- наконец-то работает позиционирование в бою. Это ещё не финальный набор действий, но уже кое-что. Игрок и существа могут перемещаться относительно друг-друга, разные действия работают на разной дистанции, у существ есть предпочтения относительно дистанции до игрока. Кроме того, наличие у существ разных наборов действий для разных дистанций добавляет в бои толику тактики: одни враги опаснее вблизи, другие - на расстоянии.
- некоторые умения существ теперь имеют расходуемый боезапас. Например, servant husk ходит с комплектом из трёх зажигательных бомб.
- появился навык survival, благодаря которому игрок сможет находить подножный корм и, соответственно, меньше зависеть от очень редко выпадающих пищевых рационов. В связи с этим скиллом я запланировал несколько интересных механик, но это пока дело будущего.
- доступна одна из восьми концовок.
Полный список изменений как водится приложу в комментариях.
Ссыль на bochs:
https://drive.google.com/file/d/16k2Gpr7oPSekq4rAhmtBV0IPnIteDLlE/view?usp=sharing
Ссыль на дискету:
https://drive.google.com/file/d/1GMZp_dqP8fFn1-YGgFVDo8gxM5FGlE0m/view?usp=sharing
В 1977 году компания Atari выпустила свою первую игровую консоль, знаменитую Atari Video Computer System, позже переименованную в Atari 2600. Даже сейчас её незатейливые игры обладают каким-то странным очарованием. Сложно сказать, в чём тут дело. Может, в низком пороге вхождения -- у контроллера Atari 2600 всего один стик и одна кнопка -- играть можно даже мертвецки пьяным. Или в простоте визуального оформления, которая раскрепощает воображение. Star Ship Боба Уайтхеда была одной из стартовых игр. Launch titles, как их теперь называют.
Как и большинство картриджей для Atari 2600, Star Ship -- это целый набор миниигр с более-менее отличающимися правилами. Их можно разделить на четыре большие группы.
Первая, её же я бы назвал основной, это тир от первого лица. Игрок, глядя из кабины своего корабля, отстреливает летящих навстречу роботов, похожие на энтерпрайз корабли и летающие тарелки. Иногда встречаются неразрушимые астероиды, от которых надо уворачиваться. Каждый сбитый объект прибавляет очки, а каждое столкновение - вычитает. Игры этой группы различаются скоростью и числом противников.
Второй тип похож на первый, но без стрельбы. Здесь игроку нужно просто лететь вперёд, уворачиваясь от астероидов.
Третий режим -- дуэль для двух игроков, в которой они, поочерёдно меняясь, занимают место стрелка и цели. Стрелок, как и в других вариантах, управляет перекрестьем прицела и пытается подбить управляемый другим игроком корабль. Цель старается продержаться как можно дольше.
Четвёртый режим сильно отличается от других. Здесь игрок уже видит свой аппарат со стороны и должен посадить его на летающий по экрану астероид. Посадить -- значит успеть нажать на кнопку, пока спрайты корабля (или что это? зонд?) и астероида наложены друг на друга.
Игроки того времени приняли Star Ship прохладно, так как все миниигры показались им сложными. Чёрт его знает. На Atari 2600 есть чертовски сложные и запутанные игры, но это не одна из них.
Графически Star Ship вышла неплохой. По меркам Atari 2600, разумеется. У большинства ранних игр для неё были менее детальные спрайты. Звуковых эффектов немного и они не раздражают. Управление отзывчивое, но прицел мог бы шевелиться и чуть быстрее.
Canyon Bomber - простая однокнопочная (чуть не напечатал "одноклеточная") игра для одного или двух игроков. Действие происходит на одном экране, представляющем собой вид каньона в разрезе. Пространство между склонами заполнено круглыми блоками с цифрами. Игроки, пролетая над каньоном, сбрасывают бомбы, потихоньку уничтожая запас блоков. Если бомба игрока долетает до дна или стены каньона, не задев ни одного блока, это считается промахом. Три промаха -- и игрок выбывает. Побеждает игрок с большим числом очков в конце партии.
Соперники начинают партию на дирижаблях, но позже пересаживаются на бипланы, которые летят быстрее. Не уверен, происходит это по таймеру или зависит от оставшегося запаса блоков. Бомбы пробивают несколько слоёв блоков, так что игра длится не так долго, как может показаться, глядя на скриншот. За уничтожение блока игра начисляет очки в соответствии с цифрой, которой он был обозначен.
Огромный недостаток игры - её малая интерактивность. Игрок не управляет ни высотой, ни направлением, ни скоростью полёта своего транспортного средства. Он нужен только для того, чтобы нажимать на кнопку в нужное время. Откровенно говоря, всё это вызывает зевоту уже к середине первой партии.
Графическое и звуковое оформление игры на уровне для своего времени. Хотя отсутствие нормального игрового процесса, конечно, было бы здорово компенсировать картинкой выше среднего. Зато -- это игра, которая подошла бы Стивену Хокингу, когда у того остался всего один рабочий палец.
И зачем, чёрт возьми, герои бомбят этот несчастный каньон? Чтобы как-то объяснить для себя происходящее, я фантазировал, что круглые блоки -- это головы санкционного сыра, который пытались ввезти в РФ контрабандисты.
Надо бы ещё придумать шутку про леопардовую расцветку летсредств с арта наверху, но лень. Голова после игры пустая, как тот самый каньон.
Да, кстати, Canyon Bomber не имеет абсолютно никакой исторической ценности, так что я только что зря потратил ваше и своё время.
Оригинал статьи: https://silicondarwin.blogspot.com/2017/04/canyon-bomber-1977.html
ASMperson
