Тема для всяких глупых вопросов

[metamorpho]

а что есть исходник на asm ?

Перечитал уже много информации по программированию на Спектрум.
Достаточно много всяких моментов нужно учесть чтобы грамотно написать игру для Спектрума.
И пока не встретил ни одного описания где вся эта конкретика (в отношении написания игры) с примерами кода была бы собрана в одном месте.
Есть игры, которые демонстрируют плавность скроллинга вертикального и горизонтального, но как это сделано - тайна.
Или не тайна ? Может где-то есть такое описание и код ?
Неужели до сих пор на Спектруме нет ниодного примера кода базовой "основы-заготовки" платформера типа "Soldier of Fortune" ?

[goodboy]

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

[Black Cat / Era CG]

Soldier of fortune

Это слишком круто. Так сразу не догнать.

[jerri]

а что есть исходник на asm ?

Перечитал уже много информации по программированию на Спектрум.
Достаточно много всяких моментов нужно учесть чтобы грамотно написать игру для Спектрума.
И пока не встретил ни одного описания где вся эта конкретика (в отношении написания игры) с примерами кода была бы собрана в одном месте.
Есть игры, которые демонстрируют плавность скроллинга вертикального и горизонтального, но как это сделано - тайна.
Или не тайна ? Может где-то есть такое описание и код ?
Неужели до сих пор на Спектруме нет ниодного примера кода базовой "основы-заготовки" платформера типа "Soldier of Fortune" ?

SoF как и Zynaps это очень технологичный движок.
там просчитано всё.
Количество блоков местности на экране, максимальное количество обьектов и прочее.

ты же хочешь чтото высокоподвижное
а экран у спектрума великоват для быстрого обновления.
И тут в ход идут хитрости

Firefly, GhoulsNGhosts - обеднение фона, сокращение объектов.

RoboCop, Batman - низкий ФПС, чернобелая графика.

Rtype, Zynaps - отсутствие заднего плана, все обьекты ЗА обьектами окружения.

[Black Cat / Era CG]

Redshift (2019) еще крутой шмап с хитростями. Но там уже 128 и 2 экрана.

[dimidus]

У меня есть вопрос, касаемо организации памяти для игры. Вывожу в два экрана поочерёдно, поскольку fps предполагается плавающим (в зависимости от нагруженности отображаемой части карты). Первый экран, это банка памяти №5, жестко закреплённая с адреса #4000. Второй экран, это банка №7, она подключается с адреса #c000. Значит мне попеременно нужно выводить или в #4000, или в #c000. Получается что вся выводимая за кадр графика должна умещаться где-то между #6000 и #c000, ну и остаётся ещё место после #db00, но там у меня программа вывода этой самой графики. В итоге, преимущество в памяти 128-го спектрума нивелируется, поскольку я не могу её использовать в полной мере при выводе на два экрана, конфигурация "цементируется" банками #5, 2 и 7. Я всё правильно описал, или есть способы вывода графики из других банок памяти на два экрана?

[Advertiser]

[NEO SPECTRUMAN]

Первый экран, это банка памяти №5, жестко закреплённая с адреса #4000. Второй экран, это банка №7, она подключается с адреса #c000. Значит мне попеременно нужно выводить или в #4000, или в #c000

проще подключать и 5 и 7 банку в $С000

В итоге, преимущество в памяти 128-го спектрума нивелируется

можно копировать графику в $8000
на время использования из других страниц
тк она вся не нужно одновременно и сразу
а потом подключать 5\7 страницу в $C000

можно строить все как и раньше в линейном буфере в районе $8000
имея несколько страниц с графикой
а потом подключать видео память по $C000
и туда перекидывать содержимое буфера

можно отключить видео память из адресного пространства процессора вообще
и использовать все 48К под какой то код
если не использовать 5-ю банку а отображать 7-ю

или же хранить процедуры работы с графикой и сами спрайта в 5 и 7-й странице
а под игровую логику отводить 40К адресного пространства

так что 128 это крута %)

[dimidus]

проще подключать и 5 и 7 банку в $С000

Из плюсов, не нужно обновлять адреса вывода. Какие ещё есть плюсы?
Минус - теряется область памяти с $db00, где у меня программа вывода графики.

можно копировать графику в $8000
на время использования из других страниц
тк она вся не нужно одновременно и сразу
а потом подключать 5\7 страницу в $C000

У меня платформер со скроллом экрана. Это значит что нужна вся графика которая есть на уровне.
Эта графика как раз занимает у меня 16КБ начиная с $8000. Особенности решения позволяют хранить там 64 тайла. Этого маловато. Хочется буйства текстур, разнообразия и красоты
Копирование графики из других страниц во время движения по уровню будет просаживать fps, кроме того, это надо делать незаметно, подменяя тайлы которых уже нет на экране. В общем, хотелось бы этого избежать.

можно строить все как и раньше в линейном буфере в районе $8000
имея несколько страниц с графикой
а потом подключать видео память по $C000
и туда перекидывать содержимое буфера

Для скролл-платформера насколько приемлемо использование буфера?

можно отключить видео память из адресного пространства процессора вообще
и использовать все 48К под какой то код
если не использовать 5-ю банку а отображать 7-ю

Это полезная фича, но вопрос про вывод на экран.

или же хранить процедуры работы с графикой и сами спрайта в 5 и 7-й странице
а под игровую логику отводить 40К адресного пространства

Боюсь, не уместится всё туда, кроме того, я не вижу в этом варианте преимущества в использовании доп.памяти.

так что 128 это крута %)

Безусловно, это лучше чем 48К, однако, если бы была дополнительная возможность подключать, к примеру, второй экран в область $4000, то применение техники двух экранов раскрылась бы на полную, поскольку можно было бы использовать доп.банки памяти для вывода во второй экран. Вообще, игры на спектрум стали бы на голову лучше. Как пример, хранение развёрнутых (уже отскроленных) тайлов в нескольких банках и их подключение, при этом, вывод на 1/2-й экран. А так приходится выбирать между отсутствием съехавшего кадра (вывод поочерёдно в два экрана) или богатством графики (вся графика текущего уровня должна помещаться в текущее адресное пространство), или приемлемым fps-ом (переброска из других страниц через буфер снижает скорость игры). Ещё приходится жертвовать размером игрового поля. Это происходит практически в большинстве игр.

В любом случае, спасибо за ответ и за "палитру возможностей"

[LW]

Минус - теряется область памяти с $db00, где у меня программа вывода графики.

Если не планируется использовать системные переменные, продублировать в 5-й странице процедуры вывода графики.

[dimidus]

Если не планируется использовать системные переменные, продублировать в 5-й странице процедуры вывода графики.

Это можно. Но зачем? В чём преимущество данного приёма по сравнению с переменным выводом в $4000/c000?