Как насчёт движка для Dungeon Crawl игр?

[Sandro]

Как мы все знаем, с одной стороны, уже давно имеется куча квадратно-гнездовых движков для (часто подземных) RPG игр от первого лица (команды ) : Dungeon Master (видимо, cамый первый, и насквозь подемный), The Eye of the Beholder, Might and Magic , Wizardry, и т.д.

С другой стороны, на БК наблюдается их жестокий дефицит. Я уже давно хотел исправить это дело, но всё как-то не шло. Дело в том, что на БК нет столько памяти, чтобы хранить заранее масштабированную графику катакомб. Стенки надо перспективно преобразовывать из единственной текстуры, с монстрами и объектами почти та же беда. В общем, надо для графики писать псевдо-3D движок. Даже для походовой игры, где секунда на кадр вполне допустима, на БК были сложности.

Но примерно в апреле я понял, что и как, и написал сравнительно быструю процедуру текстурирования. Только что я понял, как быстро считать на БК перспективную коррекцию. И написал. В принципе, осталось написать трассировщик лучей, и будет рабочий прототип графического движка, а дальше уже проще. Всякую (бизнес-учёт-контроль-действия) логику мы все по работе уже писали и так, вопросов нет. Только время на кодинг.

Так что скажет общественность: продолжать?


crawlspace1.zip

[Advertiser]

[Sandro]

Всем пофиг. Жаль.

[CodeMaster]

Всем пофиг.

Сколько ты думаешь БКшечников на форуме, что бы делать вывод за 9 часов летне-дачного воскресенья?

[Sandro]

Сколько ты думаешь БКшечников на форуме, что бы делать вывод за 9 часов летне-дачного воскресенья?

Да, был неправ. Каюсь. В своё оправдание могу сказать разве то, что меня сильно расстроили звонком с работы, что завтра (точнее, уже сегодня) к нам на объект едет комиссия от генподрядчика. А мы конечные исполнители, и у нас по некоторым работам пролёт аж с мая и растёт, поскольку наш подрядчик поленился выяснить, что часть оборудования делается только под заказ и очередь в итоге где-то в сентябре подойдёт.

Но на участниках форума действительно не надо было срываться, они тут ни при чём.

- - - Добавлено - - -

Но если задуман размер именно под работу на "оригинальном" железе - приветствую. Придерживаюсь того же.

Да, цель именно в этом. Чтобы работало на оригинальной изкоробочной БК. Дополнительный обвес -- это хорошо, но если без него можно обойтись -- ещё лучше.

На Спектруме были подобные проекты, частично можно заимствовать решения по коду оттуда.
Например, отрисовку стен блоками по 2х2 или 4х4/3х4 а ля чанки для ускорения графики.

Знаю. И про Вульф от Alone Coder'а тоже знаю, благо он объяснил основные приёмы.

Но у меня цель -- имеено попиксельно точный рендер. Благо, уже ясно что в две секунды я укладываюсь даже в худшем случае, то для походовки прокатит. Вот в квадратной Lands of Lore принудительно сделано медленное движение, чтобы был как-бы переход между клетками (на самом деле они просто морфят картинку).

Собственно, что я писал в Телеграме:

Рисуется попиксельно, это совершенно честное перспективное текстурирование. Эта картинка занимает чуть больше секунды. Я вот думаю насчёт применения в походовом движке типа Dungeon Master/Eye of the Beholder/Might and Magic/Wizardry.
Слева направо оно для простоты рисует, это же эксперимент. Так-то переходы между сценами можно и покрасивше сделать.
Там можно будет прогрессивное улучшение картинки сделать при обновлении, один фиг процедура внутри байтовая. Нарисовать с учетверённой скоростью, а потом добавить один детальный двухпиксельный столбец на байт, а потом по два однопиксельных. Это всё займёт то же время суммарно, но первая грубая картинка будет в 4 раза раньше.
Да можно вообще отдельную версию процедуры для слов написать и 32 столбца зафигачить за четверть секунды, а потом улучшать. Это даже чуть быстрее будет в сумме.
Со спрайтами тоже всё ясно, код чуть-чуть изменить для прозрачных пикселей.

Всем спасибо за поддержку! Очень надеюсь, что никого не обидел.

[CodeMaster]

Рисуется попиксельно, это совершенно честное перспективное текстурирование.

Текстуры на стенах могут быть любыми или они программно создаются?

[reddie]

Текстуры на стенах могут быть любыми или они программно создаются?

Уточню вопрос: текстура - честный битмап (двумерный массив) или расчеты данных для конкретного "пикселя" идут на ходу?
Ибо разницы в способе создания битмапа, по сути, нет. Хоть грузим, хоть пререндерим - все равно это огромный массив.

[Sandro]

Чуть попозже, когда будет время, изложу в виде программного документа, а сейчас просто отвечу на заданные вопросы:

Текстуры на стенах могут быть любыми или они программно создаются?

Произвольное 1-битное изображение. Цвета A и B задаются произвольно, то есть 4*3 = 12 осмысленных комбинаций. Так-то можно и чёрный на чёрном задать, движку всё равно. Разрешение не особо принципиально, но я решил, что пока будет 32x64 (256 байт плюс дескриптор).
С одной стороны, из дизайнерских соображений хочется побольше, с другой стороны -- памяти не так много.

- - - Добавлено - - -

Конечно, продолжать!

Спасибо!

Можно для начала сделать ремейк БКшной игры с 3D-лабиринтом (не помню как она называлась, "Фараон" что ли).

Да, была такая, именно Фараон. Незабываемое воспоминание детства. Написанная, если не подводит память, на Фокале! Но в ней нет ничего практически. Уже технодемка, которую я планирую (Этап I в моих терминах), должна быть большей вещью.

Надо бросить клич на форуме среди художников спектрумистов - может быть кто захочет поучаствовать в игре для БК, нарисовать спрайты и интерфейс.

А вот именно поэтому я и обратился к общественности. То есть, я хочу и буду писать свою внетленку, но сколько времени это займёт -- неизвестно. Но ясно, что много. И когда вот только что у меня получился ключевой элемент движка, я понял, что лучше будет пока сосредоточиться именно на нём, и пусть люди делают игру. Движок-то я напишу, и графику, и игровую механику. У меня всё это достаточно продумано уже. Основная конструкция соершенно ясна.
Ну а после получения рабочего движка и за свои мечты возьмусь.

Вот ещё полезный тред про такие движки на старых компьютерах: pouet.net.

Спасибо, ознакомился. Но там немного не про это: там про движки реального времени, где жертвуют картинкой в пользу скорости.

Я же, напротив, хочу походовку, в которой построение нового кадра за секунду ещё приемлемо, но зато этот кадр должен быть нарисован с попиксельной точностью и радовать глаз, пока игрок размышляет над следующим ходом. А погружение в игру надо обеспечивать не частотой кадров в секунду, а наполнением и сюжетом. В настоящее время за эталон я считаю Betrayal of Krondor. Не во всём, но основные идеи безусловно хороши.

- - - Добавлено - - -

В том плане, что экран 256х256, сжатый до пропорций 4х3, требует конвертации любой графики с других платформ, как и обратной конвертации с БК.

Никакая конвертация не нужна, это же 3D. Практически никогда ничего не изображается без масштабирования, так что и проблемы-то нет. Поэтому все текстуры и спрайты хранятся с квадратным пикселем. Это даже упрощает мне математику -- нужно ровно в одном месте умножение на 3/4, удобна константа. И всё. а так -- то умножай, то дели обратно, бррр... не хочу.

Пиксель-в-пиксель нужно рисовать только пользовательский интерфейс. Ну это не проблема.

Да, ещё, правда, вылазит проблема с изображениями предметов в инвентаре, что с ними делать? Разработчики BaK (у них же тоже неквадратный, VGA mode 13h) решили вопрос кардинально: предметы видно только в интерфейсе инвентаря и прочих контейнеров -- сундуков, трупов, магазинов ...
А в общем игровом мире их не видно никогда. Вообще никогда. Я думаю так и сделать, это всё упрощает.

- - - Добавлено - - -

По теме именно движка (продолжая разговор про текстуры): можно решить проблему памяти текстур, применяя паттерны.

Это перпендикулярные вещи. Текстуры и паттерны друг другу не противоречат, а дополняют друг друга.

То бишь шахматки/чанки для создания иллюзии многоцветности. Учитывая 4 цвета БК, это хорошее решение, имхо.

Про шахматку я думал, но это отложено на потом. Очень сильно на потом. Как минимум, на то время, когда уже будет работать базовый движок на уровне какой-то пусть простой, но игры.

Я же не демку пишу, а игровой движок.

Минус один, и то условный, как по мне: поверхность (полигон) будет сплошь залита одним "цветом" вместо рисунка.
Зато решается проблема выделения памяти под текстуры, и даже на БК-0010 получится сделать приличную игру.

Наличие попиксельно точных текстур является основной функцией графического движка. Это решение абсолютное, окончательное, и обсуждению не подлежит.

[reddie]

Мне, например, не пофиг, но к БК только присматриваюсь =)) Это для 0010 картинка? На 11-й проблем с памятью, по идее, не будет.

[Sandro]

Это для 0010 картинка?

Да, и по идее демка с одим уровнем на ней возможна. Я бюджет памяти уже прикинул.

На 11-й проблем с памятью, по идее, не будет.

1) Не факт. Принц персидский потребовал дополнительной памяти.
2) В любом случае, эту память можно потратить получше.
3) Наличие 3D упрощает разработку -- не нужно рисовать и хранить можество копий одного и того же под разными углами.
4) Опять же, дискета всего 800 КБ.

PS: Однако, голосов по-прежнему ноль.

[reddie]

дискета всего 800 КБ

В нынешнюю пору виртуальных CF-дисководов, полагаю, размер - последнее, что должно заботить =))
Демки с подкачкой с диска, вон, на мегабайты клепают, и ничего. Всех устраивает.
Но если задуман размер именно под работу на "оригинальном" железе - приветствую. Придерживаюсь того же.

На Спектруме были подобные проекты, частично можно заимствовать решения по коду оттуда.
Например, отрисовку стен блоками по 2х2 или 4х4/3х4 а ля чанки для ускорения графики.