Прямо сейчас я тоже не готов делать новое демо :) Возможно зимой/к весне или к лету :)
Остались еще не реализованные идеи и хочется плотнее поработать с фиксом.
Плотнее с фиксом я поработаю в финальной версии YSKB и в следующем демо на бейсике.
А по идее, нужно было бы по конкретным значениям FRAMES и чтением из памяти значения играющей в данный момент позиции в музыкальном модуле.
Тема синхронизации AY-музыки на прерываниях и BASIC демы еще мало изучена и, может быть, diver4d поделится своими наблюдениями и мыслями по этому поводу.
Я фиксился как раз через переменную FRAMES. После загрузки и небольшого прекалка я обнулял её и затем считывал в цикле эффекта либо в холостом цикле при ожидании следующего эффекта. Вызов сделал через GO SUB 1. Но всё равно эффекты этим тормозились. Если считывать напрямую номер играемой позиции, то, по идее это должно снизить тормоза, т.к. нам нужна всего лишь одна связка «IF PEEK N<POS THEN GO TO».
Фикс через FRAMES (или через номер позиции в плеере) упрощает работу, т.к. не надо думать о задержках внутри эффекта и скорости выполнения эффекта. Мы просто ловим нужную позицию в таймлайне и начинаем следующий эффект. Это должно корректно работать на всех клонах.
Внутри intro в YSKB фикс сделан как через задержки через PAUSE, так и через FRAMES, в принципе и то и другое работает вполне корректно на разных клонах.
Уже в процессе составления таймлайна для написания музыки и фикса, я вдруг осознал, что некоторые эффекты у меня могут сильно отличаться по времени выполнения, что накладывало некоторые проблемы на фикс
То же самое у меня было в Back 2 Basics. Есть какие-то эффекты можно прерывать в любой момент, но есть и части типа Greetings, части с выводом текста, части с пошаговым выводом графики, которые требуют конкретного времени на вывод всего контента, сами собой такие вещи с музыкой не состыкуются, нужны расчеты.
Именно так. Старался чистить переменные, но есть один не очень приятный момент с CLEAR — он чистит не только переменные, но и экран, что не всегда нам на руку.
(мне очень стыдно за строчки, дальше середины листинга)
Мне вообще стыдно за весь свой листинг :-D
Но, поскольку я ни разу не уперся в ограничения по памяти для бейсика, то я не тратил время на оптимизацию кода.
Раскрытие циклов, отсутствие, вызываемых по GO SUB, процедур, многократное переопределение переменных с CLEAR в начале каждого эффекта позволяют не терять скорость. Сдается мне, что бейсик при каждом GO TO/GO SUB/RESTORE ищет адресуемые строки перебором, и так с переменными — перебор, пока не будет найдено соответствующее имя. Соответственно, чем дальше адресуемая строка или больше переменных — тем больше тормоза.
Не очень понимаю, почему. Разве в качестве даты публикации не берётся текущая в момент нажатия кнопки 'опубликовать', независимо от того, когда и сколько раз сохранялся черновик? И можно долго писать локально, а здесь только форматировать перед публикацией, за день-другой. По крайней мере, мне было удобнее делать так.
В любом случае, публикация задним числом не очень нормальна по своей сути, и если для этого есть какая-то техническая причина, надо бы её исправить.
Ждём дайвера. Могу попробовать угадать: раз интерлейс, то кадр занимает 3кб. По 1кб на треть, что делается за 4 вызова LPRINT на одну треть. При этом приходится хранить данные в довольно безумном формате, но это разрешимо. Итого, раз у нас 3кб на кадр, практично хранить, например 5 фаз, почти полная страница графики. Т.к. картинка достаточно однообразная (и если присмотреться, видно, что атрибуты стоят на месте), не очень сложно сделать фазы достаточно недалеко отстояшими друг от друга. diver4d , сильно наврал? :)
introspec , тебе огромное спасибо за плеер для бейсика! За ДВЕ! версии плеера — для 48k и 128k. Мы прекрасно понимаем, что ничего путного без твоей помощи не вышло бы, как ни крути.
Остались еще не реализованные идеи и хочется плотнее поработать с фиксом.
Плотнее с фиксом я поработаю в финальной версии YSKB и в следующем демо на бейсике.
Фикс через FRAMES (или через номер позиции в плеере) упрощает работу, т.к. не надо думать о задержках внутри эффекта и скорости выполнения эффекта. Мы просто ловим нужную позицию в таймлайне и начинаем следующий эффект. Это должно корректно работать на всех клонах.
Внутри intro в YSKB фикс сделан как через задержки через PAUSE, так и через FRAMES, в принципе и то и другое работает вполне корректно на разных клонах.
Подражание C64. Удивительно, почему на speccy так мало уделяют внимание заставкам\титульным экранам и манипуляциям с ними. Это же не паханное поле!
Но, поскольку я ни разу не уперся в ограничения по памяти для бейсика, то я не тратил время на оптимизацию кода.
Раскрытие циклов, отсутствие, вызываемых по GO SUB, процедур, многократное переопределение переменных с CLEAR в начале каждого эффекта позволяют не терять скорость. Сдается мне, что бейсик при каждом GO TO/GO SUB/RESTORE ищет адресуемые строки перебором, и так с переменными — перебор, пока не будет найдено соответствующее имя. Соответственно, чем дальше адресуемая строка или больше переменных — тем больше тормоза.
В любом случае, публикация задним числом не очень нормальна по своей сути, и если для этого есть какая-то техническая причина, надо бы её исправить.
Спасибо!