Да там нечего смотреть, всё то же самое. Pyk наверное имел в виду, что я экран не стираю перед использованием. Как переработаю графику, выложу ещё чего-нибудь.Сообщение от SegaBoy
- - - Добавлено - - -
Это я в эмуляторе вижу, поправлю.
Пока не овладел эти кунг-фу. Куда ни поставь, либо картинку на две части делит, либо срыв синхронизации.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Тогда пока на них и не отвлекайся, чтоб голову не морочить.
- - - Добавлено - - -
Ну вчерашнее хоть криво но запустилось, а после небольшой правки уже и не криво. А сегодняшнее просто улетает и всё - на экране мельтешение строк и всё ((
Буду ждать новых версий!
https://disk.yandex.ru/d/F-zs61NwkS-d_w
Ещё ссылочку приложу -> https://zx-pk.ru/threads/27478-sekre...294#post905294
D356 47C0 35F8 F55E 8A52 A88F F3F8 B003 03EB 3D7F
Спасибо! Я уже остановился на 78х[email protected]Гц и 7 строк в символе. Но если найдется режим, в котором можно заквадратить псевдопиксели, то конечно рад буду проверить.
- - - Добавлено - - -
Подскажите максимально быстрый способ чтения клавиатуры. Или где описание искать. Стандартная процедура из Монитора оказалась слишком медленной.
В Пикачу смотрел? Я там каждый фрейм читаю напрямую из порта.
- - - Добавлено - - -
Максимально быстрый способ такой. Выставляем в порт 8000 (РК86) или в ED00 (Апогей) значение, соответствующее линиям клавиатуры, которые хотим опросить. Затем читаем из портов соответственно 8001 или ED01.
- - - Добавлено - - -
Вот когда-то такую подсказку делал, может поможет:
Т.е. установленный бит соответствует нажатой клавише? Если я правильно понял, то вполне можно устанавливать комбинации клавиш в одном ряду...
Ага, с подсказкой сразу понятно стало. Разобрался откуда берутся тормоза. ПДП держит шину наверное. Читается из порта всегда быстро. А записывается быстро в него только во время обратного хода луча.
Наоборот, если бит сброшен, то клавиша нажата.
- - - Добавлено - - -
Если контроллер ПДП получил управление, то процессор остановлен и уже никак и ничто не записывается им ни в порты ни в память, ни быстро ни медленно.
Вот, что у меня получается )
Сделал стирание экрана перед запуском демки, переделал счетчик-делитель, привязал его к обратному ходу луча, сделал отдельную быструю подпрограмму для вывода спрайтов фиксированного размера 4х4 знакоместа и 4 кадра, сделал набросок опроса клавиатуры, частично разметил бордюр. Получилось рабочее пространство шириной 64 знакоместа, что очень удобно.
Однако всё работает плавно, и быстро! И есть еще много возможностей для оптимизации. И есть сам по себе запас ресурсов. В принципе, теперь стало понятно, что на гугловского динозаврика мощностей хватает. Я рад )
Заставил человечка бежать по нажатию на пробел. Перемещается он на одно знакоместо. Скорость при этом в два раза выше скорости больших звёзд. Можно двигаться на половину знакоместа, тогда скорость сравняется со скоростью больших звёзд.
НО! За счет анимации, смещение на одно знакоместо выглядит вполне себе нормально, я думал, что будет заметен перескок, но нет всё норм. Если бы ФПС побольше иметь, тогда да, надо использовать перемещение на половину знакоместа. Но пока прям вот сильно заметно ускориться не получилось. А ускорение будет потрачено на карту уровня, просчёт коллизий и т.д.
Я вот чего думаю... Диззи всё время машет руками для того, чтобы его было лучше видно на фоне других спрайтов. Тут даже такое не прокатит. Слишком маленькое разрешение, персонажа от фона цветом не отделить, всё сливается в пиксельную кашу.
Вот хороший пример:
Все персонажи на ровном черном фоне. Наверное надо в эту сторону думать по рисовке.
Жаль праздники заканчиваются, поэтому темп мне придётся сильно снизить.
В любом случае, сначала надо научиться делать под ч/б 86РК.
Я один столько спрайтов не нафигачу. Тут вообще надо художником быть.
И, как ни крути, 86РК и сейчас самый распространенный конструктор. РК даже на Али продают, в разных версиях, а Апогеев я что-то не видел
Эту тему просматривают: 2 (пользователей: 1 , гостей: 1)
Ваши права
Ответить с цитированием
