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

По заголовку темы думаю всё понятно :)
Обычный болдер какой везде как-бы есть, а у нас его не было (у нас были другие, нестандартные).
Ну а теперь есть со стандартными уровнями.

Картинки

https://i.imgur.com/0Sp6dsa.png
---
https://i.imgur.com/CZM8aoB.png

[свернуть]

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

Исходник:
https://github.com/blairecas/bolder

.sav-ка там-же в /release
https://raw.githubusercontent.com/bl...ase/bolde2.sav

.dsk там-же в корне
https://raw.githubusercontent.com/bl...ain/bolder.dsk

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

Еще добавлю почему не сделан нормальный скроллинг ибо на деле скролл экрана там имеется если присмотреться. Вообще ВЕСЬ лабиринт болдера отображен в видеопамяти и по нему остается только "ездить окном".
Но внезапно вылезла увы проблема:
- Рокфорд бежит вправо и сдвигается на 8 пикселей (пока-что это не отрисовано, но запомнено уже)
- Экран сдвигается за Рокфордом и он "улетает" на 8 пикселей влево мгновенно
- Рокфорд отрисовывается на новом положении (то-есть опять 8 вправо или как-бы "по-центру")
Итого эта ерунда приводит к мерцанию и раздвоению Рокфорда - поэтому убрал постоянное смещение экрана за ним. Оно только хуже делает.

Супер! Распаковал наконец УКНЦ чтобы заценить)
У меня встроенного динамика нет, звук выводится через звуковуху на колонки.
Звуковые эффекты зачёт, звучит отлично!

Цитата:

---

Сообщение от randomizer

Распаковал наконец УКНЦ чтобы заценить)

---

А на реале текстуры и палитра также вырвиглазно выглядят как на скрине в первопосте?

Цитата:

---

Сообщение от CodeMaster

А на реале текстуры и палитра также вырвиглазно выглядят

---

Ага :) Ну блин господа, я не особо художник графония, как стырил так и стырил. Тырил с С64, но там как-то вообщем фигово стырилось согласен

Фото реальной

https://i.imgur.com/7rbpbPh.jpeg

[свернуть]

По-идее там цвета в разных уровнях меняются, я сделал некое подобие трех расцветок мол, но вообщем.. ладно уж как вышло так и вышло.

Кстати если кому интересно - полный дизасм болдера на С64 с комментариями и прочим.
http://www.retrointernals.org/boulde...sassembly.html

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

Кстати это можно перенести на БКшку, вся ерундень занимает 15кб (а там еще меньше будет) и учитывая что я жадный и расходовал их как кот васька которому дали мясо и он сразу всё захапал. Но тут даже как-то не особо много и заняло при всей моей жадности. Типа на БК-0010 попрет. Разве-что скроллинг такой не будет разумеется ибо его там нету.

Цитата:

---

Сообщение от BlaireCas

как стырил так и стырил.

---

Да вопрос не в этом, пиратство наше фсё ;-)

Цитата:

---

Сообщение от BlaireCas

Тырил с С64, но там как-то вообщем фигово стырилось

---

У C64 весьма спцфичская палитра. Есть БКшный Bolder Dash 3 для 11М с приятным графонием и УКНЦешная палитра должна ему подойти.

Цитата:

---

Сообщение от BlaireCas

Кстати это можно перенести на БКшку

---

Нужно. Я уже задолбался в твой Column играть, а бросить не могу.

Цитата:

---

Сообщение от BlaireCas

Разве-что скроллинг такой не будет разумеется ибо его там нету.

---

Жили без него в других играх, хотя и не таких динамичных.

Цитата:

---

Сообщение от CodeMaster

Нужно.

---

Да надо будет подумать как перенести. Ибо тут у меня разрешение 160х288 (но играбельное поле по вертикали только 256 как-бы). В БК будет чуть побольше по горизонтали плюс тайлы побольше станут. Но из-за особенностей БК (видеопамять сразу в обычном ОЗУ) возможно и ничего страшного и скорость не уменьшится особо.

(один фиг тут 9 фпс залочено мной точнее 50/6.. ну где-то 9. БК должно осилить)

Цитата:

---

Сообщение от CodeMaster

А на реале текстуры и палитра также вырвиглазно выглядят как на скрине в первопосте?

---

Я бы не сказал чтобы прям вырвиглазно.
В начале уровня, когда всё поле заполнено тайлами, возникает ощущение, что не хватает контрастности.
Когда подрасчитил от тайлов, становится норм. Да и когда глаз привыкнет, тоже норм.
И то, как то по началу не обратил внимания, уже после заданного вопроса запустил, и обратил на это внимание.

Цитата:

---

Сообщение от BlaireCas

По-идее там цвета в разных уровнях меняются, я сделал некое подобие трех расцветок мол, но вообщем.. ладно уж как вышло так и вышло.

---

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

Keith, автор оригинальной ChibiAkuma's говорил, что составлял палитру из принципа увеличения яркости, от чёрного к белому.
Т.е. цвет 0 - чёрный, цвет 1 - с пониженной яркостью, цвет 2 - с установленным битом яркости, и цвет 3 - всегда белый.

Цитата:

---

Сообщение от randomizer

Думаю стоит попробовать сделать один цвет с пониженной яркостью

---

К сожалению мои обе УКНЦ не особо любят пониженную яркость. На квантовой ее банально нет. На сэмзовой она типа есть, но надо выкрутить gain на минимум у OSSC чтобы она была видна (а тогда по телику артефакты от sync on green или от чего такого начнут вылазить). Вообщем тут я сторонник "стандартных" 8-ми цветов.

Ну и тут собственно есть-же тайлы в исходнике. Если их кто-то мне перерисует на лучший вариант - я очень обрадуюсь и разумеется будет улучшенная версия так-сказать. (только надо учесть что в Tiles.png используются только четные вертикальные строки графики, они для красоты сделаны 16х16, но сама игра когда вот в лабиринте использует разрешение 160 горизонтальное, то-есть перерисовывать надо будет ну скажем точно также с удвоением пикселей. Это так задумано чтобы в gimp-e мне крышу не снесло от сплющенных тайлов)

Цитата:

---

Сообщение от BlaireCas

Ну и тут собственно есть-же тайлы в исходнике. Если их кто-то мне перерисует на лучший вариант - я очень обрадуюсь и разумеется будет улучшенная версия так-сказать. (только надо учесть что в Tiles.png используются только четные вертикальные строки графики, они для красоты сделаны 16х16, но сама игра когда вот в лабиринте использует разрешение 160 горизонтальное, то-есть перерисовывать надо будет ну скажем точно также с удвоением пикселей. Это так задумано чтобы в gimp-e мне крышу не снесло от сплющенных тайлов)

---

Тут не понял. А нельзя тайлы 16x16 использовать? А то какая-то Атарищина получается.

Цитата:

---

Сообщение от CodeMaster

Тут не понял. А нельзя тайлы 16x16 использовать? А то какая-то Атарищина получается.

---

Можно конечно, просто скорость упадет в тех местах где почти перерисовка всего экрана идет. Собственно оно и сейчас не прям быстро рисует. Если вот на уровнях с амебой ее не трогать, а подождать пока размножится на весь экран - это уже заметно становится. Не прямо слайд-шоу, но ощутимо заметно.
А так да - сделано "под атари" (или С64) где также удвоенные пиксели в игре.

Что тут можно было-бы сделать и как ускорить. Ну допустим попробовать отобразить экран на обычное ОЗУ. Да вот только когда я начинал писать игруху - я специально сделал так что весь лабиринт (а это 40х22 элемента) идет целиком в видеопамять чтобы проще по нему скроллить окошком было. (Хех, а в итоге скролл все-равно ненормальный пришлось сделать).
Если сделать в разрешении 320х288 то весь он в обычную память уже не полезет (полезет, только почти всю ее и сожрет).

Если портировать на БК - тогда да, от удвоенных пикселей придется отказаться и делать 16х16 как видимо на спектруме сделано. Но там и вообще скролла все-равно не будет и незачем будет пихать всё в видеопамять.

Цитата:

---

Сообщение от BlaireCas

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

---

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

Цитата:

---

Сообщение от BlaireCas

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

---

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

Цитата:

---

Сообщение от CodeMaster

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

---

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

Цитата:

---

Сообщение от BlaireCas

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

---

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

Цитата:

---

Сообщение от BlaireCas

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

---

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

Код:

---

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

---

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

Цитата:

---

Сообщение от gid

bit @#177716,#100

---

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

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

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

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

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

Код:

---

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

---

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

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

Цитата:

---

Сообщение от BlaireCas

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

---

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

Цитата:

---

Сообщение от BlaireCas

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

---

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

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

Цитата:

---

Сообщение от BlaireCas

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

---

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

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

Цитата:

---

Сообщение от BlaireCas

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

---

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

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

Цитата:

---

Сообщение от randomizer

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

---

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

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

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

Цитата:

---

Сообщение от BlaireCas

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

---

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

Цитата:

---

Сообщение от Sandro

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

---

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

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

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

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

Добавил анимацию едущих точек в меню (переключением видеопамяти по 4-м "размноженным" в ней лого получилось сделать что они едут плавно)
И еще музыку. Тут правда вышла какая-то некая кривота ибо тырил с ZX музыку (не в виде исходника), а вообщем mp3-ку пытался сконвертировать в mid и смотреть ноты, но что-то оно там не везде окей сконвертировалось, впрочем узнаваемо играет. На UKNCBTL чуть нотки кривят, на реальной вроде тоны правильные.
Дальше улучшать видимо хватит.

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

а нельзя ли на укнц Boulder dash Construction Kit чтоб можно было свои уровни строить ?

А под виндовс не пойдет?.. Хотя тоже вряд ли.. пишем то на коленке,. и для души :)
Скрипты не подойдут?

Цитата:

---

Сообщение от ZEman

а нельзя ли на укнц Boulder dash Construction Kit чтоб можно было свои уровни строить ?

---

Думаю нет. Я там сильно "подзажрал" память в УКНЦ перебросив видеопамять на обычную (потому-что надо было портировать на БК-0010, а там видеопамять идет с адреса 40000, ну и тут сделал нечто "похожее"). Вкратце - нет, не вариант.