Ну про это и спрашивал. запас есть, значит хватит на еще что нибудь поделать. Сам сейчас колдую, игру доделываю, отрисовку спрайтов и анимацию при ударе и попаданию по врагу. Благо памяти хватает. Но опять же, хоть у меня цикл по сути отбирает практически всю производительность, всеравно пришлось вводить задержку на цикл, чтобы анимация просмотривалась, а иначе все 5 картинок перебираются так быстро что не успеваешь разглядеть что там понарисовал )).Сообщение от Hammer
Радио86 рк (Пальмира), Электроника кр04, Поиск 1
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ага, спасибо! Я вобщем понял, что с растягиванием пикселей чуда не происходит, значит будет режим 78х43@50.34Гц и 7 строк в символе.
Уберу символы с рамки, сэкономлю такты. Потестировал этот режим, можно ужаться, чтобы и в нем не сильно тормозил код.
Вариантов удобных всё равно не остаётся.
Да, снизу F3, сверху - F1 в каждой строке. В рабочей области тоже можно F1 в конце каждой строки для экономии тактов.
Убрать лишние выборки ПДП и в режиме 50 Гц тормозить будет даже меньше, чем при 60 Гц - реже обращение к ОЗУ...
Экономию можно получить, если стандартизировать анимационные спрайты. Сделать 4х4 знакоместа и 4 кадра. Верхнее знакоместо на подъем, как у колбы и сердца. А вот меч большой, его получится поднять только на половину знакоместа, значит ему просто нужна другая анимация. Большой спрайт, если такой будет, делить на малые.
Т.е. там, например, где начинается невидимая область (бордюр), можно поставить F1?
Да, но есть нюанс: возможно, после F1 придется оставить еще один байт (хотя бы нулевой). Цитирую документацию:
Note: If a Stop DMA character is not the iast character in a burst or row, DMA is not stopped until after the next character is read. In this situation, a dummy character must be placed in memory after the Stop DMA character.
Помогите понять, как это работает по времени.
У меня получается так, что вывод спрайтов (пусть даже только основных) лучше всего делать сразу после детекта обратного хода луча. А вот все вычисления уже можно делать после всего. Пусть и процессор останавливается, это уже пофиг т.к. все мерцания мы минимализировали быстрым выводом спрайтов.
Вот как правильно добывать дополнительные такты?
4 первые строки могут быть скрыты, можно смело вставить в них F1 в самом начале. Это значит, что ПДП подхватит данный код и перестанет угнетать в заточении процессор до начала следующей строки?
А вот если я делаю не так... Если я рисую картинку сразу с первой строки, но в конце 32й (к примеру) строки я ставлю F3, экран сдвигается вниз, ПДП "передаст свет" процессору... на какое время, до какого момента?
Не могу понять, 86РК это больше Билли Миллиган или Халк?
Такой момент обнаружился, что выиграть надо кадр, если мы синхронизируемся по обратному ходу луча. Тогда скорость игры, а значит плавность всего заметно увеличивается. Если при всей оптимизации выигрывается времени меньше, то и мерцаний становится меньше, но скорость остаётся прежней.
В Emu80 внизу окна показывается графический режим, и КПД процессора - это без учёта использования F1 и F3?
С учетом, по факту. Усредненное значение за (кажется) полсекунды.
Т.е. установленный бит соответствует нажатой клавише? Если я правильно понял, то вполне можно устанавливать комбинации клавиш в одном ряду...
Наоборот, если бит сброшен, то клавиша нажата.
- - - Добавлено - - -
Если контроллер ПДП получил управление, то процессор остановлен и уже никак и ничто не записывается им ни в порты ни в память, ни быстро ни медленно.
Вот, что у меня получается )
Сделал стирание экрана перед запуском демки, переделал счетчик-делитель, привязал его к обратному ходу луча, сделал отдельную быструю подпрограмму для вывода спрайтов фиксированного размера 4х4 знакоместа и 4 кадра, сделал набросок опроса клавиатуры, частично разметил бордюр. Получилось рабочее пространство шириной 64 знакоместа, что очень удобно.
Однако всё работает плавно, и быстро! И есть еще много возможностей для оптимизации. И есть сам по себе запас ресурсов. В принципе, теперь стало понятно, что на гугловского динозаврика мощностей хватает. Я рад )
Заставил человечка бежать по нажатию на пробел. Перемещается он на одно знакоместо. Скорость при этом в два раза выше скорости больших звёзд. Можно двигаться на половину знакоместа, тогда скорость сравняется со скоростью больших звёзд.
НО! За счет анимации, смещение на одно знакоместо выглядит вполне себе нормально, я думал, что будет заметен перескок, но нет всё норм. Если бы ФПС побольше иметь, тогда да, надо использовать перемещение на половину знакоместа. Но пока прям вот сильно заметно ускориться не получилось. А ускорение будет потрачено на карту уровня, просчёт коллизий и т.д.
Я вот чего думаю... Диззи всё время машет руками для того, чтобы его было лучше видно на фоне других спрайтов. Тут даже такое не прокатит. Слишком маленькое разрешение, персонажа от фона цветом не отделить, всё сливается в пиксельную кашу.
Вот хороший пример:
Все персонажи на ровном черном фоне. Наверное надо в эту сторону думать по рисовке.
Жаль праздники заканчиваются, поэтому темп мне придётся сильно снизить.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
