Должно компилироваться без проблем.
Главное проставить пути для OBJ.
Или скопировать их в основной каталог.
Щапов Юрий представляет FORTNOKS (a playable demo).
---------------------------------------------------
Смысл игры заключается в перетаскивании полудрагоценных камней на
предназначенные для них места. Все бы ничего, но игровое поле представляет
собой очень запутанный лабиринт, и на деле все оказывается не так просто.
Притом тянуть камни на себя а также толкать по два камня одновременно
запрещено правилами. Я, лично, не представляю себе общего алгоритма, который
помог бы вам пройти все 20 уровней. В общем думайте, играйте и главное не
бросайте эту игру на полпути к финалу (там вам приготовлен потрясающий
сюрприз).
Управление игрой простое: курсорные стрелки помогут вам передвигаться в
соотоветствующих направлениях, пробел - вернуться к началу уровня, клавиша
'D' (на первом уровне) включает демонстрационный режим, а если к вам
подходит терминатор (оператор терминала) - жмите ESC.
Мой ближайшие конкуренты: Sokoban by Khaled Bentebal (вероятно, автор
идеи) 1981 года, и передранный товарищем из сопредельной Грузии Kurtan. Но
ни один из них не может похвастаться такими минимальными аппаратными
требованиями: нужен компьютер не хуже 386DX-40 с видеодаптером VGA, а для
гладкой многоплановой анимации необходима 'четверка', хотя бы DX-66.
Требования к обьему оперативной памяти несущественны. Размер незараженной
копии на диске 54256 байт.
Эта игрушка - мое задание к весенней сессии первого курса физмата
КГУ.Хотя я практически не имею опыта работы с АйБиЭмками ( Вот Спектрум
-другое дело ), но могу сказать, что мне понравились некоторые прибамбасы,
которые, к сожалению, не полностью доступны владельцам дешевых балалаек.
Во первых, само собой - HDD (у моей 'трешки' - 540 мб), во вторых,
хороший монитор (хотя программировать видеоадаптер я не пожелаю и врагу), а
также цифровой звук на 44кГц (стерео). Все это обошлось мне в 1,5 млн.
рублей (дело было в августе прошлого года). Что касается 95-х форточек, то
еще не известно, стоят ли они 45 мегов на диске (пользы от них - никакой, а
убить жалко...).
Основные же преимущества АйБиЭмки - нет, нет, не скорость работы - я
убедился, что она во многих случаях тормознее любой другой машины (если не
сравнивать Pentium 200 и AMIGA на 7мГц.), а видеопамять у нее в два раза
медленнее, чем остальная RAM, хотя следовало бы наоборот. Самое главное -
доступность любого файла на диске, просмотр как в прямом, так и в
дизассемблированном виде ;), ориентация на открытые структуры данных, на
стандарты для графики и текста, возможность перетаскивания кусков файла из
одного в другой за несколько секунд т.е. внешняя открытость информации для
юзера. А с другой стороны, напротив, скопление артефактов: DOS с ее
хэндлерами, PSP и прерываниями. Работает все гадко.
2. Программирование графики.
Основные проблемы:
Очень медленная пересылка в видеопамять.
Решения.
Установить недокументированный режим vga256.
Current date: 21.03.98
Установил, как описано в ddesign.faq.Никаких изменений (в лучшую
сторону). Во первых, много возни с подпрограммой пересылки: пришлось менять
адресацию, заменять один rep movsw на четыре movsb в четырех циклах и
постоянно переключать страницы. Вопреки словам о четырехкратном ускорении
наблюдалось двухкратное торможение. Может, стоит попробовать movsd?
А как это провернуть из паскаля?
Использовать комманду 386-го 'Movsd'.
Current date: 22.03.98 Current time: 00:52.
Попробовал movsd. Просто пишешь в tasm-e:
.model tiny
.386
(...)
rep movsd
ret
Потом линкуешь этот COM в паскаль. Результаты те же.
А еще проще ставить префиксный код для данной группы команд.
Например описанное выше в паскале будет выглядеть как:
asm
(...)
db $66; rep movsw
end;
Отключить Refresh (Чтобы не конкурировать с адаптером).
Current date: 23.03.98 Current time: 19:53.
Хмм... Отключил. И ничего не вижу. Приходится включать. Очень часто.
И выключать. Тоже. Вот так вот. И снова тормозит.
Сделать аппаратное отображение на основную RAM.
К слову. Проверил игрушку на DX-66. При отключении турбонадува ведет
себя (DX-66) так же как моя 'трешка', т.е. дело не в моей ужасной
видеокарте ( у DX-66 Virge S3 ). Но ведь демки-то крутятся! Даже у меня,
например, magicbal довольно гладкий и полноэкранный. В чем дело!!!?. (Прим
сам.себя: Ломать надо, ломать.) Подсчитал FPS: 9.6 кадров.(@#$%!).
Использовать регистры графического контроллера
для пересылки четырех байт одновременно.
Current date: 24.03.98 Current time: 17:50.
Все впустую. Видео на не видео НЕ отображается (для VGA). Вот, начитался
всяких умных книжек про видеоконтроллер. Оказывается, есть такие внутренние
регистры-фиксаторы(защелки), в которые при обращении к видеопамяти по любому
адресу, помещается содержимое всех четырех плоскостей, соответствующее цвету
пикселя, который по этому адресу находится. Потом их все разом можно
записать по другому адресу, обратившись по нему. Один вопрос: зачем же мне
читать видеопамять, напрямую их программить нельзя?
Current date: та же Current time: 20:01.
Ура! Нашел хорошо структурированную и несжатую демку (JOX,4kb). Завтра
весь день буду изучать. Странно, но она, похоже копирует на экран 64 кб по
одному... Черт их разберет, демомейкеров! И вообще, она у меня тоже
тормозит...
Current date: 26.03.98 Current time: 19:24.
А, здрасте. Что-то я давно сюда не заглядывал. Замучило родное учебное
заведение. Вчера был в областной библиотеке и пролистал старые "Компьютеры
и программы". Так вот, полностью динамический экран на этом чуде техники -
386DX40 сделать просто невозможно. А то что что мы видим в игрушках -
"XIXIT" использует плазму из двух половинок в 1/3 экрана, "VIKINGS" -
плавающее по видеопамяти окно, "COOLSPOT" действует так же как я, но
выводит подготовленный буфер из быстрой RAM в видеопамять в усеченный
"почтовый ящик" (45кб из 64-х). Что касается magicbal, то он во первых,
хранит спрайты в готовом виде в четырехслойной видеопамяти (X-mode) а во
вторых, занимается в основном переключением страниц.
Итак, основные способы увеличить кол-во экранов в секунду:
Первый (минимальные требования по скорости - четверка), самый
естественный и позволяющий сделать многослойную игрушку (по типу Lion the
king): копируешь background (можно - скроллированный), накладываешь на него
следующий слой, и т.д. ( все в обычной RAM ) а затем одной командой movsd
копируешь все это прямо на экран.
И еще я тут решил сделать компенсацию движения. Алгоритм работы очень
простой: Один background, два буфера в обычной памяти в качестве
динамических видеостраниц. Обмениваешь указатели страниц, копируешь фон в
одну страницу, накладываешь спрайты, сравниваешь со второй и разницу между
ними выбрасываешь на экран. Этот способ по производительности обратно
пропорционален общему количеству изменений в кадре. В некоторых случаях (
например при скроллинге) он работает медленнее, чем простая пересылка по
movsd. Поэтому о цифровых фильтрах по всему зкрану приходится только
мечтать (Еще раз напоминаю: у меня 386-DX40 с видеокартой 'OAK' (т.е.'Дуб'
(прим.перев.)).
Насчет X-режима: в общем, в четырех страницах можно хранить много
полезных вещей, включая спрайты. Но в таком случае у нас будут точно такие
же ограничения по скорости работы со всем экраном, что и в обычном режиме
$13. К тому же я так и не придумал, как маскировать края спрайтов при
пересылке ( если мы будем использовать копирование через регистры защелки,
то хранить их придется в готовом (скроллированном) виде, в 2-4 экземплярах)
Может быть у вас это выйдет лучше.
Хотя в анимационной последовательности используется большое количество
спрайтов ( как сделать спрайт-файл - смотрите программу splink в этом
каталоге ), многие из них повторяются по методу ping-pong ;). Гораздо проще
сделать массив, содержащий ссылки на номера спрайтов в файле. При анимации
будет использоваться индекс массива. Преимущества: вам не придется
переделывать программу при изменении персонажа. Кроме того, это потребует в
сотни раз меньше памяти, чем при хранении всех последовательных итераций
( чаще всего такой файл содержит одинаковые кадры ).
EOFFrom network
|
