Порт игры Desolate на БК

[Sandro]

Воу... Это было... быстро!

Так как машины состоят в близком родстве, то удалось обойтись заменой процедуры копирования теневого экрана в реальный и некоторыми исправлениями в опросе клавиатуры. На самом дел, основное время ушло на разбор исходного кода. Его не так уж много, но всё же 4К строк -- это 4К строк.

1. Нужен "дневной" режим, чтобы меню и игровой режим не были инверсными.

Уже сделал и перезалил поверх. Ночь была просто из-за того, что поторопился.

Как вариант, можно хранить режим в переменной, и сделать два варианта копирования теневого экрана на реальный - при включении "дневного" режима делать BIS для половины битиков - тем самым выдавая другой цвет. А остальное сделать палитрой.

Я в конечном счёте сделал через XOR и палитру.

2. Лучше сместить всё ниже, чтобы сверху был отступ равный отступу снизу.

Не уверен. В общем-то это вкусовщина... ну надо подумать.

3. Все задержки нужно уменьшать раза в два - я так делал при портировании на Вектор-06Ц.

На самом деле я их вовсе обнулил. Оно сейчас упирается в отрисовку тайловой карты в теневой буфер (каждый кадр!), и несколько в меньшей степени -- в разворачивание буфера в 2 бита/пиксель.

Надо как-то это дело переписать для скорости.

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

Да даже без дополнительных страниц, так код можно где-то на килобайт сократить просто переписав все простыни cmp/beq на таблицы и сделав хотя бы минимальный байткод для логики. Только на это время нужно ...

[Advertiser]

[nzeemin]

Да даже без дополнительных страниц, так код можно где-то на килобайт сократить просто переписав все простыни cmp/beq на таблицы и сделав хотя бы минимальный байткод для логики. Только на это время нужно ...

Я там нашёл резерв примерно в 2Кбайта на том чтобы улучшить RLE алгоритм при распаковке комнат - сейчас он слишком расточительный.
Ну и по производительности - описание комнаты каждый раз разворачивается для очередной проверки "а что у нас тут", хотя это можно делать один раз при входе в комнату.

[Sandro]

Я там нашёл резерв примерно в 2Кбайта на том чтобы улучшить RLE алгоритм при распаковке комнат - сейчас он слишком расточительный.

О, да. С учётом того что номера тайлов семибитные -- да и в описаниях комнат тоже всё в 7 битах, то напрашивается канонический ход -- кодировать команду "повторить предыдущий байт" как 0x80 +n, что сразу даёт изрядный выигрыш. Плюс применить шаблонирование -- незачем копировать стенки 72 раза, они всё равно почти одинаковые. Кодировать только дельту от шаблона.
А некоторые комнаты вообще не сжаты, например 64 и 68. Почему -- неясно.

И с монстрами да предметами печаль.

Собственно, когда я об этом думаю, то сразу вспоминается спектрумовская The Bard's Tale, с её ошеломляющим монстрятником в 127 видов! С атрибутами, заклинаниями, и даже картинками! Страшненькими, но все же.

Столько, может, и не надо, но с 32 байтами (допустим) на объект мы можем себе позволить эдак десятка три объектов и десяток монстров. Это вполне нормально, В Betrayal at Krondor меньше и того, и другого, а игра отличная получилась.
Главное -- не запихивать каждый чих в код, он от этого разрастается очень резво. Таблички, какой-нибудь байтовый интерпретатор -- всё это очень сильно помогает.

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

Да, это я тоже заметил. Хорошо хоть, оно по размеру -- всего ничего.

[NEO SPECTRUMAN]

но всё же 4К строк -- это 4К строк.

тю