Именно так. Старался чистить переменные, но есть один не очень приятный момент с CLEAR — он чистит не только переменные, но и экран, что не всегда нам на руку.
(мне очень стыдно за строчки, дальше середины листинга)
Мне вообще стыдно за весь свой листинг :-D
Но, поскольку я ни разу не уперся в ограничения по памяти для бейсика, то я не тратил время на оптимизацию кода.
Раскрытие циклов, отсутствие, вызываемых по GO SUB, процедур, многократное переопределение переменных с CLEAR в начале каждого эффекта позволяют не терять скорость. Сдается мне, что бейсик при каждом GO TO/GO SUB/RESTORE ищет адресуемые строки перебором, и так с переменными — перебор, пока не будет найдено соответствующее имя. Соответственно, чем дальше адресуемая строка или больше переменных — тем больше тормоза.
Не очень понимаю, почему. Разве в качестве даты публикации не берётся текущая в момент нажатия кнопки 'опубликовать', независимо от того, когда и сколько раз сохранялся черновик? И можно долго писать локально, а здесь только форматировать перед публикацией, за день-другой. По крайней мере, мне было удобнее делать так.
В любом случае, публикация задним числом не очень нормальна по своей сути, и если для этого есть какая-то техническая причина, надо бы её исправить.
Ждём дайвера. Могу попробовать угадать: раз интерлейс, то кадр занимает 3кб. По 1кб на треть, что делается за 4 вызова LPRINT на одну треть. При этом приходится хранить данные в довольно безумном формате, но это разрешимо. Итого, раз у нас 3кб на кадр, практично хранить, например 5 фаз, почти полная страница графики. Т.к. картинка достаточно однообразная (и если присмотреться, видно, что атрибуты стоят на месте), не очень сложно сделать фазы достаточно недалеко отстояшими друг от друга. diver4d , сильно наврал? :)
introspec , тебе огромное спасибо за плеер для бейсика! За ДВЕ! версии плеера — для 48k и 128k. Мы прекрасно понимаем, что ничего путного без твоей помощи не вышло бы, как ни крути.
Да, будет. Называйте наиболее удобное время. Бейсик компо будет точно на следующем 3BM, да и отдельное виртуальное организовать не проблема. Проблема успеть к дэдлайну)))
Но, поскольку я ни разу не уперся в ограничения по памяти для бейсика, то я не тратил время на оптимизацию кода.
Раскрытие циклов, отсутствие, вызываемых по GO SUB, процедур, многократное переопределение переменных с CLEAR в начале каждого эффекта позволяют не терять скорость. Сдается мне, что бейсик при каждом GO TO/GO SUB/RESTORE ищет адресуемые строки перебором, и так с переменными — перебор, пока не будет найдено соответствующее имя. Соответственно, чем дальше адресуемая строка или больше переменных — тем больше тормоза.
В любом случае, публикация задним числом не очень нормальна по своей сути, и если для этого есть какая-то техническая причина, надо бы её исправить.
Спасибо!
Золотые слова-то!