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

[Sandro]

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

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

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

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

75880
75881

[Sandro]

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

[reddie]

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

[Sandro]

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

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


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

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

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

[reddie]

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

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

[SuperMax]

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

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


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

да конечно!

[shikoist]

Что за вопросы, нужно конечно. Любая движуха это круто.)

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

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

[Manwe]

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

Вот ещё полезный тред про такие движки на старых компьютерах: pouet.net (https://www.pouet.net/topic.php?which=6267&page=3).

[reddie]

художников спектрумистов - может быть кто захочет поучаствовать в игре для БК, нарисовать спрайты и интерфейс
Только начинаю въезжать в тему БК, и насчет графики первый же вопрос: как сочетается прямоугольно-растянутый экран БК с обычным?))
В том плане, что экран 256х256, сжатый до пропорций 4х3, требует конвертации любой графики с других платформ, как и обратной конвертации с БК.
Не буду углубляться в тему "какой чудик додумался сделать прямоугольные пиксели в БК", это отдельная тема, спрошу насчет конвертеров.
Конечно, можно и ручками в граф. редакторе пережать соотношение сторон, но это подразумевает некоторую потерю качества.
Может, существуют готовые решения конвертации для минимальных потерь? Хотя бы черно-белых рисунков, учитывая 4 цвета экрана БК.

[grf]

Может, существуют готовые решения конвертации для минимальных потерь?
https://zx-pk.ru/threads/32400-dadither-eshche-odna-programka-dlya-dither-ga-kartinok.html

Но эта тема про движок, а не картинки.

[Manwe]

как сочетается прямоугольно-растянутый экран БК с обычным?в Фотошопе выставляешь aspect correction 4:3 и рисуешь без проблем. Художники на БК нужны, присоединяйся! А то программистов полно, а рисовать некому.

[reddie]

Но эта тема про движок, а не картинки
Да, просто было предложение привлечь художников ZX, а там пиксели квадратные)) Но за ссылку благодарю.
По теме именно движка (продолжая разговор про текстуры): можно решить проблему памяти текстур, применяя паттерны.
То бишь шахматки/чанки для создания иллюзии многоцветности. Учитывая 4 цвета БК, это хорошее решение, имхо.
Особенно для 0010, где строго RGB и белого цвета, как такового, не существует (подключение ч/б выхода не в счет).
Программистам, думаю, понятно, о чем речь, остальным рекомендую посмотреть вот эту демку для Atari XL.
8-битный комп с 64к памяти, создан где-то в один год с БК0010, но графически, на мой взгляд, будет помощнее.

https://www.youtube.com/watch?v=HVuEd742Yyg&t=333s

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


https://www.youtube.com/watch?v=HVuEd742Yyg&t=333s


Художники на БК нужны, присоединяйся! А то программистов полно, а рисовать некому.
Да я тоже кодер, по совместительству музыкант)) художник наш творил на Спектруме, попробую заинтересовать. Но не факт.
У него уже давно семья, работа, другие интересы...

[Manwe]

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


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

[Lethargeek]

посмотреть вот эту демку для Atari XL.
8-битный комп с 64к памяти, создан где-то в один год с БК0010,
чипсет создан лет на пять раньше, дальше только памяти добавляли да клаву перепиливали


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

[Sandro]

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


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

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

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


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

Спасибо!


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

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


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

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


Вот ещё полезный тред про такие движки на старых компьютерах: pouet.net (https://www.pouet.net/topic.php?which=6267&page=3).

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

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

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



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

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

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

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

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



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


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



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


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

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



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


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

[jerri]

1) Не факт. Принц персидский потребовал дополнительной памяти.


В оригинале Принц персидский работал на 64к машинке.
и не жужжал.



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



присмотрись к движку Wolf48
там есть что почерпнуть.



4) Опять же, дискета всего 800 КБ.

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

[Sandro]

В оригинале Принц персидский работал на 64к машинке.
и не жужжал.


А какая именно машинка имеется в виду? Коммодор, например? Ну да, работал. С постоянными подгрузками. БКшный грузится сразу весь, и больше диск не мучает, как я понимаю.



присмотрись к движку Wolf48
там есть что почерпнуть.

От Alone Coder'а? Да, я в курсе, благо он основные решения разъяснил. Но у нас принципиальная разница в устройстве текстуры: у меня битовая карта, у него -- список столбцов одноцветных пикселей. Но я имею в виду, само собой.

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

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



;
; trampoline for the dummy texture (r0 -- offset)
;
tramp1: add #dummy0 + 10, r0
clr -(sp)
mov -(r0), -(sp)
mov -(r0), -(sp)
mov -(r0), -(sp)
mov -(r0), -(sp)
br texc1

;
; trampoline for the half of dummy texture (r0 -- offset)
;
tramp2: add #dummy0 + 10, r0
clr -(sp)
mov -(r0), -(sp)
mov -(r0), -(sp)
br texc1
;
;
; draw the pixel column
; texture is 64 pixels high (8 bytes)
;
; r0 - scratch
; r1 - destination pointer (byte)
; r2 - destination column bit mask
; r3 - colors (low/high byte), pre-masked
; r4 - texture coordinate V delta
; r5 - (texture coordinate V fraction accumulator)
;
; stack -- texture terminated by #0;
; TODO run with aligned stack and terminate by tstb sp/beq exit
;
texc1: clr r5
10$: mov (sp)+, r0
beq 19$ ; exit
sec
11$: ror r0
beq 10$ ; next word
bcc 12$ ; if bit is 1 -- swap colors (TODO -- paired drawing rountine)
swab r3
12$: bicb r2, @r1
bisb r3, @r1
add #100, r1
bmi 18$ ; if reached the bottom of the screen -- exit
add r4, r5
bcc 12$
clc
br 11$
18$: tst (sp)+ ; unload stack until end of texture is found
bne 18$
19$: ret



Это текстурирование. Текстура кладётся на стек, и завершается нулевым словом. Используются все регистры. Для константы 100 (64.) регистра не хватило, увы. Основной фокус -- отсутствие счётчика битов. Вместо этого в сдвиговый регистр (r0) при первом сдвиге заталкивается единичный бит. И если он ушёл, то всё -- надо читать следующее слово (beq 10$).
Сам алгоритм масштабирований классический -- digital difference, то есть дробные приращения текстурной координаты.

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

Расчёт масштабирования. Ну тут классический алгоритм деления для младших моделей PDP, ничего такого:



;
; Calculate scale of 64-pixel texture to fit it into given pixel count
;
; r0 - pixel count
;
; returns:
; r0 - delta fraction
;
; TODO: 16-bit precision
calctexscale:
mov r1, -(sp)
mov r2, -(sp)
mov r3, -(sp)
mov #100000, r1 ; 64. * 256. * 2
clr r2
mov #16.,r3
1$: asl r1
rol r2
cmp r0, r2
bhi 2$
sub r0, r2
inc r1
2$: sob r3, 1$
mov r1, r0
asr r0
rol r3
swab r0 ; multiply fraction by 256 / 2
ror r3
rorb r0
bis #177, r0
mov (sp)+, r3
mov (sp)+, r2
mov (sp)+, r1
ret


Вот это нужно положить в r4 для текстурника.

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

Ах да, чуть не забыл: тут у меня 1 бит в текстуре означает инверсию цвета. Т.е. текстура хранится, как последовательность инверсий. Я планирую переделать в нормальный вид, а то так неудобно.

Извините за спам сообщениями :)

[jerri]

А какая именно машинка имеется в виду? Коммодор, например? Ну да, работал. С постоянными подгрузками. БКшный грузится сразу весь, и больше диск не мучает, как я понимаю.

Apple II исходники доступны.