Попробовал, работает нормально, подробности письмом.
Вид для печати
Разбился перед вертолетами, которые летают поперёк дороги. Пока стоял перед вылетом, вертолёты перед носом летают а несущим винтом не крутят. Винт у вертолётов начинает крутиться только после начала движения самолёта.
Тоже видел такое.
Да, такая фича ;)
Ребята, мне для магнитофона нужна. Как на ленту залить игру?
На первой странице в самом первом сообщении ссылка, вот эта:
https://github.com/svofski/incursion...eleases/latest
Там есть для скачивания wav-файл.
Кроме того, в Картотеке напротив имени .rom-а есть треугольничек, который запускает проигрыватель:
http://sensi.org/scalar/ware/897/
Спасибо. Нашёл. Отличная игра!
Кланяюсь.
У меня есть Атари. Если получиться запустить на ней эту игру, то сравню.
А где в исходниках спрайты?
dbk, они заданы в скрипте, который генерит их сдвиги итд. Вот скрипт:
https://github.com/svofski/incursion...makesprites.py
А вот то, что из него выходит:
https://github.com/svofski/incursion...aster/ship.inc
svofski, почему решил использовать двухстрочный вывод вместо столбцового (столбцами было бы быстрее и короче)?
ivagor, спрайты -- это самое первое, что я вообще сделал для этой игры и это было ~8 лет назад. Не очень хорошо помню. Может быть у меня была какая-то мысль, может быть она была о чем-то не том и дала помеху. Это отмазка.
А теперь про твой вопрос -- ты собственно о чем? ;) Вот смотрю сейчас на ship_ltr, и вижу четкий паттерн, 4 пуша, lxi h, 256+8, dad sp, sphl, 4 пуша, lxi h, 256+8, dad sp, sphl.. В некоторых местах скипаются начальные пуши, если есть такая возможность. Это по-моему вывод по столбцам. А что такое двухстрочный вывод и где он?
Про двухстрочность протормозил. Посмотрел на layer 0 и не сообразил сразу, что там в связи с оптимизацией под конкретную картинку выводятся только две строки.
Спрайты я делал в первую очередь и по-моему они в общем неплохо оптимизированы. Что же касается более высокоуровневых вещей, там оптимизация очень прагматичная. Что мешало и тормозило, я переделывал. Все остальное, если гуденаф, то остается как есть. Иначе я бы никогда его не доделал.
Еще вопрос про спрайты и оптимизацию. Нулевые строки ты не выводишь, а нулевые двухбайтные push b делаешь. Зачем они нужны?
ivagor, затирать предыдущий кадр? Как именно выбирается стратегия в каких случаях я сейчас точно не скажу, это все подгонялось под конкретные кораблики-вертолетики.
Зависит еще от того, что именно затирается. Если движемся слева направо и текущая фаза сдвига по границе столбца, то надо затереть столбец слева и там все нули. Если справа налево, то левые нули не нужны, зато нужны справа.
Понятно, я про движение по горизонтали не подумал. Но тогда часть push b все же можно сократить (кроме затирающих) - пачки или даже одиночные push b, которые первые или последние в столбце. И соответственно откорректировать приращение sp, если столбец не последний. В кораблике плывущем направо есть такие пустые места справа.
- - - Добавлено - - -
Ну и видны моменты, когда меняется один байт, не два. Для них lxi h можно заменить на mvi h или mvi l. Стоят ли эти крошки усложнения генератора - не знаю. В болдере++ совсем мало тайлов и я вручную оптимизировал. Тупо, но просто.
Оценить стоят крошки или нет можно в случае, когда мы решаем какую-то проблему. Мы какую проблему решаем?
При наличии достаточного запаса по быстродействию (теоретически) можно было бы добавить домик или ёлку на берегу.
Оптимизация по содержимому требует усложнения генератора. А вот оптимизировать переход между столбцами очень просто. Отказываемся от хранения опорного адреса в DE и храним текущий адрес в HL (а в DE - данные для push). Тогда переход между столбцами станет просто inr h. Переход между плоскостями меняется на lxi d+dad d, но в случае одинакового Y можно использовать mvi a+add h+mov h,a.
ivagor, дерзай, я ж не просто так сорцы опубликовал :)
Опубликованные сорцы - это очень-очень здорово. Но они несовместимы с моим инструментарием, поэтому если я захочу что-то менять, то мне нужно или делать патчи или дизассемблировать и потом менять. Пока на это недостаточно мотивации. Сейчас мотивацию коплю на океаноид, там ведь тоже исходник мне не пойдет и придется дизассемблировать.
Вот не могу представить себе, что такое можно написать в прекрасме, что не съест любой другой инструментарий для 8080. Хотя бы после пары итераций поиска замены. Зачем сразу пускаться во все тяжкие и дизассемблировать?
Насчет RR я возможно погорячился, давно примерялся и уже забыл, что в нем смущало. А насчет океаноида дизассемблирование более чем вероятно из-за нетрадиционных мнемоник.
Взглянул бегло на сорцы ark.asm. Трудно понять, что в них непоправимо не так, но хозяин барин. Я могу себе представить например, что фаза дизассемблирования активирует какие-то области в мозгу, которые нужны для продуктивного кодинга, но обычно спят. Таким образом объективно лишняя стадия переносит кодера в зону комфорта и положительно влияет на процесс.
А еще это дополнительная отмазка, почему я буду откладывать перенос. "Ну это же надо сначала дизассемблировать, а это сложно".
По-поводу спрайтов River Raid несколько вопросов:
1. спрайт представляет из себя квадратик 16x8, увеличение этого квадратика повлечет за собой увеличение оперативной используемой памяти в программе?
2. цвета пикселей могут быть любые из палитры 256 цветов, но не более 16 для одновременного отображения?
3. цвета пикселей задаются цифрой в рисунке спрайта?
dbk,
1) Спрайты могут быть любого размера, он определяется тем, сколько пикселей и строк задано в makesprites.py. Память увеличивается при увеличении спрайта. Для типичного кораблика будет сгенерировано 16 сдвигов (8 в одну сторону + 8 в другую), для моста же, например, только один, потому что ему не надо ездить.
2) Палитра хитрая, один бит все делает черным, это нужно для рамки для прокрутки. Поэтому цветов 9: 8 + черный. Палитра определена в palette.inc (обычная называется просто palette_data).
3) Я привык думать о цифрах как о слоях, потому что Вектор и потому что когда я их планировал приходилось думать где там чего. Но это конечно же цвета.
Если ты думаешь использовать это для чего-то своего, то может быть например тебе маска будет неактуальной и можно использовать все 16 цветов. Также можно обратить внимание на критику ivagor-а в предыдущих сообщениях. Если будешь чего-то менять, сначала желательно отладить вывод какого-то тестового спрайта независимо от всего, а потом уже этот шаблон засовывать в питонский генератор.
Спасибо, что разложил, но нет, ни для чего своего я использовать не буду ))) я программировать не умею. Просто подумалось, как тяжело подправить спрайтики ) ну те же самолетики врагов на типа такой который я сейчас приаттачил (поднятно, что он большеват). Я так понимаю, как минимум нужно писать конвертер png в твою систему кодирования, ну и правка кода новые палитру и т.д. Думал, тупо ручками по "чистым" цветам подправить спрайт, ну и попробовать вручную перенести в твой формат ) тупо влоб ))) а потом посмотреть что получится )
Вложение 68951
Для пробы чуть изменил makesprites.py (всего -8 тактов на спрайт), сгенерировал ship.inc и собрал бинарник. Результат работает. А вот чтобы менять серьезнее, например оптимизировать переходы между столбцами надо или разбираться с математикой или использовать самомодифицирующийся код, для которого еще нужно генерировать метки. svofski, я понял, почему ты мог остановиться на текущем варианте :)
ivagor, Спасибо за понимание =)))) Метки несложно генерировать, хотя я взаимно понимаю, почему ты не хочешь более плотно разбираться с makesprites.py. Я и сам в него обратно лезть не хочу.
Но мне все же кажется, что сама по себе оптимизация спрайтов не приближает добавление новых фич. Если у тебя есть задача, например, добавить елочку, то надо поступить наоборот. Сначала убрать спрайты вообще и, свободно дыша, добавить елочку. А потом уже посмотреть, хватает или нет на нее времени и, если не хватает, то сколько его надо и искать откуда можно еще его выжать. Опять же, почему-то все накинулись на спрайты, но спрайты я хоть сам и не ivagor, но кое-как все-таки оптимизировал. И даже если там что-то не оптимально, оно как-то притёрто к остальному коду, что может быть немаловажно. Но кроме спрайтов там есть еще тонна кода, которая набросана вообще методом упаковки чемодана за полчаса до окончания посадки.