svofski, классные демки! А как ты волну делал?
Вид для печати
svofski, классные демки! А как ты волну делал?
Спасибо!Цитата:
Сообщение от parallelno
Амплитуда туда-сюда баунсится + постоянное смещение, а начальная фаза инкрементится значением функции с краю предыдущего кадра. Могу слегка соврать, я уже месяца два назад это писал на самом деле. Но в общих чертах так.
svofski, бодренькие демки получились....это побуждает тоже написать демку....наверно надо уже сейчас начинать создание, а далее на подходящей демопати представить свой шедевр :)
svofski, загрузка конечно СУПЕР !!!! Это и на реальном Векторе и на эмуляторах одинаково работает ? И как это сделано ?
metamorpho, если у меня получилось пробудить аппетит, я считаю что не зря потратил время.
Загрузка, это ivagor сделал сверхскоростной загрузчик, а я приделал к нему начальный загрузчик с автозапуском, который перехватывает управление из стандартного. Сейчас чтобы этим воспользоваться вообще ничего не надо, достаточно просто запустить bin2wav.js -m v06c-turbo myrom.rom myrom.wav На реале это должно без проблем работать (с обычными оговорками про провода, всякие девиантные параметры плееров на телефонах итд).
svofski, извиняюсь за опечатку в предыдущем посте. А как ты определял какую часть волны нужно перерисовать/стереть?
На реале работает, проверяли KTSerg и svofski (там вариант еще без автозапуска). В эмуляторах и на девбордах типа DE1 работает чуть лучше, можно грузить даже со скоростью 13500, реал стабильно грузит 11700. Скорее всего можно и для реала улучшить, но это надо отлаживать только на реале (или если кто-нибудь сделает близкую к реалу эмуляцию поведения магнитофонного порта).Цитата:
Сообщение от metamorpho
Идем слева направо. Вычисляем текущее значение функции. Из разницы с предыдущим значением в этой же координате считаем дельту и перекрашиваем только ее. Если стало выше -- рисуем, если стало ниже -- стираем. Фактически на каждом кадре меняется совсем немного пикселей на разделе вода-воздух, поэтому получается что как будто весь экран колбасит, а на самом деле рисуется всего-то ничего.Цитата:
Сообщение от parallelno
Про ускорение загрузки turbofm -- по-моему лучше не надо. Сейчас и так очень быстро и проверено на совместимость с разными реалами, а терять даже чуть-чуть надежности не хочется.
Можно ли в разы сократить 256-байтную демку? Иногда можно.
Возьмем для примера треугольник Серпинского. Мне показалось, что 256 байт для данной задачи многовато. Признаюсь, что оттолкнулся от исходника Артема Навалона, но полностью переписал.
Получилось сократить LoRes в 2 раза (с 256 до 127 байт) и ускорить примерно на порядок.
Но это не предел. Если ограничиться возможностью запуска из загрузчика, что позволяет не делать лишних инициализаций, то LoRes 84 байта (в 3 раза меньше прототипа), HiRes 127 байт (в 2 раза меньше прототипа).
Конечно такое компактирование (да еще и с резким ускорением) скорее исключение, чем правило, но это показывает, что иногда имеет смысл вернуться к классическим задачам и попробовать переосмыслить реализацию.
Upd 06.01.2023: Заменил sierp512.r0m на вариант с более корректной инициализацией. Сочетание неблагоприятных факторов (вариант загрузчика+неудачный момент старта) могло привести к незапрограммированной палитре. Причем я уже с этим разбирался на примере Моны, но с тех пор забыл. В вариантах для режима 256 все нормально, их не менял.
Для любителей экзотики HD версия треугольника для кристы-2 в режиме 1024x256! Вертикального разрешения не хватает, поэтому пошел на компромисс и в данной версии укрупненно отображаются верхние 27/32 картинки. Кристу-2 поддерживают Emu и VV, но в данном случае VV не подойдет, т.к. в режиме 1024 показывает только половину точек.
1. Запускаем Emu с выбором конфига Krista-2
2. В меню выбираем View>Size 2:1, чтобы в режиме 1024 были видны все точки
3. Грузить придется wav, поэтому жмем на тулбаре кнопку Play/Stop и выбираем sier1024.wav
4. Слева вверху под левой звездочкой ненадолго появится черта. Когда она пропадет можно запускать (F12).
Чтобы прочувствовать все 1024 точки можно параллельно запустить в VV. Там проще:
1. File>Config>Load...>Krista-2.con
2. Дропаем sier1024.r0m в окно эмулятора
Или при желании можно загрузить wav (File>Tape>Tape Image Open..., потом F12).
На что обратить внимание:
1. Стороны треугольников
2. В Emu видно, что cамые мелкие детали - треугольники (в этом принципиальное отличие от версии 512 точек), а в VV они выглядят как прямоугольники.
Заменил версию треугольника для режима 512 на более корректную. На этом треугольники закруглились.
Было еще два потенциальных направления:
1. 8085 в данной задаче очень помогает и хотел дожать вариант для 6128 до 64 байт, но не получилось. Даже с некоторыми послаблениями удалось уменьшить только до 68, а без послаблений до 71.
2. Попробовал несколько вариантов для 06Ц в режиме 512 не с 2 а с 3 оттенками, чтобы сгладить картинку и приблизиться к Кристе-2. Результаты не особо впечатлили, но один из вариантов более-менее интересный, правда скорее не для вектора, а для компов с разрешением 384x256 и 4 цветами/точку.
Ширится монификация околовекторовского пространства. Сделал 256-байтную версию работающую из бейсика ПК-6128Ц.
Загрузка
BLOAD"" и выбираем в диалоге MONA.CAS
Запуск
A=USR(&701F)
Когда нарисует можно вслепую набрать COLOR15 и пользоваться бейсиком дальше.
Чтобы не было сомнений в размере в архиве не только CAS, но и BIN, который можно загрузить через отладчик с адреса 701Fh и потом запустить как и CAS через A=USR(&701F)
С бейсиком действительно получилось перевести векторовскую Мону в категорию <=256 байт. Два варианта: для классического 2.5 (256 байт) и для новодельного 2.62 (255 байт).Цитата:
Сообщение от ivagor
Загрузка и старт одинаковые:
BLOAD"" (если грузить bin в отладчик, то с адреса 7000h)
A=USR(&7084)
На картинках можно увидеть некоторые допущенные послабления.
Вложение 78312Вложение 78313
В обоих версиях используются дефолтные цвета палитры, но на на мой взгляд это не стало проблемой даже в цвете (чем могут похвастаться далеко не все советские ретрокомпы), а уж в ч/б совсем хорошо. Дополнительно в версии для 2.5 пришлось пожертвовать кропом снизу.
Имея за спиной мощь бейсика оказалось не так уж сложно закрыть и другой гештальт - 64-байтный треугольник Серпинского для 06Ц.
Запуск и старт (и функциональность) версий для 2.5 и 2.62 одинаковые:
BLOAD"" (если грузить bin в отладчик, то с адреса 701Fh)
A=USR(&701F)
В отличие от Моны треугольник зацикленный, когда надоест на него смотреть для выхода в бейсик жмем БЛК+СБР (F12 в эмуляторах).
Больше фракталов хороших и разных. Кривая дракона (дракон Хартера-Хейтуэя) на основе программы С.Телицына из ZX Review 5-6/1997. Переделал (полностью переписал) для 8080, оптимизировал по размеру - уложился в 126 байт с использованием бейсиков 2.5 и 2.62. Доработал: добавил рисование первого шага, добавил регулировку длины шага, увеличил разрядность счетчика вдвое (теперь максимальный порядок 16). На картинке 13й порядок, тут еще 8, 11 и 15.
Загрузка и запуск:
BLOAD""
A=USR(&7000)
После непродолжительного рисования выходит в бейсик.
Ня.
Мона симпатичнее дракона, дракон симпатичнее треугольников, но и размеры распределились соответственно.
Все вместе было бы крутое мегадемо =)
Эклектичная мегадема на 512 байт. Можно и дракона сильнее раскрыть - нарисовать драконов разных порядков в разных плоскостях и переключать. На 6128 так можно даже короткую анимацию запилить. Возможностей много, все пути открыты.
Подскажите, а сколько цветов палитры реально поменять от строки к строке?
Один точно можно, вот пример (в части с летучей мышью). Вероятно можно и два, но это желательно протестировать на реале.
Это связано с низкой скоростью CPU? Или с тем, что палитру можно менять только в каких фиксированных положениях луча?
Программируется тот цвет, что сейчас под лучом в битмапе. Надежней всего когда это бордюр. Очень трудно сочинить такую картинку, где цвета переключаются посередине экрана. Это практически безнадежно для конверсий. Но для творчества тут непаханое поле.
Сочетание этих двух факторов - "сбоку" есть зоны, где нельзя изменить палитру ну и процессор не такой быстрый, чтобы в оставшееся время много успеть. svofski еще пишет про возможность изменить палитру в активной области и в демах это используется, но для конверсий картинок я бы не стал на это рассчитывать. На реале еще будет побочный эффект в виде светлых или темных (в зависимости от инверсности подключения) точек. А вот менять (на бордюре) один цвет для каждой строки для конверсий было бы полезно. Скорее всего там можно практически полностью спрятать изменения цвета бордюра в невидимой области. Для максимального упрощения меняться должен всегда один цвет и желательно нулевой (хотя это не обязательно).Цитата:
Сообщение от Dec
Dec, пользуясь случаем выскажу пожелание добавить в конверсии векторовский режим 512x256. Конечно можно использовать Common, но у вектора есть особенность - можно задать разные палитры для четных и нечетных точек. Т.е. фактически на экране в этом режиме может быть от 4 до 7 цветов.
Вот мой старый эксперимент с полуручной конверсией, тут 33 цвета, фото с ЭЛТ. Не могу отыскать собственно код, но в нем тут невелика ценность. Самое интересное это найти или нарисовать собственно картинку, которая в таком режиме будет выглядеть интересней, чем без него.
https://farm5.staticflickr.com/4652/...0e38fc23_z.jpg
Хотелось бы немножко подробностей. Вот есть у нас строка:Цитата:
Сообщение от ivagor
В какой момент происходит переключение цвета? В момент C? Сколько циклов/тактов составляет AB и CD? Какой код фактически используется для переключения цвета палитры?Код:Бордюр Изображение Бордюр
|----------|------------------------------------------|----------|
A B C D
Мои требования стандартные: спецификации выходного формата + пример файла в этом формате.Цитата:
Сообщение от ivagor
Честно говоря, не вижу полезности этой особенности в контексте автоматической конвертации.Цитата:
Сообщение от ivagor
"Зоны непрограммируемости палитры" недостаточно документированы. На своем 06Ц я их определял и выкладывал, а Ramiros реализовал эту фичу в VV. Но у меня (как и у подавляющего большинства современных вектористов) была доработка синхры для совместимости с современными ТВ и насколько могу судить она влияет на "зоны непрограммируемости". Просто для ориентира что у меня получалось (в активных строках, вверху и внизу все иначе):
из 192 тактов строки: 128 - изображение, потом 24 такта можно программировать, потом 12 нельзя, потом 28 - можно. Конкретный код сейчас не приведу, надо выверять по тактам, может у svofski остались исходники.
Если без учета четных/нечетных точек, то проще конвертить как Common RGB332, сохранять в bmp, показывать на векторе bmp и при необходимости сохранять дамп видеоозу или его части. И, кстати, стандартных форматов для 512 на векторе нет.
Вот по этому я и прошу определиться с выходным форматом. Если писать в виде дампа, то пусть будет в виде дампа, мне не принципиально. Куда писать палитру? Мне нужны четкие инструкции.Цитата:
Сообщение от ivagor
Отрыл закат
Dec, инструкции, явки, пароли... :) По ссылке ниже на первой странице есть раздел про палитры. Там приведены куски кода как менять палитру. Надеюсь поможет.
https://zx-pk.ru/threads/34480-programmirovanie.html
Насчет формата для 512. Проще всего дополнить формат Рембрандта (тем более он уже поддержан в DaDither) - там размер по X в байтах, поэтому можно без проблем использовать старший бит для индикации режима (0-256, 1-512). Осталось сделать примеры в таком формате. Насчет себя пока не уверен, если вдруг кто соберется - только за.
svofski выложил бинарник (у меня он откуда-то уже был) - отличный пример/шаблон для мультиколорного просмотрщика. На реале, насколько понимаю, проверен. И не портит бордюр.
Код из эмулятора VV определяющий зоны програмируемости палитры:Цитата:
Сообщение от ivagor
if(CCMapY<23)and(CCMapX>=20)and(CCMapX<144)or
(CCMapY>23)and((CCMapX<144)or(CCMapX>=156))or
(CCMapY=23)and((CCMapX>=20)and(CCMapX<144)or(CCMap X>=180))then ColPal(BrdCode2,A);
- - - Добавлено - - -
Код из эмулятора VV определяющий зоны програмируемости палитры:Цитата:
Сообщение от ivagor
CCMapX:=OldCC-192*(OldCC div 192);
CCMapY:=OldCC div 192;
if(CCMapY<23)and(CCMapX>=20)and(CCMapX<144)or
(CCMapY>23)and((CCMapX<144)or(CCMapX>=156))or
(CCMapY=23)and((CCMapX>=20)and(CCMapX<144)or(CCMap X>=180))then ColPal(BrdCode2,A);
Ну как-то так (слева 16 цветов, справа с изменением 1-го цвета каждую строку):
https://www.dadither.com/img/V01_16.pnghttps://www.dadither.com/img/V01_SL.png
https://www.dadither.com/img/V02_16.pnghttps://www.dadither.com/img/V02_SL.png
https://www.dadither.com/img/V03_16.pnghttps://www.dadither.com/img/V03_SL.png
Не могу сказать, что результат всегда получается хорошим. Иногда возникают артефакты в виде полосок, пока думаю, как с ними бороться.
Параметры, которые влияют на итоговую картинку:
Initial palette lines - кол-во строк для генерации исходной палитры.
Prev lines - кол-во строк выше текущей обрабатываемой строки, которые участвуют в процессе генерации нового цвета.
Next lines - кол-во строк ниже текущей обрабатываемой строки, которые участвуют в процессе генерации нового цвета.
Max change count - кол-во цветов, которые можно поменять в строке (это на случай, если вдруг научитесь менять два цвета за раз, а не один).
Названия параметров не особо интуитивные, если предложите получше, то готов исправить.
На выходе обычный SPR или RMB файл + дополнительный файл с расширение PALS, который описывает изменения палитры. Структура PALS файла:
Самый первый байт содержит значение 1 или 2, определяющее кол-во цветов, которые можно поменять в строке. Далее до конца файла идут пары байт, описывающие изменения палитры. Первый байт пары определяет индекс цвета, который нужно поменять, второй байт определяет значение цвета, на которое нужно поменять. PALS файл может быть либо 511 байт, либо 1021 байт, в зависимости от того, какое значение выбрано в Max change count.
Dec, круто, особенно если ориентироваться на результат как на нижней картинке с воздушными шарами.
Dec, крутотень! А можно ещё примеров с портретами, пожалуйста?
Так можно просто скачать программу и поиграться самостоятельно с любыми картинками. Денег за это я не беру.Цитата:
Сообщение от parallelno
Dec, пожелание добавить для вектора (в целом, и без построчных изменений палитры и с изменениями) опцию Fixed Black (или как-то в этом духе). При включении этой опции один цвет (желательно нулевой) всегда будет черный, и остаются 15 цветов, которые можно переопределять. Для эмуляторов это не особо нужно, а вот для реалов (без переделки для реализации уровня черного) думаю будет полезно.
Это уже можно сделать двумя способами.Цитата:
Сообщение от ivagor
1) Выбрать Palette mode в значение Custom, после этого ткнуть на кнопку Edit, в появившемся окне мышкой ткнуть черный цвет в левом верхнем углу. В такой конфигурации в палитре всегда будет черный цвет, и он будет нулевым.
2) Создать pal файл с палитрой из одного черного цвета, открыть его в программе, и выбрать его в списке Fixed palette.
А в чем суть этой полезности?Цитата:
Сообщение от ivagor
Вектор не умеет делать врезку порожка "чернее черного", поэтому реалы без доработки могут показывать рваную картинку при меняющемся бордюре.Цитата:
Сообщение от Dec
Но вообще было бы интересно посмотреть на практическую реализацию просмотрщика. По идее за промежуток от точки 256 до точки 0 следующей строки надо успеть выбрать индекс цвета бордюра, записать его, сбросить индекс цвета бордюра на старый. Довольно много операций для Вектора-06ц.
- - - Добавлено - - -
P.S. забыл сказать -- картинки смотрятся очень круто. Особенно воздушные шары.
Ничего не понял. А можно простыми словами для людей очень и очень далеких от железа и понимая принципов формирования видеосигналов.Цитата:
Сообщение от svofski
С большой вероятностью (смотря какие цвета на бордюре) картинка на телевизоре будет нестабильная. Или будет дергаться или м.б. искажение цветов.
А что определяет какие цвета на бордюре?