[SMD] SGDK

[Werton]

Отечественный кодер под ником BlodTor, написал модуль-расширение link_cable для SGDK, в котором реализовал протокол обмена данными через сеговский линк-кабель.
А так же добавил небольшой пример-игру pac-man с коопертивной геймплеем на двоих через тот же линк-кабель.

Буквально на днях этот пул-реквест был принят, и теперь модуль доступен в дев версии мастер ветки SGDK (но по умолчанию отключен).
Теперь все желающие могут писать свой Zero Tolerance на SGDK

[SeregaZ]

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

но он материл на чем свет стоит этот самый ZT и ругался на 4600 бод или сколько то там... посему, по моему диванно икспердному мнению, нужен не столько линк кабель, сколько картридж, который бы мог писать в память приставки на лету и соответственно RJ45 с вайфаем чтоб был встроен в этот картридж для игры по интернету. тогда ZT заиграла бы новыми красками. ну и чтоб два раза не ходить - такой картридж надо чтоб был сразу со встроенной х32 и CD. вот только как представлю цену такого картриджа... сразу хочеться спрятаться в шкафу и тихонько заплакать

ахахаха! самый эпик будет если на какойнить там SNES сделать такую-же приблуду и заставить играть эти две консоли в одной сети )) *как фанат мегадрайва осуждаю эту идею

[ALKOSHA]

На миг мелькнула мысль жахнуть PETSCII на сежке. Text-mode же нативный.
И тут же врезался тоблом о суровую реальность, вспомнив тот удручающий факт, что у сеги индексированные цвета per-screen, тогда как на C64 (как и на ZX, CPC, MSX, CGA) - атрибут per-tile.
Есть вариант в монохроме, как было в Commodore PET (ну или MDA, если угодно. Чип тот же, charset в ПЗУ прошит другой). Но монохром эт уныло.
Ещë вариант - загнать 256 символов с transparent, и на втором слое задавать квадратики из 16ти цветов PAPER. Но тогда INK нельзя менять. А 16 (INK) x256 вариантов кэшировать — жырновато. Это уже уровень соника 3д бласта, и то, там потоково тайлы кэшировались...
Неужели сежка не такая всесильная, как мне казалось на первый взгляд
Видяху дунди и то проще эмулить полу-аппаратно.
А есть ещë какие варианты реализации данной затеи?
конечно Petscii-art влез бы и в фуллскрин. Но хочется, чтоб и памяти он потреблял как в оригинале, а то теряется смысл такого подхода.

[Werton]

И тут же врезался тоблом о суровую реальность, вспомнив тот удручающий факт, что у сеги индексированные цвета per-screen, тогда как на C64 (как и на ZX, CPC, MSX, CGA) - атрибут per-tile.

Хз, что ты имел в виду под "индексированные цвета per-screen", но на md любому тайлу задника можно задать одну из 4х палитр.

[ALKOSHA]

Хз, что ты имел в виду под "индексированные цвета per-screen", но на md любому тайлу задника можно задать одну из 4х палитр.

То и имел в виду. Есть битовая маска индексов 4bpp.
Да, знаю, что можно задавать любой из PAL0-3 на тайл.
Но опять же, если делать transparent фона на 256chars, то получается, что INK у них может менятся лишь в пределах 4ëх цветов, а не 16ти, как у коммодора.
И то, тут слишком много ручной мороки. Для rescomp любые одинаковые изображения будут считаться уникальными, даже если это чëрная буква "Ж" на белом фоне, а рядом она же, но на фоне уже другого цвета.

Добавлено позже:
ещë по прерыванию H-Int можно переключать палитры, но это такой себе костыль. На строку всë равно не может быть больше 4ëх вариантов. И гемор по подготовке ресурсов возрастает по экспоненте.

Добавлено позже:
EGA/VGA видяхи вот идеальные для аппаратной эмуляции PETSCII графона, ибо имеют общие корни. Но поскольку это IBM PC, это будет смотреться не так эффектно, как гипотетическая реализация на сежке...

[Sharpnull]

Ещë вариант - загнать 256 символов с transparent, и на втором слое задавать квадратики из 16ти цветов PAPER. Но тогда INK нельзя менять. А 16 (INK) x256 вариантов кэшировать — жырновато.

Для тайлового шрифта состоящего из текста и фона по одному цвету из палитры (виртуальной) на 16 цветов достаточно 1024 (4 * 256) тайлов и по 4 цвета на каждую из 4 палитр MD. На переднем фоне текст задаётся палитрой MD и тайлом из 4 наборов (4 * 4 = 16 цветов), на заднем фоне однотонный тайл, от пробела можно взять. Для 8 цветов потребуется 512 тайлов (2 * 256) и 2 цвета на каждую палитру MD.

[ALKOSHA]

Для тайлового шрифта состоящего из текста и фона по одному цвету из палитры (виртуальной) на 16 цветов достаточно 1024 (4 * 256) тайлов и по 4 цвета на каждую из 4 палитр MD. На переднем фоне текст задаётся палитрой MD и тайлом из 4 наборов (4 * 4 = 16 цветов), на заднем фоне однотонный тайл, от пробела можно взять. Для 8 цветов потребуется 512 тайлов (2 * 256) и 2 цвета на каждую палитру MD.

1024 тайла - весьма прожорливо. Овчинка выделки не стóит. Дешевле готовый petscii арт скормить рескомпу как однородную картинку. Он там своими алгоритмами может даже компактнее ужать (в зависимости от комбинаций).

[Sharpnull]

1024 тайла - весьма прожорливо. Овчинка выделки не стóит

Я не знаю что у вас за овца, что приходится экономить. Если имитировать текстовый режим, то ещё останется VRAM, а в роме занимать будет 2048 байт для 1bpp шрифта + код для преобразования в 4bpp. Для PETSCII изображения на весь экран экономить VRAM нет смысла, а в роме займёт + tilemap. rescomp будет использовать VRAM до 1120 тайлов (320x224) в зависимости от уникальности тайлов (с учётом отражений).

[ALKOSHA]

Я не знаю что у вас за овца

Я про то, что при расходе в кило тайлов - теряется рентабельность заморачиваться с нарезкой фонтов, отделением зëрен от плевел. Т.к. в растровом виде готовый арт в png формате рескомп пожмëт своими алгоритмами ± в те же самые объëмы.

[ALKOSHA]

такой вопрос назрел.
Можно ли как-то без артефачного мерцалова подсасывать по DMA потоково графон фонов в виде фулл-скрин анимации не прибегая к дабл-буферингу?
Чёт пробую, не успевает оно до VBlank обновиться, и меж кадров виден тайловый мусор. Так или иначе приходится юзать буфер в VRAM
И демка bad apple кажись юзает предварительно кэш.

Добавлено позже:
А да. Ещё одно наблюдение. Если юзать меж кадрами очистку Vram, то мусор пропадает. Но соответственно видно мерцание.
Стало быть, tilemap обновляется быстрее, чем успевает обновиться графика самих тайлов.
Но проблема в моём случае в том, что графика на каждый фрейм уникальна, онли тайл-мапы обновлять - не вариант.

Добавлено позже:
DMA-трансфер данных кажись порядка 20кб за фрейм... эххх... слабенько.

Добавлено позже:
Блииин... Мне бы ещё 3д матешу асилить... 
С нейронкой о таком кекать практически бесполезно. Она оч тупит в фиксед-поинт арихметике. Да и в целом низкоуровневый программиздинг для нейронок - непосильная задача. Их удел - питоны/JS'ы, где в одной строчке укладывается вся программа.

А мне всего-то надо реализовать фёрст-пёрсон управление камерой. То бишь, на экране по вводным значениям позиции на X Y карты мира и угла поворота камеры с mip-map скейлом позиционируются аппаратные спрайты (не нужно мучать приставку per-pixel псевдо-графикой).

[SeregaZ]

хы... я тоже плевался от этого всего когда GMM делал. 32х интересно получше ли с этим делом будет? а то полноразмерное не сделал. так как второй буфер налазит на тайловую карту. отчасти можно было бы тайловый сет каждого кадра резать на 2 части. типа 1-2 половинки одного кадра идут наверх, 1 половинку второго кадра сразу за ними, а вот 2 половинку второго кадра писать за тайловой картой. это правда тайловую карту налету надо будет пересчитывать.