Я сейчас работаю над более-менее универсальным просмотрщиком для статического бордера. Для работы дайвера я написал очень быстрый говнокод для пентагона (что там с релизом я не знаю, но программа существует); скоро будет доделана более человеческая программа, поддерживающая всю классику, пентагон и скорпион. Есть несколько проблем и ограничений, которые стоит обсуждать.
1. Над экраном у 48к и пентагона - 64 строки. У 128к - 63 строки. Я считаю, нужно хранить 64 строки. В самом экране 192 строки. Под экраном у классики 312-64-192-16=40 строк. Под экраном у пентагона 48 строк. Эмуляторы рисуют по-разному; сочетания реалов с мониторами тем более непредсказуемы. С моей точки зрения нужно хранить 64+192+48=304 строки, т.е. случай максимум, и иметь в виду, что просмотрщику придётся обрезать картинку при показе на конкретном компьютере.
2. Есть существенная разница между тем, что можно рисовать на пентагоне и тем, что можно рисовать на всех остальных машинах. Фактически, бордюрный пиксель на пентагоне - 2х1 обычных пикселя. Бордюрный пиксель на классике и других клонах - 8х1 обычных пикселя. Если мы хотим переносимости между моделями, есть смысл остановиться на 8х1, хотя я могу себе представить и другие точки зрения на этот вопрос. Картинка дайвера - в 8х1. Я пишу свой просмотрщик для 8х1. Технически, по реализации, пиксели 2х1 мало чем отличаются, но мне непонятно, вот так, с ходу, что просмотрщику делать с картинкой 2х1 на 8х1 компьютере.
3. Картинку 8х1 я буду хранить в виде последовательности чисел - цветов бордерных "пикселей" 8х1 слева направа, сверху вниз. Всего в строке на спектруме 224 или 228 тактов, что соответствует 56 или 57 знакоместам. Я не стал детально разбираться в размерах вертикальных полей для разных моделей; у себя я буду хранить в каждой строке 48 чисел, т.е. 48 знакомест. Это перекрывает поля во всех известных мне эмуляторах и близко к теоретическому максимуму ширины по отрисовке. Итого, один кадр занимает 6912+48*304=6912+14592=21504 байта. Это очень неэффективно, но удобно в работе и отлично жмётся. Конечно, есть смысл думать о более компактном способе хранения. Я пока не вполне для себя определился, как "лучше" и всерьёз думаю выкинуть все пиксели оказывающиеся "под экраном"; в это случае потребуется хранть 6912+48*64+(8+8)*192+48*48=6912+8448=15360 байт. Другой очевидный вариант - хранить по два цвета на байт, т.е. 6912+48*304/2=6912+7296=14208 байт, ну или 11136 байт если ещё и не хранить данные под экраном. Так как пока что я делаю тупой просмотрщик статической графики, я не вижу для себя смысла быть особенно бережливым. Хотя, пока просмотрщик ещё в работе и я для себя не вполне определился, чего я хочу больше всего
Если бы я попробовал быть настолько же расточительным для пентагоновских 2х1 пикселов, мне бы не хватило машинной памяти.
4. Хотя картинка и состоит из "пикселей" 8х1, никакой просмотрщик не сможет менять цвет чаще чем один раз за три таких пикселя. За выполнением этого правила должен следить художник. Исключения - пиксели около кромок бордюра и экрана (реализация этого принципа - это одна из причин ограничения визуальной ширины картинки в 48 знакомест). Если скормить картинку, нарушающую этот принцип в просмотрщик, ожидаемый результат не будет получен, картинка будет отображена неверно. В принципе, можно ловить такие моменты в просмотрщике, но, имхо, более полезно бы было ловить это в пиксельном редакторе, на стадии рисования.
5. Бордюрный гигаскрин будет реализуем на этом движке почти тривиально, хотя в 48к могут возникнуть различные затруднения с объёмом памяти, занятым просмотрщиком. Я не вижу совершенно никаких технических трудностей для реализации такого эффекта на 128к машине. Бордюрный гигаскрин мы обсуждали и имеем в виду, но пока больше озабочены реализацией стандартных цветов на стандартных машинах. В моём понимании, бордюрный гигаскрин интереснее для картинок в гигаскрине, так что есть смысл делать специальный, отдельный просмотрщик под это дело, работающий только на 128к машинах.
Кажется, ничего не забыл
Posted: Sat, 10.08.2013 22:53:48
в отличии от…