Ребенок изучает asm [SMD]

[pav13]

Томахомэ, я не знаю как конкретно работает определение int16 в твоём компиляторе, попробуй изменить на конкретное указание int16_t. Но у тебя ещё есть вычисление этого значения и возможно другие переменные int и компилятор заменяет int16 на int.

Но это разовое решение. Если надо везде и сразу, то надо указать компилятору что int это 16 битное число. Как это конкретно сделать не знаю (не пробовал).

[SegaMark]

Я может пропустил, но почему нельзя сделать видео в полный размер окна 320х224?

[SeregaZ]

ничего не мешает. но размер рома тогда получится не меньше, чем у двд фильма гыгыгы.

надо кароче подумать над оптимизацией и может каким-то пожатием графики, чтоб поменьшить это безобразие. я сейчас не про выкидывание одинаковых тайлов - это я сделать могу, но пока так и не прикручено до сих пор - а про пожатие, как в том-же МК3 или еще какой игре сделано... правда еще вопрос как быстро оно будет разжимать. так-же из-за увеличения размеров надо будет играться с параметрами, что Sharpnull объяснял (я правда мало что понял). там будет мерцать изображение и нужно будет их подбирать для пал и нтсц отдельно.

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

[SegaMark]

Вообще тема проигрывания видео на Sega Mega Drive, достойна отдельной тему на форуме, так как там есть где развернуться. Я бы и сам сделал, но я еще мало информации нарыл. Возможно уже есть такая темя, но я так и не смог ее найти. Из самого интересного что мне удалось найти это пример из SGDK под названием bad-apple(https://github.com/Stephane-D/SGDK/tree/master/sample/demo/bad-apple). На скрине характеристики данного видео и рома, при чем как я понял оно 2 раза пожато, но все равно выходит за рамки обычного картриджа в 4мб.

ну и так-же хотелось бы этот палетквант из коробки.

Если ты хочешь dll для pure basic(я так понимаю ты только на нем прогаешь), то наврятли тебе любая dll подойдет, скорей всего ее надо на том же pure basic писать, а на нем вряд ли кто-то будет делать, так как он сейчас не очень популярен.


Добавлено позже:

ничего не мешает. но размер рома тогда получится не меньше, чем у двд фильма гыгыгы.

А скорость воспроизведения такая же?

МК3 или еще какой игре сделано

Не думаю что это поможет, там довольно замудренно сделано и используется 3 алгоритма для более лучшего сжатия

правда я уже получается заставляю этого юзверя ffmpeg из интернетов найти и приложить к проекту... тоже не хорошо.

Насчет этого не парься, я много таких программ видел, так что так почти все делают. Ты можешь только ссылку дать чтоб не пришлось его самому искать и написать версию которую используешь, потому что там могут меняться аргументы в зависимости от версии.

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

Есть конверторы которые питон в exe переделывают, чтоб его не пришлось устанавливать. У тебя питон будет внутри ексешки лежать.

[Марат]

ну и так-же хотелось бы этот палетквант из коробки. но там опять из объяснений Марат тоже мало что понял хотя можно чатужпт попробывать будет скормить его порт из жавы скрипта в питон.

У меня есть готовая dll и код на паскале. Напиши мне, если нужен. Уже почти месяц валяется. Лень писать инструкцию. Но есть инструкция написанная ии Claude. После того, как ии написал мне код на Питоне, я попросил его переписать всё это на паскале. После этого исправил ошибки и довёл до ума. Теперь всё работает.

[SeregaZ]

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

предлагаю вернутся к этому вопросу чуть попозже хотелось бы в январе.

[Беларус учит русский]

тема проигрывания видео на Sega Mega Drive, достойна отдельной тему на форуме

Главное чтобы не тут, в Ромхакинге, потому что тут

Всё что относится к редактированию игр (РОМов).

[SeregaZ]

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

[SeregaZ]

Sharpnuuuuuuuuuuuuuuuuuuuuuuuuuuull????? вопрос есть тут на неделе пыхтел в попытке сотворить драйвер по мотивам GEMS, но вышло так себе - вроде играет. по началу даже по науке - всякие ожидания вбланков всяких, таймер ym2612 для точной организации проигрывания 16khz, проверка конца доигрывания буфера - все оказалось фигня - не работает. все выкинул - стало намного лучше, но все равно не то... плюнул-бросил, пока решил обратно к работе с тайловыми сетами и картами вернутся. изначально там вроде тоже было все по науке - отключение экрана, заливка сета-карты-палитры, включение экрана... потом посносил это отключение выключение и в эмуляторе Gens стало все прекрасно без мерцаний. во Fusion прекрасно если тайловый сет не сжат, а если пожато - бывает тайлы сыплятся. потом решил сделать загрузку тайлового сета в два разных места - буфера и грузить попеременно оттуда. стало лучше. но теперь во Fusion, BlastEm и Exodus простреливают полоски или точнее точки в линейку. в общем меня смущает момент с двумя местами с паузами, или даже точнее тремя.

схема:

Код: [Выделить]

главный луп

загрузка тайлового сета, карты, палитры

move.w #frame_delay-1,d0    ; пишем в d0 глобальную паузу между кадрами

wait_image:
bsr wait_next_frame      ; ждем следующего кадра (вертикальной синхронизации)
dbf d0,wait_image        ; уменьшаем счетчик кадров и повторяем, пока d0 не станет -1
        ; то есть эту паузу я еще понимаю. поскольку видео распаковывалось для 5 фпс, то соответственно надо ждать некую паузу между кадрами. по моему 11 для NTSC

; следом сразу идет следующая пауза, которую я осуждаю!
move.w #PNWAIT,d0
;move.w #$1200,d0            ; для NTSC:
palntscwait:
nop                              ; пустая операция (1 такт) для создания задержки
dbf d0,palntscwait               ; уменьшаем счетчик задержки d0 и повторяем цикл
         ; по сути мы тут сидим и ждем пока тикнет таймер

; по моему от этого значения 1200 или там $2400 если внизу экрана мое "видео" и зависит от того, где будут эти самые прострелы точек при просмотре во Fusion и прочих более точных эмулях. я сделал в редакторе возможность выставить мышкой где именно на большом экране будет выводится маленькое окошко с видео. и соответственно этот PNWAIT у меня плавающий. типа:
  ; #$2400 13:18 (внизу экрана)
  ; #$2000 13:12
  ; #$1A00 13:9
  ; #$1800 13:7
  ; #$1600 13:4
  ; #$1200 13:0

конец лупа

;{ подпрограмма ожидания следующего кадра
wait_next_frame:
Vdp_wait_NoVBL:
btst #3,1(a2)                 ; проверяем бит 3 в статусе VDP (VBlank флаг)
bne.s Vdp_wait_NoVBL           ; если VBlank активен (бит=1), ждем его окончания
Vdp_wait_VBL:             
btst #3,1(a2)                 ; снова проверяем VBlank флаг
beq.s Vdp_wait_VBL             ; если VBlank не активен (бит=0), ждем его начала
rts                              ; возврат из подпрограммы
;}

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

[SeregaZ]

потерялся Sharpnull... последний раз видели заходил за водкой в магазин Березка 

эх... в общем смотреть баг в ексодусе, бластем, фьюжн... ну и видимо на железе полезет. на Gens все прекрасно.

ну и заменить в бат файле путь до эмуля на свой. там сейчас мой стоит... после сборки по замыслу сразу стартует в эмуляторе свежесобранный ром.

архив снес, так как ниже более актуальная версия сборщика

[SeregaZ]

вроде со стороны манагера все сделал что хотел. вот со стороны asm затык с этим параметром PNWAIT эти редкопростреливаемые точки меня расстраивают. вроде бы если этот параметр выставить побольше, то тогда эти точки спустятся вниз экрана или даже выйдут снизу за пределы экрана, но тогда уже начинается рассинхрон со звуком. видео чуть запаздывает - больше времени на кадр. можно конечно тогда с делеями повоевать... сейчас 11 для 5fps NTSC стоит. наверное можно попробывать увеличить PNWAIT и уменьшить делей до 10 вместо 11...

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

ну и да - третий момент - мой звуковой драйвер не взлетел...

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

еще момент видимо адрес памяти в VDP может быть негативным чтоль? $92C00000 видимо заработает только если станет меньше $7FFFFFFF...

Добавлено позже:
пум пурум... пум пурум... а как писать дальше 7FFFFFFF ? там жеж еще есть вроде память. понятно что это уже скорей всего тайловая карта второго слоя... ненавижу внутренности приставки. люблю саму приставку, но ненавижу архитектуру! 

Добавлено позже:
подсказка была в коде записи тайловой карты move.l   #$40000003,(a2) - то есть эти самые 0003. значит если мой адрес превышает $7FFF то надо начинать писать уже в #$40000001 к примеру или #$40000002... надо будет думать как это предусмотреть.

по моему если изначально адрес меньше $7FFF то дальше память при записи сама сдвигается по +2 байта куда надо. но если изначально адрес больше $7FFF то надо будет видимо считать место старта записи по другому. типа я заранее подсчитал где оно должно быть BACKVDPADD = $81400000. тогда $8140 - $7FFF и после уже полученную разницу втуливать в #$40000001. завтра наверное потестирую.

[SeregaZ]

итак, новый день - новые проблемы если указатель починил:

Код: [Выделить]

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

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

[SeregaZ]

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

хотел до нового года сделать обновление GMM, но видимо не судьба

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

или хер с ним с GMM, и лучше засесть за прототип сетки ZT... давно хочу обкатать ту идею с каиллерой. но чот все никак не соберусь.

[Ti_]

Точки - это следствие записи палитры во время отрисовки экрана. Палитра должна записываться во время vblank. А тайлы и карту можно впринципе допускается и во время отрисовки, просто это в десятки раз медленнее.

[SeregaZ]

выкинул PNWAIT - вылез рассинхрон в конце. пока решил добавлять еще один кадр в конце (дублировать последний).

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

ХОТЯ СТОЯТЬЬЬ!!!!1111... сдвинул палитру опять вниз, после тайловой карты - вроде подмаргивания теперь не происходит Fusion and Blastem полет нормальный. зато Gens жуткий рассинхрон - видео крутит со скоростью света и из-за этого куча подмаргиваний.

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

архив снес, ибо релиз ниже.

[SeregaZ]

и да. стоило поменять размеры видео - все. поплыло 

видимо раз экран меньше - меньше инфы надо грузануть в память - грузится быстрее, и тогда пауза между кадрами плывет. соответственно вылазит рассинхрон. и это не говоря про Gens еще. у которого свои тараканы в голове, и если даже все настроить во Fusion и Blastem - в Gens будет швах. видимо стоит забить на Gens... но блин. в нем жеж удобно всяко разно просматривать. и VDP и оперативку и прочее...

Добавлено позже:
правильным выходом было бы усложнение кода. сейчас получается у меня все VBlank'и паузы между кадрами мотаются в холостую и только в одном все пачкой грузится в VDP. можно попытаться разделить - карты и палитра грузятся в последнем VBlank'e паузы между кадрами, а тайловый сет где-то в середине, ибо тайловый сет у меня все равно в другой буфер пишется, значит можно не опасаться за артефакты на экране. еще больше усложнить - это саму загрузку тайлового сета разделить на VBlank'и - но это трындец. ибо та-же процедура распаковки... как её прервать на половине? отслеживать всю движуху надо будет. это взрыв мозга

Добавлено позже:
по идее самым простым вариантом было бы на стороне манагера отслеживать размер экрана. и если он маленький - пофигу. если большой, то заведомо делить тайловый сет на 2 файла. сжимать их по отдельности. и тогда тайловая карта + палитра в последнем Vblank, одну половинку тайлового сета в предпоследнем, вторую половинку в предпредпоследнем.

Добавлено позже:
втулил между тайловым сетом и картой с палитрой ожидание vblank... Fusion - прекрасно. Blastem - полезли точки в момент загрузки палитры 

проклинаю архитектуру приставки!

Добавлено позже:
опять поставил палитру выше тайловой карты - и вроде точки пропали. боюсь поменять размер видео... опять полезут и точки и рассинхрон и понос и золотуха

[Ti_]

ибо та-же процедура распаковки... как её прервать на половине? отслеживать всю движуху надо будет. это взрыв мозга

Распаковка в RAM. Затем оттуда копирование в vram. Если с dma, то можно до 7 Кб за один vblank загрузить.


Добавлено позже:

не понял я где этот самый VBlank и куда именно палитру надо запихнуть, чтоб это подмаргивание не происходило 

Сразу в начале следующего кадра. То есть палитру грузить первой.

[SeregaZ]

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

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

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

Добавлено позже:
архив с Genesis Movie Maker

и ссыль на вк видео, если вдруг ютубы вышли из чата.
https://vk.com/video349950312_456239245 (когда на эмуленде тэг для вк видео появится?)

[SeregaZ]

пример использования:

[SeregaZ]

пока освободился - надо подумать над кодеком

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

соответственно рисование будет сначала читать первые 2 байта, прыгать в VDP в нужную точку, после читать вторые 1 или 2 байта - это будет счетчик, сколько раз повторять чтение и столько-же писать в VDP.

[SeregaZ]

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