Просмотр полной версии : Демо эффекты для Вектора
metamorpho
05.12.2021, 22:10
Хотя да, умирала в 2001 году, а потом начиная с 2009 года до этого момента предпринимаются редкие попытки её реанимации, так что состояние дэмосцены на Вектор можно охарактеризовать как - состояние отличное от жизни, но в тоже время неприсущее смерти :)
Примерно в 2001году окончательно умер MSDOS, а вместе с ним и единственный качественный эмулятор Вектора. Чтобы создавать демки, энтузиастам надо на чем то работать (ну не на железе же им демки писать :) ). Вменяемые эмуляторы под винду появились после 2008 года, тогда и появилась вторая жизнь Вектора. Многие скажут - а как же emu3000, но как бы помягче сказать - он кривущий как минимум по вектору.
Качество эмуляции в emu3000 сподвигло меня сделать Вектор на FPGA, так что спасибо ему.
После разговоров о векторовской демосцене даже как-то неловко выкладывать свою поделку, но все же рискну. Не особо красивый, но быстрый и компактный (252 байта) Мандельброт. Картинку 32x31 рассчитывает и рисует за 1.1 секунды.
Upd 15.12.2021: Новая версия на гитхабе (https://github.com/ivagorRetrocomp/Mandelbrot/releases). Считает и рисует один кадр за 0.7 секунды (1.4 FPS), 219 байт.
1 кадр в секунду это быстрее, чем я сегодня могу обрабатывать информацию. Можно было бы сделать ротозумер.
Ты наверно тоже вспомнил демку для C64, где быстро рисует Мандельброта и потом ротозумит (или там даже 3D, уже подзабыл). Но мне хотелось уместиться в 256 байт, а вращалка-масштабировалка в 4 байта не влезет. Отдельно можно сделать, вроде до сих пор нет ротозумера для вектора.
Нет, я не думал о других демках. Просто подумал, что для Мандельброта 1 кадр в секунду на Векторе -- это круто. Или для Вектора один Мандельброт в секунду -- это круто.
Думаю это не предел, но на данный момент так.
Ух ты, так это оказывается мандельскроллер! Может быть можно зумер без ротора?
Может быть можно зумер без ротора?
Без ротора даже на 8080 должен выйти годный фпс, ибо не нужно столько регистров, как для стандартной реализации ротазума под Z80. Сгенерить текстурку (фрактал или что там) и потом зумить её как сетку с задаваемым шагом.
Можно и зумер без ротора, но если уж выходить за рамки 256 байт, то с ротором было бы веселее. Вопрос в FPS, если будет совсем мало, то лучше и без ротора.
Без ротора даже на 8080 должен выйти годный фпс, ибо не нужно столько регистров, как для стандартной реализации ротазума под Z80. Сгенерить текстурку (фрактал или что там) и потом зумить её как сетку с задаваемым шагом.
Более того, можно один раз на кадр сгенерировать развёрнутый код для масштабирования строчки, плюс для масштабирования по вертикали копировать уже растянутую по горизонтали строку. А с учётом битпланов, можно следующий кадр строить на невидимом слое и не рвать картинку.
Более того, поскольку битпланов больше двух, можно их складывать через палитру и получить эдакий Motion Blur. Выл бы вектористом -- обязательно попробовал бы :)
Сгенерить текстурку (фрактал или что там) и потом зумить её как сетку с задаваемым шагом.
Э нет, так не пойдет. Именно что фрактал, а не текстурка. Когда его зумим, видим детали, которые было не видно. И зумить можно бесконечно.
Насколько я знаю, для бесконечного зума нужна бесконечная точность представления чисел. Если даже не замахиваться на бесконечность, а всего лишь на очень большую точность, то в рамках вектора я бы стал, тут и с грубой точностью не мгновенно. Ротозум текстуры я попробую, интересно, сколько FPS получится.
Именно что фрактал, а не текстурка. Когда его зумим, видим детали, которые было не видно
Ну тогда слайдшоу гарантировано. Не копался в спектрумовских демках с фракталами, где они именно что "зумятся бесконечно", но предполагаю, что сделан просто зум текстуры. Смысл рассчитывать каждый раз фрактал, если при определенном значении зума картинка примет исходный вид? Делаем текстуру и зумим ее. Если нет разницы, зачем платить больше? (с)
в рамках вектора я бы стал, тут и с грубой точностью не мгновенно
Именно. На Спектруме, повторюсь, были демки с чуть ли не пофреймовым зумом (без ротации) фракталов. Даже для Z80 жирновато, стопудово текстура.
В демках на спектруме наверняка текстуры, спору нет, для красоты этого достаточно, а на таких компьютерах иначе и невозможно. Но вообще картинка Мандельброта не принимает исходный вид, это только на глаз/приблизительно.
Если даже не замахиваться на бесконечность, а всего лишь на очень большую точность, то в рамках вектора я бы стал, тут и с грубой точностью не мгновенно.
Глаза боятся, а руки делают. Увеличение точности в 16 раз привело к размеру 340 байт (можно оптимизировать, это прикидочный вариант) и время построения картинки как в варианте 252 байта увеличилось только на четверть. Все не так уж плохо. Можно увеличить точность еще в 2 раза, это только слегка усложнит начальный расчет таблицы, а все операции в цикле останутся.
Доделал высокоточного Мандельброта (378 байт). Разрешение увеличил до 128x128, что, конечно, сказалось на скорости. И добавил честный (без использования симметрии) зум.
Минимальное время расчета и построения кадра - 6.6 секунды, максимальное - 22.8 секунды. Размер можно немного сократить, но раз круглой цифры не получается, решил оставить вариант побыстрее.
Upd 15.12.2021: Новая версия на гитхабе (https://github.com/ivagorRetrocomp/Mandelbrot/releases). 320 байт. Минимальное время расчета и рисования кадра 5.9 секунды, максимальное - 21.6 секунды.
Сильно оптимизировал Мандельброта (32x31 (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1138998&viewfull=1#post1138998) со "скроллом", 128x128 (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1139379&viewfull=1#post1139379) с зумом). Выложил исходники и бинарники на гитхаб.
Мандельбротоведение для 8080/85 достигло небывалых высот.
1. Быструю версию (32x31) сократил на байт (до 218 байт) и разогнал до 2 Мандельбротов в секунду!
2. "Точная" версия (128x128) минус 31 байт, преодолен рубеж 300 и стало 289 байт. Минимальное время расчета и построения кадра - 5.3 секунды, максимальное - 21.5 секунды.
3. Предмет отдельной гордости - точная версия для ПК-6128Ц. Пришлось согласиться на r0m, зато 256 байт! Минимальное время расчета и построения кадра - 4.7 секунды, максимальное - 18.1 секунды.
Запуск в эмуляторах:
1) Простой способ - в VV выбрать конфиг 6128 и дропнуть r0m в окно эмулятора.
2) Универсальный способ - в Emu или VV перейти в загрузчик (LShift+F11, на реале CC+ВВОД+БЛК) и загрузить wav.
Все на гитхабе (https://github.com/ivagorRetrocomp/Mandelbrot/releases).
Для спорта можно побыстрее, если использовать симметрию и считать только половину, а рисовать 2 половины. А если версию 32x31 переделать для zx8080/85 Micka, да еще с симметрией, то думаю там за счет рисования атрибутами и большей частоты проца выдаст 3-4 FPS.
Можно и еще сократить точную версию 8080, портировав ее на другой комп. Пример Моны показывет, что версия для искры получилась почти на 80 байт короче векторовской, в голом векторе много чего надо инициализировать и никаких процедур в пзу.
Дожал версию 128x128 с зумом для стандартного вектора до 256 байт, но пришлось пойти на жертвы: медленнее, r0m, минус самый "дальний" уровень зума. Моральных сил на апгрейд других версий не осталось, только добавил 256-байтный вариант для 06Ц (гитхаб (https://github.com/ivagorRetrocomp/Mandelbrot/releases)).
Скорость и компактность - это хорошо, теперь можно подумать и о красоте в режиме 256x256x16 (https://github.com/ivagorRetrocomp/Mandelbrot/releases)
Мне и самому понравилось. Вопрос был в палитре, я не художник и палитру взял готовую, (примерно) jet из матлаба.
Был такой конкурс Vintage Computing Christmas Challenge 2021 (https://demozoo.org/parties/4398/). После окончания работы продолжали поступать и дошли до 32 байт для спека (http://www.sizecoding.org/wiki/Christmas_Tree#32_bytes_version_for_ZX_Spectrum). Manwe вместе с коллегами в итоге пришли к версии 28 байт (https://zx-pk.ru/threads/34009-bk-bystree-vsekh.html?p=1142823&viewfull=1#post1142823), НО! Я категорически не согласен с тем, чтобы не учитывать имя файла при определении размера программы построения елки. Если довести эту идею до абсурда, то всю программу помещаем в имя, а в содержательной части остается переход на имя или совсем ничего, если есть автостарт. Сделал пример такой ерунды для векторовского бейсика, 3 байта (jmp 3F08h, вот и вся программа), "ура, мировой рекорд".
BLOAD""
A=USR(20000)
Программу в имени я не оптимизировал, если нужен пример оптимизации для 8080, то он тут (https://zx-pk.ru/threads/8378-pk8000-soft-staryj-i-novyj.html?p=1142753&viewfull=1#post1142753).
всю программу помещаем в имя, а в содержательной части остается переход на имя
К этому бы рано или поздно пришли, весь вопрос в законности такого финта =) или в абсурдности, как посмотреть.
Так-то везде, где печатаются символы, компы юзают процедуры ПЗУ; вот если вообще ПЗУ запретить - было бы интересней.
Тут сразу вырвутся вперед компы без графических режимов, им достаточно вносить байты по адресам "экрана" с символами.
metamorpho
14.07.2022, 22:53
В октябре состоится "CAFePARTY 2022".
В конкурсах допускается участие разных ретро-платформ, в том числе и "Вектор-06Ц"
https://cafeparty.org.ru/2022/compos-and-rules/
Приглашаются мастера ассемблерного слова, умельцы алгоритмических трюков и другие свободные художники.
Там достаточно много различных конкурсов. Лично меня заинтересовали следующие:
= Game Compo (Combined) Игра для любой платформы.
= 1k Procedural Graphics (Combined) Графика, создаваемая ...с помощью различных алгоритмов.
= LowEnd 256b Intro (Combined) Intro для остальных «oldschool-платформ», кроме БК и ZX.
= LowEnd Demo (Combined) Demo для остальных «oldschool-платформ», кроме БК и ZX.
Вот я и думаю, а не....
https://www.youtube.com/watch?v=LItmRAR7Afo
А то вот еще Undefined, совсем скоро: 20-21 августа -- https://undefined.chaosconstructions.ru/
Мой продъ с Undefined 2022
http://sensi.org/~svo/undefined2022/arzak.zip
Видосы итд потом.
C'est super! Насколько помню подобного скролла текста на векторе не было. Прошу прощения за придирку - надо подумать, можно ли вывести такую здоровую картинку совсем без тиринга (без двойной буферизации).
Она как бы без какого попало теринга, но рисует через кадр белый-красный, а белый отстает от луча просто потому что он громадный. То что красный запаздывает, это спецэффект, типа скачет и трясется :)
Вообще я даже долгое время думал оставить ее совсем без синхронизации, но потом получилось синхронизировать по белому кадру (когда выводится белая плоскость).
бтв, запустил Cannon Ball с наколеночным R-Sound. Работает.
- - - Добавлено - - -
https://github.com/svofski/v06c-arzak сорцы, вроде должны быть ап ту дейт. Если вдруг кто не умеет как ivagor патчить демки прямо в zx7 потоке.
parallelno
21.08.2022, 21:16
Она как бы без какого попало теринга, но рисует через кадр белый-красный, а белый отстает от луча просто потому что он громадный. То что красный запаздывает, это спецэффект, типа скачет и трясется :)
Вообще я даже долгое время думал оставить ее совсем без синхронизации, но потом получилось синхронизировать по белому кадру (когда выводится белая плоскость).
бтв, запустил Cannon Ball с наколеночным R-Sound. Работает.
- - - Добавлено - - -
https://github.com/svofski/v06c-arzak сорцы, вроде должны быть ап ту дейт. Если вдруг кто не умеет как ivagor патчить демки прямо в zx7 потоке.
О, нужно будет глянуть. Интересно!
А кстати что означает наколеночный R-Sound?
Ты добавил поддержку R-sound? Это какой то звуковой сопроцессор как AY?
- - - Добавлено - - -
Поклацал в настройках emu80, дошло что это такоц звуковой сопроцессор. А чем он лучше? Или хуже? Насколько он был распространен? Если под него делать музыку, то есть ли преимущества?
- - - Добавлено - - -
И кстати классная демка получилась!
R-Sound лучше тем, что его можно собрать на макетке за полчаса, вместе с контрафактным AY, изготовленным из ардуины-наны. Эмулятор AY на AVR начал когда-то давно Ramiros.
Программировать его почти так же, как AY на портах 14-15, потому что это тот же самый AY, но медленней. Нужно больше out- ов. Фактически out ы в этом случае предназначаются для второго 8255.
Добрые люди залили видос, который собственно и был показан на демó-суаре
https://www.youtube.com/watch?v=e50t_c_i_Uc
Остальные крутые работы -- https://events.retroscene.org/undefined2022/Undefined_Intro
Переделал проволочную чб вращалку (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1024237&viewfull=1#post1024237) в экспериментальную твердотельную цветную. Проскакивают артефакты, поэтому экспериментальная, зато не совсем медленная. Выбор объектов убрал, оставил только кубик. Остальные объекты тоже раскрашиваются, принципиальных ограничений нет, но там надо цвета граней перевыбрать (как-нибудь в другой раз). Насколько знаю это первый твердотельный кубик для 8080. Надеюсь кто-нибудь соберется и сделает лучше, мне интересно было бы глянуть на подобную твердотельную вращалку для любого компа с 8080 (или 8085), не только для вектора.
1. Вращение:
Курсор влево, вправо - изменение угла прецессии
Курсор вверх, вниз - изменение угла нутации
F1/F2 или 'диагональная стрелка'/СТР - изменение угла собственного вращения. В emu и VV 'диагональная стрелка' - Home. В emu СТР - Page Up, в VV - End.
TAB - исходное положение (без изменения размера). Для приведения в исходное положение с исходным (максимальным) размером можно использовать рестарт (БЛК+СБР на реале, F12 в эмуляторах).
ЗБ (BackSpace в эмуляторах) - фиксирует текущее положение.
2. Изменение соотношения сторон:
'1' (по умолчанию) - PAR=5:4 (если точнее, то 59:48) соответствует реалу. Из эмуляторов это соотношение сторон поддерживает Emu80.
'2' - PAR=1:1, т.е. без коррекции
3. Изменение размера - F4/F5
Зря ты так на себя наговариваешь. Слева и справа полно места для какой-нибудь попсовой надписи. Добавить еще музон и получится гениальная интра. Цвета тоже необязательно БКшные сохранять, можно выбрать чего-нибудь помягче.
Артефактов не так много, но они все же портят впечатление. RGB цвета сделал для теста, для релиза можно будет подобрать что-нибудь поинтереснее.
Удалось почти полностью избавиться от артефактов. Не идеально, но намного лучше и еще и чуть быстрее.
Upd: Похоже в v2 удалось победить остававшиеся артефакты.
Я бы на твоем месте схоронился, допилил по мелочи и заслал бы на CAFe (https://events.retroscene.org/cafe2022). Время еще чуть чуть осталось - почти две недели.
Скажу честно - мне самому нравится эта фиговина, давно собирался и вот наконец сделал. Но бывалых демолюбов таким кубиком не удивишь, для соревнований надо что-то покруче.
Совсем необязательно. Это не только соревнование, а еще и туса и шоу. Твой кубик очень даже тусовочно-шоунячий, вот только надо музон и какие-нибудь буковки.
Еще одна возможность (которая вряд ли кого-то удивит, но все же) - можно вместо сплошной заливки использовать произвольные паттерны. Это конечно замедляет, но более-менее шевелится.
- - - Добавлено - - -
Расцветил остальные объекты, но с тетраэдром проблема - нельзя тремя цветами раскрасить его так, чтобы любые две смежные грани были разных цветов. Мне так не нравится, придется его отключить в солидной вращалке.
PAR=5:4 (если точнее, то 59:48) соответствует реалу. Из эмуляторов это соотношение сторон поддерживает Emu80.
Поясни, пожалуйста, откуда взялось 59:48 (~1,229)? В Emu80 используется близкое значение 27:22 (~1,227), и его я могу теоретически обосновать (если кратко, то 288*2/3*4*13.5/704/12, при необходимости поясню).
Pyk, вопрос с мелкими различиями расчета PAR мы уже довольно подробно обсуждали (еще раз возвращаться к этой теме у меня сейчас нет моральных сил). Возможно это было не про вектор, но это точно было про emu80, к сожалению не помню в какой теме было обсуждение.
ivagor, вроде бы действительно когда-то обсуждали, но соотношение 59:48 в памяти не отложилось. Ладно, оставим пока, тем более, что тоже навскидку не нашел то обсуждение, да и не критично это - разница в пару пикселей на экран... Будет время - поищу...
Вращалка 3D-объектов с заливкой. Цветов в итоге не 3, а 7, поэтому все раскрасилось без соседства одинаковых граней и не пришлось выкидывать никакие объекты. Текущая раскраска возможно выглядит аляповато, зато все цвета на экране (в октаэдре).
Upd 14.10.2022: Добавил выбор паттернов заливки и палитр, немного ускорил.
Проблемы в эмуляторах:
1. В Emu80 для переключения паттернов нужно
1.1. В настройках эмулятора выбрать раскладку qwerty или йцукен
1.2. Выбрать в windows английскую раскладку клавиатуры
Только при соблюдении обоих условий Emu80 будет правильно реагировать на комбинации CC (LShift)+...
2. Сложности с адекватным отображением несплошных паттернов в некоторых эмуляторах. Хуже всего в v06x, лучше всего в Emu80 (но в нем надо настраивать клавиатуру для правильного переключения паттернов). В Emu и VV нормально, если сделать размер окна побольше или установить квадратное окно. В v06x при увеличении размера окна тоже становится лучше.
Доработал крутилку (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1164768&viewfull=1#post1164768).
parallelno
15.10.2022, 09:43
ivagor, классно! понравился вариант с монохромным шейдингом. прям как затенение. и прикольно придумал сделать backbuffer из половинок экрана! хитро. возьму на вооружение :)
прикольно придумал сделать backbuffer из половинок экрана
Это придумал Сергей Ермолаев (SES). Он использовал в деме и описал в электронном журнале, а потом и я использовал и PPC.
А что не так с паттернами в v06x? Я попробовал с nop и с crt-lottes, оба смотрятся хорошо.
1. В Emu80 для переключения паттернов нужно
1.1. В настройках эмулятора выбрать раскладку qwerty или йцукен
1.2. Выбрать в windows английскую раскладку клавиатуры
Есть такое, хотя на самом деле в режиме Smart-раскладки не работает только Shift-2, остальные комбинации (1,3,4) работают (это из-за того, что символ "@" на двойке на клавиатуре Вектора набирается без СС).
Я попробовал с nop и с crt-lottes, оба смотрятся хорошо.
Если не нравится только мне, то это хорошо.
остальные комбинации (1,3,4) работают
У меня 3,4 со smartом не работают.
Если не нравится только мне, то это хорошо.
Может быть я не нашел какую-то комбинацию паттерна, шейдера и разрешения. Ты уточни все-таки, что не так?
Степень "плохости" штука субъективная, уточнить сложно. Если перевести в техническую плоскость, то фильтрация изображения в эмуляторе нужна (отключаемая), также как и фильтрация звука и практически по той же причине. Но имеющиеся в v06x шейдеры меня не устроили, хотя один из них (кажется crt) немного улучшал ситуацию. Все ведь относительно, мне субъективно больше нравится фильтр в Emu80, в Emu вроде несколько хуже (надо бы уточнить, уже забыл), в VV кажется фильтра нет, но можно в меню выбрать квадратное окно (что тоже решает проблему с паттернами, а проблема с PAR там через меню все равно не решается). В v06x не знаю как задать цифрами размер окна и выбор фильтров (для меня) не решает проблему.
Кстати вопрос. Сначала хотел повесить комбинацию на РУС/ЛАТ+..., но не нашел в v06x где это на клавиатуре (хотя на экранной клавиатуре мышкой можно нажимать, но это слишком своеобразно).
Шейдер nop -- это простой nearest neighbour. Не знаю, как можно сделать еще меньше фильтра. Но конечно набор шейдеров в v06x не исчерпывающий, а пропорции менять произвольно нельзя.
Кстати вопрос. Сначала хотел повесить комбинацию на РУС/ЛАТ+..., но не нашел в v06x где это на клавиатуре (хотя на экранной клавиатуре мышкой можно нажимать, но это слишком своеобразно).
F6. Надо бы сделать тултипы к экранной клавиатуре.
Шейдер nop -- это простой nearest neighbour.
В этом я не сомневаюсь, но в комплекте к nearest neighbour мне нужна возможность задания кратных векторовскому разрешению размеров окна. А для некратных другой фильтр.
F6
Вот это бы я долго еще искал
Вот это бы я долго еще искал
Понимаю. Я даже записал себе ишшуй по этому поводу ;) Чтобы не забыть, когда будет очередной запал допиливать эмулятор. (Изначально был задуман левый альт, но он был принесен в жертву на алтарь кроссплатформенности).
P.S. кастом aspect ratio тоже записал
У меня 3,4 со smartом не работают.
Может быть, раскладка была русская? На английской раскладке windows должны работать 1,3,4, на русской - 1,2...
Но лучше в данном случае действительно не заморачиваться и просто включить qwerty.
Вращалка 3D-объектов с заливкой.
Заливай на ютуб, пожалста)
Может быть, раскладка была русская? На английской раскладке windows должны работать 1,3,4, на русской - 1,2...
Да, только уточню, что при smart+rus LShift+2 нормально не работает, т.к. одновременно переключает и паттерн заливки и PAR.
Заливай на ютуб, пожалста)
С этим сложно. Могу рекомендовать онлайн-эмулятор (https://svofski.github.io/vector06js/) svofski, туда можно дропнуть rom или даже zip (тогда еще надо выбрать rom слева). Но, конечно, у варианта с эмулятором есть недостаток, придется почитать readme с описанием управления и нажимать клавиши.
В октябре состоится "CAFePARTY 2022".
В конкурсах допускается участие разных ретро-платформ, в том числе и "Вектор-06Ц"
https://cafeparty.org.ru/2022/compos-and-rules/
Приглашаются мастера ассемблерного слова, умельцы алгоритмических трюков и другие свободные художники.
Все залили свои шедевры? Уже совсем пора.
metamorpho
21.10.2022, 19:42
Все залили свои шедевры? Уже совсем пора.
Хотел поучаствовать в 256b Intro. Было 3 идеи - они в разной степени были реализованы, но в итоге всё упиралось в то что не получалось поместить в 256 байт то что планировалось. И одну за другой я оставлял их. А в версиях, где не реализованы все фишки которые задумал, ничего интересного нет.
Формат 256b Intro с одной стороны привлекает своей идеей втиснуть в такой размер что-то "невозможное", а с другой стороны служит "ловушкой" - когда в итоге понимаешь что уместить свою идею в 256 байт не получится и приходится бросать уже почти созданный код.
Хотел поучаствовать в 256b Intro. Было 3 идеи - они в разной степени были реализованы, но в итоге всё упиралось в то что не получалось поместить в 256 байт то что планировалось. И одну за другой я оставлял их. А в версиях, где не реализованы все фишки которые задумал, ничего интересного нет.
Формат 256b Intro с одной стороны привлекает своей идеей втиснуть в такой размер что-то "невозможное", а с другой стороны служит "ловушкой" - когда в итоге понимаешь что уместить свою идею в 256 байт не получится и приходится бросать уже почти созданный код.
Ну там же есть и другие категории, не обязательно 256.
metamorpho
21.10.2022, 21:35
Ну там же есть и другие категории, не обязательно 256.
Идеи, которые я хотел реализовать, имеют смысл только если это 256 байт.
А в процессе реализации идей не хотелось быстро сдаваться, поэтому время уходило на создание и проверку "ста" различных вариантов прежде чем понимаешь, что ничего не выйдет. Вообщем когда с последней идеей тоже ничего не получилось,
то времени сделать что-то в других категориях уже не осталось.
Но конечно не всё так грустно - сам процесс поиска решения тех или иных задач - был специфичен (т.к. 256 байт)
и очень даже интересен и притягателен как магнит.
Я вообще не понимаю как для Вектора сайзкодить. Палитру выставишь не успеешь, уже половину ресурса съел :)
Napoleon1
22.10.2022, 12:27
Значит надо использовать ту, что запрограммирована начальным загрузчиком.
Значит надо использовать ту, что запрограммирована начальным загрузчиком.
Это вариант, но там получается весьма ограниченный выбор цветов тогда :)
Очень грубо и приблизительно можно оценить влияние наличия или отсутствия тех или иных фич на размер демы класса "около 256" на примере Моны:
Вектор - 333 байта
Специалист - 300 байт (не надо программировать палитру, но монохромная картинка; в пзу есть очистка окрана)
Искра1080 - 255 байт (в пзу есть рисование точки)
Для вектора можно ужать мону примерно в район специалиста, если ограничиться 2 цветами и в район искры, если сделать версию загружаемую в бейсик.
Одному пришлось отстаивать величие Вектора перед матерыми спектрумистами и бкшниками!
Компо (все работы):
https://events.retroscene.org/cafe2022/LowEnd_Demo
Oblitterated (2nd place): [retroscene (https://events.retroscene.org/cafe2022/LowEnd_Demo/2810)] [pouet (https://www.pouet.net/prod.php?which=92594)] [github (https://github.com/svofski/v06c-oblitterated)] [youtube (https://youtu.be/VBkojq3zIEU)]
vi52 second to none (3rd place): [retroscene (https://events.retroscene.org/cafe2022/LowEnd_Demo/2811)] [pouet (https://www.pouet.net/prod.php?which=92593)] [github (https://github.com/svofski/v06c-waveintro)] [youtube (https://youtu.be/e0L5pYa8nHA)]
Волны с рыбкой симпатишные, а в Max Headrooma я так и не врубаюсь. Спасибо за векторовский вклад в демопати!
parallelno
23.10.2022, 20:57
svofski, классные демки! А как ты волну делал?
svofski, классные демки! А как ты волну делала?
Спасибо!
Амплитуда туда-сюда баунсится + постоянное смещение, а начальная фаза инкрементится значением функции с краю предыдущего кадра. Могу слегка соврать, я уже месяца два назад это писал на самом деле. Но в общих чертах так.
metamorpho
23.10.2022, 22:16
svofski, бодренькие демки получились....это побуждает тоже написать демку....наверно надо уже сейчас начинать создание, а далее на подходящей демопати представить свой шедевр :)
svofski, загрузка конечно СУПЕР !!!! Это и на реальном Векторе и на эмуляторах одинаково работает ? И как это сделано ?
metamorpho, если у меня получилось пробудить аппетит, я считаю что не зря потратил время.
Загрузка, это ivagor сделал сверхскоростной загрузчик, а я приделал к нему начальный загрузчик с автозапуском, который перехватывает управление из стандартного. Сейчас чтобы этим воспользоваться вообще ничего не надо, достаточно просто запустить bin2wav.js (https://github.com/svofski/bin2wav) -m v06c-turbo myrom.rom myrom.wav На реале это должно без проблем работать (с обычными оговорками про провода, всякие девиантные параметры плееров на телефонах итд).
parallelno
24.10.2022, 05:10
svofski, извиняюсь за опечатку в предыдущем посте. А как ты определял какую часть волны нужно перерисовать/стереть?
Это и на реальном Векторе и на эмуляторах одинаково работает ?
На реале работает, проверяли KTSerg и svofski (https://www.youtube.com/watch?v=MPCPI_RYuyM) (там вариант еще без автозапуска). В эмуляторах и на девбордах типа DE1 работает чуть лучше, можно грузить даже со скоростью 13500, реал стабильно грузит 11700. Скорее всего можно и для реала улучшить, но это надо отлаживать только на реале (или если кто-нибудь сделает близкую к реалу эмуляцию поведения магнитофонного порта).
А как ты определял какую часть волны нужно перерисовать/стереть?
Идем слева направо. Вычисляем текущее значение функции. Из разницы с предыдущим значением в этой же координате считаем дельту и перекрашиваем только ее. Если стало выше -- рисуем, если стало ниже -- стираем. Фактически на каждом кадре меняется совсем немного пикселей на разделе вода-воздух, поэтому получается что как будто весь экран колбасит, а на самом деле рисуется всего-то ничего.
Про ускорение загрузки turbofm -- по-моему лучше не надо. Сейчас и так очень быстро и проверено на совместимость с разными реалами, а терять даже чуть-чуть надежности не хочется.
Можно ли в разы сократить 256-байтную демку? Иногда можно.
Возьмем для примера треугольник Серпинского (http://tenroom.ru/scalar/ware/106/index.html). Мне показалось, что 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 они выглядят как прямоугольники.
Заменил версию треугольника (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1169783&viewfull=1#post1169783) для режима 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)
Искра1080 - 255 байт (в пзу есть рисование точки)
Для вектора можно ужать мону примерно в район специалиста, если ограничиться 2 цветами и в район искры, если сделать версию загружаемую в бейсик.
С бейсиком действительно получилось перевести векторовскую Мону в категорию <=256 байт. Два варианта: для классического 2.5 (256 байт) и для новодельного 2.62 (255 байт).
Загрузка и старт одинаковые:
BLOAD"" (если грузить bin в отладчик, то с адреса 7000h)
A=USR(&7084)
На картинках можно увидеть некоторые допущенные послабления.
7831278313
В обоих версиях используются дефолтные цвета палитры, но на на мой взгляд это не стало проблемой даже в цвете (чем могут похвастаться далеко не все советские ретрокомпы), а уж в ч/б совсем хорошо. Дополнительно в версии для 2.5 пришлось пожертвовать кропом снизу.
Имея за спиной мощь бейсика оказалось не так уж сложно закрыть и другой гештальт - 64-байтный треугольник Серпинского для 06Ц.
Запуск и старт (и функциональность) версий для 2.5 и 2.62 одинаковые:
BLOAD"" (если грузить bin в отладчик, то с адреса 701Fh)
A=USR(&701F)
В отличие от Моны треугольник зацикленный, когда надоест на него смотреть для выхода в бейсик жмем БЛК+СБР (F12 в эмуляторах).
Больше фракталов хороших и разных. Кривая дракона (дракон Хартера-Хейтуэя) на основе программы (https://zx-pk.ru/threads/34857-kakuyu-iteratsiyu-krivoj-drakona-mozhno-napisat-na-48k-speke.html?p=1170215&viewfull=1#post1170215) С.Телицына из ZX Review 5-6/1997. Переделал (полностью переписал) для 8080, оптимизировал по размеру - уложился в 126 байт с использованием бейсиков 2.5 и 2.62. Доработал: добавил рисование первого шага, добавил регулировку длины шага, увеличил разрядность счетчика вдвое (теперь максимальный порядок 16). На картинке 13й порядок, тут (https://zx-pk.ru/threads/34857-kakuyu-iteratsiyu-krivoj-drakona-mozhno-napisat-na-48k-speke.html?p=1170359&viewfull=1#post1170359) еще 8, 11 и 15.
Загрузка и запуск:
BLOAD""
A=USR(&7000)
После непродолжительного рисования выходит в бейсик.
Мона симпатичнее дракона, дракон симпатичнее треугольников, но и размеры распределились соответственно.
Все вместе было бы крутое мегадемо =)
Эклектичная мегадема на 512 байт. Можно и дракона сильнее раскрыть - нарисовать драконов разных порядков в разных плоскостях и переключать. На 6128 так можно даже короткую анимацию запилить. Возможностей много, все пути открыты.
Подскажите, а сколько цветов палитры реально поменять от строки к строке?
Один точно можно, вот пример (http://tenroom.ru/scalar/ware/32/index.html) (в части с летучей мышью). Вероятно можно и два, но это желательно протестировать на реале.
Это связано с низкой скоростью CPU? Или с тем, что палитру можно менять только в каких фиксированных положениях луча?
Программируется тот цвет, что сейчас под лучом в битмапе. Надежней всего когда это бордюр. Очень трудно сочинить такую картинку, где цвета переключаются посередине экрана. Это практически безнадежно для конверсий. Но для творчества тут непаханое поле.
Это связано с низкой скоростью CPU? Или с тем, что палитру можно менять только в каких фиксированных положениях луча?
Сочетание этих двух факторов - "сбоку" есть зоны, где нельзя изменить палитру ну и процессор не такой быстрый, чтобы в оставшееся время много успеть. svofski еще пишет про возможность изменить палитру в активной области и в демах это используется, но для конверсий картинок я бы не стал на это рассчитывать. На реале еще будет побочный эффект в виде светлых или темных (в зависимости от инверсности подключения) точек. А вот менять (на бордюре) один цвет для каждой строки для конверсий было бы полезно. Скорее всего там можно практически полностью спрятать изменения цвета бордюра в невидимой области. Для максимального упрощения меняться должен всегда один цвет и желательно нулевой (хотя это не обязательно).
Dec, пользуясь случаем выскажу пожелание добавить в конверсии векторовский режим 512x256. Конечно можно использовать Common, но у вектора есть особенность - можно задать разные палитры для четных и нечетных точек. Т.е. фактически на экране в этом режиме может быть от 4 до 7 цветов.
Вот мой старый эксперимент с полуручной конверсией, тут 33 цвета, фото с ЭЛТ. Не могу отыскать собственно код, но в нем тут невелика ценность. Самое интересное это найти или нарисовать собственно картинку, которая в таком режиме будет выглядеть интересней, чем без него.
https://farm5.staticflickr.com/4652/39232615254_d80e38fc23_z.jpg (https://flic.kr/p/22LRpEW)
Сочетание
Хотелось бы немножко подробностей. Вот есть у нас строка:
Бордюр Изображение Бордюр
|----------|------------------------------------------|----------|
A B C D
В какой момент происходит переключение цвета? В момент C? Сколько циклов/тактов составляет AB и CD? Какой код фактически используется для переключения цвета палитры?
добавить в конверсии векторовский режим 512x256
Мои требования стандартные: спецификации выходного формата + пример файла в этом формате.
можно задать разные палитры для четных и нечетных точек
Честно говоря, не вижу полезности этой особенности в контексте автоматической конвертации.
"Зоны непрограммируемости палитры" недостаточно документированы. На своем 06Ц я их определял и выкладывал, а Ramiros реализовал эту фичу в VV. Но у меня (как и у подавляющего большинства современных вектористов) была доработка синхры для совместимости с современными ТВ и насколько могу судить она влияет на "зоны непрограммируемости". Просто для ориентира что у меня получалось (в активных строках, вверху и внизу все иначе):
из 192 тактов строки: 128 - изображение, потом 24 такта можно программировать, потом 12 нельзя, потом 28 - можно. Конкретный код сейчас не приведу, надо выверять по тактам, может у svofski остались исходники.
Если без учета четных/нечетных точек, то проще конвертить как Common RGB332, сохранять в bmp, показывать на векторе bmp и при необходимости сохранять дамп видеоозу или его части. И, кстати, стандартных форматов для 512 на векторе нет.
стандартных форматов для 512 на векторе нет
Вот по этому я и прошу определиться с выходным форматом. Если писать в виде дампа, то пусть будет в виде дампа, мне не принципиально. Куда писать палитру? Мне нужны четкие инструкции.
parallelno
13.01.2023, 19:30
Dec, инструкции, явки, пароли... :) По ссылке ниже на первой странице есть раздел про палитры. Там приведены куски кода как менять палитру. Надеюсь поможет.
https://zx-pk.ru/threads/34480-programmirovanie.html
Насчет формата для 512. Проще всего дополнить формат Рембрандта (тем более он уже поддержан в DaDither) - там размер по X в байтах, поэтому можно без проблем использовать старший бит для индикации режима (0-256, 1-512). Осталось сделать примеры в таком формате. Насчет себя пока не уверен, если вдруг кто соберется - только за.
svofski выложил бинарник (у меня он откуда-то уже был) - отличный пример/шаблон для мультиколорного просмотрщика. На реале, насколько понимаю, проверен. И не портит бордюр.
"Зоны непрограммируемости палитры" недостаточно документированы. На своем 06Ц я их определял и выкладывал, а Ramiros реализовал эту фичу в VV. Но у меня (как и у подавляющего большинства современных вектористов) была доработка синхры для совместимости с современными ТВ и насколько могу судить она влияет на "зоны непрограммируемости". Просто для ориентира что у меня получалось (в активных строках, вверху и внизу все иначе):
из 192 тактов строки: 128 - изображение, потом 24 такта можно программировать, потом 12 нельзя, потом 28 - можно. Конкретный код сейчас не приведу, надо выверять по тактам, может у svofski остались исходники.
Код из эмулятора VV определяющий зоны програмируемости палитры:
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(CCMapX>=180))then ColPal(BrdCode2,A);
- - - Добавлено - - -
"Зоны непрограммируемости палитры" недостаточно документированы. На своем 06Ц я их определял и выкладывал, а Ramiros реализовал эту фичу в VV. Но у меня (как и у подавляющего большинства современных вектористов) была доработка синхры для совместимости с современными ТВ и насколько могу судить она влияет на "зоны непрограммируемости". Просто для ориентира что у меня получалось (в активных строках, вверху и внизу все иначе):
из 192 тактов строки: 128 - изображение, потом 24 такта можно программировать, потом 12 нельзя, потом 28 - можно. Конкретный код сейчас не приведу, надо выверять по тактам, может у svofski остались исходники.
Код из эмулятора VV определяющий зоны програмируемости палитры:
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(CCMapX>=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, круто, особенно если ориентироваться на результат как на нижней картинке с воздушными шарами.
parallelno
15.01.2023, 22:11
Dec, крутотень! А можно ещё примеров с портретами, пожалуйста?
А можно ещё примеров с портретами
Так можно просто скачать программу и поиграться самостоятельно с любыми картинками. Денег за это я не беру.
Dec, пожелание добавить для вектора (в целом, и без построчных изменений палитры и с изменениями) опцию Fixed Black (или как-то в этом духе). При включении этой опции один цвет (желательно нулевой) всегда будет черный, и остаются 15 цветов, которые можно переопределять. Для эмуляторов это не особо нужно, а вот для реалов (без переделки для реализации уровня черного) думаю будет полезно.
добавить для вектора (в целом, и без построчных изменений палитры и с изменениями) опцию Fixed Black (или как-то в этом духе). При включении этой опции один цвет (желательно нулевой) всегда будет черный, и остаются 15 цветов, которые можно переопределять.
Это уже можно сделать двумя способами.
1) Выбрать Palette mode в значение Custom, после этого ткнуть на кнопку Edit, в появившемся окне мышкой ткнуть черный цвет в левом верхнем углу. В такой конфигурации в палитре всегда будет черный цвет, и он будет нулевым.
2) Создать pal файл с палитрой из одного черного цвета, открыть его в программе, и выбрать его в списке Fixed palette.
для реалов (без переделки для реализации уровня черного) думаю будет полезно
А в чем суть этой полезности?
А в чем суть этой полезности?
Вектор не умеет делать врезку порожка "чернее черного", поэтому реалы без доработки могут показывать рваную картинку при меняющемся бордюре.
Но вообще было бы интересно посмотреть на практическую реализацию просмотрщика. По идее за промежуток от точки 256 до точки 0 следующей строки надо успеть выбрать индекс цвета бордюра, записать его, сбросить индекс цвета бордюра на старый. Довольно много операций для Вектора-06ц.
- - - Добавлено - - -
P.S. забыл сказать -- картинки смотрятся очень круто. Особенно воздушные шары.
Вектор не умеет делать врезку порожка "чернее черного", поэтому реалы без доработки могут показывать рваную картинку при меняющемся бордюре.
Ничего не понял. А можно простыми словами для людей очень и очень далеких от железа и понимая принципов формирования видеосигналов.
С большой вероятностью (смотря какие цвета на бордюре) картинка на телевизоре будет нестабильная. Или будет дергаться или м.б. искажение цветов.
А что определяет какие цвета на бордюре?
У вектора номер изменяемого цвета в палитре - это еще и номер цвета бордюра.
Т.е. при формировании картинки со сменой палитры каждую строку при смене цвета индекса, который соотнесен с бордюром, также поменяется и цвет бордюра?
В самом простом случае, да. Может быть можно успеть поменять индекс бордюра, сменить цвет палитры и поменять индекс бордюра обратно.
поменять индекс бордюра обратно
Только нужно, чтобы в палитре был черный цвет, на который можно поменять обратно.
Только нужно, чтобы в палитре был черный цвет, на который можно поменять обратно.
В конце концов с грехом пополам все Векторы показывают картинку начального загрузчика на синем фоне с синим бордюром. Если загонять себя в рамки немодифицированного Вектора, то вообще непонятно где проводить черту. С моей точки зрения Вектор как с завода вообще картинку показывать не умеет.
Рекомендации (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1170696&viewfull=1#post1170696) для фиксации черного работают в 256x256x4, но не в 256x256x4 Scanline - в этом режиме не вижу средств для кастомизации палитры.
06Ц с завода должен был показывать в цвете на каком-то из мониторов того времени. Для работы со старыми цветными ТВ достаточно было добавить инверсию. В .02 как раз добавили инверсию и (в какой-то мере) уровень черного, т.е. .02 уже был практически нормальный (для своего времени).
Насчет синего бордюра:
1. Он сравнительно темный
2. Он не меняется от строки к строке
Синий бордюр в нескольких ранних программах (например в бейсике и тесте устройств) и игрушках с драйверами устройств.
В тесте техпрогона бордюр в основном красный, кроме моментов, когда он разноцветный.
В pairs (игрушка портирована в 1989) зеленый бордюр.
Возможно все это не так уж важно и критично.
Если плюнуть на теоретические проблемы с уровнем черного и на эстетику (пусть будет полосатый бордюр), то проблем совсем нет.
Если плюнуть на теоретические проблемы с уровнем черного и на эстетику (пусть будет полосатый бордюр), то проблем совсем нет.
Я предлагаю сначала плюнуть, а там уже поискать пути к совершенству.
не в 256x256x4 Scanline - в этом режиме не вижу средств для кастомизации палитры.
Когда я делал этот режим я еще не знал, как у Вектора все так сложно и запутанно с цветами. В следующей версии добавлю галку Fixed black. Эта опция требует много переделок а алгоритме.
Есть простой, но не очень изящный вариант - ограничить число цветов в каждой строке до 15, а 16й (лучше 0й) цвет оставить только для бордюра.
Пробный подход к процедурам просмотра spr+pals с изменением одного (kitten50) и двух (bab51) цветов в строке.
7834678348
Скриншоты из VV, при включении эмуляции зон непрограммируемости работоспособность сохраняется. В эмуляторах отличаются не только палитры (при конверсии использовал палитру Linear), но и смещение цвета при программировании палитры. В vv и v06x примерно одинаково, в emu80 чуть отличается (или это особенности масштабирования, которые я не победил), в emu сильно отличается.
Обалденно смотрится! Мандрил вообще как живой. По моим подсчетам получается 54 цвета. Dec и ivagor, респект!
Decу несомненно респект.
В картинках должно быть (и ирфан говорит что есть) 50 цветов в котенке и 51 в мандриле. 51 в vv, в других эмуляторах может быть 54. А 50 везде должно быть 50.
Что касается просмотрщиков. Если вдруг "одноцветный" не заработает на реале, то его точно можно подстроить, исходник в помощь. С "двухцветным" сложнее, но я сделал все что мог, за счет xor там достигается максимальная скорость изменения цветов, эмуляторам хватает и есть небольшой запас для подстройки.
Decу несомненно респект.
В картинках должно быть (и ирфан говорит что есть) 50 цветов в котенке и 51 в мандриле. 51 в vv, в других эмуляторах может быть 54. А 50 везде должно быть 50.
Пересчитал заново, получилось 51 в мандрилле, все сошлось. Давай еще картинок =)
Ты сам писал, что надо искать подходящие картинки, могу только согласиться. Вероятно должны подходить пейзажи (сверху небо, внизу что-то не синее), восходы, закаты. Возможно Dec еще заборет полосатость, которая проявляется в некоторых конверсиях.
есть небольшой запас для подстройки
А этого запаса не хватит на третий цвет?
- - - Добавлено - - -
Еще можно вместо конструкции
pop de: ld a,e: out 2: xor d: out 0Ch
использовать
pop af: out 2: pop af: out 0Ch
Такты вроде те же, но не требует bc/de/hl.
А этого запаса не хватит на третий цвет?
К сожалению нет. Можно ограничить полезную ширину картинки и использовать часть активной области для третьего цвета.
Еще можно вместо конструкции
pop de: ld a,e: out 2: xor d: out 0Ch
использовать
pop af: out 2: pop af: out 0Ch
Использование xor (при желании можно заменить на add или sub) позволяет обеспечить минимальное возможное время между первым и вторым out 0Ch. Нужно ли это для реалов - пока не могу сказать с полной уверенностью, но это максимально гибкий вариант, обеспечивающий наибольшие возможности настройки.
Можно ограничить полезную ширину картинки
А сколько третий цвет съест от полезной ширины? А четвертый?
Третий съест минимум 8 точек, каждый следующий - еще минимум по 32 точки (по 16 тактов). Речь о точках в режиме 256. И скорее всего получится медленнее, т.к. регистров не хватает.
Только нужно, чтобы в палитре был черный цвет, на который можно поменять обратно.
Наверное можно попробовать прогнать первую палитру через что-либо такое, сравнивая получившиеся от 0 до 17 уровни.
ClrLum:
push b
mov b,a
ani 111B
mov c,a
mov a,b
rrc
rrc
rrc
ani 111B
add c
mov c,a
mov a,b
rlc
rlc
ani 11B
add c
pop b
ret
Найти индекс с самым минимальным и использовать его как индекс цвета бордюра, надеясь что он не станет сильно ярче (или вообще не поменяется) в следующих далее палитрах.
;DrkBrd Set border to darkest color in palette
;INPUT <HL> = 16-byte palette address
;OUTPUT [Border] becomes index of darkest color in palette
DrkBrd: lxi b,10FFh
DrkB01: mov a,m
call ClrLum ; <A> is guaranteed to be [0..11h]
cmp c
jnc DrkB02
mov c,a
mov e,b ; 16 - index
DrkB02:inx h
dcr b
jnz DrkB01
mvi a,10h
sub e
jmp SetBrd
Если в картинке отсутствует чёрный, то бордюр будет каким-то из тёмных цветов (в Robotz в меню опций бордюр вышел тёмно-синим). По нормальному, надо ещё разную яркость компонент с одним уровнем учесть.
В пределе можно пробежать по всем палитрам, найти minimum minorum, замутить его с частотой изменений и выбрать индекс самого тёмного цвета с наименьшей частотой изменений.
Можно ещё "нормализовать" биты изображения так чтобы нулёвой индекс палитры всегда получался наиболее тёмным. Но это наверное при конверсии удобнее делать.
Восемью точками можно было бы пожертвовать ради многоцветия. Даже 40 точками во многих случаях, если котенок все еще влезает в кадр на фоне заката.
Можно ещё "нормализовать" биты изображения так чтобы нулёвой индекс палитры всегда получался наиболее тёмным. Но это наверное при конверсии удобнее делать.
Это поведение DaDither по умолчанию.
- - - Добавлено - - -
Третий съест минимум 8 точек, каждый следующий - еще минимум по 32 точки (по 16 тактов).
А где будут находится съеденные точки? Справа/слева? Можно ли часть справа, часть слева?
PPC, если посмотреть например MultiColor1, то исходно в spr 0й цвет - черный. Теперь смотрим pals - и там 0й цвет активно меняется на нечерный.
Что касается обмена ширины картинки на цвета можно посмотреть сюда (http://tenroom.ru/scalar/ware/770/index.html). Каждый столбец - смена цвета или 32 точки. Скорее всего можно поменять еще один цвет сбоку.
А где будут находится съеденные точки? Справа/слева? Можно ли часть справа, часть слева?
Или справа в предыдущей строке или слева в текущей. Или можно поделить.
PPC, если посмотреть например MultiColor1, то исходно в spr 0й цвет - черный. Теперь смотрим pals - и там 0й цвет активно меняется на нечерный.
То что он будет меняться-это понятно, я об этом писал. Если в общем случае меняется "активно", то надо пробежать по всем палитрам, построить таблицу из индексов наиболее тёмных и использовать её. Ясно, что могут встретиться палитры, где чёрного не будет вообще. Но артефактов цветовых на бордюре станет меньше. Хотя мне лично нравится как сейчас, с полосами. Просто не уверен что каждый телек такое потянет.
Если в общем случае меняется "активно", то надо пробежать по всем палитрам, построить таблицу из индексов наиболее тёмных и использовать её.
Технически это возможно если меняется 1 цвет в строке, при двух уже не хватит времени. И все равно бордюр будет полосатый. На мой взгляд надо или делать черный бордюр или плюнуть на полосатость, полумеры не очень нужны.
делать черный бордюр
Я пока немного занят, но примерно недели через 2 я вернуть к DaDither. Будут добавлены три варианта использования палитры:
1) 16 цветов. Для формирования изображения используются 16 цветов на выбор программы.
2) Черный + 15 цветов. Для формирования изображения используется фиксированный черный и 15 цветов на выбор программы.
3) 15 цветов. Для формирования изображения используются 15 цветов на выбор программы, самым первым цветом палитры будет фиксированный черный.
В общем на любой вкус и цвет. Также я бы хотел реализовать 3 и 4 изменяемых цвета, но мне нужно понимать, где в изображении будут съеденные столбцы. В идеале симметрично по краям.
Фиксированный черный было бы хорошо.
Что касается регулировки числа изменяемых цветов, то лучше просто увеличить диапазон изменения до 8 (больше точно не получится). А ширину картинки можно оставить на откуп тому, кто делает конверсию, он должен сделать картинку меньше 256 точек в ширину и DaDither дополнит ее черным бордюром, как сейчас реализовано.
оставить на откуп тому, кто делает конверсию, он должен сделать картинку меньше 256 точек в ширину
Не доверяю я столь серьезный вопрос незнакомым людям :) Я вижу доп функциональность в виде отдельных режимов вида 248x256, 216x256, ... при этом программа будет создавать обычные spr файлы + pals файл.
К тому же
полумеры не очень нужны.
А нельзя режим "без столбца сбоку" эмулировать, добавив черный столбец сбоку в исходной картинке?
А нельзя
Если вопрос ко мне, то я его не понял.
Если вопрос ко мне, то я его не понял.
Вопрос ко всем активно участвующим, но больше наверное к ivagor-у, потому что это больше затрагивает отображение на Векторе. Зачем делать какую-то специальную поддержку альтернативных размеров, если можно просто оставить черный столбец в исходной картинке 256х256? В чем будет приницпиальное отличие такой конверсии от конверсии с доп функциональностью в виде отдельных режимов вида 248х256 итд.. ? Если ни в чем, то эксперимент можно начать, не дожидаясь новых фич в DaDither.
А нельзя режим "без столбца сбоку" эмулировать, добавив черный столбец сбоку в исходной картинке?
Если итогом будет картинка 256x256, то это даст тот же результат, что и дополнение черным бордюром в DaDither. Тоже собирался написать про этот вариант, но отвлекся.
вижу доп функциональность в виде отдельных режимов вида 248x256, 216x256, ... при этом программа будет создавать обычные spr файлы + pals файл.
Не понимаю, зачем жесткие ограничения, если можно сделать гибко. И spr - это только 256x256, там задание размеров не предусмотрено.
- - - Добавлено - - -
Дополню про формирование картинки в DaDither. Для повышения удобства можно было бы предусмотреть генерацию полос нужного цвета сбоку и тогда жесткая связка ширины и числа изменяемых цветов приобретала бы смысл. Но тогда кто-то должен заранее написать векторовский просмотрщик и сказать, где генерировать служебные полоски в изображении. В любом случае лучше чтобы это было опционально.
И spr - это только 256x256
Spr файл будет по факту 256x256, но с черными полосами. И я хочу узнать их размеры.
Эффект огня для вектора есть в SKYNET, правда там довольно неспешно. Сделал крупноблочно, зато большая площадь и пободрее (13-15 FPS).
Upd: Добавил версию с потрескиванием.
Upd 2: Уменьшил интенсивность потрескиваний.
Ну приделай же какой-нибудь текст и картиночку, стань демосценером =)
Если была бы картинка и текст, возник бы следующий вопрос - а где музыка? Я не против всех этих вещей, превращающих демонстрацию технологии в нечто более художественное, но сам не рисую (никогда не рисовал) и не пишу музыку (очень давно), а заимствовать не очень хочется без крайней необходимости. Элементом (извините) искусства выступают особенности реализации - "самая компактная и быстрая программа в нашей деревне". Но может со временем сделаю что-то менее сухое.
Можно звуковой эффект потрескивающих дров, или протекающего газопровода.
Элементом (извините) искусства выступают особенности реализации - "самая компактная и быстрая программа в нашей деревне".
Из всех искусств для нас важнейшим является оптимизация.
svofski, хорошая идея с потрескиванием, добавил (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1171476&viewfull=1#post1171476) пробный вариант.
PPC, и size coding!
добавил пробный вариант
Стало уютно.
Слишком сильно трещало, сделал поменьше, вроде так лучше.
Полностью переделал в DaDither алгоритм формирования картинки для режима со сменой палитры между строками. Субъективно стало сильно меньше левых полосок, хотя они по прежнему попадаются. Буду думать еще. Добавил возможность выбора использования фиксированного черного в первой позиции палитры.
Спасибо за доработки, полосатость в картинке пока не тестировал, а вот фиксированный черный попробовал.
78446
Это максимум убирания полосатости бордюра, который получился при сохранении перепрограммирования одного цвета (и при включении эмуляции зон непрограммируемости в VV). В emu и v06x картина примерно аналогичная, а emu80 показывает больше бодюра, поэтому там видно больше полосатости слева и еще и справа. На реале все будет зависеть от конкретного телевизора/монитора и его настроек.
Upd: v2 - убрал полосатость справа в emu80 (в других эмуляторах без изменений), убрал черточку внизу справа.
Upd2: Добавил альтернативный вариант, который программирует палитру не сразу после зоны непрограммируемости, а непосредственно до. В emu, v06x и vv цветных полосок на бордюре не видно, в emu80 (и скорее всего на реале) видны цветные полоски справа.
Это максимум
А почему вообще бордюр имеет полосы, если в палитре нулевой цвет всегда черный?
А маленькая черная полоска в правом нижнем углу - это картинка такая или какая-то специфика вывода изображения?
Немного доработал - убрал полосатость справа в emu80 и черную полоску в правом нижнем углу.
А почему вообще бордюр имеет полосы, если в палитре нулевой цвет всегда черный?
Чтобы поменять цвет палитры нам надо записать его номер в порт 2, по совместительству это цвет бордюра. Т.е. цвет бордюра черный, потом резко меняем его на номер из pals, меняем содержимое палитры, потом резко обратно черный. Сдвинуть еще влево мешает зона непрограммируемости, а сдвигать вправо нет смысла, т.к. цветная полоска на бордюре станет шире.
На всякий случай - на реалах возможно потребуется дополнительная подстройка.
- - - Добавлено - - -
Добавил альтернативный вариант. В 3/4 эмуляторов полос на бордюре не видно, это максимум возможного.
В v06x с crt-lottes смотрится очень лампово. Сделай другие примеры так же, с мячами была красивая картинка. Лена тоже чего-то давно не заходила.
Лена так себе получается, хотя полосатость (в картинке, тут я не про бордюр) уменьшилась, прогресс есть. Нужны подходящие картинки, типа которых Dec постил в качестве примеров.
Надеюсь, эмуляторами дело не ограничится, и кто-нибудь проверит на реале.
Нужны подходящие картинки
На мой взгляд конверсии фотографий природы получаются неплохо. На них не так заметны косяки алгоритма конвертации.
https://en.wikipedia.org/wiki/The_Son_of_Man#/media/File:Magritte_TheSonOfMan.jpg ?
В emu, v06x и vv цветных полосок на бордюре не видно, в emu80 (и скорее всего на реале) видны цветные полоски справа.
Протестировал в ve27: почти так же, как в emu80, только в v2 полоски слева чуть короче, а в альтернативном варианте справа - чуть длиннее, чем в emu80...
У среднестатистического телевизора ширина отображаемой области в районе 48 мкс или 288 LoRes точек при 6 МГц. Большинство эмуляторов столько и отображают, но есть нюанс - у реалов изображение смещено вправо (https://zx-pk.ru/threads/8739-vektor-06ts-videovykhod-podklyuchenie-k-tv.html?p=977593&viewfull=1#post977593) (Improver далее сделал доработку с центровкой). Поэтому я поменяю показания и склонюсь к мысли, что на большинстве телевизоров как и в большинстве эмуляторов alt вариант просмотрщика HAM1 не будет показывать цветные полосы на бордюре (они будут в невидимой области).
То что в emu80 показывается более широкая область это тоже хорошо (для других целей). Возможно стоит добавить настройку "широкий/узкий бордюр".
Возможно стоит добавить настройку "широкий/узкий бордюр".
В emu80 традиционно выводится видимая область в 52,148 мкс соответствии с современными цифровыми стандартами. Но для Вектора я почему-то отцентрировал активную область: возможно, решил ориентироваться на доработанный вариант или из каких-то других соображений - сейчас уже не помню. Может быть, стоит сместить вправо?
Идея ввести настройку "широкий/узкий бордюр" у меня была, но не совсем понятно, как именно ее реализовать. Все 52 мкс могут отображать, например, ТВ-тюнеры, с телевизорами же все неоднозначно. На старых ЭЛТ-телевизорах уменьшение ширины до 48 мкс можно объяснить форматом кинескопа 5:4, из-за чего исходное изображение 4:3 обрезалось по горизонтали. В современных же ТВ полный разброс. На моем, например, по вертикали выделяются 540 средних строк (видимо для удобства скейлинга до 1080), и пропорционально обрезается изображение по ширине. Где-то, как на приведенных выше фото improver'а (нашлись в web archiv'е), изображение обрезается меньше (или это был ЭЛТ?). Приходилось также на некоторых ТВ встречать настройку "overscan", которая управляет этой обрезкой...
Возможно стоит добавить настройку "широкий/узкий бордюр".
Для чего? Не получится случайно непонятная настройка, которая делает как должно (как будто), а не как было на самом деле, причем без возможности достоверно проверить?
В данном случае нет одного варианта, как было на самом деле. ТВ-тюнеры показывают 51-52 мкс, а (по крайней мере цветные) телевизоры (без целенаправленного вмешательства) - нет, причем и старые и новые. У старых знающий человек мог влезть в телевизор и попробовать накрутить ширину побольше (и не факт, что для произвольного ТВ получится это сделать малой кровью). В современных надо входить в сервисное меню, опять же надо знать - как, и остается вопрос - какие там пределы регулировки. Во многих старых ч/б ТВ и у некоторых мониторов были ручки регулировки размера и положения, тут вопросов нет. Мое субъективное мнение, что два варианта (48 и 51.2 или 52 мкс) ширины отображения позволили бы отобразить и типичный вариант и максимальный. По деталям можно спорить (хотя у меня желания нет), т.к. некоторые ТВ настроены так, что показывают 49 мкс, а некоторые - 47, лично мне, повторюсь, 48 кажется хорошим компромиссом.
- - - Добавлено - - -
Забыл написать для чего. 48 (+-) - типичный пользовательский вариант. 52 (или 51.2) - вариант для отладки бордюрных эффектов или посмотреть, как будет выглядеть на тюнере.
ТВ-тюнеры показывают 51-52 мкс
Если честно, мне не попадались показывающие меньше, чем полная ширина с запасом гашения (720 точек, 53,33 мкс). Но допускаю. что такие существуют.
48 кажется хорошим компромиссом
Надо подумать, перегружать эмулятор лишними не всем понятными настройками тоже не хочется. Может быть, какую-нибудь галку типа "overscan"... Да и еще вопрос возникает: что в режиме 48 мкс делать с высотой? Тоже пропорционально обрезать?
мне не попадались показывающие меньше, чем полная ширина с запасом гашения (720 точек, 53,33 мкс). Но допускаю. что такие существуют.
Вроде один из моих умел максимум 704 (52.1 мкс), но 100% уверенности сейчас нет.
Что касается не всем понятных настроек в emu80 это да, система настройки соотношения сторон (для меня) сравнительно сложная.
Чтобы сделать универсально, то от собственно эмулятора нужна просто текстура, которая показывает 100% кадра, включая все области синхронизации. А шейдер уже будет отрезать лишнее с краев. Тогда настройки шейдера можно вынести из основных опций, поскольку это фактически получаются настройки телевизора, а не эмулятора.
svofski, хорошая мысль, тоже подумал об этом, все равно буду пользовательские шейдеры прикручивать к эмулятору, соответственно и часть настроек перейдут туда...
Бездумно (зато очень быстро) переделал известный спековский пример (https://github.com/nagydani/lpfp/tree/master/raytracing) трассировки лучей для вектора с z80. Если делать специально для вектора, то несомненно можно получить намного более красивую картинку, хотя время рисования и так слишком долгое.
Upd: v2
1. Более быстрое умножение, время рисования на 10 секунд меньше (примерно 8:35 вместо 8:45)
2. На 512 байт короче
3. Порядок рисования изменен на построчный сверху-вниз
Бездумно (зато очень быстро) переделал известный спековский пример (https://github.com/nagydani/lpfp/tree/master/raytracing) трассировки лучей для вектора с z80. Если делать специально для вектора, то несомненно можно получить намного более красивую картинку, хотя время рисования и так слишком долгое.
А думно и для 8080 не планировал?
Думать не хочется. Насчет 8080 пока непонятно, что быстрее - переделывать версию z80 или написать с нуля для 8080.
Давай сразу в Бейсик-Корвет, чтобы 512х256 и красиво было =)
На бейсике было бы прикольно сделать, тем более там и плавучка готовая, но насколько медленно, сложно даже представить (размер картинки можно уменьшить). Интереснее все же для 2.5 и потомков, чтобы с полутонами. Если кто сделает, то я только за.
Можно сразу с труколорным дизером. На фоне трассировки лучей, дизеринг вряд ли займет много сил и времени.
Зачем сразу труколорный, ordered dither для яркости легко делается на ходу, пример - jpeg8080, там на фоне распаковки временем дизерения тоже можно пренебречь.
Заменил (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1189456&viewfull=1#post1189456) на слегка оптимизированный вариант. И определился - адаптировать для 8080 в данном случае проще, чем писать с нуля.
Глаза боятся, а руки делают. Психанул (в хорошем смысле) и за 1.5-2 часа переделал на 8080. Теперь на векторе безо всяких оговорок есть пример трассировки лучей. Рисует очень долго, примерно 12 минут 16 секунд.
Upd 26.11.2023: v2
1. Добавил подсчет и показ числа прерываний (в HEX), потраченных на расчет и рисование. Чтобы перевести во время преобразуем в десятичные и делим на 50.08
2. Оптимизировал.
v1: 8F8Fhex -> 733.85 секунды
v2: 7DFDhex -> 644.03 секунды
v2FastAddSub: 798Fhex -> 621.39 секунды
Версия FastAddSub дает чуть отличающуюся картинку, но она и на z80 дает отличающуюся картинку. Можно кстати глянуть здесь (https://github.com/DW0RKiN/Floating-point-Library-for-Z80), там 3 варианта и во всех этот элемент рисует чуть по разному.
Upd 29.11.2023: v3
Не стал разбираться, в чем особенности FastAddSub и сделал свои варианты сложения и вычитания с таблицами. Получилось быстрее и с полным совпадением по точности с нетабличными. Также ускорил умножение и некоторые другие вещи.
v3: 6303hex -> 505.25 секунды (8 минут 25.25 секунды)
Выложил исходник v1 (для TASM 3.2)
Upd 03.12.2023:
v4 (8080) - 6164hex -> 497.84 секунды (8 минут 17.84 секунды)
v4 (8085) - 5462hex -> 431.35 секунды (7 минут 11.35 секунды)
Воображение немного дорисовывает, но все же современный человек ожидает от RTX большего. Надеюсь со временем появится картинка побогаче, и желательно чтобы в полчаса укладывалась.
Источник света используется только для теней, а яркость определяется как тень ? черный : текстура, или 100% зеркало, правильно? Получается, что в такую модель полутона особенно некуда и вставить. В конкретно этот пример даже цвет не вставишь, потому что весь цвет тут -- это цвет пола и его же отражение.
Богатство недорого можно сделать из режима 512 точек.
Насколько я тоже понял, полутона отсюда малой кровью не получаются, поэтому вчера немного приуныл, но остается возможность оптимизации по скорости.
Заменил (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1189541&viewfull=1#post1189541) на оптимизированный вариант, там еще добавлено отображение числа прошедших прерываний, можно использовать в качестве бенчмарка супервекторов.
- - - Добавлено - - -
Переделка в 512 теоретически в рамках возможного, но опять же не малой кровью, я пас.
Попытка 512. Подвинул камеру немного ближе, увеличил область рисования с 256x192 до 320x256 и вот что получилось. Надо повышать точность вычислений, но время рисования и так уже 1049 секунд.
Да, неожиданные эффекты проявляются. Особенно интересно, как пол будто загибается кверху из-за алиасинга текстур. Вблизи так ну очень красиво.
Алиасинг вдали на мой взгляд не самый показательный, он и в 256x192 заметен. Если посмотреть на три картинки с тремя разными библиотеками плавучки по ссылке, которую раньше приводил, то чем больше бит в мантиссе, тем приятнее выглядит отражение пола в левом шаре. И если сравнить "свои" 256x192 и 320x256, то в 320 клетки в левом отражении чуть сильнее "погрызены".
Да, пожалуй погрызенность просто притягивает к себе ненужное внимание и замечаешь то, чего можно было бы и не заметить.
Пригляделся к тем трем картинкам - там и в правом шаре влияние числа бит мантиссы очень заметно. Получается для этой задачи динамический диапазон плавучки не так важен, как число бит мантиссы.
v3 для 8080 (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1189541&viewfull=1#post1189541) обогнал выложенный вариант для z80 (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1189456&viewfull=1#post1189456) (8:25 против примерно 8:35).
Ютуба (https://www.youtube.com/watch?v=rY413t5fArw), в которой затронуты некоторые ранее поднимавшиеся (и не поднимавшиеся) вопросы связанные с рейстрейсингом: бейсик (очень специфический для калькулятора с z80), полутона, С++ и асм на ez80. И там есть ссылки. Возможно кто-нибудь вдохновится и сделает что-нибудь рейтрейсинговое с оттенками для вектора.
Любителям изощрений версия трассировщика лучей для конфига Vector06c-smp Emu. Четные строки рендерит один проц, нечетные другой, соответственно работает в 2 раза быстрее v3 (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1189541&viewfull=1#post1189541) - 252.46 секунды (4 минуты 12.46 секунды).
Стоит отметить, что нельзя запустить конфиг smp дропнув rom в окно Emu (в этом случае запустится стандартный вектор). При старте Emu выбираем Vector06c-smp, потом для запуска программы надо использовать штатные для вектора способы. Проще всего выбрать через правую иконку Change External ROM, потом F2+F11, потом F12. В обычном конфиге работать будет, но нарисует только половину строк и не выведет время работы.
Немного оптимизировал вариант 8080 (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1189541&viewfull=1#post1189541), что позволило преодолеть границу 500 секунд. Добавил вариант 8085 для 6128, но там мало оптимизаций специально для 8085, основной выигрыш за счет более быстрого выполнения "старых" команд.
Гигачад-16 мог бы исполнять 16 параллельных рейтрейсеров.
При наличии продвинутой операционки, которая могла бы распределять задачи по ядрам, многопоточность имела бы смысл (при наличии еще и многопроцессорных векторов), но на одном проце накладные расходы на переключение контекстов вряд ли скажутся положительно.
Пятицветный (если с бордюром, то шестицветный) вариант. Область построения увеличена до 256x256, поэтому время расчета и построения больше, чем у двухцветного варианта (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1189541&viewfull=1#post1189541) - 625.96 секунды, или 10 минут 26 секунд. Если бы строил 256x192, то даже немного обогнал бы двухцветный. Во время рисования палитра из оттенков зеленого. Когда нарисует и напечатает результат можно менять палитру:
УС - оттенки зеленого
СС - оттенки желтого
РУС/ЛАТ - оттенки красного
Upd 17.12.2023: v2
Изменились только цифры времени прогона, картинки не стал менять.
74CE -> 597.08 секунд
Постепенно приближаемся к совершенству. Особенно ценно то, что сферы теперь не сливаются с небом. Мне пожалуй зелененький больше всех нравится. А почему ты не сделал как в бейсиковском варианте с красивыми цветами?
Предполагал, что будут оттенки желтого, но когда сделал и пробовал разные варианты, мне тоже зеленый больше понравился, поэтому он по умолчанию.
С раскраской как в версии на бейсике есть нюанс, который я (пока?) не смог сделать.
Прочитал про новомодное японское умножение "Minus Square", но, к сожалению, оно медленнее процедур в трассировщиках. Тем не менее нашел, что можно оптимизировать помимо умножения и пятицвет (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1190035&viewfull=1#post1190035) теперь быстрее 10 минут.
Прочитал про новомодное японское умножение "Minus Square", ...
Через таблицу квадратов что ли? Ему тысяча лет. В той же Elite сделано умножение на матрицу преобразования пространства через него. Что там нового?
Что там нового?
Смотрите (https://github.com/uniabis/z80depacker/blob/master/unpack_upkr_minusquare.asm) и там есть ссылка на японца, до которого правда я смог добраться только через vpn.
А я и так смог ... но это же вроде деление столбиком в двоичной системе???
По ссылке (https://piclabo.blog.ss-blog.jp/Z80MultiplicationOptimization) открывается (если еще нажать на English Version) заметка с названием "High-speed multiplication processing on Z80 (Part 2) Optimization [Z80]", про деление я ничего не заметил.
Снова приглашаю тех, кто хочет улучшить показатели Вектора к оптимизации кода. Пока код заметно быстрее того, что сделал ivagor в 2021.
Решил узнать секрет мастера. Сравнивал m256.com (1175 байт) из архива fast-mandel.7z (https://litwr2.github.io/vector-06c/fast-mandel.7z) (14.01.2024) с m256x256 (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1140787&viewfull=1#post1140787) (364 байта, 25.12.2021, файл сейчас не доступен для скачивания, при необходимости могу перевыложить).
Оказалось, что одинаковых параметров расчета и построения в двух программах нет и честного сравнения не получится. При корректном сравнении нужны:
1. Одинаковое количество точек и цветов - нет. litwr считает половину точек и рисует симметрично, в отличие от m256x256, хотя для компенсации можно взять для m256x256 половину времени построения или строить симметрично.
2. Одинаковые масштабы при одинаковом максимуме итераций - нет. По числу итераций одно совпадение - mentry 6, 5, 15 ;9. Масштабы при этом разные.
3. Одинаковые параметры оптимизации программ - нет. litwr оптимизировал по скорости; m256x256 получен из оптимизированного по размеру варианта m128x128. В m256.com довольно много текста, но даже если его полностью убрать, размер останется как минимум вдвое больше по сравнению с m256x256.
Четкое количественное сравнение в таких условиях невозможно.
Неформально сравнил при близких параметрах и "заметно быстрее того, что сделал ivagor в 2021" не получилось. Из секретов мастера поучиться можно разве что некорректному предвзятому подходу, но лучше воздержусь.
Отдельно отмечу формат файла. Бинарники litwrа имеют расширение .com, но не существует операционных систем для вектора, в которых они будут корректно работать. Нормальное функционирование возможно только при запуске из монитора-отладчика. Этот технический момент я не считаю недостатком при сравнении скорости, просто он не документирован и надо его учитывать.
Решил узнать секрет мастера. Сравнивал m256.com (1175 байт) из архива fast-mandel.7z (https://litwr2.github.io/vector-06c/fast-mandel.7z) (14.01.2024) с m256x256 (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1140787&viewfull=1#post1140787) (364 байта, 25.12.2021, файл сейчас не доступен для скачивания, при необходимости могу перевыложить).
Оказалось, что одинаковых параметров расчета и построения в двух программах нет и честного сравнения не получится. При корректном сравнении нужны:
1. Одинаковое количество точек и цветов - нет. litwr считает половину точек и рисует симметрично, в отличие от m256x256, хотя для компенсации можно взять для m256x256 половину времени построения или строить симметрично.
2. Одинаковые масштабы при одинаковом максимуме итераций - нет. По числу итераций одно совпадение - mentry 6, 5, 15 ;9. Масштабы при этом разные.
3. Одинаковые параметры оптимизации программ - нет. litwr оптимизировал по скорости; m256x256 получен из оптимизированного по размеру варианта m128x128. В m256.com довольно много текста, но даже если его полностью убрать, размер останется как минимум вдвое больше по сравнению с m256x256.
Четкое количественное сравнение в таких условиях невозможно.
Неформально сравнил при близких параметрах и "заметно быстрее того, что сделал ivagor в 2021" не получилось. Из секретов мастера поучиться можно разве что некорректному предвзятому подходу, но лучше воздержусь.
Отдельно отмечу формат файла. Бинарники litwrа имеют расширение .com, но не существует операционных систем для вектора, в которых они будут корректно работать. Нормальное функционирование возможно только при запуске из монитора-отладчика. Этот технический момент я не считаю недостатком при сравнении скорости, просто он не документирован и надо его учитывать.
Добавил к исходникам коммент, который показывет как параметры программы (в макросе mentry) пересчитываются в стандартные границы множества Мандельброта.
;x-min = (x0+dx*HSize)/512, x-max = x0/512, y-max = dy*VSize/1024
В mentry легко задать любые параметры, исходники открыты для всех...
Ну и зря вы так всё лично. Мне просто было интересно сравнить то, что получилось у меня, с тем что было в софте для Вектора. То, что ваша программка строит Мандельброта медленнее, - это просто факт. У вашего кода есть свои безусловные достоинства. А то, что вы написали, эти факты никак не отменяет.
Кстати, не так давно сделал Мандельброта для Geneve 9640 и выложил результаты (https://forums.atariage.com/topic/344463-one-more-benchmarkdemo-for-the-geneve/) на профильном форуме. Среди результатов факт того, что мой код примерно в 200 раз быстрее того, что демонстрировала соответствующая программа для генерации Мандельбротов. И ежу понятна, что та программа имеет на порядок больше полезных функций. Но речь-то про простое сравнение по одному из параметров. Кстати, автор той замечательной программы мне дал несколько ценных подсказок. А в целом фаны той системы даже наградили меня кубком! Что-то похожее было и с тем, как встретили мой код фанаты Амстрада, хотя там было много мандельбротов и оптимизированных по скорости в том числе.
К сожалению, на этом форуме нередки случаи немотивированного хамства. Хотя энтузиаст Спека и БК reddie помог мне очень капитально с оптимизацией для Z80...
Не понял вполне про бинарники. У меня код использует только вызов БДОС, который есть в любом мониторе или CP/M... COM - стандартное расширение для исполнимых файлов CP/M. Не могли бы вы пояснить, что имеете в виду?
В таблице (https://litwr2.github.io/mandelbrot8/micro-mandel.html) результатов Мандельброта litwr есть такое примечание "The number in parentheses after @ is the approximated effective CPU frequency". Использовано это у Apple IIgs, Sinclair QL, Amstrad PCW, Amstrad CPC, БК0011, БК0010, Commodore 128 c Z80, Commodore +4. А остальные компьютеры, у которых процессор тормозится? А у них ничего не написано, ни "не знаю" ни "требует уточнения", ничего.
В число остальных попал и вектор, хотя казалось бы, раз он с 3 МГц уступает корвету с 2.5, значит очевидно торможение есть. Благодаря Emu можно точно определить "эффективную частоту" для конкретных программ, а не среднюю по больнице, как в таблице (точность "эффективных частот" в таблице - отдельный вопрос). Заодно будет видно, какая программа лучше оптимизирована для вектора - чем меньше "эффективная частота", значит тем больше используются тормозные, "неудобные" для вектора команды.
Для m256 использовал встроенное определение времени расчета/рисования (T).
Для m256x256 засекал по брякам в отладчике эмулятора.
По второму рисунку (отличия от первого минимальные - в районе одной сотой, но по второму рисунку результат чуть лучше для litwr и чуть хуже для меня):
"Эффективная частота" m256 - 2.2826 МГц
"Эффективная частота" m256x256 - 2.3748 МГц
Если сравнить с ранее приводившимися результатами (1 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1187315&viewfull=1#post1187315), 2 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1187396&viewfull=1#post1187396)), то вариант litwr почти на уровне не оптимизированных для вектора программ, мой получше, но даже до 2.4 не дотянул. Предполагаю, что дело или в побочных эффектах оптимизации по размеру или просто я плохо старался (или и то и другое).
В таблице (https://litwr2.github.io/mandelbrot8/micro-mandel.html) результатов Мандельброта litwr есть такое примечание "The number in parentheses after @ is the approximated effective CPU frequency". Использовано это у Apple IIgs, Sinclair QL, Amstrad PCW, Amstrad CPC, БК0011, БК0010, Commodore 128 c Z80, Commodore +4. А остальные компьютеры, у которых процессор тормозится? А у них ничего не написано, ни "не знаю" ни "требует уточнения", ничего.
В число остальных попал и вектор, хотя казалось бы, раз он с 3 МГц уступает корвету с 2.5, значит очевидно торможение есть. Благодаря Emu можно точно определить "эффективную частоту" для конкретных программ, а не среднюю по больнице, как в таблице (точность "эффективных частот" в таблице - отдельный вопрос). Заодно будет видно, какая программа лучше оптимизирована для вектора - чем меньше "эффективная частота", значит тем больше используются тормозные, "неудобные" для вектора команды.
Для m256 использовал встроенное определение времени расчета/рисования (T).
Для m256x256 засекал по брякам в отладчике эмулятора.
По второму рисунку (отличия от первого минимальные - в районе одной сотой, но по второму рисунку результат чуть лучше для litwr и чуть хуже для меня):
"Эффективная частота" m256 - 2.2826 МГц
"Эффективная частота" m256x256 - 2.3748 МГц
Если сравнить с ранее приводившимися результатами (1 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1187315&viewfull=1#post1187315), 2 (https://zx-pk.ru/threads/30566-bejsiki-dlya-vektora-06ts-i-klonov.html?p=1187396&viewfull=1#post1187396)), то вариант litwr почти на уровне не оптимизированных для вектора программ, мой получше, но даже до 2.4 не дотянул. Предполагаю, что дело или в побочных эффектах оптимизации по размеру или просто я плохо старался (или и то и другое).
Интересная тема эффективная частота. Для Коммодора+4, 64 и 128 (под 8502) - это весьма точная характеристика, не зависящая от используемого набора команд. Поэтому эффективные частоты для +4 и 128 (под 8502) в таблице точны, для +4 эта частота зависит только от выбранного видеорежима. Хотя для 128 (под 8502 и VDC) эффективная частота возможно должна быть чуть пониже из-за возможных циклов регенерации памяти, но скорее эти циклы вставляют в холостые циклы 8502. С этим можно ещё поразбираться. Для систем с Z80 ситуация сложнее, так как эффективная частота может зависeть от исполняемого набора команд. Однако для Амстрада и Коммодора 128 (под Z80) приведенные частоты практически подтверждаются почти всегда и общепризнанны. С MSX сложнее, какое-то время назад в таблице была частота 3.1 для этих систем, но большой статистики не собирал и само понятие ЭЧ для этих систем почему-то не используется. С БК похожая история, но есть некоторая статистика, которая подтверждает приведенные числа как некие ориентировочные средние. Для первых Макинтошей часто приводится эффективная частота, но возможности потестировать эту величину пока мне не представилось, поэтому из таблицы убрал. Аналогичная ситуация с IIgs, но особенности систем на базе семейства процессоров 6502 позволили мне эту частоту оставить. С Вектором практически не знаком, но если вы рекомендуете поставить 2.4, то поставлю.
В таблице эффективная частота величина близкая к иллюстративной. Никаких данных прямо направленных на установление этой характеристики там нет. Она используется для расчета ER процессора, но для 8080 данные, как лучшие, берутся с Корвета. Но и ER - это тоже побочная иллюстративная характеристика.
Мне кажется, мне стало примерно понятна ваша проблема. Вы ищите однозначности там, где её нет. Для некоторых систем практически невозможно сказать даже просто о частоте процессора однозначно, например, для MSX turboR или некоторых моделей PDP-11. В моём проекте просто собираются данные по скорости работе на одном фиксированном алгоритме. Если кто из ценителей Вектора найдет возможным сделать код быстрее, это будет отражено в результатах.
Что до скорости моего кода, то могу обратить ваше внимание на одно важное обстоятельство. Все коды в проекте используют абсолютно одинаковую математику, что, в частности, требует 60 лишних циклов в главном цикле для Вектора для сброса нулевого бита в индексе массива. Этого легко избежать, что сделало бы код процентов на 20% быстрее, но это слегка изменило бы математику, хотя визуальный результат остался бы практически неотличимым.
Идея измерять эффективную частоту по конкретной программе - это реально интересно. Но не факт, что код лучше использующий особенности тормозов будет быстрее того, что просто эффективнее реализует алгоритм. Поэтому ваши расчеты никак прямо скорость работы кода не отражают.
Мне кажется, мне стало примерно понятна ваша проблема. Вы ищите однозначности там, где её нет.
Неправильно. Ищу приближение к объективной истине. Например если нельзя однозначно определить единственную эффективную частоту (а в подавляющем числе случаев так и будет), то надо приводить диапазон.
Все коды в проекте используют абсолютно одинаковую математику, что, в частности, требует 60 лишних циклов в главном цикле для Вектора для сброса нулевого бита в индексе массива.
Алгоритм и реализация алгоритма - разные вещи. Фиксация каких-то одних деталей реализации при упускании других - это вопрос субъективного выбора.
если вы рекомендуете поставить 2.4, то поставлю.
2.4 лучше, чем ничего, но еще лучше 2.23-2.45 (и эти цифры тоже требуют уточнения).
Для некоторых систем практически невозможно сказать даже просто о частоте процессора однозначно, например, для MSX turboR
Если не читать User Manual, то невозможно. А если почитать, то возможно.
Неправильно. Ищу приближение к объективной истине. Например если нельзя однозначно определить единственную эффективную частоту (а в подавляющем числе случаев так и будет), то надо приводить диапазон.
Реально для Вектора или БК нужно не просто диапазон, а диапазон с вероятностями. Нужно всесь имещийся софт прогнать и это вычислить, а потом ещё делать поправки на новые коды. Поэтому и пишу, что эффективная частота - это для многих систем лишь иллюстративный параметр. Коммодоры тут скорее исключение. А вы требуете типа убрать лучики от солнца на рисунке,
Алгоритм и реализация алгоритма - разные вещи. Фиксация каких-то одних деталей реализации при упускании других - это вопрос субъективного выбора.
Давайте тут конкретно. Речь о конкретных кодах. Какие могут быть разные реализации, если хотим идентичный результат?
2.4 лучше, чем ничего, но еще лучше 2.23-2.45 (и эти цифры тоже требуют уточнения).
Поставил 2.4 по Вашему требованию. Если кто будет жаловаться, переведу стрелки на Вас.
Если не читать User Manual, то невозможно. А если почитать, то возможно.
Японский знаете? Круто! Проблема в том, что общепринятой точки зрения тут нет. Некоторые и таких похоже большинство считают R800 чем-то типа Риска, где команды исполняются за такт. И если рассматривать проц как черный ящик это вполне верно. В реальности имеем усеченный Z800 с учетверенной внутренней частотой. Эту внутреннюю частоту можно считать глубинным уровнем реализации, которая никак до юзера не доходит. Что-то похожее имеем и для TMS9995. И ещё имеем маркетинговые стратегии, которые пудрят мозги выбранными важными параметрами, но эти параметры, как правило, реальны, они лишь выбраны как самые узнаваемые.
А вы требуете типа убрать лучики от солнца на рисунке,
Я хочу единообразного добросовестного подхода.
Давайте тут конкретно. Речь о конкретных кодах. Какие могут быть разные реализации, если хотим идентичный результат?
Смотрите исходники и сравнивайте, если интересно.
Поставил 2.4 по Вашему требованию.
Я выдвигал требование поставить 2.4 для вектора? Можно ссылку?
Проблема в том, что общепринятой точки зрения тут нет. Некоторые и таких похоже большинство считают R800 чем-то типа Риска, где команды исполняются за такт. И если рассматривать проц как черный ящик это вполне верно. В реальности имеем усеченный Z800 с учетверенной внутренней частотой.
Потрясающие откровения. Ну а то, что они не соответствуют User Manual - это проблемы User Manual и тех, кто ему верит (я в их числе).
Я хочу единообразного добросовестного подхода.
Вам же приводят конкретные примеры, что в случае с Коммодорами эффективная частота - это штука конкретная, а для Вектора или БК - вероятностная. Где ваши факты? Пока приводите только какую-то философию, типа обидел кто-то.
Смотрите исходники и сравнивайте, если интересно.
Какие исходники?! Вам пишут, про издержки для поддержания одинаковых условий, а вы про что?
Я выдвигал требование поставить 2.4 для вектора? Можно ссылку?
Ну как же, жаловались и обижались, без ЭЧ для Вектора у вас кругом недобросовестность.
Потрясающие откровения. Ну а то, что они не соответствуют User Manual - это проблемы User Manual и тех, кто ему верит (я в их числе).
Опять болото разводите, а мне случилось с японцем общаться, который в теме. И никаких откровений, противоречащих мануалу нет, разве только для вас.
Мне понравилась 256-байтная дема morph (https://events.retroscene.org/mf2024/oldschool_intro_256b/3349) (автор Gogin, Сергей Смирнов) для спека с Мультиматогрофа 2024. Для вектора цифры те же, но в другом порядке - 265 байт.
Upd 11.05.2024: 256 байт
8080 не так уж плох, дожал векторовский morph (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1198664&viewfull=1#post1198664) до 256 байт.
Навестил одну из прикопанных стюардесс. В "твердотельной" 3d крутилке (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1164768&viewfull=1#post1164768) добавил простейшую имитацию освещения. Это не замена предыдущего варианта, скорее ответвление, т.к. кое-что убрал/упростил:
1. Убрал разноцвет, остались оттенки желтого
2. Убрал паттерны, осталась сплошная заливка
3. Уменьшил диапазон изменения размера/расстояния до объекта
Антидемовый твистер. В принципе работает, осталось добавить красоту и интересность.
Антидемовый твистер. В принципе работает, осталось добавить красоту и интересность.
Ня. А на всю высоту экрана растянуть можно?
Можно, но 2 проблемы:
1. FPS упадет с 25 до примерно 5. Ускорить можно.
2. Будет еще более очевиден маленький период "колебаний". Надо какой-то более интересный вариант кручений реализовать.
Что касается технической стороны, то я бы скорее ограничился высотой <=128, но с 8 цветами.
Понравилась демка Downtown (https://m.pouet.net/prod.php?which=103553) (Darklite) и портанул ее на вектор (легко портируется на любой ретрокомп с графикой минимум 256x192). В 256 байт никак не влезает, поэтому не стал оптимизировать. При желании можно и сократить и ускорить.
Ленивый порт еще одной микродемы Department of Twisting Scrollers (https://m.pouet.net/prod.php?which=103563) (тоже Darklite). Заметно ускорить вряд ли получилось бы, а вот сократить размер раза в полтора-два (в основном за счет оптимизации шрифта) можно. Изогнутый скроллер для вектора уже делал svofski в Arzak (https://caglrc.cc/scalar/ware/919/), я не стал сильно напрягаться.
Upd: Добавил цвет и сократил в полтора раза.
Upd2: Слегка медленнее, зато 489 байт.
Upd3: Нашел приемлемый компромисс. Скорость практически как у версии 2, но 509 байт вместо 553.
Upd4: Пятая версия (по внутренней нумерации шестая).
В итоге получилось (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1211672&viewfull=1#post1211672) все и сразу (в разумных пределах).
Скорость как у быстрой версии, размер 460 байт - меньше, чем у компактной версии. И бордюр теперь как у спековского оригинала, и во время предварительного расчета и во время самой демонстрации.
Портировал еще одну микродему со спека - Chess-Board of Madness (https://m.pouet.net/prod.php?which=49699) (tiboh / debris).
Благодаря простому и удобному строению экрана векторовская версия получилась компактнее оригинала.
svofski & ivagor представили демо для нерасширенного Вектора-06ц на Outline 2025 (https://outlinedemoparty.nl/).
БЛК+СБР! (8th place): [pouet (https://www.pouet.net/prod.php?which=104243)] [demozoo (https://demozoo.org/productions/372870/)] [github (https://github.com/svofski/v06c-floppy)] [kartoteka (https://github.com/svofski/v06c-floppy)] [youtube (https://www.youtube.com/watch?v=IWnbBv89zrw)]
metamorpho
01.06.2025, 15:16
svofski & ivagor представили демо для нерасширенного Вектора-06ц на Outline 2025 (https://outlinedemoparty.nl/).
БЛК+СБР! (8th place): [pouet (https://www.pouet.net/prod.php?which=104243)] [demozoo (https://demozoo.org/productions/372870/)] [github (https://github.com/svofski/v06c-floppy)] [kartoteka (https://github.com/svofski/v06c-floppy)] [youtube (https://www.youtube.com/watch?v=IWnbBv89zrw)]
Супер !!!!
Вращающийся диск - это спрайтами сделано или же по другому ?
Вращающийся диск - это спрайтами сделано или же по другому
Нет, диск честно в трех измерениях вращается и рисуется. Перерисовываются только диффы между кадрами.
Извините за оффтоп.
Смотрел стрим про спринтер и вдруг логотип DF99 (https://youtu.be/wa24K2cGpg0?t=8296). Не секрет, что SES писал для спринтера программы, но тут он портанул с вектора, неожиданно.
Хакнутый вариант SKYNET совместимый с более быстрыми чем 8080 процами (3 МГц). Без хаки зависание в районе 3D букв KIROV CODERS GROUP. Спасибо Дмитрию2012 за обнаружение проблемы и проверку на Турбо+.
Еще эта версия доработала до конца в эмуляторе в конфиге 6128 с включенным квазом (т.е. это скорее 6128++).
Выравнивание синхронизации музыки под какой-либо вариант быстрого проца конечно не делал, только работоспособность на грани, только хардкор.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot