Sea Dragon

[jerri]

Lethargeek

Ладно понятно связной концепции нет
то что ты предлагаешь не очень весело и не очень быстро

движок мой тоже еще никто не понял
как разберетесь - призовете

[Advertiser]

[ace210]

Обновил первый пост ветки http://zx.pk.ru/showthread.php?t=11233

Уф. Закончил делать познакоместный вывод. Чем дальше - тем сложнее.
Это уже 3-я по счету реализация.

Немного комментариев к ревизии 18:
1) Теперь ландшафт рисуется не тайлами, а спрайтами высотой 8 пикселей и различной шириной (1,2,3,4 знакоместа). За счет этого удалось избавиться от маскирования левого тайла.
2) Для быстроты вывода прямо в данных ландшафта зарезервированы (и используются) дополнительные данные такие как: адрес процедуры вывода спрайта, адрес спрайта, координата X спрайта, адрес экрана.

Т.е. это и есть буфер, что предложил Jerri. Но он не строится заново на каждой обработке, а только немного корректируется.

В снапшоте голубой бордюр отмечает общее время цикла (обработка+отрисовка). Причем обработка делается только каждые 4 кадра, поэтому бордюр в это время мерцает.

qsave1.rar
https://seadragon.svn.sourceforge.ne...oot/seadragon/

В пике уже больше 40 Ктактов получается. Что-то я забеспокоился. Удастся ли уложится в 1 фрейм?

[ace210]

Немного продлил ландшафт
qsave1.rar

[ZEman]

jerri,
ace210,
по вашим коментариям я понял что вы вроде играли в эту игрушку на trs80,
не можете подсказать где взять биосы для этого компьютера ?
у меня пара эмуляторов trs80 есть, но запустить не могу.
не поможете ?

[newart]

1) Теперь ландшафт рисуется не тайлами, а спрайтами высотой 8 пикселей и различной шириной

Может все таки 4 пикселя?
(или это спрайты так нарисованы, c парными строками?)

[ace210]

Может все таки 4 пикселя?

Правильно. Хранится 4, выводится - 8 дублированием.

[Lethargeek]

Уф. Закончил делать познакоместный вывод. Чем дальше - тем сложнее.

А нужны ли такие сложности
Ты хоть считаешь, будет ли реальное ускорение?
Как бы экономия на спичках не получилась

1) Теперь ландшафт рисуется не тайлами, а спрайтами высотой 8 пикселей и различной шириной (1,2,3,4 знакоместа). За счет этого удалось избавиться от маскирования левого тайла.

А например мину в шахте (или просто слева по склону) ты как рисовать собрался?

В пике уже больше 40 Ктактов получается. Что-то я забеспокоился. Удастся ли уложится в 1 фрейм?

Так вроде в оригинале скорость в два раза меньше
В два неполных (за лучом/перед лучом) фрейма точно уложишься

[Barmaley_m]

В снапшоте голубой бордюр отмечает общее время цикла (обработка+отрисовка). Причем обработка делается только каждые 4 кадра, поэтому бордюр в это время мерцает.

Очень хорошо получилось! Ландшафт скроллится каждый фрейм, и в основном это происходит за весьма малое время. Респект!

Что касается мерцания каждые 4 такта - то оно весьма существенное. По-видимому, обработка занимает немало времени. В связи с этим идея: разделить обработку на 4 этапа и выполнять каждый из них каждый фрейм, так чтобы более равномерно распределить нагрузку на проц. Но это можно сделать и после.

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

В 1 фрейм нужно обязательно уложиться. Судя по тому, что у тебя уже получилось, это должно быть возможно. Насколько при этом игра будет более динамичной!

Что касается плавности восприятия движения человеком, то здесь можно сравнить 3 варианта, а именно:

1. изображение смещается на 1 пиксел каждый кадр
2. изображение смещается на 2 пиксела каждый кадр
3. изображение смещается на 1 пиксел каждые 2 кадра.

Так вот, в первом и втором случае (а также в случае смещения на >2 пикселов каждый кадр) движение воспринимается идеально плавным, а вот в случае 3 оно получается дерганным и размытым. В чем тут дело?

А дело в том, что когда человек присматривается к движущемуся по экрану объекту, то он зрачком следит за этим объектом, то есть зрачок перемещается плавно так, чтобы движущийся объект всегда оказывался в одном и том же месте сетчатки. И если объект смещается на равное расстояние каждый кадр - то его изображение будет вспыхивать (экран мерцает) всегда на одном и том же месте сетчатки. То есть объект будет виден четко.

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

Я видел недавно в общественном месте такой прикол. Было несколько вертикальных столбиков светодиодов, которые хитрым образом мерцали, так вот, если относительно медленно (но не слишком медленно) перемещать взгляд мимо этих столбиков, то удавалось увидеть различные картинки (движущиеся и статические). Механизм здесь тот же. Зрачок движется, а источник света стоит, в результате получается, что изображение источника света движется относительно сетчатки, что и формирует на некой ее протяженной области изображение картинки.

---------- Post added at 01:25 ---------- Previous post was at 01:08 ----------

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

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

Реализовать это просто: прорисовка ландшафта может выполняться по прерываниям (в процедуре обработки прерывания), а обработка буферов и т.д. - на заднем плане, с разрешенными прерываниями. Процедура обработки прерываний должна будет, разумеется, сохранять значения регистров, чтобы можно было вернуться к исполнению прерванной программы. В этом заключается плата за вытесняющую многозадачность. Без нее регистры сохранять не надо.

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

[jerri]

Barmaley_m, а вот например в играх Firefly и Zynaps разве движение дерганое?

[goodboy]

zynaps надо смотреть на оригинальном zx -скролл заточен под него, на пентагоне рывки заметны.