Разработка и ромхакинг > Программирование

[SMD] SGDK

<< < (41/42) > >>

ALKOSHA: Таки решил рендерить объекты мип-мапами на одном из слоёв, ибо объекты достаточно крупные, и спрайт-генератор вряд ли вывезет... Но блин... врагов и фаерболлы для плавности хотел таки спрайтами, и тут возникают сложности с Z-сортировкой с объектами на плейне. Походу всё  на плейн придётся переносить. Посмотрим. А, и ещё... Rescomp анализирует дубли по тайлам, если оные встречаются в разных файлах ресурсов типа IMAGE для компактной упаковки в VRAM ? У ГПТшки спросил, фиг знает, где он это вычитал или додумал, но слишком хорошо, чтоб быть правдой Добавлено позже: п.с. у меня последняя версия. То он за 1.12 воспринял из-за старых каталогов, в которых я обновлял файлы. Просьба не размещать с помощью тэга img изображение со стороной более 700 пикселей. ghostdog3

Werton: --- Цитата: ALKOSHA от 13 Сентябрь 2025, 13:26:53 ---Rescomp анализирует дубли по тайлам, если оные встречаются в разных файлах ресурсов типа IMAGE для компактной упаковки в VRAM ? У ГПТшки спросил, фиг знает, где он это вычитал или додумал, но слишком хорошо, чтоб быть правдой --- Конец цитаты --- Нет в rescomp нет никакой крос оптимизации между ресурсами (знаю это, потому ковырял его когда добавлял поддержку перекрестных сылок между ресурсами Object), гптшка как ему и положено нафантазировал :biggrin: Про аргумент BEST он тоже насвистел, это не для оптимизации тайлов и экономии VRAM, а для сжатия и экономии места в ROM, но его тогда нужно будет для использования расжимать, а во VRAM оно займет столько же места. Расшарить тайлы можно только через общий Tileset между разными Tilemap, а для Image нельзя, тайлсет уже вшит во внутрь его структуры. Добавлено позже: А вообще зря ты тут такие вопросы задаешь, тут спецов по sgdk нет, с такими вопросами лучше напрямую к разрабу на официальный дискорд.

ALKOSHA: --- Цитата: Werton от 13 Сентябрь 2025, 16:22:47 ---Расшарить тайлы можно только через общий Tileset между разными Tilemap, а для Image нельзя, тайлсет уже вшит во внутрь его структуры. --- Конец цитаты --- Получается... для раскадровки мне нужно все кадры анимации с дублирующимися тайлами хранить в едином атласе, а рядом к нему тайлсет прилагать. Я видел чёто такое в примерах с анимированными тайлами фона соника. Но пока на уровне теории. На практике ещё не догнал, как там это прописать,  чтоб пахало как положено.

Werton: --- Цитата: ALKOSHA от 13 Сентябрь 2025, 16:37:51 ---Я видел чёто такое в примерах с анимированными тайлами фона соника. Но пока на уровне теории. На практике ещё не догнал, как там это прописать,  чтоб пахало как положено. --- Конец цитаты --- Это мой пример, могу пояснить, если есть вопросы. --- Цитата: ALKOSHA от 13 Сентябрь 2025, 16:37:51 ---Получается... для раскадровки мне нужно все кадры анимации с дублирующимися тайлами хранить в едином атласе, а рядом к нему тайлсет прилагать. --- Конец цитаты --- 3 раза прочитал и не понял, что ты хотел сказать :biggrin:

ALKOSHA: --- Цитата: Werton от 13 Сентябрь 2025, 16:44:44 ---3 раза прочитал и не понял, что ты хотел сказать --- Конец цитаты --- Ну смари... Есть такая деревянная древняя игра thunder blade. Приближающиеся здания типа - это кадры анимации, которые я должен в один монолитный png загнать, дабы rescomp у них определил все дубли 8х8 меж разными кадрами. Каждое здание состоит из тайлов условного тайлсета, например, есть в тайлсете один экземпляр окна, один экземпляр бетона. Нужно рескомпу указать на этот тайлсет, чтоб он его использовал в VRAM как собственно тайлсет. А кадры анимации в Vram будут как тайл-мап  (2д массив ссылок указателей на окно или бетон из тайлсета)... наверное опять непонятно пояснил... Добавлено позже: Вроде рескомп понимает tmx-формат.

Werton: --- Цитата: ALKOSHA от 13 Сентябрь 2025, 16:52:54 ---наверное опять непонятно пояснил... --- Конец цитаты --- да. Я понял, что ты хочешь сделать анимацию на задниках (что уж там будет рисоваться не столь важно). Анимацию можно сделать путем подмены тайлов в vram, но немного по-костыльному, т.к. встроенной функциональности для анимации тайлов в sgdk нет, а сам ты не знаешь в какую ячейку в vram sgdk засунет конкретный тайл. Поэтому тайлсет нужно подготовить так, чтобы можно было это предсказать: - в исходном тайлсете все тайлы подлежащие замене/анимации располагаешь в начале тайлсета - исходный тайлсет должен быть оптимизирован и не содержать дубли, зеркальные тайлы и пустоту между тайлами - готовишь тайлсеты под анимацию (1 тайлсет на кадр) - в тайлсетах под анимацию, тайлы которые будут замещать/анимировать исходные тайлы располагаешь ровно в тех же позиция, что и на исходном тайлсете (если в кадре анимации есть дубли тайлов, то оптимизацию тайлсета можно отключить, иначе позиции съедут), остальные тайлы которые не анимируются туда не суешь - с помощью исходного тайлсета рисуешь исходную мапу/картинку (Map или TileMap) - в рантайме подгружаешь в vram нужный тайлсет (следующий по кадру) на позицию исходного тайлсета, затирая/подменяя при этом только тайлы, которые должны быть анимированы В примере так сделано, возможно есть способ получше.

ALKOSHA: --- Цитата: Werton от 13 Сентябрь 2025, 17:18:59 ---(1 тайлсет на кадр) --- Конец цитаты --- Ну вот если раскадровка будет в атласе, то там 1 тайлсет на все кадры... Тут сложность в том, чтоб выцепить указатель на нужный кадр, чтоб всё не посыпалось. Добавлено позже: --- Цитата: Werton от 13 Сентябрь 2025, 17:18:59 ---- в рантайме подгружаешь в vram нужный тайлсет (следующий по кадру) на позицию исходного тайлсета, затирая/подменяя при этом только тайлы, которые должны быть анимированы --- Конец цитаты --- А... До меня дошло, что именно непонятного я пишу. Не. В том и прикол, что в моём случае тайлсет должен кешироваться в VRAM однократно, и висеть там статично. Нужно маняпулировать исключительно тайл-мапом (массивом ссылок-указателей на тайлсет), процедурно раскидывающим этот тайлсет по экрану. Добавлено позже: И вот я думал, что рескомпу можно как-то указать отдельно файл статичного тайлсета, а отдельно файлы для тайл-мапы, которые можно щёлкать туда-сюда. И я глянул чендж-логи, таки да. Есть поддержка TMX формата. Терь бы обуздать сию фитчу. (опыт работы с ним уже имеется, но на libgdx, sdl, godot).

Werton: --- Цитата: ALKOSHA от 13 Сентябрь 2025, 20:35:25 ---В том и прикол, что в моём случае тайлсет должен кешироваться в VRAM однократно, и висеть там статично. --- Конец цитаты --- В этом не особо много смысла, т.к. если не стримить тайлы анимации на лету из rom, а загружать все тайлы во vram сразу, то она быстро кончится (даже с учётом, что все дубли и зеркальные тайлы удалены, тем более, что в описанном мною способе они тоже удалены). А тебе ещё под спрайты место нужно, если разве, только, у тебя совсем простая анимация на задниках в пару-тройку кадров на несколько тайлов. --- Цитата: ALKOSHA от 13 Сентябрь 2025, 20:35:25 ---Нужно маняпулировать исключительно тайл-мапом (массивом ссылок-указателей на тайлсет), процедурно раскидывающим этот тайлсет по экрану. --- Конец цитаты --- Это будет сделать не просто, т.к. когда sgdk грузит тайлсет (без разницы из изображения или tmx файла), он его оптимизирует (а если отключить оптимизацию, то vram не хватит), и на каких позициях тайлы окажутся в vram ты не знаешь, поэтому манипулировать тайлами в тайлмапе ты не сможешь (точнее сможешь, но на угад). Поэтому тебе всё равно придётся заранее подготовить оптимизированный и отсортированный в нужном порядке тайлсет и для tmx тоже (как и в моем примере), чтобы ты мог гарантировать себе позиции тайлов в vram. Но, опять же я не вижу никакого профита от этого способа анимации, а гемора с ручной работой, как по мне, в нём ещё больше. --- Цитата: ALKOSHA от 13 Сентябрь 2025, 20:35:25 ---И я глянул чендж-логи, таки да. Есть поддержка TMX формата. Терь бы обуздать сию фитчу --- Конец цитаты --- Я там буквально неделю назад в дев версию (master ветка на GitHub) отправил пример загрузки карты из Tiled tmx (смотри sample/basics/tmx-map), может это чуть ускорит твои изыскания.

ALKOSHA: Очень нравится вид из глаз в Sword of Vermilinon. Мечта повторить и улучшить. Убрать дискретность, сделать фуллскрин. https://youtu.be/HNxjS7XwU8o?t=232

ALKOSHA: А вот чисто на уровне теории можете пояснить, что за сатана происходит в мозгах VDP в игре Lawnmowerman на уровнях вида из глаз? Как я понимаю, там всë те же мип-мапы пререндером приближаются, но хранятся они в виде покадрового X-скейла, а по Y их растягивает уже H-Blank.(таким же образом скейлится морда в финального босса)... но блин... как же сделана слоëнка в 4 слоя? Чëт в голове не укладывается, как оно так... тоже какой-то прикол со скроллами по H-blank? в VRAM там тока два слоя как будто изображены в моменте... в общем, нипанятна... На снес-то из коробки есть режим в 4 слоя (сама процедура скейла походу тем же алгоритмом сделана, что и на сеге, ведь MODE7 распространяется лишь на один слой). По уровням, где действительно юзается MODE7, на сеге используют palette shifting, там тоже всë предельно просто и понятно. Но 4 слоя - магия какая-то.

Werton: Отечественный кодер под ником BlodTor, написал модуль-расширение link_cable для SGDK, в котором реализовал протокол обмена данными через сеговский линк-кабель. А так же добавил небольшой пример-игру pac-man с коопертивной геймплеем на двоих через тот же линк-кабель. Буквально на днях этот пул-реквест был принят, и теперь модуль доступен в дев версии мастер ветки SGDK (но по умолчанию отключен). Теперь все желающие могут писать свой Zero Tolerance на SGDK :biggrin:

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: --- Цитата: ALKOSHA от 05 Ноябрь 2025, 09:45:01 ---И тут же врезался тоблом о суровую реальность, вспомнив тот удручающий факт, что у сеги индексированные цвета per-screen, тогда как на C64 (как и на ZX, CPC, MSX, CGA) - атрибут per-tile. --- Конец цитаты --- Хз, что ты имел в виду под "индексированные цвета per-screen", но на md любому тайлу задника можно задать одну из 4х палитр.

ALKOSHA: --- Цитата: Werton от 05 Ноябрь 2025, 16:55:45 ---Хз, что ты имел в виду под "индексированные цвета per-screen", но на md любому тайлу задника можно задать одну из 4х палитр. --- Конец цитаты --- То и имел в виду. Есть битовая маска индексов 4bpp. Да, знаю, что можно задавать любой из PAL0-3 на тайл. Но опять же, если делать transparent фона на 256chars, то получается, что INK у них может менятся лишь в пределах 4ëх цветов, а не 16ти, как у коммодора. И то, тут слишком много ручной мороки. Для rescomp любые одинаковые изображения будут считаться уникальными, даже если это чëрная буква "Ж" на белом фоне, а рядом она же, но на фоне уже другого цвета. Добавлено позже: ещë по прерыванию H-Int можно переключать палитры, но это такой себе костыль. На строку всë равно не может быть больше 4ëх вариантов. И гемор по подготовке ресурсов возрастает по экспоненте. Добавлено позже: EGA/VGA видяхи вот идеальные для аппаратной эмуляции PETSCII графона, ибо имеют общие корни. Но поскольку это IBM PC, это будет смотреться не так эффектно, как гипотетическая реализация на сежке...

Sharpnull: --- Цитата: ALKOSHA от 05 Ноябрь 2025, 09:45:01 ---Ещë вариант - загнать 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: --- Цитата: Sharpnull от 05 Ноябрь 2025, 22:52:09 ---Для тайлового шрифта состоящего из текста и фона по одному цвету из палитры (виртуальной) на 16 цветов достаточно 1024 (4 * 256) тайлов и по 4 цвета на каждую из 4 палитр MD. На переднем фоне текст задаётся палитрой MD и тайлом из 4 наборов (4 * 4 = 16 цветов), на заднем фоне однотонный тайл, от пробела можно взять. Для 8 цветов потребуется 512 тайлов (2 * 256) и 2 цвета на каждую палитру MD. --- Конец цитаты --- 1024 тайла - весьма прожорливо. Овчинка выделки не стóит. Дешевле готовый petscii арт скормить рескомпу как однородную картинку. Он там своими алгоритмами может даже компактнее ужать (в зависимости от комбинаций).

Sharpnull: --- Цитата: ALKOSHA от 06 Ноябрь 2025, 01:08:25 ---1024 тайла - весьма прожорливо. Овчинка выделки не стóит --- Конец цитаты --- Я не знаю что у вас за овца, что приходится экономить. Если имитировать текстовый режим, то ещё останется VRAM, а в роме занимать будет 2048 байт для 1bpp шрифта + код для преобразования в 4bpp. Для PETSCII изображения на весь экран экономить VRAM нет смысла, а в роме займёт + tilemap. rescomp будет использовать VRAM до 1120 тайлов (320x224) в зависимости от уникальности тайлов (с учётом отражений).

ALKOSHA: --- Цитата: Sharpnull от 06 Ноябрь 2025, 02:14:07 ---Я не знаю что у вас за овца --- Конец цитаты --- Я про то, что при расходе в кило тайлов - теряется рентабельность заморачиваться с нарезкой фонтов, отделением зëрен от плевел. Т.к. в растровом виде готовый арт в png формате рескомп пожмëт своими алгоритмами ± в те же самые объëмы.

ALKOSHA: такой вопрос назрел. Можно ли как-то без артефачного мерцалова подсасывать по DMA потоково графон фонов в виде фулл-скрин анимации не прибегая к дабл-буферингу? Чёт пробую, не успевает оно до VBlank обновиться, и меж кадров виден тайловый мусор. Так или иначе приходится юзать буфер в VRAM И демка bad apple кажись юзает предварительно кэш. Добавлено позже: А да. Ещё одно наблюдение. Если юзать меж кадрами очистку Vram, то мусор пропадает. Но соответственно видно мерцание. Стало быть, tilemap обновляется быстрее, чем успевает обновиться графика самих тайлов. Но проблема в моём случае в том, что графика на каждый фрейм уникальна, онли тайл-мапы обновлять - не вариант. Добавлено позже: DMA-трансфер данных кажись порядка 20кб за фрейм... эххх... слабенько. Добавлено позже: Блииин... Мне бы ещё 3д матешу асилить...  :wacko: С нейронкой о таком кекать практически бесполезно. Она оч тупит в фиксед-поинт арихметике. Да и в целом низкоуровневый программиздинг для нейронок - непосильная задача. Их удел - питоны/JS'ы, где в одной строчке укладывается вся программа. А мне всего-то надо реализовать фёрст-пёрсон управление камерой. То бишь, на экране по вводным значениям позиции на X Y карты мира и угла поворота камеры с mip-map скейлом позиционируются аппаратные спрайты (не нужно мучать приставку per-pixel псевдо-графикой).

Навигация

 Главная страница сообщений

Следующая страница

Предыдущая страница

Перейти к полной версии