Разработка ZXOOM

[NovaStorm]

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

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

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

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

[Advertiser]

[Jukov]

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

[Andrew771]

>15кб хочу под карту
А что так много? Судя по "(150х100)" это будет битмап? Можно ведь сделать дерево со списком кусков комнат и объектов, должно получится меньше и наверное быстрее, ведь дерево для отсечения нужно будет так или иначе.

Сообщение от Andrew771: А про дерево со списком можешь рассказать подробнее на примере? Идея интересная, но пока не врублюсь, как...


Я имел в виду http://en.wikipedia.org/wiki/Quadtree , но сейчас мне уже кажется, что такое пожалуй будет слишком круто.
Идея по уменьшению карты в том, чтобы хранить разряжённый массив "комнат", для каждой из которых прописывалась бы видимость из них объектов и других комнат(+геометрия карты, из какой комнаты в какую можно попадать).
Это будет практически http://en.wikipedia.org/wiki/Portal_rendering

Уже уменьшил место под карту в 2 раза до 7.5кб (по полбайта на клетку).
А с деревом понял наконец, только это ж надо иметь список для каждой комнаты, коих будет раз в 8-10 меньше, чем самих стен. А список-то из не менее 8 стен... Я не буду делать огромных комнат, а сам лабиринт будет насыщенным (компактным), больших комнат или больших непроходимых областей не будет. Так что, ничего не выиграешь. Quadtree не сэкономит места в моем случае.
Портальный рендерер - поинтереснее, может пригодиться для отсечения невидимых спрайтов-клеток, чтобы их не выводить. Нашел в сети книгу А.В.Боресков "Графика трехмерной компьютерной игры на основе OpenGL", там очень хорошо всё описано, рекомендую всем. Думаю сейчас, как применить портальный рендерер, только не из заранее заданного дерева или списка граней (у меня его нет, как я написал выше), а рассчитывать на ходу для текущего положения. Возможно, позволит убыстрить вывод на экран за счет невывода закрываемых дальних клеток-спрайтов.

---------- Post added at 16:51 ---------- Previous post was at 16:23 ----------

Про пирамиды - Total Eclipse. Не на треть экрана, а больше, чем на половину. Она написана на движке Freescape. На нем же - Darkside, Driller, Terminator, Castle Master 1 и 2. Но даже при таком размере скорость рендера оставляет желать. Если сделать больше - пошаговая стратегия получится... Причем, насколько я понимаю, это не обойдешь - я где-то читал, что основное время тратится не на построение трехмерной графики, а на затирание уже нарисованной.

Наверно, на определение невидимых граней. Затереть-то просто и быстро

[baxter]

...Она написана на движке Freescape. На нем же - Darkside, Driller, Terminator, Castle Master 1 и 2...

Terminator?! На видел на движке freescape, кинь ссылочку, плиз

[Andrew771]

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

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

[NovaStorm]

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

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

[Andrew771]

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

[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 ----------

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

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