Игра Bolder Dash для УКНЦ

[CodeMaster]

Можно конечно, просто скорость упадет в тех местах где почти перерисовка всего экрана идет.

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

Да надо будет подумать как перенести.

Если соберёшься, то давай тогда под 11М (ну, как под 11М, там от неё только нормальная палитра нужна будет). Можно наверное сделать и автодетект 10/11М для включения палитры.

[BlaireCas]

Если соберёшься, то давай тогда под 11М

Да думаю соберусь однажды (не прямо сейчас). Там в БКшке я не особенно соображаю конечно (даже не нашел как там определить момент "отжатия" клавиши, она вроде прерывание не генерирует при этом).
Разумеется надо будет весь вывод на экран переделать, а так в основной логике обработки лабиринта ничего менять-то и не надо, я кажется не прям использовал там всякие ash mul и div (ну их на что-то поменять можно будет).

[CodeMaster]

даже не нашел как там определить момент "отжатия" клавиши

Я 100% не знаю, но ИМХО его там нет. Это всегда было проблемой в играх на БК.

[gid]

как там определить момент "отжатия" клавиши

Никаких прерываний. Нужно непрерывно мониторить бит 6 регистра 177716.

bit @#177716,#100 ; при такой записи операндов команда работает на пару микросекунд быстрее
beq одна_или_несколько_клавиш_нажато
bne ни_одна_клавиша_не_нажата

Причём определить отжатие конкретной клавиши невозможно. Определяется только факт - нажато/не нажато.
Для тех, кто привык к обработке реакций по событиям очень не удобно. Тут надо продумать игровой цикл, где будет опрос нажата/отжата клавиша.

[BlaireCas]

bit @#177716,#100

Какой интересный момент кстати да Вот уж никогда бы так не написал (написал-бы наоборот).

А так с "отжатиями" этими вижу вот ну сразу проблему на клавиатуре БК. Например тут на УКНЦ нажатие или отжатие клавиши генерирует прерывание и можно ну сделать полное состояние клавиатуры по нему. Хотя в УКНЦ есть тоже проблема например отжатие кажется вверх и вниз генерирует одинаковый код, поэтому невозможно определить какую из клавиш точно отжали Но как-бы на геймплей не особо влияет.
А в БК влиять будет вот что - скажем при нажатии шифта рокфорд не бежит, а как-бы либо двигает камень либо "скушивает" рядом алмаз или грязь (ну так там названо да, dirt). То-есть надо удерживая шифт нажимать вправо-влево-вверх-вниз. Мы например держим шифт нажатым. Нажимаем вправо - окей, он скушал алмаз справа. Далее не отпуская шифт нажимаем влево (но блин кнопка вправо-то уже отжата была и значит шифт тоже чтоли отжат... вообщем ужасы)

К счастью на БК есть джойстик и видимо лучше его использовать.

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

Еще возможно не сразу будет понятно почему я парюсь с этой клавиатурой даже на УКНЦ где она более-менее адекватно сделана.
На деле играбельность игры это вот на очень много процентов как-бы "отзывчивость" управления. А тут в игре всего 9 фпс. Это вам не 50 и не даже 25.
Итого что происходит:

[... идет цикл ожидания ..][идет обработка лабиринта][тут прорисовка обработанного]
   ^ здесь нажали кнопку         ^ здесь отжали (а обработка кнопки чуть позже)

Можно по разному это перевернуть, но смысл не изменится.

Итого какие-то кнопки банально при таком фпс "проглотятся". Какие-то наоборот приведут к +2 перемещению если вовремя не отпустить.
Пробовал разные подходы и засовывать нажатые кнопки в буфер и прерывать цикл ожидания vsync при нажатии кнопки - лучше не становится (увы только хуже становилось, начиналась слишком быстрая беготня через 2 клетки).

[Titus]

Часть вещей ну и графоний брал оттудова, часть ну понятно что мое (цвета прям оттуда взять невозможно, либо нужна "полноцветная" УКНЦ)

Вот тебе еще один повод использовать 128-цветную палитру УКНЦ.

[Advertiser]

[randomizer]

Хотя в УКНЦ есть тоже проблема например отжатие кажется вверх и вниз генерирует одинаковый код, поэтому невозможно определить какую из клавиш точно отжали

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

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

На квантовой ее банально нет.

Запаять недостающие компоненты, и всё)

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

На сэмзовой она типа есть, но надо выкрутить gain на минимум у OSSC чтобы она была видна (а тогда по телику артефакты от sync on green или от чего такого начнут вылазить).

Ну вот, дорогая железка, и такие проблемы(
В ChibiAkumа's, палитры составлены с использованием всех 53 цветов. Там где это получилось конечно.

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

Ну вот, дорогая железка, и такие проблемы(

PVM дешевле выйдет.

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

Кстати насчёт яркостей.
На многих платах отсутсвуют компоненты для их отображения.
Микросхема ЛН2, и 6 резисторов.
У меня сейчас стоит микруха 74ACT05, помню что ставил отечественную 1533ЛН2, яркости изменились не в лучшую сторону.
Не знаю почему так, в итоге оставил буржуйскую ACT05.

[Sandro]

Итого какие-то кнопки банально при таком фпс "проглотятся". Какие-то наоборот приведут к +2 перемещению если вовремя не отпустить.
Пробовал разные подходы и засовывать нажатые кнопки в буфер и прерывать цикл ожидания vsync при нажатии кнопки - лучше не становится (увы только хуже становилось, начиналась слишком быстрая беготня через 2 клетки).

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

[BlaireCas]

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

Такое как-бы пробовал (буферизовать ввод). Казалось-бы верное решение и какие тут могут быть подводные? В УКНЦ кнопками заведует периферийный процессор по прерываниям и вроде как да ему пофиг. Нажатия и отжатия в буфер ЦП записываются и вроде как окей. ЦП их при обработке лабиринта и перемещениях Рокфорда должен вытащить и сначала пообрабатывать разумеется нажатия, а потом при нахождение отжатий кнопок при завершении цикла прорисовки - поснимать их с буфера. Даже буфер необязателен, а только факты нажатия вправо-влево-вверх-вниз-шифт. Однако уже как и сказал - выходило так что рокфорд начинал бежать слишком шустро. Почему так происходило - возможен мой косяк (я тот еще программист при обработке буфера.

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

Я еще попробую поэкспериментировать без буферизации. То-есть нажатия вправо-влево-вверх-вниз сразу установят флажок, а отжатия туда перепишутся только после обработки лабиринта. Но как-то все-равно не уверен что станет лучше. Сейчас на реальной машинке ну более-менее с даже вот недоделанными нажатиями.
Однако все-равно проблема останется. По-идее когда быстро жмешь вправо-вправо-вправо (с отпусканиями). Очень быстро жмешь - персонаж должен наплевать на фпс и переместиться ровно на 3 клетки вправо. Но..

[tnt23]

А буферизация нажатия с каким-нибудь временем (например, сколько тиков было в момент события) не поможет потом при разборе очереди?