Разработка ZXOOM

[Jukov]

Ого! Классная намётка твоей игры! Давай, конечно, объединимся.
Кажется, тот же принцип вывода - спрайтовый на 8 сторон?

---------- Post added at 20:25 ---------- Previous post was at 19:30 ----------

Нашел твой механизм построения движка: http://zx.pk.ru/showpost.php?p=35537&postcount=35
У меня всё-таки по-другому. Я сделал еще проще, не надо ничего рассчитывать по формулам, необходимые для вывода клетки уже заданы для каждой из восьми сторон (точнее, смещения до них от текущего положения игрока). Для каждой клетки - свой спрайт (точнее, группа спрайтов, в зависимости от значения в клетке). Естественно, стороны 0,90,180,270 градусов и стороны 45,135,225,315 градусов имеют одинаковые спрайты. На экран спрайты для клеток выводятся начиная с дальних клеток и заканчивая ближними - так строится полное изображение. Благодаря отсутствию математических расчетов удалось выводить игру на весь экран за приемлемое время.

У меня тоже в игре выводятся чисто спрайты. Они рисуются не в самой игре, а заранее создаются по формулам с помощью нехитрой проги на Бэйсике. Простейшие расчеты подсказывают мне, что чтобы сделать нормальную игруху с поворотами на 45 градусов и 7-плановым изображением потребуется 1Мб памяти. Если же брать только 90 градусов и 5-плановое изображение, то теоретически можно влезть и в 128Кб. Во-вторых, ты собираешься делать аркаду или стратегию? Аркада, по-моему, на таком движке получится не очень, к тому же уже есть Цитадель и Wolfenstein 2004. Хотя они смотрятся и неплохо, играть скучно. А вот стратегия, вроде Return to Home-4, будет очень даже ничего.

[Andrew771]

Всё же я делаю аркаду. Цель игры - найти выход из огромного запутанного лабиринта. А убивать всех не обязательно, если только мешают пройти. Даже когда уничтожишь всех на своем пути, еще нужно поломать голову, чтобы найти выход. Еще раз повторю - это будет Lode Runner, только трехмерный и без кладов. Хочется именно создать запутанный большой лабиринт, тем более есть опыт по их рисованию на клетчатой бумаге - у нас такая развлекуха в школе была, кто нарисует запутаннее.
Всякой предыстории и фантастического сюжета не будет - терпеть не могу, да и место не позволяет. В других играх я всегда пропускаю эту заставочную муть, если можно. С фантастикой я завязал в 16 лет, интерес полностью пропал.
Заставка естественно будет, будет показываться на небольшом участке лабиринта симуляция прохождения.
А вот с размером спрайтов не понял у тебя - откуда такие безумные цифры? Я в 7 кб вместил все голые стены, еще освободил сейчас 7.5 кб, сжав карту в новый формат (полбайта на клетку). Теперь есть 15 кб - должно хватить под всё остальное. Повторяющиеся элементы в спрайтах хранятся только один раз, т.е. многие спрайты состоят из повторяющихся блоков.
Сейчас думаю над "портальным рендерингом", точнее, над адаптированием его для Спекки, чтобы убыстрить вывод на экран (не выводить перекрываемые спрайты, как сейчас). Пока моя идея состоит в том, чтобы выводить спрайты начиная с ближних (сейчас у меня наоборот), и для каждого знакоместа отслеживать флаг - было заполнено или нет. Если заполнено, то на это знакоместо не выводить следующие попадаемые спрайты. Не всё конечно просто, т.к. на граничные по спрайту знакоместа всё же нужно выводить и перекрываемый по маске спрайт. Это я уже продумал, как не сложно учесть.

[NovaStorm]

Пока моя идея состоит в том, чтобы выводить спрайты начиная с ближних (сейчас у меня наоборот), и для каждого знакоместа отслеживать флаг - было заполнено или нет. Если заполнено, то на это знакоместо не выводить следующие попадаемые спрайты.

Z-buffer получается =)
Структур данных я конечно не знаю, но

Это я уже продумал, как не сложно учесть.

по флагу наличия активной маски на знакоместе? Проверка на такое может съесть преимущество в выводе =\

[Andrew771]

по флагу наличия активной маски на знакоместе? Проверка на такое может съесть преимущество в выводе =\

Для каждого знакоместа в описании спрайта заранее ставить флаг - будет занято знакоместо на экране или нет. Для граничных знакомест спрайта ставить "не занято".
Хотя, у меня пока есть сомнения, дадут ли все эти методики большой выигрыш в скорости. Всё-таки, проверки этого z-буфера тоже время займут. К тому же 768 байт под него жалко.
Можно ужать в 96 байт (1 бит на каждое знакоместо), но тогда долго будет искаться нужный бит.
Можно использовать под буфер байты атрибутов экрана (виртуального), бит под ненужный flash. Но тогда перед выводом виртуального экрана на реальный необходимо будет все эти биты сбрасывать, что тоже займет время.

[NovaStorm]

Можно ужать в 96 байт (1 бит на каждое знакоместо), но тогда долго будет искаться нужный бит.

Не обязательно долго, зависит от способа задания координат, если из координат выгрызти смещение и нужные три бита, то их можно будет подставить вперёд по коду прямо в BIT b,(IX+d), где координаты могут пойти в IXL и d.

[Andrew771]

Спасибо за IX+d. Я его игнорировал часто, а здесь как раз уместен. Попробую написать на этих идеях в ближайшие дни. Посмотрим, что получится.

[Jukov]

Расскажи поподробнее о распределении памяти. Можешь ли ты сейчас сделать демо, где вместо голых стен какая-нибудь текстура (например стена из кирпичей)? Сколько разных текстур вообще планируешь?
Про особенности своего движка расскажу позже (щас под рукой нет материалов).

[Andrew771]

Память сейчас так распределена:

24576-31488 - виртуальный экран
31500-39000 - карта лабиринта
39000-41000 - программа
41000-51200 - данные и спрайты

Память меньше адреса 24576 будет использована для заставки. Программа и спрайты, естественно, увеличатся.
Клетка карты может содержать максимум 16 значений. Сейчас задействованы 2 - пусто и сплошная стена. Планируется:
0 - пустота
1 - сплошная стена
2 - стена с окнами
3 - колонна
4 - бассейн (эффект воды 1)
5 - бассейн (эффект воды 2)
6 - труп
7 - враг стоит
8 - враг стреляет
9 - враг (фаза 1) вперед
A - враг (фаза 2) вперед
B - враг (фаза 1) влево
C - враг (фаза 2) влево
D - враг (фаза 1) вправо
E - враг (фаза 2) вправо
F - резерв

Задницей враг не будет поворачиваться, т.к. бегство не предусмотрено.

Т.е., элементами лабиринта будут: сплошная стена, стена с окнами, круглая колонна, круглый бассейн с движущейся водой. Для сплошных стен уже спрайты есть и заняли своё место в памяти. Для стен с окнами будут использованы многие блоки из сплошных стен, а окна - это просто дыры, так что памяти почти не займут. Колонны и бассейны будут круглыми, так что их нужно всего по 5 спрайтов разного размера, при поворотах их внешний вид не меняется. Вода в бассейне - отдельными спрайтами, причем у дальних бассейнов скорее всего не будет. Труп - 5 спрайтов. Враг в разных положениях - 8*5=40 спрайтов.
Т.к. я теперь решил использовать z-буфер для вывода на экран, то все маски отменяются - это в 1.7 раза сократит размер спрайтов.
Размеры спрайтов, предположительно, 2х2, 4х4, 8х8, 12х12, 16х16. От 20х20 останутся только отдельные куски. И то, это по максимуму. А ведь колонны тонкие, а бассейны низкие, так что уже не все знакоместа из перечисленных хранятся в памяти. Еще могут быть повторяющиеся блоки - сокращаем. Т.е., один тип спрайтов займет около 1кб.
Теперь приблизительно оценим размер (сплошные стены не учитываем уже):
стены с окнами - около 0;
колонны - 1 кб;
бассейны - 1 кб;
трупы - 1 кб;
враги - 8 кб.

Всего около 11 кб. Так что, всё уместится.

[NovaStorm]

А зачем состояния врагов хранить в карте? Там имхо этому не место.
>Т.к. я теперь решил использовать z-буфер для вывода на экран, то все маски отменяются
Как Z-буфер поможет избавится от маски? Мне кажется в лучшем случае можно сделать бит наличия маски на знакоместе или его строке.

[null_device]

Клетка карты может содержать максимум 16 значений.

А как, насчет точек входа\выхода, я понимаю, стартовую позицию, можно не отображать, но как "визуально" играющий поймет, что через n ходов он подойдет к выходу?!

---------- Post added at 15:22 ---------- Previous post was at 15:20 ----------

А зачем состояния врагов хранить в карте? Там имхо этому не место.

Логичнее только отметить наличие врага на карте, т.к. он "непроходим" и является своего рода "ходячим препятствием".