Любой код после DI перестаёт исполнять прерывания, можно на контроллере таймер выключить, и сказать, — «ой ваш АРМ перестал задачи переключать», а можно ещё и питание выключить. Любой код после порчи его перестаёт работать. Это просто качество написания кода, и поточность тут не играет никакой роли. Процесс нужно прибивать только после того как код этого процесса написан с учётом того, что он может сделать DI, или попортить память, — не более чем качество написания кода.
И, кстати, любой шедуллер простейший, он состоит из простых логических действий. Можно трижды написать «он простой и наколенный», но от этого ничего не изменится. Так же можно сказать, — «О, да, Vitamin, дышит простым 23% кислородом», и после сделать циничное выражение лица. Только вот вопрос, зачем эти слова? Цель какова?
Отличное название, слушай. ты не против я его у тебя упру? Я теперь эти процедуры буду называть «Шинкованные сквозные процедуры». А представляешь, возможно что этого метода есть нормальное название. Помню как мне в детстве все говорили — «вот есть объектно-ориентированное программирование, это тебе не ZX-Spectrum», а потом я узнал, что и так половина всего, что я вижу это оно и есть, просто кто-то этому дал «страшное» название.
Я понимаю, что возможно у меня фраза «сквозные процедуры» прижилась ещё с детства, я их тогда так назвал. Допустим, чисто как пример, у нас есть что-то откуда мы берём стрим данных, например это модем по UART'у, допустим что у нам надо принять байт и его обработать, например разобрать АТ команды. Вызов такой процедуры будет в цикле:
LOOP ...что-то
CALL PARS_MODEM
...что-то
JP LOOP
Вот процедура PARS_MODEM будет всегда однопроходная. В ней будет хранится текущая позиция исполнимого кода, и там никогда не будет циклов. Да же не текущая позиция кода, а текущее полодение в наборе мелких участков кода. Пришёл байт, проверили закончил ли он строку, нет, вышли, если да, проверили строку, вышли. Вошли снова, проверили что надо сделать со строкой, если ответить, ответили, вышли, переключили снова в ожидание окончания строки. Таким образом если у меня будет 10 модемов, то процедура PARS_MODEM, будет вызвана 10 раз, но со ссылкой на описание нужного UARTа, или другого интерфейса. то есть в таких процедурах допускается выполнение чего-то ёмкого, но крайне редко, или эти ёмкие части кода будут исполняться поэтапно, что бы вылетать из процедуры и давать работать соседней процедуре.
Лёша, но это честные потоки. В данном примере количество потоков ограничено до четырёх. В этих потоках только нет MUX'ов, а остальное всё по классике жанра.
Примеры привести очень сложно, по скольку у меня львиная доля работ это демка. А тут за всю историю я не нуждался в более чем двух потоков, просто это не нужно. Что для демки надо? На заднем плане что-то считать и контролировать логику на переднем плане, ну а на прерываниях показывать эффекты. Вообще я давно не использовал потоки, по скольку мне приятнее сквозные процедуры, и если бы не SYNCHRONIZATION и gift WAYHACK, я бы не вспомнил о них.
Вот в WAYHACK на первом потоке происходит расчёт эффекта, а на втором потоке печатается текст, рассчитываются координаты букв, создаётся предварительная анимация.
В SYNCHR'е потоки пускаются в части с иконками и летающем кубике. Пока все смотрят на выпадающего Бина, в соседнем потоке подготавливается куб.
Ещё эти потоки, и это было впервые со страницами, были сделаны в игре WonderLust, там пока кто-то смотрит интро, выбирает какими клавишами играть, — на втором потоке генерируется лабиринт.
Прости, но в тематике Speccy, сложно применять более серьёзно потоки, ведь мы все привыкли писать код так, что бы он по сути не требовал потоков. Лёша, просто ты это прошёл, поэтому тебе проще использовать то, что у тебя наработано. И ты прав, я начиная с игры WonderLust не усложнял потоки, просто не нужно больше. Вообще когда я впервые встретился с потоками, увидел, что в большинстве случаев люди(PC) их пихают в местах где это ну совсем не надо.
Поэтому, да более чем два потока я не вижу применений.
Молодцы, ребята. Вы сделали отменную демку. Считаю, что вы воплотили мечту SQ. Это тот случай, когда исполняют свою роль все три компонента демки — «C.G.M». Вы идёте семимильными шагами, и что меня больше всего радует, что работы на конфе совершенно не похожи друг на друга. Они кардинально разные и имеют собственный стиль. Как правило почти все демы отображают техническую сторону платформы на которой они работают. Тут же напротив, получается дема в которой отображается техническая сторона душ авторов. Кому надо возьмёт частичку души текста, другой возьмёт частичку видеоряда, третий заберёт себе звук. И да же тот который накидает «кирпичей», получит своё, иногда полезно вынуть внутренности, показать их «кирпичную» сторону окружающим и засунуть назад. «HAPPYNOW»
Полностью согласен насчёт минусов. У них совсем другой смысл. Критика и минус имеют совсем разные значения. Критика высказывается словами, изложением мыслей или выражением чувств. Критика не имеет оценки, у неё не бывает очков(score), критика это взгляд на какой либо вопрос сквозь чьё-то мировоззрение, и в худшем случае высказывание того как бы кто-то, что-то сделал по своему. Для меня HYPE это мнение людей которые я хотел бы читать без оценок. И оценки я хотел бы видеть от людей чьему мнению я доверяю, например это люди из списка моих друзей в профиле. Для не зарегистрированных людей я бы оставил видимость только плюсов.
Я раньше точно так же приходил и считал за честь высказать своё мнение несогласия с чем-то каждому и повсеместно. Но потом понял, что если моё негативное мнение кому-то надо, оно будет высказано непосредственно этому человеку. И в итоге приобрёл позицию, что если я не согласен с чем-то, то просто прохожу мимо. Ну не нравится дамка, ну и что, найду ту, которая нравится. Но и вправду, я за частую молчу по тому, что просто не хочу участвовать в чьей-то ругани. Есть ещё одна причина по которой я могу не высказывать мнение, но это уже мои тараканы в голове.
Саня, я конечно понимаю, что в реальности всё равно будет кто-то, кто обязательно решит устроить разброс коричневых шариков, только не переставай писать. Лучше всего писать(делать) в первую очередь для себя, кому надо тот возьмёт. Пусть это понадобится только маленькой кучке людей, но это важнее, если кто-то будет искать твои слова, но их не найдёт.
— Сложно, когда художника меряют своим аршином, но ужаснее, когда мереть вовсе нечего.
Когда-то мы долго перебирали многие из этих редакторов. У каждого были свои плюсы. Но в итоге был выбран DMM. Его я как-то сделал универсальным на АУ или SounDrive, с авто настройкой под турбы, подправленный плеер +10% скорости, и сильно улучшенный интерфейс загрузки. У него есть особенность, есть двойные ноты на один канал. Это любил использовать Dreamer, по сути он миксовал с бассом аккомпанемент. Качество на Speccy всё равно не вытянуть да же на 11к, поэтому можно было использовать подобные приёмы.
Но был ещё один редактор, основная масса музыки осела на дисках. Вот с него снятое видео одной из мелодий.
Привет, Вовка!!! Не знаю чему тебе там учиться… Но одно точно знаю, у меня мозг уже не работает без EXX! Но думаю что это отлично если то, что ты делаешь работает без ЭХХХов. Учиться нужно каждый день, как я люблю говорить — «екжкнаноскунднно».
Код, как и графика с музыкой это в первую очередь искусство, а оно никогда не бывает идеальным. Все люди разношёрстные, поэтому у каждого возникают разные чувства при просмотре чьей-то работы. Есть определённые люди, которые смотря на, не важно какой, эффект и сразу задаются вопросом — «а как это сделаю я ?». Потом они его делают, и вероятнее всего он у них получится лучше и лаконичнее. Но как не крути этот эффект попадёт на дискетку с надписью «TEST1023», ну в современности это будет каталог на РС. Дальнейшая его судьба это «мегадемо» через 10-ть лет. Но смысл-то в том, что ты видишь перед собой новое. Но этот эффект останется навеки новым, и лучшим будет именно оригинал, именно тот который кривой и теперь уже охаянный, сколько бы раз его не переписывали. Я очень редко изучаю код в дебаггере, потому, что я, или понимаю, что увижу там что-то простое, или безумно сложное, что проще написать заново, ну или не возможно вообще написать. Для меня будет приятнее непосредственно встретиться с автором и поговорить с ним о коде, он тогда становится более живым, «он» это как код, так и автор. Но… У меня возникает другое ощущение «мёртвого кода», совсем не из-за дебаггера. Я бы сказал, что он мёртв из-за подхода штампами и отсутствием максимализма. Штампы делают код обыденным и понятным без просмотра оного. Но одно из главных в искусстве это максимализм, если, конечно, автор не гений, а просто талантливый. Например ты ставишь себе задачу — «скролл», как только их будет на экране 30 штук, или его размер будет на весь экран, или его будет «колбасить» как любит ААА, он тут же станет предметом изучения и это будет ново. Хотя, согласись, сам scroll не новый эффект. А вот что бы сделать совершенно новый эффект, тут надо уже менять штампы. К сожалению код мёртв из-за того, что не применяются неординарные инструменты, у Coderов или их нет, или они принципиально не пользуются «супер мечом из космической стали 80-ого уровня». Из-за штампов Coder мечтает в новом компиляторе или в новом языке увидеть то, что уверенно знает, и новый язык превращается в супер «IF», лишь из-за того что ему стало лень писать JR NZ… Или происходит другое, кто-то пытается применить язык, который никак не подходит для данной задачи, а у нас Z80, в итоге весь пар уходит на гудок, который отлично бы работал на х86. Хороший инструмент даёт возможность создать код, который будет бесполезно смотреть в дебаггере, единственное, что там будет знакомо это POP POP POP… PUSH PUSH PUSH. Мало того этот инструмент даёт возможность Coderру расширить свои рамки и стать дизайнером эффекта. Например часто ли ты генерируешь кодом графику? Только я не говорю про генерацию крутящегося кубика, я говорю про точную и плавную графику основанную на пикселах, в которой будет генерироваться части спрайтов, например моргающий персонаж. Представляешь себе этот код внутри? Это будет мясо. А хороший инструмент даст возможность писать код всякими мудрёными предкомпиляторными процедурами. Например задача надо в момент мультиколора генерировать графику для этого мультиколора, которая на ходу будет распаковываться. Имея инструмент в котором минимизируются затраты на подсчёт тактов, можно будет усложнить код? поскольку освободятся такты в голове автора на новые идеи. Вот тогда, мне кажется, код будет жить, и эффекты будут новыми.
И, кстати, любой шедуллер простейший, он состоит из простых логических действий. Можно трижды написать «он простой и наколенный», но от этого ничего не изменится. Так же можно сказать, — «О, да, Vitamin, дышит простым 23% кислородом», и после сделать циничное выражение лица. Только вот вопрос, зачем эти слова? Цель какова?
Вот процедура PARS_MODEM будет всегда однопроходная. В ней будет хранится текущая позиция исполнимого кода, и там никогда не будет циклов. Да же не текущая позиция кода, а текущее полодение в наборе мелких участков кода. Пришёл байт, проверили закончил ли он строку, нет, вышли, если да, проверили строку, вышли. Вошли снова, проверили что надо сделать со строкой, если ответить, ответили, вышли, переключили снова в ожидание окончания строки. Таким образом если у меня будет 10 модемов, то процедура PARS_MODEM, будет вызвана 10 раз, но со ссылкой на описание нужного UARTа, или другого интерфейса. то есть в таких процедурах допускается выполнение чего-то ёмкого, но крайне редко, или эти ёмкие части кода будут исполняться поэтапно, что бы вылетать из процедуры и давать работать соседней процедуре.
Примеры привести очень сложно, по скольку у меня львиная доля работ это демка. А тут за всю историю я не нуждался в более чем двух потоков, просто это не нужно. Что для демки надо? На заднем плане что-то считать и контролировать логику на переднем плане, ну а на прерываниях показывать эффекты. Вообще я давно не использовал потоки, по скольку мне приятнее сквозные процедуры, и если бы не SYNCHRONIZATION и gift WAYHACK, я бы не вспомнил о них.
Вот в WAYHACK на первом потоке происходит расчёт эффекта, а на втором потоке печатается текст, рассчитываются координаты букв, создаётся предварительная анимация.
В SYNCHR'е потоки пускаются в части с иконками и летающем кубике. Пока все смотрят на выпадающего Бина, в соседнем потоке подготавливается куб.
Ещё эти потоки, и это было впервые со страницами, были сделаны в игре WonderLust, там пока кто-то смотрит интро, выбирает какими клавишами играть, — на втором потоке генерируется лабиринт.
Прости, но в тематике Speccy, сложно применять более серьёзно потоки, ведь мы все привыкли писать код так, что бы он по сути не требовал потоков. Лёша, просто ты это прошёл, поэтому тебе проще использовать то, что у тебя наработано. И ты прав, я начиная с игры WonderLust не усложнял потоки, просто не нужно больше. Вообще когда я впервые встретился с потоками, увидел, что в большинстве случаев люди(PC) их пихают в местах где это ну совсем не надо.
Поэтому, да более чем два потока я не вижу применений.
Я раньше точно так же приходил и считал за честь высказать своё мнение несогласия с чем-то каждому и повсеместно. Но потом понял, что если моё негативное мнение кому-то надо, оно будет высказано непосредственно этому человеку. И в итоге приобрёл позицию, что если я не согласен с чем-то, то просто прохожу мимо. Ну не нравится дамка, ну и что, найду ту, которая нравится. Но и вправду, я за частую молчу по тому, что просто не хочу участвовать в чьей-то ругани. Есть ещё одна причина по которой я могу не высказывать мнение, но это уже мои тараканы в голове.
Саня, я конечно понимаю, что в реальности всё равно будет кто-то, кто обязательно решит устроить разброс коричневых шариков, только не переставай писать. Лучше всего писать(делать) в первую очередь для себя, кому надо тот возьмёт. Пусть это понадобится только маленькой кучке людей, но это важнее, если кто-то будет искать твои слова, но их не найдёт.
— Сложно, когда художника меряют своим аршином, но ужаснее, когда мереть вовсе нечего.
Но был ещё один редактор, основная масса музыки осела на дисках. Вот с него снятое видео одной из мелодий.
PopRoller on the mason player