Среди многочисленных демосценерских конкурсов, которые традиционно входят в программу различных demo party, незаслуженно недооценённым, на мой взгляд, является конкурс процедурной графики (procedural graphics). Смысл этого специфического вида компьютерного творчества — формирование статичного изображения при помощи короткой программы. Стандартные ограничения на размер — 4кб, 1кб, 256 байт.

Связана недооценка, думаю, с тем, что конкурс одновременно не вполне понятен как тем, кто любит демки (поскольку процедурная графика статична), так и тем, кто любит картинки (т.к. процедурная графика не позволяет нарисовать что хочешь). И всё же, его популярность хоть и медленно, но растёт.

Читать дальше →

Как вы уже, вероятно, слышали, в этом году мы возобновляем проведение Chaos Constructions — он состоится 24-25 августа в ДК Кирова, Санкт-Петербург.
Хотя мы объявили даты несколько месяцев назад, довольно много людей сомневалось, что это правда (а некоторые даже пытались, увы, убедить в своих сомнениях других).

Отчасти это можно понять, так как в проведении CC был достаточно длительный перерыв, перед которым формат фестиваля стал существенно уходить в сторону от многим привычного.
Одной из мотиваций к организации Chaos Constructions 2024 было как раз наше желание вернуться к тем идеям (к тому сочетанию подхода, тематик и масштаба) которые, как нам кажется, делают CC особенным. Хотелось бы добавить "… и к тому духу", но как раз дух как фестиваля, так и демопати, организаторы не могут создать — могут лишь этому способствовать.
За много лет проведения как ENLiGHT, так и CC получалось очень по-разному и всегда — подчёркиваю — всегда непредсказуемо. Это касалось всего — посещаемости, количества и качества работ, впечатлений как участников, так и нас, организаторов. Все же Chaos Constructions был и остаётся глубоко неформальным мероприятием.

Организацией в этом году занимается команда, которая уже неоднократно организовывала CC. Трое основных организаторов — 3ym, random, frog.

Как, возможно, вы заметили по анонсам и разговорам — процесс идёт. Площадка арендована и оплачена. Уже есть договорённости по различным семинарам (это касается как тематики демосцены, так и ретро компьютеров и прочего железа), по разнообразным экспонатам выставки компьютерной ретротехники, realtime конкурсам и прочей движухе. Один PDP-11 чего стоит — с ужасом думаю о том, как мы его будем затаскивать в ДК :)

Сколько работ будет представлено на конкурсы — этого, конечно, не скажет никто, но что несколько человек готовят, как минимум, демо/интро — могу сказать определённо.

Фестиваль проводится на средства (примерно 50/50) спонсоров и организаторов. Вход сделан бесплатным не потому, что у нас много денег — наоборот. Мы взвесили все за и против и решили, что такое решение упростит многие организационные моменты, а добровольная помощь позволит нам хотя бы частично сбалансировать бюджет.

Возможно, этот текст (специально для читателей Hype) добавит определённости неопределившимся. Надеемся на это!

P.S. Приём работ открыт — https://events.retroscene.org/cc2024

Хотелка

Хочется компилить и отлаживать в Unreal Spectrum проекты для Спектрума в Visual Studio Code тем же хоткеем, который я использую для других языков.

Проблема

Я давно освоил Visual Studio Code и использую ее, например, для проектов на Python. При этом все мои проекты для Спектрума жили в Sublime Text с расширением Z80Asm от Breeze, и я решил смигрировать их в более привычный VS Code.

В VS Code есть понятие Build Task, позволяющее запустить только компиляцию workspace (и, вообще говоря, выполнить любую команду shell) и отдельно debugger'ы, свои для каждого типа workspace. Если для языка установлено отладочное расширение, то по F5 (у меня клавиатурная тема от MSVS) workspace компилится при наличии изменений, и сборка запускается в отладчике. А запускать вместо отладчика команду shell (и Unreal Spectrum) нельзя, нужно отладочное расширение. Итого: для Python использую F5, для Z80 — Shift+Ctrl+B, и постоянно путаю их.

Чуть подробнее

Для разработки на Z80 есть расширение Z80 Macro-Assembler, которое понимает синтаксис Z80 и имеет еще всяческие фишки (подробнее про это писал камрад sq в статье Как быстро настроить среду разработки на ZX: Visual Studio Code + Z80MacroAsm boilerplate). Однако расширения, позволяющего запускать Unreal Spectrum в качестве отладчика нет.
Переопределить шоткат F5 для проекта невозможно, глобально переопределить его на Build Task — тоже не выход, потому что оно тогда будет так работать и для всех остальных языков.
Надо сделать как-то так, чтобы для workspace Z80 F5 вызывал Build Task, в котором можно выполнить команду shell и запустить что хочется, а для других проектов поведение оставалось прежним: компиляция (если есть) и запуск отладчика из расширение.

На просторах Интернета накопал способ переопределить шоткат для проекта, которым на всякий случай делюсь. Суть способа такая:

• пользовательские шоткаты переопределяют системные, при этом, если условие when для пользовательского шотката не выполнено, то работает штатный шоткат из клавиатурной схемы;
• условие вычисляемое, в нем можно использовать настройки, в том числе, и уровня проекта;
• суть решения: добавляем в проект некоторую кастомную настройку, наличие которой является условием пользовательского шотката на запуск Build Task, а при ее отсутствии работает штатный шоткат VS Code для запуска дебаггера.

Инструкция

1. Нажать Shift+Crtl+B (или ваш шоткат для билда) чтобы появилось предложение создать tasks.json. Если дефолтные таски в конфигах самой VS Code уже есть, то, по Вашему вкусу, можно либо добавлять новые таски туда, либо создать в проекте файл .vscode/tasks.json.
2. Вставить в tasks.json пример сборочных тасков из справки extension'а Z80 Macro-Assembler и настроить его на свой вкус. Для настройки шотката интересен только параметр label. Назовем его, например, Compile and run. В параметр command пишется shell-команда, которую хотим прикрутить к шоткату
3. Нажать Shift+Ctrl+P (или ваш шоткат для поиска команд) и выполнить Preferences: Open workspace settings (JSON). Добавить в него параметр

"runTaskInsteadOfDebug": true

4. Нажать Shift+Ctrl+P (или ваш шоткат для поиска команд) и выполнить Preferences: Open Keyboard Shortcuts (JSON). Добавить в него:
   

   
           {
               "key": "f5",
               "command": "workbench.action.tasks.runTask",
               "when": "config.runTaskInsteadOfDebug && taskCommandsRegistered",
               "args": "Compile and run"
           }
       

   
   
Собственно, все. Теперь в проектах, в которых есть .vscode/settings.json с параметром «runTaskInsteadOfDebug»: true, по кнопке F5 будет вызываться таск с именем Compile and run, а в проектах без этой опции — отладчик по умолчанию для workspace.Например, я себе в проектах Saboteur сделал по F5 сборку и запуск отладочной версии, по Ctrl+F5 — релизной, а по Shift+F5 — только компиляцию без запуска.

По сравнению с другими, ранее описанными мной архитектурами, архитектура Sony Playstation 1 (PSX) — сравнительно современная. И дело даже не в годе выпуска (1994) — скорее это общее ощущение сочетания новых возможностей и исчезновения привычных старых, которые были типичными для компьютеров и приставок предыдущей эпохи.

Читать дальше →

На днях выпустил свой новый альбом биперной музыки для ZX Spectrum 48K — Ear Shaver. По сути не только новый, но первый, так как мои предыдущие около-биперные релизы были или компиляциями разрозненных треков, или были альбомами, но для других платформ. На этот же раз я целенаправленно делал именно альбом, сразу много треков в более-менее общем звуке и концепции, и именно для ZX Spectrum.

Послушать без дополнительных прелюдий можно в прикреплённом видео (которое здесь почему-то не видно) или на разнообразных музыкальных площадках.


Не планировал писать очередной making of, но начал делать некоторые заметки для релизных текстов, лично для себя, и как-то само написалось – привычка страшная сила.

Читать дальше →

Публикую обзоры жюри и оценки на графические работы zxgfx compo #7. Результаты в конце статьи. В этот раз оценка работ проводилась не зрителями, а жюри из числа вызвавшихся членов канала @zxgfx. При этом условие было только одно — в жюри может быть тот, кто не нарисовал на компо. Наверное этим и объясняется такой баланс количества участников конкурса и жюри — 3 участника (8 работ) и 9 человек жюри. Но, надо сказть, быть в жюри оказалось не проще. Дело даже не в оценивании и написании обзора. На это у каждого ушел наверное просто 1 вечер. Проблема жюри — больше в обсуждении выставленных оценок и подходов к оцениванию.

Все началось достаточно легко. Создали отдельный telegram-канал для жюри. Кто-то спросил «как оцениваем», я с ходу предложил — давайте оценим по трем критериям:
1. Соответствие условиям конкурса
2. Техника
3. Оригинальность/общее впечатление от работы.
Бросил и забыл. Обсуждения критериев не было, потом один за другим посыпались обзоры. Понятное дело, никто не читал обзоры друг друга, чтобы они не повлияли на собственные. В результате мы получили следующее:
Я сам решил отказаться от первого критерия. Двое жюри последовали моему примеру. А Schafft просто выбрал другие, на самом деле, более интересные критерии. Это все произошло абсолютно независимо и без какого-либо обсуждения.

Что мы получили в итоге — текстовая часть без претензий, мнения всех членов жюри. А вот цифровые оценки — … Вот тут-то мы и поимели некоторое обсуждение, или оно нас. Закончилось тем, что все же большинством членов жюри мы решили, что первый критерий (Соответствие условиям конкурса), во-первых, не может иметь балльную оценку, а во-вторых, является слишком формальным и применять его не следует, поскольку большинство считает все работы соответствующими теме конкурса («Пейзаж»). Поэтому решено было отбросить первый критерий и оценки посчитать на основе оставшихся — среднее по каждому жюри (кроме sq, у него уже стояла авторская общая оценка, не равная среднему отдельных компонент). Ну и общие результаты также по среднему баллу.

Что получилось…
Читать дальше →

После некоторого перерыва, решил вернуться к Vectrex. Аналоговость и ламповость (в буквальном смысле) манит. Поскольку Dihalt, на который планировалась работа, назначен на начало января, хотелось сделать что-то новогоднее. Снег, особенно много — не лучший выбор для векторных устройств, так что ёлка мне показалось лучшим вариантом. Рисовать её прямыми векторами не очень интересно, решил кривыми, тем более технология была более-менее отработана в предыдущих работах (Electric Force, Springs ). В данном случае, однако, трудность была в том, что кривые должны быть не какие-нибудь случайные, а вполне конкретные, причём разные.

Читать дальше →

Так сложилось, что ZX Spectrum'a у меня раньше никогда не было. Еще учась в школе, я с БК-0010 сразу «перепрыгнул» на x86 (Robotron, Amstrad, далее — везде). Поэтому в то время, когда на территории exUSSR бушевала популярность ZX, у меня дома уже были довольно актуальные тайванские 286/386/486/etc и на их фоне ZX меня абсолютно не впечатлил, как, впрочем, и 8/16 битные игровые консоли. Игры казались ужасно примитивными, Турбо Паскаль не работал… Даже недолгий период интереса к демосцене в конце 90-х, правда не ушедший далее чтения сценерских электронных журналов, проходил исключительно на х86.

Читать дальше →

Статья на Demoscene.ru и последующее обсуждение в tg-чатике CAFePARTY

Demoscene.ru — MasterMentor: Я подниму Cцену с колен* или Make Scene great again**!

Написал и выставил на CAFe 2022 полноформатное демо для редкой в наших краях платформы, одного из древнейших персональных компьютеров — Commodore PET 4032. Монохромный текстовый режим 40x25 без возможности загрузки шрифта, никаких аппаратных скроллов, однобитный бипер на выходе последовательного порта, 32 килобайта ОЗУ, в которые помещается все 4 минуты демо без дозагрузок.



На этот раз я решил не делать традиционный making of, чтобы его написание не затянулось на год после релиза, с мучительными воспоминаниями о подробностях позапозапрошлого проекта. Вместо этого я в очередной раз попытался вести полноценный дневник разработки, записывая мысли непосредственно в рабочем процессе, и в кои-то веки удалось довести документируемый таким образом проект до завершения. Записи до 06.09 сделаны по памяти, до того момента я ещё не определился, что и в каком формате буду делать. Осторожно: плохо структурированное чтиво эпических размеров.


Читать дальше →