Просмотр полной версии : Демо эффекты для Вектора
Под влиянием соответствующей корветовской темы (http://zx-pk.ru/showthread.php?t=21891) наваял нечто подобное. Пара отличий - режим 256, а не 512 точек по горизонтали (для 6128 можно и один в один сделать), зато быстрее, во фрейм укладывается и еще много тактов остается (на музыку и т.п.). Для полного счастья желательно смотреть на 50 Гц мониторе (с соответсвующими настройками эмуляторов) или на реале, а на 60 Гц мониторе немножко неидеально.
Огромный недостаток - YouTube нет и не будет.
marinovsoft
28.09.2013, 10:35
Будет Яндекс видео http://video.yandex.ru/users/mehfk/view/11/
Спасибо, только на видео несколько подергивается.
VV, к сожалению, пишет 25 fps, а не 50. Еще я не пробовал, переварит ли yandex видео с 50 fps.
А как сделано, заливкой через стек?
Горизонтальное движение - заливка границ через стек. По вертикали - читерский аппаратный скроллинг.
простимулировали вы меня батенька ;)
теперь тоже OneFrame
правда времени не сильно много остается во фрейме, но немного есть
http://zx.pk.ru/showpost.php?p=630788&postcount=7
да, аппаратный скрол тут сильно помогает,
у меня %80 времени отнимает то чем его заменять приходится.
Эх, хотел же сделать полноэкранную фоновую картинку. Но попробовал аппаратный скролл и поленился дальше делать.
да, аппаратный скрол тут сильно помогает,
у меня %80 времени отнимает то чем его заменять приходится.
в 3 ночи спатть надо, а не писать
горизонтальные полоски 80%
и без PageFlipping.
Надо признать, что V3 (http://zx-pk.ru/showpost.php?p=631038&postcount=8) один в один (в режиме 512 точек) на стандартном векторе не повторить. Но в принципе у вектора можно продемонстрировать свои фишки - например фоновую картинку сделать с 8 градациями желтого/красного/зеленого.
ivagor, бетон!
Сделай интру полноценную, раз уж начал =)
Надо признать, что V3 (http://zx-pk.ru/showpost.php?p=631038&postcount=8) один в один (в режиме 512 точек) на стандартном векторе не повторить. Но в принципе у вектора можно продемонстрировать свои фишки - например фоновую картинку сделать с 8 градациями желтого/красного/зеленого.
не сыпьте сударь соль на рану ;)
без текстового режима было бы тяжко
svofski, я не начинал, я мимо проходил.
Плюсую.
---------- Post added at 16:06 ---------- Previous post was at 16:04 ----------
То есть плюсую к написанию интры или демы :-)
svofski, я не начинал, я мимо проходил.
Еще пару кружочков и будет интра.
Шахматная доска, теперь на бейсике. Только квадратики маленькие и несколько дергано (задержку в строке 28 можно подрегулировать). Зато на полный экран и ни байта на асме.
Игра палитры однако :)
помню на реале такие эффекты подглючивали в виду нестабильной записи в палитру.
Можно "честно" рисовать (SCREEN3 + LINE BF), ограничившись двумя плоскостями (для двойной буферизации через SCREEN0), но тогда будет заметно медленнее, даже если не на весь экран.
"Подглючивание" IMHO в данном случае не из за нестабильной записи в палитру (бейсик пишет долго и упорно) а из за возможности прихода прерывания в процессе выполнения SCREEN0 (вроде прерывания на время его выполнения не запрещаются). При этом сначала палитра перепрограммируется частично и только потом полностью. В своих модификациях бейсика для ВМ1 и 6128 я этот момент пофиксил.
Посмотрел демку для msx2 nocnoc (http://www.pouet.net/prod.php?which=66247). Нечто подобное как раз можно и для вектора сбацать. Для 6128 еще лучше получится.
Для практической проверки генератора случайных чисел (http://zx-pk.ru/threads/9031-etyudy.html?p=930124&viewfull=1#post930124) сделал "проявление" картинки по точкам. Работает достаточно хорошо, картинку 256x256 полностью проявляет за 2 минуты с копейками. На векторе такой эффект могу вспомнить только в какой-то игрушке Лебедева (вроде так картинка с рекламой выводилась).
Для практических эффектов типа проявления по точкам есть смысл сначала реализовать перетасовывание последовательности. Тогда каждая точка будет появляться ровно один раз.
Для демки я бы считерил - последние точки закрасил бы принудительно.
Насчет перетасовки - разве для нее в данном случае не нужен буфер размером 256x256 элементов?
Еще попробовал 16 битный вариант (алгоритм blackmirrora, но реализация моя собственная, тормозная, не та, которую он привел в ЭТЮДах) - на несколько секунд быстрее. При этом сразу генерируются пары YX
- - - Добавлено - - -
Взял (в wiki) рекомендованные 97 и 33 (которые использовал Dart Alver (http://zx-pk.ru/threads/9031-etyudy.html?p=929845&viewfull=1#post929845)) - с ними 16битный генератор еще на несколько секунд быстрее заполняет все дырки на экране, несмотря на некоторое замедление самой процедуры rnd.
- - - Добавлено - - -
Варианты с 16битным rnd - пиксельный и байтовый. Пиксельный заполняет все дырки за минуту 50 секунд (секунд на 20 быстрее предыдущего), байтовый - примерно за 10 секунд (вот это можно и в демке использовать).
Кстати, лучше реализовать алгоритм самостоятельно, вариант blackmirrorа (я про 8битный, 16битный не изучал) имхо не соответствует алгоритму.
Насчет перетасовки - разве для нее в данном случае не нужен буфер размером 256x256 элементов?
Если строго требуется, чтобы было честно по одному пикселю за итерацию, то да. Но если никто не будет проверять, то я бы попробовал как-то разбить на фрагменты.
Можно и на фрагменты, но гораздо проще сделать блоки покрупнее. Блоками 4x4 проявляет за 6 секунд - для демы вполне подойдет.
Когда попробовал блоками вспомнил, где еще на векторе видел подобный эффект - в демке SESа, вроде black ice. У Лебедева попиксельно, у SESа как раз поблочно.
Павиан, или кто это, хорошо получился. Согласен, что бегать за отдельными точками совершенно незачем. Можно назвать "Зеркало" и релизить.
Еще идея — каждый блок 4х4 выводить тоже как-нибудь необычно. Через строку, ромбиком, перетасованным рандомом внутри него самого, по спирали от центра к краю итд.
Это бабуин, но название вроде "Автопортрет" приходило на ум.
Идея с постепенным рисованием блока интересная, только нужен баланс между задержкой при рисовании блока (чтобы было заметно) и общим временем. Но это уже сильно далеко от моего первоначального желания просто попробовать такой вариант ГСЧ.
Знаменитый любовный треугольник Лена - Клоун - Бабуин.
По идее рисовать внутренности с анимацией просто, но уже нетривиально. Нужен пул воркеров — рисовалок блоков, допустим 16. Когда очередной воркер освобождается, основной цикл выдает для него новую задачу. Если сделать общую схему, то нетрудно сделать вариации. Например, сделать их всех разными, или чтобы они могли рисовать со своей скоростью каждый.
Вот какой-то широко растиражированный вариант, похоже, что он был в некой популярной книге:
https://github.com/erich666/GraphicsGems/blob/master/gems/Dissolve.c#L80
Создает вариант LFSR c разрядностью (бит-на-строки)+(бит-на-столбцы). В случае 256x256 - 16 битный. Каждое следующее состояние — это X и Y. Крутится в цикле, расставляя точки. Делает это, пока не вернется к начальному состоянию, после которого крутиться смысла нет. (Ну и в идеале мы должны были обойти все точки).
В общем-то даже читать исходник по ссылке необязательно, ты все и так написал. Берем LFSR, я взял отсюда (https://users.ece.cmu.edu/~koopman/lfsr/16.txt) самый первый - и вперед. Попиксельно проявляет весь экран за 10 секунд! На 8080 удобнее реализовать в перевернутом виде, но можно и в "классическом".
Спасибо за инфу, заполнять область несомненно целесообразно именно таким генератором, тем более буфер не нужен и заранее точно известно число циклов (только надо не забыть {0,0}). Но для ГСЧ общего назначения длина цикла 65535 очень мала и Фибоначчи конечно предпочтительнее.
Меня в итоге смущает только одно - почему я сам не подумал о lfsr?
- - - Добавлено - - -
Знаменитый любовный треугольник Лена - Клоун - Бабуин.
Насколько помню, Лена и Бабуин из одного набора, а Клоун из другого. Хотя могу и ошибаться, давно это было. Ах, Лена, я ведь ее даже использовал.
svofski уже все предусмотрел и написал онлайн-эмулятор (http://sensi.org/scalar/vector06js/). Туда можно дропнуть прямо zip, не распаковывая.
Ах, Лена, я ведь ее даже использовал.
:D Отлично проявляется мандрил теперь!
Что мне нравится в этом алгоритме, так это то, что он прекрасно адаптируется и для варианта c клетками 4х4 (поле 64x64) — берем 12 битный LFSR, и все то же самое. И даже для клеток 4х4 его можно рекурсивно употребить. Прям руки зачесались, но я знаю, что ты это сделаешь быстрее.
Да я уже сделал по этой теме больше чем хотел. Выкладываю исходник последнего варианта, вдруг кто-нибудь еще поиграется.
И да, lfsr очень удобен для данного применения легкостью масштабирования, прямо красиво.
Добавил как рыбу в ассемблер (https://svofski.github.io/pretty-8080-assembler/), если ivagor не против.
https://i.imgur.com/rWvtSs7.png
Прямо из ассемблера можно запустить.
Он (ivagor), конечно, не против и даже за.
Возник вопрос - выбрать в шапке обезьяну смог, а переключится с нее на что угодно (РК, Микроша и т.д.) не получается. Куда надо ткнуть или что нужно нажать?
И злостный оффтоп - в биологии не разбираюсь и по названию (baboon) всегда думал, что это бабуин. Когда ты написал, что мандрил, я тоже посмотрел - и точно, мандрил. Странно, но насколько я понял из английской вики, какое-то время мандрил(ов?) относили к бабуинам, но сейчас нет, может так и получилось название классической картинки.
- - - Добавлено - - -
Насчет переключения - насколько вижу, в обязьянине не хватает хитрой пиктограммы с рыбкой, при нажатии на которую и появляется выбор. Возможно так и задумано
В биологии, в Ленах и в чайниках я разбираюсь исключительно по иллюстрациям к алгоритмам компьютерной графики.
Да, я поторопился. Обновил заголовок:
https://i.imgur.com/M9SBKi9.png
(Бе, у форума аллергия на рыбу, пришлось цитату заменить на скриншот).
Ты сделал правильный вывод о том, что меню просто реагирует на рыбу в тексте.
Black Cat / Era CG
06.10.2017, 08:43
(Бе, у форума аллергия на рыбу, пришлось цитату заменить на скриншот).Оффтоп, конечно, но можно подробнее. Форум не пропустил сообщение?
Небольшое дополнение. Раз уж в названии темы есть слово "демо", то это поднимает планку ожиданий по оптимизации предлагаемых вариантов. А в выложенном исходнике многое можно оптимизировать. Хотя это все лежит на поверхности, но я перечислю:
1. Заменить setpixel на вариант с маской по таблице (8 байт). Это дает ускорение на 2 секунды (20%). А если как в basic 2.5 выделить под таблицу 256 байт, то будет еще быстрее.
2. Можно оптимизировать счетчик основного цикла, сейчас он "школьный".
3. Можно внести ГСЧ и рисование точки в тело цикла, чтобы убрать накладные расходы на вызов процедур.
4. Очистка экрана медленная. Причем можно очищать только одну плоскость, а не 4.
- - - Добавлено - - -
Вопрос к svofski - как вставлять бинарники в прекрасный асм?
Black Cat / Era CG, он показывал рыбу в превью (внутри тега code), но отправленное сообщение оказалось оборванным. Какая именно рыба - просто скопировать и вставить из ассемблера.
Black Cat / Era CG
06.10.2017, 12:36
Black Cat / Era CG, он показывал рыбу в превью (внутри тега code), но отправленное сообщение оказалось оборванным. Какая именно рыба - просто скопировать и вставить из ассемблера.
Понял. У меня просто недавно не хотелось сообщение с кодом отправляться, вот я и подумал... но это скорее всего браузер у меня просто умничает :)
Небольшое дополнение. Раз уж в названии темы есть слово "демо", то это поднимает планку ожиданий по оптимизации предлагаемых вариантов. А в выложенном исходнике многое можно оптимизировать. Хотя это все лежит на поверхности, но я перечислю:
1. Заменить setpixel на вариант с маской по таблице (8 байт). Это дает ускорение на 2 секунды (20%). А если как в basic 2.5 выделить под таблицу 256 байт, то будет еще быстрее.
2. Можно оптимизировать счетчик основного цикла, сейчас он "школьный".
3. Можно внести ГСЧ и рисование точки в тело цикла, чтобы убрать накладные расходы на вызов процедур.
4. Очистка экрана медленная. Причем можно очищать только одну плоскость, а не 4.
Высылай обновленный исходник, я все выложу. По-моему не обязательно все делать сверхоптимально, читабельность кода в нашем случае предпочтительна. Но если больше, чем 20%, то конечно. Пиши комментарии.
Вопрос к svofski - как вставлять бинарники в прекрасный асм?
Утилитой base64 кодируешь бинарник в base64 и полученную строку засовываешь в директиву db64. Учитывая, что максимальный размер бинарника по нынешним меркам комически мал, это вполне практично. На виндус можно найти такую же программу из разных портов GNU утилит. Но вот, говорят, еще есть под виндус некий такой стандартный certutil:
certutil -encode inputFileName encodedOutputFileName
Black Cat / Era CG
06.10.2017, 13:35
в base64
В base64 и TC умеет по дефолту.
Рисование линии в одном слое в режиме 256ъ256:
Версия с запрещенными прерываниями ~246 линий в секунду:
https://svofski.github.io/pretty-8080-assembler/?line-di
Версия с разрешенными прерываниями ~220 257 линий в секунду:
https://svofski.github.io/pretty-8080-assembler/?line-el
Если вдруг у кого есть на примете более быстрые варианты - поделитесь плиз исходником или ссылкой.
Этот вариант с минимальнейшей переделкой годится и для специалиста и для ориона, если использовать область 256x256 (лучше в центре, но мало ли кому чего захочется). Доработка под ширину 384 возможна, но будет медленнее.
При желании можно хорошо оптимизировать под 580ВМ1 и (особенно) z80.
- - - Добавлено - - -
Забыл самое важное (оценочное суждение) - это очень быстрые процедуры рисования линии!
- - - Добавлено - - -
Хотя нет, самое важное другое. Респект svofski, что он поднял эту тему и написал процедуру, ну и я молодец, что поучаствовал (сам себя не похвалишь и все такое...) !
(От скромного соучастия ivagor-а линия ускорилась чуть ли не в 2.5 раза).
Прогнал вышеприведенный бенчмарк с процедурой рисования линии из специалистовского бейсика. Выбрал его, а не векторовский, т.к. думал, что рисование в одной плоскости будет ближе всего. Но специалистовская процедура просто ужасна - 28 линий/секунду! Прогонял на векторе (изменил начальный адрес экрана в выводе точки), не на специалисте. Даже 16-цветный вариант (4 плоскости), который я переделал из промежуточной версии процедуры svofski и то в 3 раза быстрее (и его еще можно процентов на 20 ускорить)!
От скромного соучастия ivagor-а линия ускорилась чуть ли не в 2.5 раза
Если поточнее прикинуть, то мой вклад в это ускорение от 50 до 75%
Подумал по поводу твоей идеи о четных длинах линий итд. Интересно было бы сделать реализации линий для псевдо-разрешений поменьше. Например, 128x128: то есть все идет с шагом 2, число шагов делится пополам, обращений к экрану мм... (1/2 + 1)/2 = 0.75, суммарно должно стать заметно быстрее. Могу представить себе много ситуаций, особенно в разговоре про демо эффекты, когда можно пожертвовать детальностью картинки ради частоты кадров.
Не мог обойти стороной линию в векторовском бейсике - 40 линий/секунду. Нужно отметить условия тестирования - COLOR1:SCREEN2,1 (но это не сильно влияет, т.к. при запрещении плоскостей рисование недостаточно оптимизируется).
Интересно было бы сделать реализации линий для псевдо-разрешений поменьше.
Это может дать эффект, но тут наверно надо под конкретную задачу подстраиваться.
Рисование линии в одном слое в режиме 256ъ256:
Версия с запрещенными прерываниями ~246 линий в секунду:
https://svofski.github.io/pretty-8080-assembler/?line-di
Подскажите, пожалуйста, что я делаю не так? По ссылке выше в pretty assembler открывается его штатная демонстрационная программка с декодированием base64
x-code, πάντα ῥεῖ :) Буквально вчера линия с запрещенными прерываниями была отменена, потому что ivagor довел линию с прерываниями до совершенства. Называется она по-прежнему line-ei (https://svofski.github.io/pretty-8080-assembler/?line-ei).
Более интерактивный способ — кликнуть на рыбу в заголовке рыбы и выбрать нужную рыбу из меню.
Если вдруг кому интересно - последний вариант выдает 257 линий/секунду. Т.е. примерно в 9 раз быстрее специалистовской процедуры, в 6.5 раз - процедуры из векторовского бейсика. В свою очередь примерно в 8 раз медленнее аппаратной рисовалки линий в 9938/9958.
blackmirror
19.12.2017, 20:48
последний вариант выдает 257 линий/секунду
Имеется ввиду 257 линий из последней точки в новую случайную точку координаты которой выбираются из диапазона 0-255?
А 256 случайных линий для которых dx=255 или dy=255 (то есть которые касаются противоположных краёв экрана) данный код за сколько нарисует?
Имеется ввиду 257 линий из последней точки в новую случайную точку координаты которой выбираются из диапазона 0-255?
Да
А 256 случайных линий для которых dx=255 или dy=255 (то есть которые касаются противоположных краёв экрана) данный код за сколько нарисует?
На основе рисования 65536 случайных линий
1. Во всю ширину экрана (dx=255), x0=0, y0=0, x1=255, y1=случайный от 0 до 255: 91 линия/секунду
2. Во всю высоту экрана (dy=255), x0=0, y0=0, y1=255, x1=случайный от 0 до 255: 100 линий/секунду
Нетрудно заметить, что "крутой" цикл работает несколько быстрее "пологого".
Error404
20.12.2017, 11:22
Парни, а DOOM то будет, ну или хотя бы driller в линиях? А то предыдущие эксперименты с 3-мерным лабиринтом так и не закончились игрой, а мы же ждем. :v2_dizzy_rastoman:
Error404, с ходу я могу сделать вращающийся проволочный 3D-кубик, причем максимально тупо, без убирания невидимых ребер. Учитывая, что для вектора уже есть пара (и даже больше) примеров нормальной (с убиранием невидимых ребер) векторной 3D графики, нет желания делать то, что уже есть, только хуже. Или надо почитать, поразбираться, чтобы сделать нормально. Пока такого желания тоже нет.
Насчет doomов и wolfов - счастливым обладателям z80 стоит обратить вниманием на результаты alone codera для спека. wolf48 реально портануть на орион с z80, было бы желание.
Я кстати не видел для Вектора синглфреймовых, ну или хотя бы даблфреймовых, вращающихся кубиков.
blackmirror
21.12.2017, 01:00
Пока оставлю это здесь, всякие dx-dy здесь считаются байтами, но на картинку это вроде не влияет.
Написано в EmuZWin, поэтому про быстродействие на векторе ничего сказать не могу.
Вроде как должно быть шустрее, но есть еще большой резерв для оптимизации.
defs 7&-$
PixMask defb 128,64,32,16,8,4,2,1
SetPix macro
xor a,(hl)
ld (hl),a
endm
LineTo:;(hl - x1y1)
ld de,$0000
ld (LineTo+1),hl
Line:;(hl - x1y1, de - x2y2)
ld a,d
sub a,h
jp nc,LineGm
neg
ex de,hl ;swap p1,p2
LineGm: ld d,a ;dx
ld bc,PixMask
ld a,$7
and h
add c
ld c,a
ld a,h
srl a
srl a
srl a
add a,$80
ld h,a
ld a,(bc)
ld b,a
LineDy: ld a,e
sub a,l
jp nc,LineXi
neg
LineXd: ld e,a ;dy
sub a,d
jp nc,LineYd
neg
ld (LineXdd+1),a ;dx-dy
ld a,$2D;dec l
ld (LineXmm),a
jp LineXi1
LineYd: ld (LineYdd+1),a ;dy-dx
ld a,$2D;dec l
ld (LineYy),a
ld (LineYyy),a
jp LineYi1
LineXi: ld e,a
sub a,d
jp nc,LineYi
neg
ld (LineXdd+1),a ;dx-dy
ld a,$2C;inc l
ld (LineXmm),a
LineXi1:ld c,d ;cnt
inc c
ld a,d
srl a
ld d,a
ld a,b
LineXp:SetPix
dec c
ret z
ld a,d
sub a,e
ld d,a
jp nc,LineXpp
LineXmm:dec l
ld a,b
rrc a
ld b,a
jp nc,LineXm
inc h
LineXm:SetPix
dec c
ret z
ld a,d
LineXdd:add a,$0
ld d,a
jp nc,LineXmm
LineXpp:ld a,b
rrc a
ld b,a
jp nc,LineXp
inc h
jp LineXp
LineYi: ld (LineYdd+1),a ;dy-dx
ld a,$2C;inc l
ld (LineYy),a
ld (LineYyy),a
LineYi1:ld c,e ;cnt
inc c
ld a,e
srl a
ld e,a
ld a,b
LineYp:SetPix
dec c
ret z
LineYy: inc l ;++y
ld a,e
sub a,d
ld e,a
ld a,b
jp nc,LineYp
rrc a
ld b,a
jp nc,LineYm
inc h ;++x
LineYm: SetPix
dec c
ret z
LineYyy:inc l ;++y
ld a,e
LineYdd:add a,$0
ld e,a
ld a,b
jp c,LineYp
rrc a
ld b,a
jp nc,LineYm
inc h
jp LineYm
Сначала я покритиковал, а потом все же проверил.
blackmirror, респект, это просто супер - 313 линий/секунду и еще видны возможности для ускорения.
- - - Добавлено - - -
Убрал про несимметричность - см. ниже.
Просто для истории. Мой вариант 1BPP линии от 2015 года. С тех пор ничего не трогал, просто рекомпильнул. Там в среднем 205 линий в секунду, если заполнять экран радиально от центра без смены цвета и 195 линий в секунду, если менять цвет каждой выводимой линии. Может просто будет интересен алгоритм. Сырки и демка прилагаются. Демку запускать из МикроДОСа. Когда отрисовка остановится, нажать [АР2] для 2й части.
blackmirror, отбой тревоги - при переводе z80->8080 я допустил механическую ошибку. После ее исправления рисует замечательно - симметрично и правильно.
Еще раз респект, снимаю шляпу.
blackmirror
22.12.2017, 00:20
Немного безумия: данный код не является полноценным кодом рисования линии, а только проверкой, что может дать один из вариантов разворота цикла. Цикл развёрнут на 8 точек, чтобы не вычислять маски, кроме того делается поочерёдно по 4 приращения ошибки, потом рисуются 4 точки, чтобы не перезагружать лишний раз аккумулятор. Для практического применения данный код пока мало пригоден: занимает 512 байт, не вычисляет нужные ему числа из координат, не обрабатывает хвосты, рисует по 8 точек и только в сторону увеличения Y, но позволяет оценить какие у нас есть резервы в плане рисования линий. В EmuZWin данный код рисует 256 линий из точки 0,0 до правого края экрана за 32 кадра, предыдущий код рисует 256 линий от левого края до правого за 72 кадра, сверху вниз за 64 кадра. То есть потенциально, если кому-то не жалко пары килобайт для рисования линии, раза в полтора линию точно сможет ускорить.
Test3:;(x1=0, y1=0, x2=255, y2=0..255)
ld de,$FF00 ;dx-dy=255 dy=0
Test3_0:
ld hl,$8000 ;x1=0, y1=0
ld bc,$7F20 ;err=dx/2=127 cnt=256/8=32
push de
ld a,b
call LineX01
pop de
dec d ;--(dx-dy)
inc e ;++dy
jp nz,Test3_0
ret
SubPos macro lab
sub a,e ;err-=dy
jp c, lab
endm
SubNeg macro lab
sub a,e ;err-=dy
jp nc, lab
endm
AddNeg macro lab
add a,d ;err+=dx-dy
jp c, lab
endm
AddPos macro lab
add a,d ;err+=dx-dy
jp nc, lab
endm
Ymove macro
inc l
endm
SetPix1 macro m1
ld a,m1
xor a,(hl)
ld (hl),a
endm
SetPix2 macro m1,m2
SetPix1 m1
Ymove
SetPix1 m2
endm
SetPix3 macro m1,m2,m3
SetPix2 m1,m2
Ymove
SetPix1 m3
endm
SetPix4 macro m1,m2,m3,m4
SetPix2 m1,m2
Ymove
SetPix2 m3,m4
endm
DecRetZ macro
inc h ;inc x
dec c ;dec cnt
ret z
endm
;+0+1-4+2-3-5-7-6+
;+1-4+2-3-5-7-6+0+
LineX00:SubPos LineX71
LineX01:SubPos LineX72
LineX02:SubPos LineX33
LineX03:SubPos LineX14
LineX04:ld b,a
SetPix1 $F0
ld a,b
LineX15:SubPos LineX76
LineX16:SubPos LineX77
LineX17:SubPos LineX38
LineX18:SubNeg LineX09
LineX19:ld b,a
SetPix2 $0E,$01
ld a,b
DecRetZ
LineX40:AddNeg LineX01
LineX41:Ymove
AddNeg LineX02
LineX42:AddPos LineX73
LineX43:SubPos LineX54
LineX44:ld b,a
SetPix2 $80,$70
ld a,b
LineX25:SubPos LineX76
LineX26:SubPos LineX77
LineX27:SubNeg LineX08
LineX28:AddPos LineX39
LineX29:ld b,a
SetPix2 $0C,$03
ld a,b
DecRetZ
LineX30:SubPos LineX71
LineX31:SubPos LineX72
LineX32:SubNeg LineX03
LineX33:AddNeg LineX24
LineX34:ld b,a
SetPix3 $C0,$20,$10
ld a,b
LineX55:AddNeg LineX06
LineX56:Ymove
AddNeg LineX07
LineX57:AddPos LineX78
LineX58:SubNeg LineX49
LineX59:ld b,a
SetPix3 $08,$06,$01
ld a,b
DecRetZ
LineX70:AddNeg LineX01
LineX71:Ymove
AddNeg LineX02
LineX72:AddNeg LineX43
LineX73:AddNeg LineX64
LineX74:ld b,a
SetPix4 $80,$40,$20,$10
ld a,b
LineX65:AddNeg LineX06
LineX66:Ymove
AddNeg LineX07
LineX67:AddNeg LineX48
LineX68:AddPos LineX79
LineX69:ld b,a
SetPix3 $08,$04,$03
ld a,b
DecRetZ
LineX10:SubPos LineX71
LineX11:SubPos LineX72
LineX12:SubPos LineX33
LineX13:SubNeg LineX04
LineX14:ld b,a
SetPix2 $E0,$10
ld a,b
LineX45:AddNeg LineX06
LineX46:Ymove
AddNeg LineX07
LineX47:AddPos LineX78
LineX48:SubPos LineX59
LineX49:ld b,a
SetPix2 $08,$07
ld a,b
DecRetZ
LineX20:SubPos LineX71
LineX21:SubPos LineX72
LineX22:SubNeg LineX03
LineX23:AddPos LineX34
LineX24:ld b,a
SetPix2 $C0,$30
ld a,b
LineX35:SubPos LineX76
LineX36:SubPos LineX77
LineX37:SubNeg LineX08
LineX38:AddNeg LineX29
LineX39:ld b,a
SetPix3 $0C,$02,$01
ld a,b
DecRetZ
LineX50:AddNeg LineX01
LineX51:Ymove
AddNeg LineX02
LineX52:AddPos LineX73
LineX53:SubNeg LineX44
LineX54:ld b,a
SetPix3 $80,$60,$10
ld a,b
LineX75:AddNeg LineX06
LineX76:Ymove
AddNeg LineX07
LineX77:AddNeg LineX48
LineX78:AddNeg LineX69
LineX79:ld b,a
SetPix4 $08,$04,$02,$01
ld a,b
DecRetZ
LineX60:AddNeg LineX01
LineX61:Ymove
AddNeg LineX02
LineX62:AddNeg LineX43
LineX63:AddPos LineX74
LineX64:ld b,a
SetPix3 $80,$40,$30
ld a,b
LineX05:SubPos LineX76
LineX06:SubPos LineX77
LineX07:SubPos LineX38
LineX08:SubPos LineX19
LineX09:ld b,a
SetPix1 $0F
ld a,b
inc h
dec c
jp nz,LineX00
ret
Идея избавиться от сдвига маски развернув циклы у меня была (еще применительно к svoline), даже писал об этом svofski. Основной очевидный недостаток - код разбухнет сильно, а выигрыш в быстродействии будет не таким уж и большим. Если для какой-либо конкретной задачи чуть-чуть не будет хватать (например, чтобы в фрейм утрамбовать) - придется заморочиться, а пока не хочется.
Вчера в связи с приключениями IRL прочитал по диагонали, сегодня внимательно.
Т.е. не только избавление от сдвига маски, но и уменьшение числа пересылок ошибки. Ну и в целом разделение расчета и рисования с группировкой рисуемых точек. Суммарный эффект, конечно, будет не чуть-чуть, а вполне заметный. Теперь бы кто-нибудь сделал завершенную процедуру для 8080.
Моя любимая маргинальщина. 580ВМ1 позволяет избавиться от пересылок (маска в A, ошибка (или как ее теперь называть) в H, слагаемые/вычитаемые в B и D, счетчик в L, адрес в H1L1). Это дает ускорение на 20% при сокращении размера на 8 байт.
- - - Добавлено - - -
А если ничего не менять и просто прогнать на 6128, то будет быстрее почти на 30% за счет mov r,r; inr/dcr и условных переходов.
Слегка ускорил процедуру blackmirrora - с 313 до 323 линий/секунду.
Проверил свою идею (и, соответственно, одну из идей blackmirrora) по разворачиванию циклов с избавлением от сдвига маски. Но применил, конечно, уже к процедуре blackmirrora.
Разворачивание пологих циклов: +320 байт, зато 353 линии/секунду.
+еще разворачивание крутых циклов: +еще 350 байт, 355 линий/секунду - нафиг нужно.
blackmirror
25.12.2017, 01:07
+еще разворачивание крутых циклов: +еще 350 байт, 355 линий/секунду - нафиг нужно.
У меня после разворота крутых циклов 256 линий от верхнего края до нижнего стали рисоваться за 48 кадров вместо 64, а после разворота пологих циклов, но без группировки точек 256 линий от левого края до правого стали рисоваться за 48 кадров вместо 73. Пологие циклы можно ускорить еще в полтора раза за счёт группировки точек, а вот крутые циклы ускорять будет явно сложнее.
У меня после разворота крутых циклов 256 линий от верхнего края до нижнего стали рисоваться за 48 кадров вместо 64, а после разворота пологих циклов, но без группировки точек 256 линий от левого края до правого стали рисоваться за 48 кадров вместо 73.
Максимально длинные линии +, предполагаю, без части предварительных вычислений - максимальный эффект. На коротких линиях необходимость модификации направления вверх/вниз сказывается, особенно для крутых, т.к. там точек модификации в 2 раза больше, а выигрыш от "несдвига" маски меньше. Можно попробовать еще в 2 раза увеличить основные циклы - одна версия вниз, другая вверх. Но эффект будет совсем слабым, лучше уж попробовать разделение расчета и рисования с группировкой. Только это сложновато.
blackmirror
25.12.2017, 08:03
У меня разворот крутого цикла был сделан так:
LineYn0: SetPix 128;продолжнение цикла здесь
IncY
Err+=dy-dx
jp nc,LineYn1
LineYp0: SetPix 128 ;точка входа здесь
IncY
Err-=dx
jp nc,LineYp0;крутимся рисуя вертикальный отрезок
LineYn1: SetPix 64
IncY
Err+=dy-dx
jp nc,LineYn2;нарисовав точку нового отрезка идём дальше или
LineYp1: SetPix 64
IncY
Err-=dx
jp nc,LineYp1;крутимся рисуя следующий
LineYn2:
...
LineYn8:
IncH ;x
Dec Cnt8 ;изначально=(x2-x1-8)/8
Jp nz,LineYn0
Я не успел :)
Вышеприведенного поста не видел, вечером еще раз взглянул на развороты.
Удалось сократить и ускорить и пологий (немного) и крутой циклы. Крутой теперь похож на вышеприведенный и никто не поверит, что я сам до этого тоже допер (пусть и только на второй день).
В итоге:
1. Бенч svofski
1.1. Без разворотов - 323 линии/секунду
1.2. Развернутый пологий - 355 линий/секунду (+285 байт по сравнению с 1.1)
1.3. Развернутые пологий и крутой - 369 линий/секунду (+588 байт по сравнению с 1.1)
2. По результатам рисования 256 пологих линий (x0=0, y0=0; x1=255, y1=0..255)
2.1. Без разворотов - 113 линий/секунду
2.2. Развернутый пологий - 145 линий/секунду
3. По результатам рисования 256 крутых линий (x0=0, y0=0; x1=0..255, y1=255)
3.1. Без разворотов - 126 линий/секунду
3.2. Развернутый крутой - 139 линий/секунду
> до 220 или 380 далеко
Уже нет!
Про 380 я помню. Если с допингом (ВМ1/8085/Z80), то уже больше. А для 8080 надо реализовать оставшиеся идеи blackmirrorа, что несколько сложно.
blackmirror
29.12.2017, 20:02
В процессе размышления о рисовании линии пришёл к мысли, что вычисление ошибки это затратная и не особо полезная работа в том смысле, что это не точки которые нужно записать в память. Если достаточно длинную линию нарисованную алгоритмом Брезенхема поделить на кусочки по n точек, то различных кусочков для данной линии будет встречаться n+1. То есть если мы рисуем линию кусочками по 4 точки, нам нужно 5 вариантов кода для рисования кусочков данной линии, и хитрая схема переходов между ними. Схема переходов для линий скорее горизонтальных чем вертикальных (|dy|<|dx|) выглядит так:
1/8 0->01248 1248->0
1/7 0->1248 124->0 8->01
1/6 0->248 12->0 4->01 8->12
1/5 0->48 1->0 2->01 4->12 8->24
1/4 1->01 2->12 4->24 8->48 0->8
2/7 1->12 9->1 2->24 4->48 8->89
1/3 2->24 1->2 4->489 9->12 8->9
3/8 2->459 5->2 4->9A A->4 9->24
2/5 2->59 5->2 4->9A 9->24 A->45
3/7 2->9A 5->24 9->45 A->59 4->A
1/2 5->245 9->5 A->59A 24->A
4/7 5->56A BD->5 A->ABD 6->A
3/5 5->6A B->5 6->AB A->BD D->56
5/8 5->AB 6->BD B->56 D->6A A->D
2/3 6->BD B->56 5->B D->6AB A->D
5/7 6->DE 7->6 B->67B D->BD E->D
3/4 7->67 B->7B D->BD E->DE 6->E
4/5 7->7B F->7 B->BD D->DE E->EF
5/6 7->BD B->DE D->EF F->7B E->F
6/7 7->DE B->EF F->7BD DE->F
7/8 7->EF F->7BDE BDE->F
8/8 F->7BDEF 7BDE->F
Здесь 1/8 означает что данная схема переходов работает для линий с отношением dy/dx от 0/8 до 1/8, то есть почти горизонтальных, 1/7 для линий от 1/8 до 1/7, и так далее, 8/8 для линий от 7/8 до 8/8 то если почти диагональных. Кусочек линии из 4х точек закодирован 16-ричной цифрой, где нулевой бит означает смещение вправо после рисования точки, а 1 смещение по диагонали: 0 - рисуем 4 точки по горизонтали и смещаемся вправо для следующего кусочка, 1 - рисуем 4 точки по горизонтали и смещаемся по диагонали, F - рисуем 4 точки по диагонали и смещаемся по диагонали, E - рисуем 4 точки по диагонали и смещаемся вправо, 5-рисуем две точки, смещаемся по диагонали, рисуем еще 2 точки и опять смещаемся по диагонали, ну и далее в том же духе.
Если посмотреть на строку помеченную как 1/5, то можно увидеть, что после рисования кусочка из 4 точек, нужно сделать 1 условный переход, чтобы выяснить какой из двух кусочков рисовать дальше. Есть правда и такие строки как 1/8 или 8/8 где после рисования горизонтального или диагонального кусочка есть целых 5 альтернатив, и для их выбора требуется 2-3 условных перехода, но зато только одна альтернатива после рисования любого другого кусочка, и в среднем на одну точку будет приходиться раза в два-три меньше сравнений и переходов.
Конечно такое количество вариантов закодировать нереально, меня хватило только на 1/8 и 8/8 как самые простые и понятные, и проверка показала, что данные варианты рисуют 256 почти горизонтальных линий за время от 13 до 20 кадров(против от 22 до 25), почти диагональные линии за время от 35 до 32 кадров против от 39 до 41 у кода с группировкой 4x сравнений и 4х рисований точек, не говоря уже про варианты с вращением маски, которые требуют кадров по 50. В общем для быстрого рисования нужно для каждой линии компилировать свой алгоритм.
Как-то я пропустил. Круто, но даже вариант с группировкой по 2 все не соберусь реализовать, хотя уже все придумано/продумано. Причем я созрел только на "тупую" группировку - расчет группируется по 2 и рисование по 2, но рисование каждой точки отдельно с декрементом счетчика и проверкой окончания. В итоге экономия только на пересылках ошибки в A и обратно. Можно еще подумать и сделать рисование линий четной длины + (если нужно) еще одной точки. Но настолько громоздко, что нет никакого желания реализовать это.
blackmirror
03.01.2018, 01:00
Не знаю, насколько это может быть полезно для реального кода, но есть мысль, что всю линию можно нарисовать имея код для рисования двух небольших отрезков. Совсем в тривиальном случае мы это делаем рисуя единичные отрезки по горизонтали или диагонали, но такие отрезки можно и укрупнить. Например линию dy/dx=144/233(числа Фибоначчи) можно рисовать парой отрезков /-/ и /-/-/, здесь "-" это движение вправо, а "/" это движение по диагонали. Можно все отрезки из трёх точек прицепить к отрезкам из 5 точек и рисовать линию отрезками в 5 и 8 точек или пойти дальше и рисовать линию отрезками в 8 и 13 точек. Для других линий отрезки будут другие, например для рисования линии 92/255 можно использовать отрезки -/--/-/--/- и -/-, хотя тут тоже можно рисовать отрезками в 11 и 14 или в 11 и 25 точек. Для линии 197/252 можно использовать отрезки //-///-// и //-//. Для почти горизонтальных или почти диагональных линий базовые отрезки могут получаться слишком длинные и там могут потребоваться другие алгоритмы.
Общий алгоритм выбора отрезков пока еще не совсем ясен, но если взять целые числа, умножить на dy, вычислить остаток от деления на dx, и вычесть dx если остаток получился более dx/2, то мы получим табличку насколько изменяется ошибка при рисовании отрезка длиной n точек. Для первого отрезка нам подойдёт n1, которое даёт минимальное изменение ошибки по сравнению со всеми предыдущими, а для второго n2 которое даёт еще меньшее изменение ошибки и кроме этого в другую сторону. Для 144/233 табличка ошибок и подходящие для рисования отрезки выглядят так:
1 -89 /
2 55 /-
3 -34 /-/
4 110
5 21 /-/-/
6 -68
7 76
8 -13 /-/-//-/
9 -102
10 42
11 -47
12 97
13 8 /-/-//-//-/-/
14 -81
15 63
16 -26
17 -115
18 29
19 -60
20 84
21 -5 /-/-//-//-/-//-//-/-/
22 -94
Теория ушла далеко вперед, практика сильно отстает.
Какбыдизерингом легко получить 7 довольно убедительных (особенно на реальном элт тв) оттенков синего вместо штатных 4. Причем с разрешением до 256x256.
ivagor, даешь clrs в котором 8 синих строк!
https://youtu.be/wdYbeqP5KPs вот типо последние достижения многоцветного zx... интересно потянет ли Вектор эту игру даже просто используя штатные режимы? Что интесно наложения предметов нету вообще, все в своих знакоместах, по идее годится для перевода даже на чисто vt52 терминал
bigral, все "нештатные" режимы для игр не годятся, они слишком эзотеричны для нормального использования.
В спектрумовских играх есть чему поучиться. Например, как отбросить несущественные аспекты представления ради достижения цели. Атрибуты-клёш? Сотрем фон, оказывается это смотрится совсем неплохо. У Вектора нет атрибутов, но вычисление наложения спрайта на фон невыносимо медленно и можно было бы хорошо сэкономить, просто стирая фон. Не знаю, сколько игр осталось несделанными просто из-за того, что авторы слишком рано и слишком глубоко закопались в рисование спрайтов.
Что до этой игры и игр вообще, по-моему тут вопрос дизайна в первую очередь: кто-то должен такое придумать. Сделать — это уже вторично. Технически ничего архисложного для Вектора тут не видно. Но если и найдется проблема, всегда же можно найти компромисс, чем-то несущественным пожертвовать ради общего дела.
Сделал таки вращение проволочного кубика. Хотя строго говоря на экране отображается параллелепипед, т.к. нет коррекции соотношения сторон.
14-14.5 FPS
Самая долгая операция - собственно рисование кубика. Использовал процедуру рисования линии (http://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=942572&viewfull=1#post942572) по заветам blackmirrora.
- - - Добавлено - - -
Забыл написать клавиши управления: курсор+F1/F2. TAB - исходное положение.
Красота! А отсечение тыльных сторон + модели посложнее планируешь сделать?
Удаление невидимых ребер хотелось бы сделать.
С моделями посложнее принципиальных проблем нет (кроме быстродействия). Разве что надо бы как-то стандартизовать описание.
- - - Добавлено - - -
Точнее описание углов я уже явочным порядком стандартизовал, а описание ребер - пока нет.
Сделал таки вращение проволочного кубика.
Даешь ютуб!
На ютубе меня нет, но можно посмотреть прямо с яндекс диска (https://yadi.sk/i/V4nvBE5H3UcDJa)
Расширил возможности управления. Теперь клавишами 1-6 можно выбрать один из 6 вариантов "абсолютно-относительного" управления (в cube3dv2 был вариант соответствующий клавише 1), при этом кубик переходит в исходное положение (TAB только переводит в исходное положение без переключения варианта управления). Из исходного положения может показаться, что разницы нет, но она становится понятна при повороте по нескольким осям. Мне самому кажется наиболее понятным вариант 6. Может возникнуть вопрос - почему бы не использовать "абсолютное" управление? Пробовал такой вариант, но точность целочисленной реализации невысокая, и после долгих поворотов и вращений становятся видны огрехи. А выложенные варианты можно вращать сколько угодно без видимых проблем.
- - - Добавлено - - -
Наверно стоило для повышения наглядности вместо кубика использовать несимметричную фигуру.
- - - Добавлено - - -
Насчет "абсолютно-относительного" управления. Можно сказать иначе - кубик в кардановом подвесе.
Если задача вращать единичный объект, то можно не сам объект крутить в пространстве (меняя координаты его вершин), а "камеру" вокруг него, меняя координаты расположения камеры. Тогда погрешность (приводящая к искажениям объекта) вычислений координат вершин объекта не будет накапливаться.
Так и в случае вращения объектов незачем копить погрешность.
Насчет управления хочу окончательно прояснить, без непонятных "абсолютного" и других неортодоксальных терминов.
Как написал выше, в выложенных вариантах кубик как бы находится в кардановом подвесе. При этом одна ось вращения фиксирована, вторая меняет положение относительно первой, третья - относительно второй. Три оси дают 6 возможных комбинаций.
Другой возможный вариант - когда все три оси вращения фиксированы. К сожалению реализовать его без накопления погрешности вращения я на данный момент не смог. Честно говоря особо и не пытался. Кстати очень забавно кубик выглядел после долгого вращения (моделировал в матлабе с целочисленной арифметикой) при использовании других проекций, например прямоугольной или косоугольной фронтальной (хотел обойтись без деления, но эти проекции меня не устроили).
Насчет вращения камеры. Пока не смог сообразить, в чем принципиальная разница.
По-моему "как в кардане" — это назвается в каноне углами Эйлера. Так и надо, это позволяет однозначно задать положение объекта самым дешевым способом. И, главное, интуитивно понятным.
Вокруг "фиксированных" осей, погрешность из-за вращения вокруг оси, которая вычислена уже с погрешностью итд? С ними еще проблема очередности применения вращения. Все время все вращается не вокруг того, что ожидал. Так можно с ума сойти очень быстро.
Современный способ решения трансформации в 3D пространстве — через кватернионы.
О, нашел клевый термин: складывание рамок (https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BB%D0%B0%D0%B4%D1%8B%D0%B2%D0%B0%D 0%BD%D0%B8%D0%B5_%D1%80%D0%B0%D0%BC%D0%BE%D0%BA).
Не знал, что практически разговариваю прозой, вернее почти использую поворот на углы Эйлера. После микроскопической переделки получилось без почти. Теперь при описании управления могу сослаться на вики (https://ru.wikipedia.org/wiki/%D0%A3%D0%B3%D0%BB%D1%8B_%D0%AD%D0%B9%D0%BB%D0%B5% D1%80%D0%B0)
Курсор влево, вправо - изменение угла прецессии.
Курсор вверх, вниз - изменение угла нутации.
F1, F2 - изменение угла собственного вращения.
TAB - исходное положение.
При вышеописанном вращении каждый раз танцую от печки, т.е. от исходного положения. А при вращении вокруг фиксированных в пространстве осей каждый поворот независимый и относительно предыдущего положения. При этом накапливаются погрешности.
Про кватернионы бегло почитал, но как из полученных выражений следуют заявленные преимущества для меня пока не очевидно. Надо еще читать и разбираться, увы я не такой умный и быстрый, как хотелось бы.
- - - Добавлено - - -
Может для Эйлера поменять F1/F2 с курсором влево-вправо? Т.е. чтобы курсор менял угол собственного вращения, а F1/F2 - угол прецессии.
Если бы ты Блендер портировал на Вектор, можно было бы поспорить за клавиши. Пока я рад любым комбинациям мутации и рецессии.
В кватернионах по-моему идея в том, что мы получаем проекцию из высшей размерности, но врать не буду, потому что у меня тоже никогда не было сил разобраться.
Навеяло...
Когда-то в универе делал контрольные по комп. графике. А в методичке были приведены матрицы преобразований с ошибками. Долго маялся, в результате взял учебник геометрии за 7 класс, пересчитал все преобразования, получил систему уравнений, которая была визуально очень похожа на матрицу преобразования из методички. И сразу увидел где в матрице ошибки.
Тож крутили разные кубы, октаэдры, "проволочные" и с удалением не видимых рёбер... как давно это было...
Сделал отсечение невидимых граней, теперь кубик "сплошной", не просвечивает. Ускорить можно, но пока не уверен, что буду этим заниматься.
Управление как в предыдущей версии (http://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=960806&viewfull=1#post960806)
Добавил один важный момент - коррекцию соотношения сторон. Т.к. этот вопрос вызвал недавно сильную (с переходом на личности) полемику, реализовал 3 варианта (переключаются клавишами 1-3):
1 (по умолчанию) - AR=4:3, как в эмуляторах
2 - AR=5:4 (если точнее, то 59:48), результат моего расчета, который выкладывал в двух темах, считаю, что так на реале. Приложил конфиг для emu, можно его скопировать в каталог эмулятора, чтобы посмотреть как это выглядит. Коррекцию сделал только для оконного режима, полноэкранный emu у меня на основном компе не работает и я этот режим не трогал.
3 - AR=1:1, т.е. без коррекции, как в предыдущих версиях
Добавил один важный момент - коррекцию соотношения сторон. ...
2 - AR=5:4 (если точнее, то 59:48), результат моего расчета, который выкладывал в двух темах, считаю, что так на реале. ...
На ч/б мониторе "Электроника" с 02-ым Вектором, вариант "2" - даёт практически квадрат по соотношению сторон.
А вот на ТВ-тюнере (карта видеозахвата) с выводом на монитор, при разрешении 1024х768, настройках экрана тюнера 3:4, квадрат не получается на с одним вариантом. Но тут у самого монитора рабочая поверхность экрана не совсем 3:4.
О, подобрал. При разрешении монитора 1280х1024, ТВ-тюнер 3:4, при изображении "в окне", вариант 2 так-же даёт квадрат.
Ускорил кубик и добавил изменение размера. Думаю можно считать релизом. Добавил readme.txt
Здорово получилось. Плавно крутится.
А мат.модель позволяет объединить смещения? Что-бы крутил одновременно по двум или трём осям?
F1 и F2 удобнее (мне кажется) перенести на кнопки "влево-вверх" и "Стр".
F3 и F4 соответственно на F4 и F5.
А мат.модель позволяет объединить смещения? Что-бы крутил одновременно по двум или трём осям?
Да, крутить сразу по нескольким осям можно, проблема только в клавиатуре вектора, которая не позволяет определить одновременное нажатие всех клавиш. Хотя теоретически можно попробовать подобрать такие клавиши, которые допускают определение одновременного нажатия. У эмуляторов на компе, кстати, тоже есть ограничения по данному вопросу.
F1 и F2 удобнее (мне кажется) перенести на кнопки "влево-вверх" и "Стр".
Думал об этом, на реале это хороший вариант, зато в эмуляторах не очень. Возможно стоит продублировать.
F3 и F4 соответственно на F4 и F5.
Пожалуй да, F4/F5 в одном ряду на реале, а F3/F4 в разных да еще и "вразброс"
- - - Добавлено - - -
Насчет одновременного вращения по нескольким осям. Надо признать, что кроме ограничений клавиатуры вектора или PC у меня и программа сочетания не переваривает (не математика, а именно опрос). Доработаю.
Можно команды вращения сделать переключателями. Один раз нажал стрелку влево, или вправо, и поехало прецессировать. Нажал вверх, к этому присоединилась нутация. Еще чего-нибудь, конвекция. Еще другую, дедукция. И в обратную сторону так же — либо обратную стрелку нажимать, либо TAB, чтобы цыц.
Можно команды вращения сделать переключателями. Один раз нажал стрелку влево, или вправо, и поехало прецессировать.
До того, как сделал первый вариант, так и планировал. А когда сделал и попробовал вращать у меня стал ум за разум заходить и я решил - лучше пошагово. Но после перехода к углам Эйлера появилась шпаргалка, да и сам попривык, может действительно стоит вернуться к автоматическому вращению.
Еще дело в том, что обывателю не нужно тестировать алгоритм и на самом деле хочется просто на крутящийся кубик поглядеть. Я за то, чтобы автоматическое вращение было включено сразу при старте.
Возможно вариант с "переключателями" действительно подойдёт для клавиатур реала и эмуляторов без ограничений.
И да, алгоритм опроса клавы много значит. Думаю нужно не останавливаться при обнаружении нажатой клавиши, а проверять все используемые клавиши.
Не знаю как реализовано сейчас. Предположу, что значение неких переменных (с величиной угла поворота), при нажатии клавиши, увеличивается или уменьшается на определённую "константу". И далее вычисления, отрисовка.
Возможно, вычисления и отрисовку нужно сделать постоянными.
Опрос клавы должен приводить к изменению значения "констант" приращения углов. Каждая константа может иметь только три значения, например [-5, 0, 5] (в зависимости от нажатой клавиши). "ТАВ" - сбрасывает все константы в "0".
Например, было "0". Нажал "вниз", получил "-5". Затем нажал "вверх" - получил "0". Снова нажал "вверх" - получил "5"....
Единственное, "но" - значения "констант" изменяемые при анализе клавиатуры, не должны сразу использоваться в вычислениях. В вычислениях должен использоваться второй комплект переменных "константа", их значение нужно обновлять только перед началом нового цикла "вычисление-отрисовка".
Блин, чего накатал...
Изменил клавиши управления и сделал две версии - "пошаговую" (можно вращать по нескольким осям одновременно) и "автоматическую". Автоматическая при вращении вокруг одной оси еще ничего, а вот при вращении по двум или трем осям у меня моск немного ломается. Выложил здесь (https://yadi.sk/d/EkeElPs93VbGvc).
По всем степеням свободы сразу и с одной скоростью это слишком пожалуй. Чтобы не усложнять математику, может быть в автоматическом режиме проредить повороты вокруг второстепенной оси? Например, на три шага прецессии один шаг нутации итд. Тогда моск будет видеть кадры, имеющие меньший логический разрыв между друг другом и, соответственно, рваться не так сильно.
Т.е. что-то вроде такого (https://yadi.sk/d/QPy7NsCF3VbQhq), но чтобы это было более-менее плавно, надо пересчитать косинусы/синусы для меньшего шага. Пока не планирую, но может как-нибудь потом.
Сейчас, когда я запускаю вращение по двум осям, например нажав стрелки влево и вверх, есть ощущение какого-то мотыляния. Как будто бы кубик не просто крутится, а его еще на ветру болтает, или он танцует дабстеп. Может быть и правда дело в слишком большом шаге и получается эдакая эмерджентность.
"Эмерджентность говоришь, хы-х!"
Просто так воспринимается, думаю с шагами поменьше смотрелось бы лучше
- - - Добавлено - - -
Рассчитал косинусы/синусы с шагом в 2 раза меньше (rom здесь (https://yadi.sk/d/7SWeX7Bt3Vbm75)).
Немного изменил принцип управления, по сравнению с v12. Теперь по каждой оси возможны 5 вариантов скорости: -2, -1, 0, 1, 2. Соответственно можно разогнать или затормозить по желаемой оси вручную.
v13 очень симпатично крутится. Не хватает вариантов скорости ±0.5. Но это уже изыски. Про этот кубик уже можно моск не ломая сделать вывод, что он кубичен и вертится.
Тогда v14 (https://yadi.sk/d/rDiGnV9D3Vc8YR) тебе должен понравиться еще больше, он даже мне понравился. Еще в 2 раза уменьшил шаг синусов/косинусов, вариантов скорости теперь по 9, от -4 до 4 с шагом 1.
- - - Добавлено - - -
Надо бы собраться и сделать индикацию скоростей
Это уже почти Элита. Осталось доделать детали =)
Ну да, осталось начать и закончить. Элиту на векторе интересно бы посмотреть, но не думаю, что можно обеспечить приемлемую скорость. Даже на спеке заметно тормозит, хотя я в детстве играл и особых претензий по скорости не предъявлял. Больно уж игровой процесс увлекательный.
Это редко обсуждаемый аспект Элиты. Собственно космос там в основном для того, чтобы в начале повосторгаться тремя Д на чугунном компьютере. Потом он только мешает. Но я вот больше как раз с точки зрения первичного восторга: что-то типа твоего кубика, но побольше деталей и с музыкой и было бы уже ух! А игра, ну ее, кто в нее не наигрался то еще.
Нельзя исключить полностью, но вероятность чего-то бОльшего (тем более творческого) по этой теме небольшая. Вот индикаторы скорости стоит приделать.
Эх, еще бы полигоны закрасить, наверное тормозить будет сильно, но теоретически 3 цвета можно сделать (правда один из цветов совпадет с цветом линий).
Если ограничить размер проекции кубика до 128x128, то можно и 7 (+8й фон) цветов сделать. Проблема действительно в скорости. Проволочные модели еще приемлемо, а текстурированные, хотя бы даже закрашенные одним цветом на грань - это уже будет совсем грустно.
Простой, но прикольный эффект для БК (https://www.youtube.com/watch?v=jlMS5s0ImM4&feature=youtu.be&t=492). На векторе вроде так не делали, хотя с 16 цветами можно сделать круче.
ivagor, с прокруткой, которая из просто вертикальной вдруг становится еще и горизонтальной? Я это видео смотрел но, честно говоря, не до конца понял, что именно там происходит. Откуда берется горизонтальное смещение? На Векторе можно замесить циклическое прокручивание палитры, но на БК разве так делалось?
Откуда берется горизонтальное смещение?
Из вертикального конечно. Не зря же там объекты по диагонали расположены.
Набросал воспроизведение того БКшного эффекта (исходник прилагается). В нем главное, конечно, это картинка, творческая сторона. При желании можно хоть попиксельный скролл изобразить.
Пара замечаний:
1. Как и любой фреймовый скролл эту штуку лучше смотреть или на реале или в эмуляторе, который (эмулятор) синхронизируется с разверткой писишного монитора, который (монитор) должен быть в режиме 50 Гц. Можно, конечно, и без всех этих заморочек, но эффект будет не совсем тот.
2. Поддерживается и диагональный скролл, если нажимать 2 клавиши одновременно (по крайней мере в эмуляторе, насчет реала уверен не на 100%).
Набросал воспроизведение того БКшного эффекта ...
На реале диагональный скролл видно, и даже в правильном направлении.
Только скролл слишком быстрый, что вертикальный/горизонтальный, что диагональный. Наверное даже в 2-3 раза можно замедлить.
Воткнул сканирование клавы (скролл) "не каждое прерывание", замедление получилось нормально, но шаг смещения получается великоват - смещение картинки скачками...
Сделал попиксельный скролл. Надо было сразу так сделать, этот вариант и в эмуляторе нормально смотрится (и даже мне самому понравился).
Попиксельный обалденно смотрится! Давай еще четыре плана с разными сдвигами.
Можно, кстати. сюда применить идеи svofski по управлению объектами, реализованные в 3х мерной вращалке. Т.е. нажатие клавиш может управлять не собственно перемещением, а скоростью перемещения в данном направлении. И можно сделать (тоже как во вращалке) несколько градаций скорости.
- - - Добавлено - - -
Насчет нескольких планов, цветов и всего такого - тут первична картинка, если есть творческие люди, то они могут допилить шаблон до нужной кондиции, сам я рисовать не умею.
Ну просто шашечки разного размера.
Просто чтобы продемонстрировать интересующимся, как это может выглядеть, сделал вариант с двумя битпланами (перемещение здесь только вправо-влево, вверх-вниз убрал). А вобще на векторе можно до 15 битпланов забабахать.
- - - Добавлено - - -
на векторе можно до 15 битпланов забабахать
Это если каждый своим цветом делать
ivagor, ну ваще!! Очень красиво. Пили интру на цц.
Респект изобретателю эффекта.
Насчет множества битпланов. Это субъективно, но возможности вектора похоже превышают мои возможности восприятия - 3 битплана еще приемлемо, а при 4-х при быстрой прокрутке уже сложно что-то разобрать кроме переднего и мельтешения на заднем плане.
Просто чтобы продемонстрировать интересующимся, как это может выглядеть, сделал вариант с двумя битпланами (перемещение здесь только вправо-влево, вверх-вниз убрал). ...
Вот жешь блин... я на ч/б второго плана не вижу :(
На реале перемещение плавное и четкое, а ТВ-тюнер "размывает" при перемещении.
на ч/б второго плана не вижу
Совсем?
1. Если дело в цвете (в его яркости на ч/б), то можно попробовать поменять Red .equ 6 на более яркий, например на 48 (зеленый). Но это странно, помню что красный на моем ч/б был виден. Т.е. я вряд ли мог для произвольной незнакомой картинки определить по яркости - "да, это точно красный", но в обратную сторону, когда сам рисовал красные элементы, они были видны.
2. Проблема с программированием палитры. Имхо маловероятно, т.к. эту процедуру неоднократно успешно использовал, да и в случае непрограммируемости вместо красного д.б. остаться (от загрузчика) желтый, который даже более яркий на ч/б, чем зеленый.
- - - Добавлено - - -
3. Еще один очень маловероятный вариант, но вдруг. Может просто дело в путанице, оба рома (и из hvscroll_1px.zip и из hvscroll_2bitplanes.zip) называются одинаково hvscroll.rom
Совсем?
1. Если дело в цвете (в его яркости на ч/б), то можно попробовать поменять Red .equ 6 на более яркий, например на 48 (зеленый). Но это странно, помню что красный на моем ч/б был виден. ...
Да, совсем не видно, что собственно действительно странно. Не видно ни на ч/б мониторе, ни на ТВ-тюнере (картинка тоже ч/б).
Поменял местами значение у "белого" и "красного" (яркие кружки стали задним планом), и вместо значения 6 поставил 15. Второй план появился. Но в ч/б не очень эффектно, один ряд "бежит" быстрее другого, но из-за взаимного перекрытия, появляется "мерцание" - такие своеобразные волны яркости, идущие по экрану или снизу вверх, или сверху вниз, в зависимости от направления смещения картинки.
Нашел вот такую картинку (http://zx-pk.ru/threads/8739-vektor-06ts-videovykhod-podklyuchenie-k-tv.html?p=947778&viewfull=1#post947778). На ней девятки цветом 6 (красный) и они видны. Может с тех пор что-то отвалилось в векторе в районе формирования оттенков серого для ч/б ТВ?
Нашел вот такую картинку (http://zx-pk.ru/threads/8739-vektor-06ts-videovykhod-podklyuchenie-k-tv.html?p=947778&viewfull=1#post947778). На ней девятки цветом 6 (красный) и они видны. Может с тех пор что-то отвалилось в векторе в районе формирования оттенков серого для ч/б ТВ?
Точно...
Запустил тот тест, нескольких колонок нет. Только не отвалилось, а резюк на "уровне черного" уплыл. Покрутил его и все колонки снова появились, видать окислился.
На демке появились оба плана.
Пардонте за "шухер"...
KTSerg, нет худа без добра, зато теперь вектор снова в полной боевой готовности. Еще раз спасибо за проверку на реале!
Завершая тему "аппаратного горизонтального скролла" выкладываю вариант с 4мя битпланами. Вспомнил, как делали в демках с битпланами настоящие демомейкеры - у них были больше расстояния между соседними элементами. Увеличил расстояния и стало приемлемо. Пришлось еще пару изменений внести - шаги в 2 раза больше, но сдвиг в 2 раза реже, зато можно разглядеть. Исходник этого варианта не выкладываю, т.к. слишком много копипасты, поленился сделать нормально.
Хочу и тему с трехмерными фигурами тоже закруглить. В финальном варианте можно повращать не только кубик, а одну из 4х фигур. Также расширены пределы изменения скорости в сторону медленных вращений.
Хочу и тему с трехмерными фигурами тоже закруглить. В финальном варианте можно повращать не только кубик, а одну из 4х фигур. Также расширены пределы изменения скорости в сторону медленных вращений.
Крутотень...
А на больших скоростях, у меня в глазах двоится, или эффект какой-то проявляется? Правда это скриншоты с ТВ-тюнера, но на обычном мониторе выглядит аналогично.
Про тюнер есть предположение. Тюнеры, с которыми я имел дело, в кадр с высотой 576 точек захватывают 2 сформированных вектором кадра (в четные и нечетные строки). Т.е. тюнер захватывает 25 чересстрочных кадров в секунду и их потом нужно разделять построчно на 50 кадров/секунду. Это еще не все. Если в настройках включено удаление чересстрочности, то изображение размазывается и разделение строк становится невозможным. Поэтому при захвате я отключал всю пред- и постобработку. Простой способ проверить это предположение - отключить все улучшайзеры (в первую очередь деинтерлейсер), захватить кадр и посмотреть четные/нечетные строки.
С монитором сложнее. Про современные ТВ могу сказать, что у них, как правило, тоже есть деинтерлейсинг и не факт, что его получится отключить. Вспоминаю, что svofski с этим сталкивался, а потом, с его подачи, и я.
Если монитор старый (ЭЛТ), то тут развожу руками, возможно просто так кажется.
- - - Добавлено - - -
Можно даже программно попробовать бороться с этой штукой. Предлагаемый вариант моргает (и скорость немного меньше), но скриншоты с него должны быть без задвоения даже если не разделять кадр на строки и при включенных улучшайзерах.
Я пока ленюсь подключать реал, чтобы заценить на ЭЛТ. Но лучше не торопиться делать изменения в коде, идя на поводу у сомнительных деинтерлейсеров. Сколько я переживал из-за Рива Рейда на лцд, например. А тут вообще бесплатный motion blur.
(страдая) запилите видос на ютубе!
Запусти в эмуляторе. Видос не будет лучше.
Про тюнер есть предположение. Тюнеры, с которыми я имел дело, в кадр с высотой 576 точек захватывают 2 сформированных вектором кадра (в четные и нечетные строки). ...
Про совмещение, в тюнере, двух кадров в одном, я знаю. Много раз видел этот эффект на скриншотах. По этой причине и написал, что возможно тюнер виноват.
На фотике батарейки сели, что-бы экран монитора сфоткать.
Подозреваю, что каждое новое положение объекта отрисовываются в "отключенной" экранной плоскости, а во время прерывания, меняется палитра - в новом кадре подменяется видимая плоскость. Соответственно не возможно одновременное отображение двух положений (старого и нового) объекта. Т.к. исключаю ошибку значений цвета в палитре.
В итоге, считаю, что отступление про "двоится в глазах" можно будет удалить, а наблюдаемый эффект списать на странности зрительного восприятия.
Кстати о зрительном восприятии.
В нете когда-то видел фотки клубники. В описании утверждалось, что фотка черно-белая (точнее оттенки серого), но по какой-то причине, люди видят, что клубника явно красная.
Так вот. В "окончательной" (многоплановой) версии демки со скроллингом, которую я смотрел на ч/б мониторе, во время смещения колец, они казались цветными! Мне казалось, что они зелёные, цвет был конечно бледным, но во время движения они явно были не серыми. Только после остановки, кольца снова постепенно становились серыми...
Во глючу да... и вроде не курил ничего...
KTSerg, во хорошо тебе, не надо никаких субстанций :) Я вспоминаю что-то про мельтешение на экране, которое превращается в цветность. Очень давно, у меня причем тогда был чб монитор. И сам я словить этот эффект тогда не смог, так что подумал, что не-а.
С клубникой это другой эффект, там наверное были приглушенные дополнительные цвета?
Про мельтешение.
На тёмном фоне, по кругу, бегает серое пятнышко. Если следить за ним, оно серое, если смотреть в центр экрана, пятнышко становится цветным.
А про цветную клубнику, скорее всего манипуляция, тема легко гуглится.
Наверное палочки резко срабатывают и оказывают наводки на колбочки. Там же все сделано тяп ляп как попало и работает только благодаря ловким патчам в фирмвари, да и то не всегда и завалить легко.
Вот пример:
https://upload.wikimedia.org/wikipedia/commons/5/5d/Disappearing_dots.gif
Это совсем простой случай. Тут исчезает кружочек и в глазном нерве перерегулирование, которое мы видим как кружочек дополнительного цвета. Это потому что глаза к зрительной коре подключены цветоразностным проводком (компонент).
Про кажущуюся раскраску движущихся ч/б объектов есть такой пример (https://io9.gizmodo.com/5918913/see-black-and-white-turn-to-color-in-this-optical-illusion)
Это ладно, бывают ещё невозможные aka химерические цвета, которые возможно увидеть. Например - Stygian Blue, или цвет "ярче белого":
https://en.wikipedia.org/wiki/Impossible_color
И никаких веществ :).
Я часто зависаю на клумбах. Там встречаются самые невозможные и невоспроизводимые цвета в пурпурном и фиолетовом диапазонах.
В Noname demo (http://sensi.org/scalar/ware/227/) есть часть с картинкой с разрешением якобы 1024 точки. При этом просто каждый кадр чередуются приложенные картинки. Сам я не вижу причин углядеть в результате 1024 точки, но может у кого-нибудь будет другое мнение.
ivagor, вот я тоже не смог понять, где именно их надо видеть 1024. Может быть, если бы это была картинка во всю ширину, было бы понятней. Типа черезстрочность, но по вертикали. А тут два одинаковых слайда слева и справа, в чем смысл не ясно.
Откопал стюардессу (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=966175&viewfull=1#post966175)
1. Расчет вращения ускорен практически в два раза. При большИх размерах фигур бОльшую часть времени занимают остальные операции, поэтому ускорение будет более заметно при меньших размерах фигур. При больших размерах фигур ускорение можно заметить при вращении по всем трем осям.
2. Убрал лишнюю задержку, связанную с кадровой синхронизацией (синхронизация осталась, убрал именно лишнюю задержку), вместе с эффектом от предыдущего пункта ускорение видно невооруженным взглядом.
3. Увеличена точность расчета при отсечении невидимых граней. Это позволило уменьшить минимальный размер фигур без погрешностей в отсечении.
4. В связи с добавлением эмуляции вектора в Emu80 убрал один из вариантов коррекции сторон (4:3) и оставил только 5:4 (по умолчанию) и 1:1 (без коррекции). Клавиши переключения соответственно изменились. Убрал из архива конфиг для emu c 5:4.
Я нарочито игнорирую (https://i.imgur.com/3Aw4RY1.jpg) новые спасибки, но в этом случае не могу промолчать и выражаю свой восторг от новой версии. Вот кстати она в картотеке, кому лень запускать эмулятор руками: [906 (http://www.sensi.org/scalar/ware/906/)]
ivagor, я присоединяюсь с бестами и регардами: это хорошо!
Немного цифр по скорости вариантов 17 и 20. Для простоты взял исходную фигуру (куб) исходного (максимального) размера.
Вращение по одной оси
17:12.5 FPS; 20:16.67 FPS
Вращение по двум осям
17:10-12.5 FPS; 20:16.67 FPS
Вращение по трем осям
17:10 FPS; 20:12.5-16.67 FPS
Можно свести простой процессора на кадровую синхронизацию к минимуму перейдя к тройной буферизации и еще немного поднять FPS, по крайней мере в "сложных" пограничных случаях.
KTSerg, спасибо на добром слове, но на "круто" все же не тянет, скорее "нормально".
Что потенциально можно улучшить:
1. Расчет вращения. Самая долгая операция - умножение, в 20 оптимизирована по максимуму, вычисляется по таблице. Но вокруг код рыхлый, можно его уплотнить. С другой стороны сейчас зато понятно, я вот через год смог вспомнить-разбраться.
2. Проекция. Деление реализовано самой быстрой известной процедурой, без таблиц (которые без залезания в кваз уже негде хранить) не ускорить.
3. Отсечение невидимых граней. Умножение можно ускорить.
4. Стирание и рисование - уже некуда ускорять. Стирание стеком, рисование самой быстрой известной процедурой.
Резервы есть в вышупомянутой тройной буферизации, оптимизации неглавного умножения и деления, и в целом можно пробежаться по коду и везде подоптимизировать. Но 25 FPS при максимальном размере кубика вряд ли будет. Железного минимума 16.67 FPS вполне реально достичь.
Оказалось, что можно еще сократить задержку ожидания кадровой синхронизации без перехода к тройной буферизации.
При вращении исходного кубика по трем осям с максимальной скоростью
средний FPS в 20: 14.8
средний FPS в 21: 16.4
electroscat
24.09.2019, 13:54
Да я уже сделал по этой теме больше чем хотел. Выкладываю исходник последнего варианта, вдруг кто-нибудь еще поиграется.
И да, lfsr очень удобен для данного применения легкостью масштабирования, прямо красиво.
Доброго времени! Прошу прощения за беспокойство, я только разбираюсь в программах на асемблере, и сейчас пытаюсь разобраться с графикой. Очеь интересно, в ваших исходниках лежит файл baboon.pic - я пытался открыть его разными редакторами и программами, просматривал его в hex редакторе, и ничего не нашел, что говорило бы о его параметрах и о том, что это вообще такое. Понимаю, что это код картинки, но как он получается, подскажите пожалуйста, хотя бы намекните, от куда получается этот дамп?
И еще одна вещь меня интересует, может не совсем в тему, но интересно...
Как на асемблере обратиться к текстовому файлу, находящемуся на дискете или жестком диске, с определенным именем, прочитать определенное количество строк из него ? всего этого нет в руководстве по ассемблеру вроде, векторовскому.. Помогите пожалуйста разобраться, или по крайней мере скажите, где можно информацию поискать ?
И еще вопрос, в батнике у вас опция -b компилятора используется, а в tasm 3.0.1 такой опции нет.. Подскажите каким компилятором вы пользуетесь ? Прошу еще раз меня простить за такое количество вопросов... Очень хочется освоить асю.. Но пока только Pretty 8080 Assembler могу считать более менее понятным )))))) Спасибо огромное автору !!!
Заранее очень благодарен !!!
Improver
24.09.2019, 15:05
Попробую ответить на один из вопросов...
Как на асемблере обратиться к текстовому файлу, находящемуся на дискете или жестком диске, с определенным именем, прочитать определенное количество строк из него ? всего этого нет в руководстве по ассемблеру вроде, векторовскому.. Помогите пожалуйста разобраться, или по крайней мере скажите, где можно информацию поискать ?Тут всё сложнее, чем кажется... Есть два варианта запуска программ на Векторе: полностью автономный и из какой-либо операционной системы. В первом варианте нужно в программу на ассемблере добавить подпрограммы обращения к диску, считать нужные сектора с каталогом, найти запись нужного файла, считать перечисленные там сектора, выделить из двоичных данных строки... Второй вариант немного проще, там не нужно изобретать велосипед, а можно просто использовать средства ОС. В общем случае можно почитать, например, эту документацию по системным вызовам Микродос (http://zxpress.ru/book_articles.php?id=2322), или вот ещё по CP/M (http://atmturbo.nedopc.com/inf/bios_cpm.htm).
файл baboon.pic - я пытался открыть его разными редакторами и программами, просматривал его в hex редакторе, и ничего не нашел, что говорило бы о его параметрах и о том, что это вообще такое.
Это просто копия трех плоскостей вектора, заголовка там нет. Параметры, если их так можно назвать, фактически содержатся в программе.
Как на асемблере обратиться к текстовому файлу, находящемуся на дискете или жестком диске, с определенным именем, прочитать определенное количество строк из него ? всего этого нет в руководстве по ассемблеру вроде, векторовскому.. Помогите пожалуйста разобраться, или по крайней мере скажите, где можно информацию поискать ?
Можно начать смотреть здесь (http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm), там не на 100% совпадает с ТЗ, но близко.
опция -b компилятора используется, а в tasm 3.0.1 такой опции нет.. Подскажите каким компилятором вы пользуетесь ?
Использую TASM 3.2 (https://www.ticalc.org/archives/files/fileinfo/250/25051.html)
electroscat
24.09.2019, 15:54
Есть два варианта запуска программ на Векторе: полностью автономный и из какой-либо операционной системы.
Благодарю за ссылки, интересует как раз второй вариант, из под системы, буду изучать, Спасибо !
- - - Добавлено - - -
Параметры, если их так можно назвать, фактически содержатся в программе.
Благодарю, углублюсь в код...
Можно начать смотреть здесь (http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm), там не на 100% совпадает с ТЗ, но близко.
Это тоже пригодится, спасибо огромное за ссылочку, я собираюсь из под оси файл доставать, но для общего развития, уверен, очень ценно.
Использую TASM 3.2 (https://www.ticalc.org/archives/files/fileinfo/250/25051.html)
Спасибо !
собираюсь из под оси файл доставать, но для общего развития, уверен, очень ценно.
Ну это как раз "из под оси", пример "5.4 A Sample File Dump Utility" почти то, что нужно - читает файл заданный в командной строке и печатает, только бинарный в hex-виде, а не текст.
После прочтения статьи про ошибку в 1801ВМ1 (https://zx-pk.ru/threads/23978-tsifrovaya-arkheologiya-1801-i-vse-vse-vse.html?p=1029492&viewfull=1#post1029492) решил портануть калейдоскоп и на вектор. Особо не напрягался, можно сделать и быстрее и короче, зато сравнительно быстро сделал и вроде даже работает.
electroscat
23.12.2019, 11:30
Хочу поделиться своей первой програмкой на ассемблере 8080, для вектора. Она как раз к спецэффектам относится.. Вот тут я ее описал : https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1039328&viewfull=1#post1039328 И скриншоты там есть... Приурочил к тому, что форум таки снова в доступе ! Спасибо что есть такой рессурс !!!https://sun9-32.userapi.com/c855628/v855628679/1b8b26/Ko7bH2-foSc.jpg
Пока нормальные люди готовятся или уже отмечают новый год я успел доделать некую специфическую, странную и некрасивую штуку. Если конкретнее - спектроанализатор сигнала с магнитофонного входа. Это честный анализатор на базе fft, отсюда и его недостатки. Т.к. я спешил и ленился, то сделал только fft-8. На экране показываются 4 полосы с центральными частотами 1302, 2604, 3906 и 5208 Гц. Перекрытие блоков и оконные функции не используются, поэтому в отличие от взрослых анализаторов растекание спектра и алиасинг присутствуют, но я с ними все же немного поборолся. Скорее всего это не первый пример реализации fft для 8080, но я других пока не нашел, поэтому временно горжусь.
Есть альтернативные очень-очень-очень упрощенные варианты анализаторов типа такого (http://www.worldofspectrum.org/infoseekid.cgi?id=0007929). Там фактически многополосный частотомер, в котором не используются умножение, комплексные числа, возведение в квадрат и извлечение корня, т.е. все прелести fft. На вектор анализаторный движок той штуки вполне перелагается, svofski даже пробовал на реале, за что ему большое спасибо, но все же fft лучше, особенно если все же сделать 16 точек. Из эмуляторов для данного применения могу порекомендовать emu80. Скорее всего VV и v06x тоже подойдут, но я не пробовал. emu не очень подойдет, зато я в нем отлаживаю.
Всех с наступающим Новым Годом!
Мегареспект!
Я запустил FFT на реале, но кина пока не делал. Посмотрев типатакое я уже гурман и впечатления неоднозначные. Обе программы делают невозможное и превосходят все ожидания.
В типатаком много необъяснимых шумов и часто например кажется, что должен прыгать басовый столбик, а прыгает самый верхний. Но иногда можно увидеть и что-то веселенькое. Например, в ППК-Воскресенье в тихом месте весело так все плясало, а в Megablast хоть и верхний столбик прыгал, но очень ритмично и позитивно.
FFT вызывает значительно меньше WTF, это замечательно. Но в том же Воскресенье от этого стало более однообразно, все попадает на одну полосу. Это наверняка правильно, хоть и менее зрелищно. Но вот как-то подозрительно все мельтешит. Может быть экран стирается рановато? По-моему я даже часто вижу верхушки столбиков без низа.
Но вот как-то подозрительно все мельтешит. Может быть экран стирается рановато? По-моему я даже часто вижу верхушки столбиков без низа.
"Признаю свою вину. Меру, степень, глубину." В типотакой программке была синхронизация отрисовки с прерываниями, добавил и здесь. Почему не добавил сразу - сложно сказать, я подумаю над этим.
Я тоже признаю твою глубину! Снял на скорую руку, постарался, чтобы была неправильная экспозиция и нерезко. С наступающим!
https://youtu.be/UVp7JbDOkgQ
electroscat
07.01.2020, 12:05
Дорогие друзья, доработал программку, в целом, скорее всего это крайние доработки, по крайней мере по функционалу, может код чуть оптимизирую еще, но внешне это вряд ли проявится. Научил программку менять палитру, там семь встроенных палитр, восьмая для выхода в microDOS онли, и десять пиксельных блоков 8X8 с разным рисунком. Переключаются палитры клавишей рус\лат, блоки пиксельные (смайлы) переключаются клавишей СС, и автоматически переключение происходит по нажатию УС. Выход в микроДОС - одновременное нажатие УС+СС. Выход опробован под t34,t72 и mdos31h, работает визуально чуть про разному, но работает. Без оси сочетание клавиш не работает. Можно грузить как в загрузчик так и в микродос, работает везде.
Видеообзор тут
https://youtu.be/GnkJOBtv500
Программа : тут (https://yadi.sk/d/p8ZXTM_ZPeidCQ)
- - - Добавлено - - -
В типотакой программке была синхронизация отрисовки с прерываниями, добавил и здесь. Почему не добавил сразу - сложно сказать, я подумаю над этим.
Круто ! как то писал что то подобное на C++, нужно было вырезать диапазон частот из сигнала.. там была математика серьезная, правда там поток информации со звуковой карты был, если честно даже в голове не укладывается как это на векторе возможно, с его "однобитным ацп" :) ! Спасибо !
Нет предела совершенству...
P.S.... Добавил пикселных блоков, теперь их 16, и палитры чутка упорядочил, сделал RGB палитры контрастные. Отработал нерегрузку программы по "БЛК"+"СБР" код оптимизировал, самую малость... Сейчас видео не соответствует программе. Обновил на яндекс диске.
Еще добавил вариант - CM-MAHA.COM и CM-MAHA.WAV (для загрузки с телефона в реал. вектор) - это стилизация под "Матрицу". Пикселные блоки программы предтавляют собой санскритские символы маха- мантры, с небольшим дополнением, и по цветовой гамме это похоже на код "матрицы" из всем известного фильма...
Заменил CM-MAHA.COM и CM-MAHA.WAV на CM-MM.COM и CM-MM.WAV - окончательные версии, проработал с настоящим санскритологом, чтобы написание "деванагари" шрифта соответствовала на 100% действительности, упорядочил символы, сделал смену символа не "поплоскостно" а "построчно" - теперь это аутентичная махамантра, которую в плане правильности написания символов даже санскритолог ободрил.. Управление такое же, УС - останов автоматической смены символа, он же запуск, чтобы все символы можно было просмотреть, СС - переключение символа, когда не автоматический просмотр, и рус\лат - смена палитры. Совместное нажатие "УС"+"СС" - выход в microDOS.
Так же поигрался еще с СМ-SMILE - палитру сменил кое где, символы поменял некоторые, главное - отработал глюк - который меня доставал с самого начала работы программы, иногда последний байт символа заносило в адресс 0000h. И тогда перегрузка программы по БЛК+ВВОД вешала комп, на некоторых символах. Разобрался, и наверняка - это конечная версия.
Xотел бы добавить, общение с санскритологом дало некоторое понимание ассемблера... Санскрит и ассемблер - это очень похожие штуки. Санскрит - это первый язык, вообще изначальный, он был всегда, по крайней мере к такому выводу пришел санскритолог, то есть что то вроде ассемблера, на компе. Машинный код это еще трудные в целом для понимания человека "вибрации", а первый вариант их упорядочить для человеческого сознания, не усложняя - это Ассемблер. И из него уже строятся все остальные языки, но с заметным расширением функционала, то есть неминуемо с усложнением.. Так же примерно и с санскритом и остальными языками..
Недавно Manwe адаптировал (https://zx-pk.ru/threads/19866-demki-dlya-bk.html?p=1077817&viewfull=1#post1077817) для БК известную демку Mona (http://www.pouet.net/prod.php?which=62917). Под влиянием этого факта и svofski я попробовал адаптировать ее на вектор, но у меня пока получилось слишком много байт - 370. Может кто-нибудь попробует сделать покомпактнее? В БКшной демоветке можно пройти по ссылке (https://zx-pk.ru/threads/19866-demki-dlya-bk.html?p=1077849&viewfull=1#post1077849) на описание алгоритма. Уточню, что текущие 370 байт - это цветной вариант, двухцветный (псевдоцветной, как на БК) с запуском из загрузчика можно сделать покороче.
Отказ от некоторых базовых прав и свобод (минус старт из дос и возможность рестарта) позволил сократить до 352 байт. Еще на 100 байт я точно не смогу сократить, жалко, демка прикольная.
Improver
02.09.2020, 08:12
ivagor, а результат всех этих действий где можно взять посмотреть (на Векторе)?
Постараюсь дожать хотя бы до 350 и тогда наверно выложу
342 байта
Upd 03.09.2020: Мона в Картотеке (http://www.sensi.org/scalar/ware/911/)
Upd 05.09.2020: В картотеке новая версия - 333 байта + центровка.
Примечательно, что после БЛК+СБР рисуется уже не мона
Вышенаписанное
Отказ от некоторых базовых прав и свобод (минус старт из дос и возможность рестарта)
относится и к версии 342 байта
svofski выложил в Картотеку (спасибо!), а я добавил ссылку в пост (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=1079276&viewfull=1#post1079276)
CodeMaster
03.09.2020, 20:12
у меня пока получилось слишком много байт - 370.
Можно, в двух словах, для непрограммистов, чего именно в 8080 не хватает по сравнению с другими процами?
результат всех этих действий где можно взять посмотреть (на Векторе)
И на ютубе тоже бы.
Ютубу в значительной степени заменяет Картотека. Если там навести курсор на картинку, то станет виден треугольник и если на него нажать, то запустится программа, т.к. svofski встроил туда эмулятор вектора.
Насчет недостатков 8080 для данной задачи я торопиться не буду, но могу пару слов сказать конвретно про вектор.
Основные минусы:
1. Много байт отъедает программирование палитры
2. Рисовать точку по плоскостям не очень удобно
3. Нет пзу с подпрограммами
Сравнивая с версией для специалиста - там (без перечисленных ограничений) получилось 313 байт, т.е. почти на 30 байт короче векторовской версии.
Небольшие резервы есть, если нарисовать немного лишнего, то можно сократить на 5-6 байт. В специалистовской еще можно нарисовать менее "красиво", будет еще короче (скорее всего <300).
- - - Добавлено - - -
Насчет недостатков 8080 все же один момент могу отметить. Мало регистров при сравнительной бедности режимов адресации. Т.е. или регистров бы побольше или режимов адресации или и того и другого.
CodeMaster
03.09.2020, 20:42
Ютубу в значительной степени заменяет Картотека.
Не вопрос, спасибо. Я когда спрашивал ссылки ещё не было.
Друг записал ютубу с реала:
https://www.youtube.com/watch?v=dQnhsHx4Gz8
Не верится, что это PAL-кодер, судя по качеству больше похоже на захват RGB (у меня даже есть такой тюнер), круто.
crackintosh
04.09.2020, 16:17
у меня даже есть такой тюнер
Open Source Scan Converter (OSSC) ?
Нет, Behold TV T8. Я писал до того, как svofski перечислил использованное оборудование.
Удалось сократить Мону и даже появилась возможность подумать о прекрасном. Часть выигрыша была потрачена на центровку не только по горизонтали, но и по вертикали. Спасибо svofski, он заменил на новую версию (333 байта) в картотеке (http://sensi.org/scalar/ware/911/).
Что касается достижений именно в области оптимизации по размеру, то в версии для специалиста получилось дожать до 300 байт.
Теперь Мона в картотеке с исходником. Надеюсь, что кто-нибудь все же подхватит почин и сбросит хотя с десяток байт. Ну или сразу сделает 250.
Нашел подходящую для моны платформу (искра-1080) с процедурой рисования точки в пзу и получилось 266 байт. Более удачные палитра и видеорежим по умолчанию позволили бы дожать и до 256. В итоге 8080 не так уж плох, но у вектора повышенные накладные расходы на приведение его в боевое состояние, что особенно плохо сказывается на микродемах. Для справки версия для 6128 (с использованием его особенностей и команд 8085) получилась 322 байта.
Писал здесь про недостатки 8080, наверно стоит здесь написать и про их преодоление. Последняя версия моны для искры-1080 - 255 байт, что, надеюсь, реабилитирует в некоторой степени 8080 как процессор и меня как кодера.
CodeMaster
10.09.2020, 19:27
и меня как кодера.
Тут и не было сомнений ;-)
Последняя версия моны для искры-1080 - 255 байт
Тогда, другой вопрос: если не использовать софтовые хаки, типа кода из ПЗУ и пр., чисто аппаратно (но тоже общего назначения, а не конкретно для этой демы) что на компах с 8080 помогло бы её уменьшить ещё? Какие-то особенности видеоподсистемы?
Компактность искровской версии связана в первую очередь с использованием процедуры рисования точки из пзу. Ну и программирование палитры там заметно более простое.
Для вектора подобный результат возможен, если ориентироваться на запуск не из загрузчика, а, например, из бейсика 2.5.
Насчет 255 байт без использования пзу. Смотрел только код на codegolf и там
1) В программе для x86 используется пзушное включение режима - насколько помню, там довольно много надо задать для корректности.
2) В программе для БК очистка экрана, установка режима и рисование точки - из пзу. На форуме Manwe выложил другую версию, я ее код не смотрел, возможно там пзу используется в меньшей степени.
Версию для атари не копал, но подозреваю, что и там не обошлось без пзу.
Если сравнить версии для вектора и специалиста (точки там рисуются без пзу, в специалистовской пзушная очистка экрана), то специалистовская короче на 33 байта в первую очередь в связи с отсутствием необходимости приведения видеосистемы в "рабочее" состояние. Там все параметры видео жестко фиксированы и сразу есть готовность к бою.
Глянул спековскую мону256 - там рисуют через пзушную процедуру.
Для более-менее адекватного сравнения эффективности разных процов или компов на одном проце с использованием моны надо разобрать ее на детали (вычисление случайного числа, рисование точки и т.д.) и сравнить их по отдельности.
Сейчас выяснится, что в пересчете на абсолютные байты Векторовская Мона -- самая компактная =)
Смех смехом, но после поверхностного ознакомления со спековской версией не вижу там находок, которые позволили бы что-то выиграть по размеру. Хотя пожалуй местами там более изящно.
для Союз-Неона "Мона Лиза" получилась в 254 байта, точки рисуются без использования ПЗУ (при режиме ровно 1 байт на точку проще руками рисовать в экранный буфер). Но вот инициализация графического режима (там хитрая оконная система) делается частично через обращение к ПЗУ, что добавляет байт 210 или около того.
На примере "Моны" я вижу ещё одну отличительную черту "домашних компьютеров" (здесь на форуме обсуждали что следует считать "домашним компьютером", а что нет): у домашнего компьютера в ПЗУ есть Бейсик или что-нибудь такое (Фокал, Форт, Монитор), что позволяет просто использовать графические процедуры типа рисования точки. Чем компьютер "профессиональней", тем сложней (больше кода) это делать.
На примере "Моны" я вижу ещё одну отличительную черту "домашних компьютеров" (здесь на форуме обсуждали что следует считать "домашним компьютером", а что нет): у домашнего компьютера в ПЗУ есть Бейсик или что-нибудь такое (Фокал, Форт, Монитор), что позволяет просто использовать графические процедуры типа рисования точки.
Это все же спорно. По такому критерию из "домашних" придется вычеркнуть РКподобные и специалист (у них в мониторе нет рисования точки), вектор, которые к "профессиональным" все же сложно отнести. С другой стороны у океана-240, который делали для решения профессиональных задач, есть рисование точки в пзу.
Конечно, это не однозначный критерий. Но один из плюсов в пользу "одомашенности" компьютера :) Конечно, бывают исключения (например, нет смысла применять этот критерий к домашним компьютерам, у которых вообще нет графического режима). И вряд ли кто из инженеров специально сидел и думал: "раз компьютер для домашнего рынка, значит надо добавить процедуру рисования точки". Но как-то так в итоге и получилось, чисто статистически.
Встроенный Бейсик это действительно аргумент в сторону одомашенности (во слово-то, ¡хабаджибулдых! одометрическое машиностроение) по критериям конца 70-х. А рисование точки достается из Бейсика в наследство. Вектор же делали через 10 лет после первых домашних компьютеров, в то время, когда уже не было блажной идеи, что домашнему пользователю нужен только Бейсик. Все уже понимали, что большинству нужен как раз не он.
Отсутствие бейсика в почти всех клонах вектора имхо проще объяснить стремлением удержать размеры платы и стоимость компа в разумных пределах (при 32 микросхемах озу и учитывая дефицит пзу удовлетворительной емкости). Но я лично рад, что авторы вектора пожертвовали бейсиком, а не возможностями видеосистемы. А когда более емкие микросхемы озу и пзу стали менее дефицитными появился 6128 почти со всем чем можно на борту, в т.ч. бейсиком.
metamorpho
31.08.2021, 11:21
В ноябре состоится "Демодуляция 2021". В список участвующих платформ включили "Вектор-06Ц" :v2_jawdr:
https://yandex.ru/museum/yaretrocomp#retro
Возможно кто-то вдохновится творческой идеей и выразит это в формате "Вектор-06Ц" ;)
Векторовский режим высокого разрешения идеологически повторяет один из режимов Apple IIGS (https://retrocomputing.stackexchange.com/questions/8382/how-does-apple-gs-hardware-dithering-work). Можно совмещать на экране черно-белую графику высокого разрешения с 15-цветной графикой половинного разрешения.
https://c.radikal.ru/c05/2110/13/511ebf7e7dfc.gif
Думаю на реале с ЭЛТ-монитором такой режим смотрелся бы наиболее хорошо, но и так идея видна. Люди с неидеальным зрением для усиления эффекта могут снять очки и отодвинуться подальше от монитора.
С шейдером singlepass в v06x.
https://i.imgur.com/KOCurft.png
Для такого режима надо бы переделать масштабирование, хотя смотрится очень ретро.
Хм, хотя дефолтный (shader:none) не так и плохо смотрится.
https://i.imgur.com/eJlWrAs.png
Как обычно, где-то на швах нелады.
Из этих двух мне shader:none кажется лучше (хотя у меня и с шейдером "без очков" получается приемлемый результат). Думаю, что один из главных врагов этого железного дизера в эмуляторах - некратное масштабирование по горизонтали.
Если говорить про реалы, то у эппла еще преимущество в пиксельклоке в SHR - 16+ против 12 у вектора, соседние точки сильнее размазывались и сливались.
В принципе тут pal-singlepass ни к селу ни к городу, потому что ни у Вектора, ни у Apple IIgs никогда не было PAL-модуляторов. Но все-таки, как-то.. По крайней мере я записал себе это на случай долгого зимнего вечера.
- - - Добавлено - - -
P.S. Кстати для тех кто на винде и в силу неумолимо хорошего здоровья не может позволить себе просто снять очки, еще есть вот такой веселый проект:
https://github.com/mausimus/ShaderGlass
Просто окошко можно навести на что угодно и оно превращается в размытое, выпуклое, потертое, тусклое и заартефаченное до неузнаваемости. Всевозможные ЭЛТ и VHS там в комплекте (в том числе адаптированный каким-то добрым человеком мой pal-singlepass)
Очень прикольная программа. В crt очень много шейдеров и есть нечто похожее на мои воспоминания о цветном элт телевизоре.
А pal - это ностальгия для тех, кто в начале 90х подключал вектор через pal-кодер, у меня такого опыта не было.
- - - Добавлено - - -
Немного поперебирал шейдеры и crt>tvout-tweaks кажется подходящим для hwdit.
Угу. Но не все шейдеры сразу хорошо работают на маленьком окошке, потому что по-моему многие из них (все?) рассчитаны на определенный масштаб. Я даже думаю, что может быть многие из них могут быть рассчитаны на 4K экран и GUI scaling 200%.
Из других настроек я делал
Input>Pixel Size>x1
Output>Scale>150% или 200%
metamorpho
24.11.2021, 00:17
Сегодня потратил несколько часов, чтобы "выжать" последние лишние байты из моей демки.
Теперь в ней ровно 256 байт - отправлю её на ДЕМОДУЛЯЦИЮ в раздел "Old school Intro 256b".
Процесс создания этой демки научил под "другим углом" смотреть на код.
Нестандартные и необычные решения в кодировании удивляли - это полезный опыт.
Процесс создания оказался очень интересным.
Хотелось ещё звук добавить и изменение цвета, но похоже мой предел "выжимки" в этом коде достигнут.
Хотя наверное кто-нибудь смог бы ужать код ещё сильнее.
Хотя наверное кто-нибудь смог бы ужать код ещё сильнее.
Потом, если будет интерес, можно выложить исходник - подскажут, что улучшить =)
Для 256 байтной демы исходник не обязателен, достаточно будет бинарника.
metamorpho
27.11.2021, 11:23
Организаторы конкурса прислали сообщение, что моя демка на реальном Векторе работает с какими-то артефактами :(
Сообщение прочитал только сейчас. Менять что-то похоже уже поздно. Да и как ? ведь реального Вектора у меня нет.
На эмуляторе VV, Башкирия-2М а также на Pretty 8080 Assembler - работает всё отлично.
Нужно было попросить здесь кого-нибудь с реальным Вектором потестить заранее.
Ну да ладно, посмотрим что за артефакты там появились, может с ними даже лучше выглядеть будет :)
Нужно было попросить здесь кого-нибудь с реальным Вектором потестить заранее.
Да, если нет в наличии оригинального железа - лучше проверять. Эмуляторы, они такие.
А организаторам в любом случае отсылать видео, чтоб знали, как задумано автором.
metamorpho
27.11.2021, 11:56
Да, если нет в наличии оригинального железа - лучше проверять. Эмуляторы, они такие.
А организаторам в любом случае отсылать видео, чтоб знали, как задумано автором.
Видео отослал. Даже эмулятор VV отослал - на всякий случай :)
Видео отослал.
Это правильно. Когда-то тыщу лет назад, когда на ЦЦ показывали мою 8-bit snail, где-то в процессе адаптации одного видеосигнала к другому оказалась отрезанной нижняя часть экрана. Аккурат та, где была улитка. Все происходило в рилтайме и на железе, поэтому no backsies. Было досадно.
Организаторы конкурса прислали сообщение, что моя демка на реальном Векторе ...
Однако организаторам респект и уважуха... где-то смогли раздобыть реальный Вектор, и даже к чему-то (телик/монитор) умудрились его подключить...
Я похоже все пропустил, уже ведь было?
Upd: да, я все пропустил. Ясно-понятно.
Upd2: все работы, в том числе metamorpho https://demodulation.retroscene.org/competition/?competition_id=9
metamorpho
27.11.2021, 22:43
Ну что ж 5-е место из одинадцати совсем неплохо :)
Стало понятно какие артефакты организаторы конкурса имели ввиду.
Оказывается реальный Вектор не стирает экран при запуске программы - вообщето я об этом и так знал, но забыл.
Меня ввело в заблуждение то, что эмуляторы Вектора при загрузке ROM файла автоматически стирают экран - странно
зачем так сделали - ведь на реальном Векторе этого нет, но похоже была причина так сделать.
Вообщем вот демка ROM файл и исходник на ассемблере (смотри архив в приложении)
Может кто-то найдёт что-то интересное для себя или сможет ужать эту демку ещё сильнее.
svofski, если можно то внеси в картотеку :)
По сути в 256 байтах содержится почти игра - осталось только управление прикрутить :))
вот она моя первая демка для Вектора 256 байт:
https://www.youtube.com/watch?v=vZi33-Hz6do
Классная демка!
Мой эмулятор не стирает экран специально. Просто ROM загружается сразу в память, минуя загрузчик. Но если загружать через загрузчик, например из WAV-файла, на экране все будет как в настоящем Векторе. Подозреваю, что другие эмуляторы делают так же.
Ну что ж 5-е место из одинадцати совсем неплохо
Весьма неплохо, особенно для дебюта.
Интра от Manwe (видео) не воспроизводится.
И позабавило "скачать zip 4.7 кб" для интры размером 256 байт.
metamorpho, поздравляю с успешным участием в конкурсе! Демка хорошая, возможно даже лучшая (или одна из лучших) в категории 256 для вектора за все время. Но есть довольно большие резервы оптимизации, которые можно использовать для увеличения корректности работы и улучшения внешнего вида:
1. Добавить очистку экрана (на мой взгляд это обязательно)
2. Добавить отключение кваза (желательно для запуска из квазных досов)
3. Задавать всю палитру только на основании самой демы, без вылезания в "чужую" память (желательно для запуска из доса после другой программы)
4. Сделать сплошную зеленую заливку по обоим бокам (а это уже дело вкуса)
После реализации перечисленных пунктов у меня еще осталось 6 байт до 256 (не уверен, что это предел). Если же ориентироваться только на запуск из загрузчика и не обращать внимания на досы, то пп. 2-3 отпадают + можно попробовать отыграть еще чуть-чуть оформив в виде r0m. Тогда появляется запас, куда возможно влезет звук.
- - - Добавлено - - -
Оказалось, что в 6 байт влез вполне подходящий звук (можно ничем не жертвовать), я аж сам удивился.
metamorpho
28.11.2021, 12:41
.........Но есть довольно большие резервы оптимизации, которые можно использовать для .......
...........После реализации перечисленных пунктов у меня еще осталось 6 байт до 256 (не уверен, что это предел).....
Это удивительно !!!! :v2_eek::v2_eek::v2_eek:
ivagor, можно ли мне посмотреть твой вариант, хочу научиться оптимизировать код ещё лучше :)
можно ли мне посмотреть твой вариант
Можно, но я тогда пролезу в соавторы :)
Если согласен, то я выложу доработанный вариант.
metamorpho
28.11.2021, 14:31
Можно, но я тогда пролезу в соавторы :)
Если согласен, то я выложу доработанный вариант.
Конечно согласен :)
Собственно вот. Думаю можно выиграть еще несколько байт (один точно можно), но вряд ли это позволит заметно улучшить дему.
metamorpho
28.11.2021, 16:22
Собственно вот. Думаю можно выиграть еще несколько байт (один точно можно), но вряд ли это позволит заметно улучшить дему.
ivagor, великолепная оптимизация !!
Особенно трюк с встраиванием программы обработки прерываний в цикл основной программы просто супер !! :v2_jawdr:
Спасибо !! :v2_dizzy_hello:
svofski, если можно то внеси в картотеку вот эту версию (указав ivagora соавтором)
svofski, если можно то внеси в картотеку вот эту версию (указав ivagora соавтором)
https://www.sensi.org/scalar/ware/915/
Добавил, говорите если что поправить, уточнить или добавить какую-то лирику.
P.S. а чего-это на pouët-e ее нет? Тоже надо
https://www.pouet.net/party.php?which=1931&when=2021
Возможно стоит добавить в карточку оригинальную пати версию, если конечно metamorpho не против.
metamorpho
30.11.2021, 09:40
https://www.sensi.org/scalar/ware/915/
Добавил, говорите если что поправить, уточнить или добавить какую-то лирику.
P.S. а чего-это на pouët-e ее нет? Тоже надо
https://www.pouet.net/party.php?which=1931&when=2021
svofski, спасибо за размещение в картотеку.
А на pouet.net размещает организатор конкурса или кто ?
Возможно стоит добавить в карточку оригинальную пати версию, если конечно metamorpho не против.
Я не против :)
А на pouet.net размещает организатор конкурса или кто ?
Кто угодно может. Чаще всего сами авторы работ.
- - - Добавлено - - -
P.S. Я могу, если лень логиниться.
metamorpho
30.11.2021, 20:47
Кто угодно может. Чаще всего сами авторы работ.
- - - Добавлено - - -
P.S. Я могу, если лень логиниться.
svofski, было бы здорово если бы ты разместил на pouet.net эту дэмку :)
svofski, было бы здорово если бы ты разместил на pouet.net эту дэмку :)
Подумал, что надо еще добавлять тебя как группу, добавлять демку.. Кстати неплохо написать к ней минимальный .nfo Ты не хочешь сам себя добавить все-таки? =)
metamorpho
01.12.2021, 21:09
Подумал, что надо еще добавлять тебя как группу, добавлять демку.. Кстати неплохо написать к ней минимальный .nfo Ты не хочешь сам себя добавить все-таки? =)
Минимальный .nfo написать могу. А что входит в минимальный .nfo, о чём написать нужно ?
Вчера, ещё до твоего предложения добавить, я сам попытался это сделать, но там (на pouet.net) в плане добавления мне показалось всё как-то слишком заморочено. Поэтому почитав (через переводчик) несколько страниц и так и не поняв как это сделать, я остыл и потеряв желание в этом разбираться, ушёл оттуда. Потом увидел твоё предложение разместить там дэмку и обрадовался :)
На данный момент самому размещать там дэмку особого желания совсем нету.
Ну просто, типа 256-байт интра, зовется так-то, для участия в конкурсе Демодуляция 2021, как тебя зовут по-демосценному =) Если хочется, можно детали реализации какие-то уточнить, можно не уточнять. Можно передать привет маме. Это текст от себя. Посмотри как другие демки и интры описаны.
metamorpho
01.12.2021, 21:49
Ну просто, типа 256-байт интра, зовется так-то, для участия в конкурсе Демодуляция 2021, как тебя зовут по-демосценному =) Если хочется, можно детали реализации какие-то уточнить, можно не уточнять. Можно передать привет маме. Это текст от себя. Посмотри как другие демки и интры описаны.
Думаю вот такой минимальный вариант будет достаточен.
"Acceleration" - this is a 256 byte intro. Code by Metamorpho. For participation in the "Demodulation-2021" competition.
Добавил https://www.pouet.net/prod.php?which=90364
metamorpho
01.12.2021, 23:36
Добавил https://www.pouet.net/prod.php?which=90364
svofski, спасибо !!
Жаль что там в списке платформ нет Вектора, а только Wild можно поставить.
Вот если нужно, то можно добавить видео (там я указываю для какого компьютера это сделано):
Acceleration (v.2.0) - улучшенная (ivagor) версия
https://www.youtube.com/watch?v=sW3DzP-AeD0
конкурсная версия
https://www.youtube.com/watch?v=vZi33-Hz6do
Жаль что там в списке платформ нет Вектора, а только Wild можно поставить.
Не все сразу. Благодаря тебе для Вектора теперь целых три демы. Если так дело дальше пойдет, то году к 2040-му мы сможем претендовать на свою категорию.
metamorpho
02.12.2021, 12:06
Не все сразу. Благодаря тебе для Вектора теперь целых три демы. Если так дело дальше пойдет, то году к 2040-му мы сможем претендовать на свою категорию.
Можно ускорить процесс появления Вектора в списке платформ на pouet.net
Есть ещё несколько идей для дэмо, если вдохновение найдёт то создам и на какой-нибудь REVISION поучаствую :)
Там есть разные разделы для участия - wild demo, oldskool intro, oldskool demo. Похоже там любые платформы берут.
Надо войти в семёрку лучших и тогда Вектор-06Ц станет известным :)
Можно ускорить процесс появления Вектора в списке платформ на pouet.net
Хорошо бы добавить видео интры на ютубе в описание работы на pouet.
Весьма удобно для "простых смертных", не знакомых с платформой. Да и вообще, это частая практика =)
metamorpho
03.12.2021, 22:06
Сейчас посмотрел на pouet, а там работа №2,6,7 256 интро стоит категория платформа BK-0010/11M.
А как они смогли включить в список платформ BK-0010/11M ?
svofski, а можешь там где моя дэмка добавить ссылку на видео ютуб ? :)
Там есть ссылка на ютуб в комментариях. Глöператор потом поправит.
Категория БК как-то исторически просочилась, не знаю.
metamorpho
04.12.2021, 23:31
Написал на pouet.net письмо с просьбой добавить в список платформ "Вектор-06Ц".
Вот что мне ответили:
"Общая политика заключается в том, что мы добавляем платформы только в том случае, если есть активная сцена на нем, которая произвела не менее 10-15 демо для него."
Три дэмки на Вектор на pouet.net уже есть, осталось ещё как минимум 7 штук =))
Еще десять тысяч ведер и золотой ключик у нас в кармане.
Написал на pouet.net письмо с просьбой добавить в список платформ "Вектор-06Ц".
Вот что мне ответили:
"Общая политика заключается в том, что мы добавляем платформы только в том случае, если есть активная сцена на нем, которая произвела не менее 10-15 демо для него."
...
Я не совсем понял, речь идёт о 10-15 конкурсных работах, или демок вообще?
Демок вообще. Демосцена это не только конкурсы, есть еще тыщи всевозможных кректро, ббстро и просто не пойми чего. Так что можно просто добавить старые демки и наберется. Но мне кажется, что это пустое. Допустим добавят категорию Вектор. Это будет дополнительная морока глоператору, а смысла глубокого в этом нет. Активной демосцены от этого на Векторе не случится.
Активной демосцены от этого на Векторе не случится
Кто знает... вдруг стараниями metamorpho родится демосцена Вектора =)) Всегда трудно быть первопроходцем, но за ним потянутся.
Кстати, что за термин "глоператор"?
Мы все смотрим на metamorpho и надеемся :)
Термин имеет какие-то очень глубокие корни, к которым я не причастен. В общем он оперирует глопами.
metamorpho
05.12.2021, 21:25
Кто знает... вдруг стараниями metamorpho родится демосцена Вектора =)) Всегда трудно быть первопроходцем, но за ним потянутся......
Мы все смотрим на metamorpho и надеемся :) ........
Мой взгляд на это дело такой - дэмосцена на Вектор-06Ц рождена до меня и она даже не умирала - например последние 4 года регулярно (раз в год) выходят дэмки для Вектора. Свободное время и вдохновение и рождается дэмка :)
И конечно тут ещё есть те кто мог бы написать интересное дэмо на Вектор - может оно так и будет.
она даже не умирала
...если вы не живете, то вам и не.. =)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot