ZX-Art: платформы и компьютеры

ZX-Art — это не только графика и музыка, но и с некоторого времени софт. Пока еще не окрепший, глючный, неудобный, но уже работоспособный.
На данный момент я занимаюсь расширением возможностей по каталогизации софта, и конкретно сейчас остановился на железе, с которым работает софт. В связи с этим хочу инициировать обсуждение, набраться советов и определиться с мнением.





Текущий план таков: есть «проды» (то есть программы как таковые), у каждой из них есть релизы.
Программа имеет:
  • Название
  • Лицензионный статус
  • Родительскую категорию из дерева категорий
  • Год первой публикации
  • Группу(фирму)-разработчика
  • Список оригинальных разработчиков с различными ролями.
  • Набор скриншотов.
  • Пати и место в конкурсе
  • Доп.материалы — карта игры, инструкция.
  • Связанную музыку/графику
  • Релизы.

Релизы могут иметь:
  • Дополнительных авторов (авторов крактро, доработок, фиксов, дисковой версии)
  • Издателя (некоторые программы издавались в разных странах разными компаниями)
  • Файл релиза
  • Дополнительные скрины
  • Файл обложки
  • год
  • Тип издания — оригинал, крак, переиздание, мод..
  • Формат издания (tap, tzx, trd, scl)
  • Минимально требуемое железо
  • Опционально поддерживаемое железо

Большая часть этой системы реализована, кое-что в процессе разработке, пара пунктов ждут своего часа. Я докидываю возможностей по мере возникновения необходимости.
Сейчас возникла необходимость реализовать грамотно Минимально требуемое железо и Опционально поддерживаемое железо. В моем понимании это — два непересекающихся списка с одними и теми же вариантами выбора.
Например:
Компьютеры
ZX 48
ZX 128
ZX Evolution (baseconf)
ZX Evolution (tsconf)

Управление
Kempston
Sinclair 2

Звук
AY
GS
SAA


То есть, как пример, для какой-нибудь игры можно выбрать в минимальных требования ZX 48, а в опциональных ZX 128, AY и Kempston.
Сложность сейчас заключается в конкретизации набора этого списка железа и в политическом решении по поддерживаемым платформам.
Например, вот такой список машин в ZXDB от Einar Saukas:
ATM
Pentagon 128
SAM Coupe
Scorpion
Sinclair QL
TC2048
TC2048/Tx2068
TS2068 or TC2068
ZX-Evolution
ZX-Spectrum 128 +2
ZX-Spectrum 128 +2A/+3
ZX-Spectrum 128 +2B
ZX-Spectrum 128 +3
ZX-Spectrum 128K
ZX-Spectrum 128K (load in USR0 mode)
ZX-Spectrum 16K
ZX-Spectrum 16K/48K
ZX-Spectrum 48K
ZX-Spectrum 48K/128K
ZX-Spectrum Next
ZX-UNO
ZX80
ZX81 16K
ZX81 1K
ZX81 2K
ZX81 32K
ZX81 64K

Жду ваших мнений по вопросам:
1. Нужно ли отдельно хранить ZX-Spectrum 128K (load in USR0 mode)? Разве это не та же самая машина?
2. Нужен ли в коллекции софт от SAM Coupe? Графика-музыка уже есть, люди частенько те же самые, то есть нельзя сказать, что это совсем-совсем уж не пришей рукав. Тем более, что ограниченную совместимость с ZX оно имеет даже, с некоторым бубном и матом позволяя запускать часть софта без эмулятора. Чем, в конце-концов, оно отличается от игр под ZX-Evo? От игр под Next? От невышедшего Sprinter?
3. Нужны ли ZX80/ZX81? Вроде как они конкретно несовместимы с ZX Spectrum ни в какой ипостаси. С другой стороны, если они не ZX, то что вообще тогда ZX?



Со своей стороны гарантирую возможность быстро и удобно пофильтровать платформы в категориях, выкинув неугодные из поля зрения. Вероятно, даже с запоминанием выбора на уровне пользователя, если проблема будет очень актуальной.

21 комментарий

avatar
Оу, 800 топик!
1. load in USR0 mode — никаких отличий от обычного 128, имхо
2. SAM Coupe было бы хорошо
3. ZX80/ZX81 довольно интересны. мы с ними не знакомы практически
  • VBI
  • +2
avatar
Sprinter-то определённо вышел, у меня один лет 15 уже пыль собирает.

Если добавлять ATM, Evo, то и Sam Coupe тоже. Это всё тот же 'суперспектрум' от поклонников оригинала и для них же, к тому же исторически первый.

ZX80/81 и QL определённо интересны.
avatar
Я тоже считаю, пусть будет и Sam Coupe и QL и ZX80/81.
Раз есть графика и музыка для Sam Coupe, то значит есть аудитория. Не вижу смысла ограничивать и проводить какие-то четкие границы, пусть они будут размыты )
avatar
предложу ещё категории:
1. язык (англ, рус, и т.д.)
2. наличие скрытых частей / читов
3. наличие релизов для других платформ (ссылки на другие подобные zxart-сайты)
4. примечание/заметки

> Формат издания
думаю это лишнее. переконвертить дело 1 минуты.
avatar
Спасибо, согласен! Так-то еще оценки надо (для топов по категориям) обязательно.
Примечание, в целом, вроде есть уже.
Формат нужен больше для системных потребностей — так проще встроить фильтр в категорию, чтобы видеть только программы под диск или под ленту.
avatar
Что планируется делать со скриншотами/графическими работами, относящимися к игре? Сейчас они полностью смешаны: в граф. работах есть скриншоты, а в скриншотах есть заставки.

Например: Astro Marine Corps
avatar
План такой:
1. Обновить систему хранения md5 у картинок, чтобы она была общей с релизами.
2. В выбранном релизе показывать картинки и скриншоты общим списком.
3. Через md5 убрать скриншоты, которые есть в виде картинок.
4. Сделать кнопку, позволяющую быстро сделать картинку из скриншота игры с указанием авторства.
avatar
md5 это нормально для поиска 100% идентичных дублей, на заставках должно сработать на ура.
Не было мыслей по поиску похожих картинок? Хотя бы среди тех, которые 256x192? В случае со скриншотами не думаю, что мы найдем идентичные через md5…
avatar
В принципе, поиск похожих картинок — не фантастика в целом. Другое дело, что похожих картинок раз два и обчелся, даже копии одного и того же оригинала обычно кардинально различаются.
Со скриншотами по идее можно разбить картинку на знакоместа, прохэшировать какое-то подмножество знакомест по каким-то критериям заполненности и проиндексировать картинки по вхождению знакомест. Но зачем? Да и для скринов, где спрайт на пиксель сдвинут, этот метод не сработает. Самое главное, что потребности не так много. MD5 выявит большую часть дублей, а остальное пусть остается как есть — необязательно все скриншоты рассортировывать по авторам и превращать в картинки. Пусть в галерее автора будут избранные картинки из игры, специально снятые для этой цели, а в скриншотах прода будут все скрины со всех источников в произвольных форматах.
avatar
Вообще-то можно написать хеш-функцию, которая будет выдавать результатом степень похожести от 0 до 100%. Установить экспериментально пороги значений для трёх уровней «не похоже», «возможно похоже» и «похоже». Например, 0-70, 70-95, 95-100. Верхняя автоматом записывает в дубль, средняя — с ручной проверкой. Как-то так.
avatar
Звучит как инструкция «как нарисовать сову» :)
Какие есть мысли по хеш-функции? Я видел только такой рецепт — картинка уменьшается до микроразмера, постеризуется и каждый пиксель превращается в кусок хэша. Это хорошо работает с большими картинками, но повторно использованные куски (одни и те же спрайты, например) оно не покажет.

Вот эти две картинки, например, похожи очень по деталям, но не по общей композиции. Единственный вариант, как сравнить детали — поделить картинку на знакоместа (?) и отдельно прохешировать какие-то из них (не все, все не нужны), а потом найти общие вхождения.

И всё же мой главный вопрос — а зачем :) Похожая графика уже объединена по авторам и по играм. Дубликатов больших заставок штук 10-20, и это в основном версии с разными логотипами (Where time stoods still)

avatar
еще можно нейронную сеть прикрутить, обучить её как надо, и через год проблема этих самых 10-20 дублей будет решена :)
avatar
Да я просто люблю упоротые алгоритмы. При необходимости придумать хитрый способ — не проблема. Но вопрос — зачем, да)
Кстати, приведенная картинка похожа процентов на 70, если правильно подойти к вопросу. Треть экрана 1-в-1 + очень много пересечений в верхних долях.
avatar
Я бы сходу предложил такой вариант, для частного случая ZX графики: вычитаем цвет каждого пикселя одной картинки из другой. Если они совпадают на 100%, остаётся чёрный экран. Если нет, остаётся N пикселей, тем больше, чем больше различий.

В любом случае полностью автоматически искать нечёткие дубли сложно, но можно строить список потенциальных дублей по некоторому порогу, чтобы дальше их оценил человек.
avatar
Да, я о чем-то таком и думал. + для ускорения — можно сначала отсеить тупо по разнице атрибутов — в разы быстрее. Хотя, наверное, ты это и имел ввиду.
avatar
Можно даже не считать пиксели, можно сжать картинку любым паковщиком и посмотреть размер. Скорее всего чем больше размер сжатой картинки — тем больше различий.
avatar
Иван Рощин в статье про конверсию графики для ч/б мониторов с увеличением градаций яркости (цвета = разные яркости в ч/б) оценивал качество конверсии по степени сходства с картинкой до конверсии.

www.ivr.webzone.ru/articles/bw/app_1.htm
avatar
Зачем? Если без разницы сколько у нас дублей разной степени похожести и схожих скриншотов — то наверное не зачем. Если мы хотим быть уверены, что у нас в базе не затесались похожие картинки, например по каким-то причинам загруженные в разных авторов, или иметь возможность сравнивать скриншоты по степени схожести, то проводить подобные проверки время от времени было бы полезно. При росте базы появление дублей и бОльшего количества схожих картинок, мне кажется, неизбежен.
avatar
Я думаю, что нет проблем иметь похожие работы или даже какой-то процент дублей в скриншотах к продам. А в галереях авторов всё равно всё выбрано вручную.
Так как хочется сделать именно агрегатор, то полная аккуратность, вероятнее всего, принципиально недостижима.
avatar
это, конечно, при условии, что текущая ситуация всё же будет поправлена по плану, который я выше набросал :)
avatar
Мне кажется подобный тул по сравнению картинок наверное лучше пилить, тестировать и запускать чисто локально, раз уж применимость столь узкая — для каких-то частных исследований. Нагрузку он даст приличиную, а смысла грузить общий сервер для узкой задачи — никакого.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.