Портировать Boulder Dash на ПК-01 Львов

[als]

ДОП.
(ОСНОВНОЕ В ПРЕДЫДУЩЕМ СООБЩЕНИИ!)

На момент вызова этой процедуры адрес тайла находится в HL, а координаты - в соотв. переменных _GrTiles_x и _GrTiles_y - их можно взять в произвольном месте кода.

Значит, для процедуры Call_DrawSPRITE1 нужно адрес тайла в DE ( если в HL, то можна будет позже ПОПРОБЫВАТЬ переделать процедуру чтобы не перекидывать DE=HL)
_GrTiles_x и _GrTiles_y нужно высчитывать и в HL =$4000+(Gr_DrawTile_Y*64)+Gr_DrawTile_X

Как правильнее всего выводить тайлы на Львове - я не знаю.

Смотри пример в выложеном архиве.

По поводу переключения на экранную память в Львове я ещё думаю. Видимо, тайлы надо размещать выше #8000,

ЭТО ОБЯЗАТЕЛЬНО!

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

"а в конце переключаться назад." - КОНЕЧНО! СМ.ПРОЦ LabelA(Call_DrawSPRITE1);
ОНА ТАК И УСТРОЕНА!
В начале
XraA;Out_($C2); // включить видео ОЗУ
в конце
MviA($02);Out_($C2); // отключить видео ОЗУ
поэтому лабиринты могут быть где угодно В ОТЛИЧИИ ОТ ТАЙЛОВ КОТОРЫЕ ДОЛЖНЫ НАХОДИТСЯ С $8000 - ...

Сделал не совсем то, что ты хотел, но приблизительно. Рыба есть, основа положена.

ДА НИЧЕГО СТРАШНОГО! ВОТ ТОЛЬКО В БУДУЩИХ ПРОБАХ ЗАДАВАЙ ЯВНО РАЗНЫЕ ПАРАМЕТРЫ В ПРОЦЕДУРУ Т.Е. НАПРИМЕР Gr.DrawTile(10, 10, 1); надо было не ДВЕ "10" а скажем
Gr.DrawTile(10, 20, 1); чтобы сразу можна было чётко находить их в декомпиляции!

Теперь не надо ничего дизассеблировать, просто добавить в GrTiles.c подпрограмму вывода тайла на асме, перекомпилировать её (GrTiles.Def -> F11). И пересобрать Bolder16K -> F12.

Ага!... а как же!... а кто тебе сказал что я знаю си, что у меня XDev уставлен, что мне XDev очень сильно нравиться ?!... ну-ну...

Да, пусть тебя не смущает размер бинаря. Сейчас туда попали все уровни, а они и весят примерно полтора килобайта.

Не, не смущает! Меня как видишь другое смущает, читай далее!

Ты вроде сам предложил портировать игру! А тепер хочешь все тупо скинуть на меня - "не надо ничего дизассеблировать... добавить в GrTiles.c... перекомпилировать ...пересобрать "
ну а я в свою очередь помог чем смог, а если тебе далее не интересно, то пусть эти все наработки ожидают следующего "пассажира"!

[Zorko]

У нас есть одна трудность, о которой я не подумал раньше: тайлы в этой версии Bolder могут выводиться по полу-тайловым координатам, т.е. если кратная позиция тайлов в пиксельных координатах будет {0, 0}, следующий {0, 12}, следующий {0, 24} и т.д., то наш Bolder выводит тайлы ещё и в полупозиции: {0, 6}, {0, 18}, {0, 30}. И точно то же самое по Y, но это уже не проблема.

Так что придётся с битовыми наложениями всё равно возиться. Как минимум, сделать две ветки подпрограммы вывода: по кратным 12 позициям и по полупозициям 6.

В принципе, в основном, большинство тайлов будет выводиться по кратным позициям. По некратным - только в момент падения (алмазы, камни) или движения (монстры и человечек). Так что падение быстродействия на битовые наложения не столь критично.

Или же задействовать весь экран и тайлы шириной 16, что, видимо, тоже не очень хорошая идея.

Как думаешь?

[als]

Или же задействовать весь экран и тайлы шириной 16, что, видимо, тоже не очень хорошая идея.
Как думаешь?

А вот я думаю что лучше уж делать 16х16!
Потому, то если "долбатся" с какими-то побитовыми наложениями - быстродействие явно упадет в корень! Ну а если 16х16, то полу-тайлы делай 8х16 или как там тебе надо ?
Короче, сам понимаешь, что ширина (X) в ПИКСЕЛАХ должна соответствовать правилу
(X mod 4) = 0;
Поэтому вытворяй что хочешь но правило для ширины (X mod 4) = 0; соблюдай! Про иначе, особенно для такой игрушки, я и думать не хочу! Никаких побитовых наложений!
По Y - любое можно какое тебе нужно!
Да и...
тебе не обязательно заморачиваться вбахивать саму процедуру LabelA(Call_DrawSPRITE1); в оберон (если это сложно) я то её и сам "врезать" смогу. Главное, чтобы "подточка" была под неё вот это "нужно высчитать $4000+(Gr_DrawTile_Y*64)+Gr_DrawTile_X"высчитавалось в оберене (чтобы в асме не махаться) или же в виде таблицы, но то уже позже!
А насчёт ты писал "декомпиляции не нужно" - ты глубоко ошибаешься!
Дай Бог игрушка хоть как-то заработает, я представляю сколько там нужно будет оптимизировать для скорости.
И вообще, может придется делать так сказать уровне-"экранный"-кеш,
т.е. проверять по кешу, что уже_было_выведено в данную конкретную ячейку!.. и если выводится в ту ячейку тоже самое (т.е. то что там уже есть), - то вывод не нужен!
Например надо вывести алмаз в ячейку 3,3 код алмаза=1
проверяем что было выведено в ту ячейку, если там код = 1, то пропустить вызов процедуры Call_DrawSPRITE1. при выводе естественно "метить" кеш той ячейки что туда было выведено т.е кеш-екран-уровень[3,3]:=1
хотя...
может игра у тебя так и устроена!
в тонкости еще не всматривался!

[als]

ДОП.
Ты было писал что не буду ли я плеваться... на быстродействие..
Я, - НЕТ!
А ВОТ ТЫ САМ, - ДА!
Я "нет", потому, что уже догадуюсь что это будет "на выходе", и оптимизаций никаких не хватит!
А как я понял по тебе, по твоим "замашкам" про битовые наложения какие-то,
то ты вообще не ощущаешь насколько ПК-01 Львов по быстродействию слаб!
Ты говоришь, что в 2,5 раза ниже чем на спеке, а будет казаться что во все 25 раз!
Потому говорю сейчас - может опомнись "окаянный"... пока не поздно...
может первую игрушку все таки надо поменьше и попроще какую-то взять... например "Охота на лис" ? Хотя бы вывод на екран и опрос клавиатуры был бы готовой по игре "Охота на лис", к использованию в булдере ?!
Да и наверняка нет там полу-тайлов и прочее.
Ох, с заморочливого ты сразу начал (с булдера) при том всем что нихрена ж ведь не готово толком, не вывод на экран, не опрос клавиатуры... и т.д. Тут еще и полу-тайлы "выползли"... что еще "там" "выползет" страшно подумать!

[Zorko]

В "Охоте на лис" есть игра с цветами при подсветке вертикалей, горизонталей и диагоналей. Что для Спека делается атрибутами, а для Львова придётся перерисовывать целиком в других цветах. Т.е. два набора цифр и прочих спрайтов. Тут уже долбёжка чисто техническая, это не так интересно.

Я тут прикинул, документация по Львову, включая графический вывод через ПЗУ, предлагает нам пользоваться только областью экрана разрешением 200*225 точек.

Если тайл Bolder'а будет шириной 12, то 12*16 будет 192 точек. То есть, если мы ещё и захотим выравнить изображение по центру, то придётся выводить тайлы от смещения 4, т.е. уже по полубайту. И уже наши основные тайлы, а не полупозиционные, будут в полупозиции.

А если ширину тайла сделать 16, тогда по краям всё поплывёт и исказится, насколько я понимаю. А может и выйдет за пределы отображения на телевизоре. А на эмуле зато всё будет чётенько.

Вот такая вот дилемма.

[als]

Если тайл Bolder'а будет шириной 12, то 12*16 будет 192 точек. То есть, если мы ещё и захотим выравнить изображение по центру, то придётся выводить тайлы от смещения 4, т.е. уже по полубайту. И уже наши основные тайлы, а не полупозиционные, будут в полупозиции.

Считаю большой глупостью в игре будердаш делать тайлы не квадратными!
Ты можешь представить как оно выглядеть то будет ?!
И скорость по горизонтали будет казаться меньшей чем по вертикали.
Вот запусти мой "лабиринт" в "сас-емуляторе" сделай мышкой форму 3к4 и попробуй поиграть,
я думаю ты все поймёшь о чём я!

Уж лучше тогда 8на8 если же 16на16 никак получаться не будет!
ну а 12х12 - опитимально бы было, ну вот полу-тайлы...

А как тебе такой видон булдера, а ?

[Zorko]

Про высоту тайлов я вообще ещё ничего не говорил.

Считаю большой глупостью в игре будердаш делать тайлы не квадратными!

Но ты ведь сам знаешь, что у Львова пиксели не квадратные. А как ты себе представляешь квадратные тайлы в игре с картой 16x16 тайлов на неквадратном телевизоре? Скомпенсировать размером бордюра? Ну не знаю. По идее, задействовать рабочую площадь экрана надо по-максимуму.

Кстати, из-за этой проблемы такой вариант Булдера не получается сделать на игровых консолях SegaMD/Nintendo. Там тайлы фиксированного размера 8x8.

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

Кстати, у меня в булдере рассчитывается такая табличка. Это, так сказать, хитрость игры для компенсации тормозов странслированного с Си кода.

[als]

Про высоту тайлов я вообще ещё ничего не говорил.

ну это видимо я что-то запутался... ?!?!?
Итак, поле уровня 16х16 квадратов!
один квадрат должен быть
либо 8на8 пикселей или 12на12 или 16на16.

В чем проблема то не могу понять ?!
Чего ты полемику начинаешь з-за 16на16 ?
Если ты уверен что быстродействия не хватит - могу понять, а ты о чём ? Искажения какого-то конкретного ТВ хочеш учитывать ? ну делай 12на12... а ну да... тайлы... полу-тайлы...
а 8на8 ? ах, ну да... маленькие очень! Слушай, ну все равно то выбирать нужно что-то!
4на4 не предлагаю.
"Прикол" будет в том, что если даже 8на8 не будет быстродействия хватать, - вот это проблема будет! Не хочеш з 8на8 начать, а ? не понравится тогда переделывать! Ну или з 16на16. Да какая разница! давай уже двигаться куда-то!
Что от меня то требуется (сейчас) ?

[Zorko]

Скажи, есть ли в ПЗУ Львова хоть какая-то подпрограмма вертикального скроллинга? Ведь Бейсик как-то листает вверх символы. Нам понадобится скролл вверх и вниз на заданное количество линий. В принципе, операция простая, и её тоже можно делать через нашу табличку экранных адресов (для скорости можно скроллить не весь экран, а только рабочую область).

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

Ещё я не понял, что это за линия на скриншоте типа курсора после вызова очистки экрана? Ведь не курсор же?

Ещё такой вопрос: если будем делать всё-таки шириной 12, то к какому краю лучше поджимать тайлы (для байтовой кратности) - к левому или к правому?

Всё-таки я склоняюсь к ширине 12. Число тайлов, выводящихся с битовыми наложениями, будет небольшим. Просадка скорости на них будет не заметна. Золотая середина ИМХО.

А при ширине 12 какую предлагаешь высоту тайла? Ты ведь опытный львовец, у тебя наверняка и Львов железный есть)

[als]

Скажи, есть ли в ПЗУ Львова хоть какая-то подпрограмма вертикального скроллинга?

Что то я не знаю такого! НЕТУ!

Ведь Бейсик как-то листает вверх символы.

А что значит листает вверх символы ?! Ну если постоянно выводятся строки то естественно символы строки вверх уходят!

Нам понадобится скролл вверх и вниз на заданное количество линий. В принципе, операция простая, и её тоже можно делать через нашу табличку экранных адресов (для скорости можно скроллить не весь экран, а только рабочую область).

Ну в принципе надо самому писать! Если хочешь давай детали, попробую написать!

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

Та подожди ты! А ты заглушить не можешь что-ли там где скролинг и опрос управления, чтобы хотя бы увидеть как оно тайлы выводит ?
что ты прям всё сразу, потому будем "метаться" между выводом тайлов, скролингом и опросом клавы ?! Не очень то удобно!
Поэтому наверно давай "глуши" все и сразу вывод тайлов на экран посмотрим!

Ещё я не понял, что это за линия типа курсора после вызова очистки экрана? Ведь не курсор же?

?!?! наверное курсор все таки! Его можна отключить, на док смотреть, в голове не держу!

Ещё такой вопрос: если будем делать всё-таки шириной 12, то к какому краю лучше поджимать тайлы (для байтовой кратности) - к левому или к правому?

Что то я тебе вооще отказываюсь понимать ?!
Перефразируй пожалуйста!

Всё-таки я склоняюсь к ширине 12. Число тайлов, выводящихся с битовыми наложениями, будет небольшим. Просадка скорости на них будет не заметна. Золотая середина ИМХО.

О-о-о-о! Дорогой друг, далее я тебе в этом не помошник! И думаю зря ты с эти связываешься!

А при ширине 12 какую предлагаешь высоту тайла? Ты ведь опытный львовец, у тебя наверняка и Львов железный есть)

Железного нету! ну по поводу ширины, ну я говорил - 12на12 чтобы квадратами было!
----------------
Так! По сути, жду ЧЁТКОГО ОПИСАНИЯ какая должна быть процедура скролинга, входящие какие, в каких регистрах будут и.д.т откуда и куда скролить должна по сколько линий и т.д.
----------
Процедуру управления "стрелки" и "любая" я вроде где-то кидал...
сейчас еще раз кину.
В общем пиши!

[als]

Доп.
{процедура опроса Дополнительно клавиатуры на нажатие "стрелок"}
{процедура опроса основной клавиатуры на нажатие любой клавиши}

KeyD.7z

(1.06 KiB) Downloaded 678 times

Code: Select all

program KeyD; uses  uMD01u in 'uMD01u.pas';

VAR
bKeyleft, bKeyRight, bKeyUP, bKeyDown, bKeyProtect, pKeyD, gKeyD_m1, gKeyD_m2, gKeyD_m3, gKeyD_m4,
pKeyO
:TLabelLV;

BEGIN
INITCompiler;SetFullNameLVTfile('_res.LVT');SetNameInternalKOI(#$20+#$20+#$20+#$20+#$20+#$20);

SetAddrRAM($0000);

{данные (Флаги) для каждой клавиши!}
LabelA(bKeyleft);DB($00);
LabelA(bKeyRight);DB($00);
LabelA(bKeyUP);DB($00);
LabelA(bKeyDown);DB($00);
LabelA(bKeyProtect);DB($00);


{процедура опроса Дополнительно клавиатуры на нажатие "стрелок"}
{после выполнени процедуры если bKeyleft, bKeyRight, bKeyUP, bKeyDown, = 0 -
клавиша не нажата, если любое другое - нажата!}
LabelA(pKeyD);
MviA($00);Sta(bKeyDown);Sta(bKeyleft);Sta(bKeyUP); Sta(bKeyRight);//Обнуление

MviA($F7);Out_($D2);In_($D2);cma;Ani($F0);

        Cpi($80);Jm(gKeyD_m1);Sta(bKeyDown);Sui($80);
LabelA(gKeyD_m1);Cpi($40);Jm(gKeyD_m2);Sta(bKeyleft);Sui($40);
LabelA(gKeyD_m2);Cpi($20);Jm(gKeyD_m3);Sta(bKeyUP);Sui($20);
LabelA(gKeyD_m3);Cpi($10);Jm(gKeyD_m4);Sta(bKeyRight);
LabelA(gKeyD_m4);
RET;

{процедура опроса основной клавиатуры на нажатие любой клавиши}
LabelA(pKeyO);
MviA($00);Sta(bKeyProtect);
Out_($D0);In_($D1);
Xri($FF);
Sta(bKeyProtect);
RET;

StartProgram;
Call(pKeyD);
Call(pKeyO);
FINALCompiler;
END.

// ИЗ МАДЛ04:

//BEGIN
//INITCompiler;
//VarDATAProgram;{Разметка данных программы}
//Begin
//BEGINPROCEDURE(pKeyD);
//R(bKeyDown,bKeyleft,bKeyUP,bKeyRight,0);
//
//Ar($F7);OUT_($D2);IN_($D2);NotA;Ai($F0);
//
//IfAless($80,gKeyD_m1);_rA(bKeyDown);Am($80);
//LABELg(gKeyD_m1);IfAless($40,gKeyD_m2);_rA(bKeyleft);Am($40);
//LABELg(gKeyD_m2);IfAless($20,gKeyD_m3);_rA(bKeyUP);Am($20);
//LABELg(gKeyD_m3);IfAless($10,gKeyD_m4);_rA(bKeyRight);
//
//LABELg(gKeyD_m4);ENDPROCEDURE;
//
//begin
//BEGINPROCEDURE(pKeyO);
//R(bKeyProtect,$00);
//OUT_($D0);IN_($D1);Ax($FF);
//_rA(bKeyProtect);
//ENDPROCEDURE;
//end;
//
//StartProgram;
//Proc(pKeyD);
//Proc(pKeyO);
//
//end;

[als]

Доп.
КУРСОР ВКЛ/ВЫКЛ.
ИЗ "RAM_ROM_(1).HTML" ПОМОЩЬ ПК-01 "Львов" Автор:САС (25.06.2020)

$BE3C/48700|CURSOR: db $00 | LaSa|$00 |0 | |видимость курсора
$BE3D/48701|CURSOR*: db $00 | La |$00 |0 | |уст. видимость курсора

2.2.4 Вывод символа на экран ( TTY ).
............
Системная переменная ( CURSOR ) ( $BE3C ) ( 48700 ) определяет видимость курсора
( 00H (00)(по умолчанию) - видим, FFH (255) - невидим ).

2.6.6 Курсор в начало экрана.
Точка входа $EBE4 ( 60388 ) ( HomeSCR ).
Выполняется установка текущей текстовой позиции вывода в
(0,0). Видимость курсора определяется системной переменной
( CURSOR ) ( $BE3C ) ( 48700 ).
Внимание !
Перед обращением к подпрограммам 2.6.4, 2.6.5 и 2.6.6 необ-
ходимо подключить экранное ОЗУ к шинам МП ( см. выше ), после
обращения,- отключить.

2.2.11 Позиционирование курсора ( LOCATE ).
......
( CURSOR* ) ( $BE3D ) ( 48701 ) : 00H (0) - ON, FFH (255) -OFF.

[Zorko]

Пока получилось вот такое. Продвигаемся помаленьку! Думаю, ты оценишь) Пока что шаг движения тайла по горизонтали кратен байту. Управляется стрелками.



Если есть желание заняться скроллингом, то нужны такие процедуры:

Code: Select all

PROCEDURE ScrollDown (lines: BYTE);
PROCEDURE ScrollUp (lines: BYTE);

Вниз и, соответственно, вверх весь экран (рабочую площадь экрана, т.е. 192 x ?) на заданное число пиксельных строк. Скроллинг нам требуется не циклический, т.е. то, что исчезает сверху - не появляется опять снизу. И наоборот.

[als]

Пока получилось вот такое. Продвигаемся помаленьку! Думаю, ты оценишь)

ну правильно что исходники выкладываешь, позже посмотрю.

Пока что шаг движения тайла по горизонтали кратен байту. Управляется стрелками.

Ну правильно, ДЛЯ НАЧАЛА хоть что-то! Далее видно будет!

Если есть желание заняться скроллингом, то нужны такие процедуры:

Code: Select all

PROCEDURE ScrollDown (lines: BYTE);
PROCEDURE ScrollUp (lines: BYTE);

Никогда не занимался, но попробую конечно! А что уж получится "подточим", "подпилим"

Вниз и, соответственно, вверх весь экран (рабочую площадь экрана, т.е. 192 x ?) на заданное число пиксельных строк. Скроллинг нам требуется не циклический, т.е. то, что исчезает сверху - не появляется опять снизу. И наоборот.

Скроллинг нам требуется не циклический, т.е. то, что исчезает сверху - не появляется опять снизу. И наоборот.

Не очень-то мне это понятно, ну попробую хоть как-то для начала, все будем по ходу отрабатывать! Мои исходник мадла, понято то можно ? Если нет, то я ЛВТ предоставляю ведь тоже, как говорится декомпилируй как хочешь!

[als]

Декомпилировал и расматривал

2021-06-03.7z

(4.08 KiB) Downloaded 662 times

Слушай, обязательно в обероне делай возможность АСМ-вставок! Точнее говоря, чтобы была возможность заменять код оберона на асм-вставку!
АСМ вставки нужны в любом виде в каком бы они не были!
А еще лучше в нескольких видах! И строковые и не строковые и ДБ и какие фантазия позволяет!
Потому что глядя на вот такое (см ниже), да еще и в опросе клавиатуры,
мы на ПК-01 далеко не уйдем! Потом будешь говорить, что ПК-01 очень слабый!
Да он слабый! поэтому надо писать на него программы с учётом этого!

Code: Select all

BEGIN
  SetTable;
  x := 1; y := 1;
  LOOP
    keys := Ctrl.Get();
    IF (Ctrl.Right IN keys) & (x < 51) THEN INC(x) END;
    IF (Ctrl.Left IN keys ) & (x >  0) THEN DEC(x) END;
    IF (Ctrl.Up IN keys   ) & (y >  0) THEN DEC(y) END;
    IF (Ctrl.Down IN keys ) & (y < 31) THEN INC(y) END;
    (* Lvov.FIL_BOX(x, y, x+5, y+5, 3); *)
    Gr.DrawTile(x, y, 8000H-1);
    RK86.WAIT(5000);
  END;
  Scr.Close
END Bolder16K.

Code: Select all

{BEGIN}
LabelA(StartProgram0);
Call(L8009); //SetTable;
Call(L8057);

MviA($01);Sta(X);//   x := 1;
LxiHL($0001);MovAL;Sta(Y);//y := 1;

LabelA(LOOP1);//   LOOP
Call(Ctrl_Get);MovAL;Sta(Keys);//	    keys := Ctrl.Get();

MovLA;MviH($00);MovAL; rrc;rrc;rrc;rrc;Ani($0F);MovLA;Ani($01);Jz(L8118);

Lda(X);Sui($33);Jnc(L8118);
Lhld(X);MviH($00);InxHL;MviH($00);MovAL;Sta(X);

LabelA(L8118);
Lhld(Keys);MviH($00);MovAL;rlc;rlc;Ani($03);MovLA;Ani($01);Jz(L813F);
Lhld(X);MviH($00);MviA($00);SubL;Jnc(L813F);
Lhld(X);MviH($00);DcxHL;MviH($00);MovAL;Sta(X);

LabelA(L813F);
Lhld(Keys);MviH($00);MovAL;rlc;rlc;rlc;Ani($07);MovLA;Ani($01);Jz(L8167);

Lhld(Y);MviH($00);MviA($00);SubL;Jnc(L8167);
Lhld(Y);MviH($00);DcxHL;MviH($00);MovAL;Sta(Y);

LabelA(L8167);
Lhld(Keys);MviH($00);MovAL;rlc;Ani($01);MovLA;Ani($01);Jz(L818A);
Lda(Y);Sui($1F);Jnc(L818A);Lhld(Y);MviH($00);InxHL;

MviH($00);MovAL;Sta(Y);

LabelA(L818A); // Gr.DrawTile(x, y, 8000H-1);
Lda(X);Sta(L8027);   Lda(Y);Sta(L8028);   LxiHL($7FFF);  Call(Gr_DrawTile);

LxiHL($1388);Call(L81A9); //    RK86.WAIT(5000);
JMP(LOOP1);