Демка - SatAM для GBA

[Image Master 4]

Уважаемые поклонники персонажа Sonic the Hedgehog, и особенно - одноименного мультсериала!

 

Наконец готов с радостью представить на ваш суд вашему вниманию изготовленную мной посвященную ему маленькую "демку" для ARM7TDMI (Game Boy Advance)

 

http://narod.ru/disk/15218826000/SATAM2.GBA.html

 

(должна нормально пойти на эмуляторе; я запускаю через M3 adapter)

 

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

 

(to administration: так и не смог решить, какой раздел подходит для этой публикации. Если что, пожалуйста, перенесите по своему усмотрению)

[Varyen 671]

Переместил и переименовал тему

 

На всякий случай уточню, это полноценный декодер видео для GBA, написанный с нуля. Кстати, работает очень шустро, вспомните ром с Sonic X - какое там качество. =)

[LinesPrower 0]

Впечатляет.

А можно побольше технических подробностей?

В частности, интересно

- в каком формате хранится видеопоток? в каком-то собственном? Судя по соотношению длительность/битрейт/качество он хранится практически без сжатия... это как-то не радует. Или все таки как-то сжимается? Если да, то как? Реально ли заюзать, например, MPEG-4?

- какой реальный FPS в этом видео?

- какой видеорежим здесь используется? (мне сказали, что их на GBA как минимум два - 15-битный цвет без двойной буферизации, либо 256-цветная палитра, но с буфером)

 

P.S. Я не специалист в области ARM и, в частности, GBA. Просто очень любопытно))

[Image Master 4]

Полностью отвечу чуть позже, пока интересно, что может быть очевидно интересующимся.

 

Видео взято с SatAM DVD, и, к счастью, удалось вернуть ему исходный вид. В оригинале было 720x480 24 fps, уменьшаем размер изображения ровно в три раза - и как раз подходит под экран GBA, 240x160 24 fps. С учетом 16-битного цвета и длительности в 1:02 мин вполне очевидно, сколько места бы это заняло без сжатия, и во сколько раз это бы превосходило максимальный объем GBA картриджа.

 

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

Прежде всего интересно, можно ли достичь чего-то лучшего (код был написан почти сразу после первого знакомства с инструкциями ARM, лобовым методом, "авось и так получится", и ни разу не оптимизирован).

 

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

 

Вообще графических режимов на GBA шесть, я же здесь использую простейший - 16 bit bitmap, это значит, можно рисовать по точкам, используя в любом сочетании любые доступные цвета (реально их 15bit), вот я решил попробовать, как у меня это получится.

 

Sonic... He's the fastest thing alive.

 

Я специально хотел, чтобы первым реальным видео, воспроизведенным этим алгоритмом, был именно SatAM... это символично.

[mega shedoy 0]

а можно скрины из игры

[LinesPrower 0]

Видео взято с SatAM DVD, и, к счастью, удалось вернуть ему исходный вид. В оригинале было 720x480 24 fps, уменьшаем размер изображения ровно в три раза - и как раз подходит под экран GBA, 240x160 24 fps. С учетом 16-битного цвета и длительности в 1:02 мин вполне очевидно, сколько места бы это заняло без сжатия, и во сколько раз это бы превосходило максимальный объем GBA картриджа.

При 15 битах на пиксел без сжатия получаем 102 метра. Хм, значит сжатие все-таки есть. Примерно 4 бита на пиксел. Все равно жутко много <_< Еще бы ужать раз в 20, и будет реально круто))

Кстати, а какой максимальный размер картриджа?

 

Насчет "внешних" впечатлений... Самый мерзкий артефакт - это сильный шум, на "однотонных" светлых областях очень заметно. Откуда он берется - мне не совсем понятно (15-битный цвет?). Ну и еще отсутствие backbuffer'а (рендерится ведь прямо в "видимую" область памяти, да?) - только тут искажения возможно различаются на разных эмуляторах, как это выглядит на реальном железе я не знаю - у меня его нету.

 

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

 

P.S. Хоть кто-то здесь чем-то интересным (для меня) занимается))

P.S.2. http://citeseerx.ist.psu.edu/viewdoc/summa...=10.1.1.20.4313 Немного погуглил на тему)) Но MPEG-4 конечно жестокий алгоритм))

[Image Master 4]

Это мультфильм, игрой как таковой он не является.

 

Некоторые картинки (из эмулятора) ниже.

 

 

 

 

 

Внимание: недавно обнаружил, что в некоторых эмуляторах возможна более сильная постеризация, чем 15 bpp, поэтому изображение может быть хуже, чем на реальной системе.

[sonic hero 0]

Штука сделана добротно,но увы мне не нравится Сатам так что оценку ставить не буду.

[mega shedoy 0]

Штука сделана добротно,но увы мне не нравится Сатам так что оценку ставить не буду.

мне тоже не нравится сатам я шитаю что это жалкая пародия на соника

[Stormwind 202]

mega shedoy, вы хотите добавить в свою коллекцию ворн за оффтопик?

 

По теме - запустил на VBA 1.8.0 beta, видео отстаёт от звука, ибо фреймрейт видео на глаз где то 19-20. Зум и все прочие св/п для улучшения картинки отключены.

Щас попробую запустить на ДСке через 3-в-1.

[LinesPrower 0]

Ладно, расскажу как это работает))

Изображение кодируется блоками 4х4 пиксела. Все блоки независимы. Каждый блок кодируется двумя словами. Первое слово содержит два цвета (a и b), и определяет 4-цветную "палитру" блока, куда кроме a и b входят еще две линейные комбинации (2a+b)/3 и (a+2b)/3.

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

Интересный алгоритм.

Достоинства:

- не требовательный к вычислительным ресурсам

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

- производительность и степень сжатия никак не зависят от входного сигнала

Недостатки:

- низкая степень сжатия

- создает характерные искажения

 

Ну и два вопроса

- вы этот алгоритм сами разрабатывали или он стандартный?

- а как работает кодер? в частности, как выбираются цвета для палитры? теоретически это может заметно влиять на качество картинки

[Image Master 4]

запустил на VBA 1.8.0 beta, видео отстаёт от звука

Скорее всего, неточные тайминги в эмуляторе. На реальной системе и других эмуляторах (в т.ч. VBA 1.7.2) все нормально.

[Image Master 4]

P.S. Хоть кто-то здесь чем-то интересным (для меня) занимается))

Взаимно.

 

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

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

Каким отладчиком пользовался?

 

P.S.2. (ссылка)

Спасибо за информацию. Интересно, что это вообще сделали, и особенно интересно, что утверждается достижение использования 16 млн тактов на 1 секунду (что как раз как на GBA). Но...

0) Разрешение намного меньше, чем у GBA, и лишь 15 кадров в секунду

1) Речь о подготовке YUV-данных, а надо еще в RGB перевести и вывести

2) Подчеркнута "заточка" на приложения типа видеоконференций, когда большую часть времени большая часть изображения статична (фон), и за счет компенсации движений расчеты для нее пропускаются, что дает сильную экономию времени

3) IDCT: 3a) ориентация на данные с сильными потерями, когда ненулевых коэффициентов немного и 3б) для тех данных, которые всё-таки есть, упоминается дополнительное уничтожение (игнорирование) малых по модулю коэффициентов - опять же, для как можно большей экономии времени расчетов

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

 

Но, честно говоря, я полагал, что для алгоритмов, испольщующих ДКП-квантование и компенсацию движений, процессора GBA принципиально не хватит, а тут хотя бы что-то.

 

При 15 битах на пиксел без сжатия получаем 102 метра мегабайта.

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

И потом, не забываем, что оригинал 24-битный. Размер составляет около 111 мб и 167 мб соответственно.

 

Кстати, а какой максимальный размер картриджа?

32 мегабайта.

 

 

to be continued

[Image Master 4]

Хм, значит сжатие все-таки есть. Примерно 4 бита на пиксел.

В данном случае - точно, не примерно.

 

Все равно жутко много.

Смотря с чем и как сравнивать.

 

Еще бы ужать раз в 20, и будет реально круто.

В случае сжатия с потерями - да, вообще говоря, можно, только полезных данных останется так мало, что, например, лично я бы задался вопросом - а зачем? а надо ли?

 

ты хочешь примерно 1 кб на кадр... кстати, почти так (даже еще чуть меньше) обстоят дела в realvideo-файлах, в которых хранится этот сериал на данном сайте. Конечно, да, именно в таком виде я и смотрел всё в первый раз, и было понятно и нравилось, но ты уверен, что не хочешь, чтобы изображение было получше?

Изначально там 8 кадров в секунду, но даже RealVideo с его фрактальным сжатием во многих местах не уложился в 1 кб на кадр и был вынужден пропускать часть кадров, чтобы в оставшихся было видно хотя бы что-нибудь.

 

И потом, это всё в принципе, когда нет ограничений на быстродействие. А здесь у нас GBA, ARM7TDMI @ 16 MHz. Реально ли на нем сделать ДКП-квантование + фрактальное сжатие (на распаковку) в реальном времени, пусть даже для 8- кадров в секунду?

Хотя этот вопрос получается открытым, после знакомства с той заметкой я начал сомневаться в полной невозможности этого...

 

Насчет "внешних" впечатлений... Самый мерзкий артефакт - это сильный шум, на "однотонных" светлых областях очень заметно. Откуда он берется - мне не совсем понятно (15-битный цвет?).

Что касается этого, я думаю, он берется от:

1) шума в исходном видео

2) потерь от сжатия, в том числе - из-за несовершенства алгоритма, примененного мной

3) округления до 15 бит на дисплее GBA

4) приближений, примененных мной при распаковке

5) дополнительного округления, которое может делать эмулятор, если запущено не на реальной системе

 

С п. 1 и 3 я сейчас ничего не могу поделать (кстати, шум в оригинале далеко не на последнем месте здесь), и они не имеют отношения к сжатию и данному алгоритму в частности.

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

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

 

Ну и еще отсутствие backbuffer'а (рендерится ведь прямо в "видимую" область памяти, да?) - только тут искажения возможно различаются на разных эмуляторах, как это выглядит на реальном железе я не знаю - у меня его нету.

Да, видеостраница лишь одна, поэтому прямо на экран, блок за блоком... уже сам видел в коде...

Но тут ничего не поделаешь, исходных кадров 24 в секунду, на экране 60 полей, поэтому несинхронность и tearing неизбежны в этом случае... Если бы было в целое число раз меньше - тогда было бы лучше, конечно. Но не сильно, из-за отсутствия буфера (а хранить данные во "внешней" ОЗУ бесполезно, так как копирование туда-сюда было бы неприемлемо медленным в этом случае; конечно, при 8 fps об этом можно думать, но при 24 - скорее всего, нет).

 

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

 

И еще, впечатление действительно отличается на разных системах. На первом GBA SP, например, вообще всё смотрится безупречно, постеризация и потери от сжатия практически совсем не бросаются в глаза. А несинхронность как раз, наоборот, хорошо заметна.

 

 

to be continued

Изменено 2 декабря, 2009 пользователем Image Master

[LinesPrower 0]

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

Десять лет занятий не прошли даром)) Да и ARM - не первая архитектура, которую я изучаю. И даже не вторая))

 

Каким отладчиком пользовался?

Называть это отладчиком как-то язык не поворачивается... Там даже breakpoint не поставишь. Visual Boy Advance.

 

Но, честно говоря, я полагал, что для алгоритмов, испольщующих ДКП-квантование и компенсацию движений, процессора GBA принципиально не хватит, а тут хотя бы что-то.

Для родного для GBA разрешения не хватит точно. И все-таки там видимо компенсация движений сильно сокращает расчеты, ибо ДКП ну очень вычислительно сложная штука. (Но компенсация движений требует много памяти (как минимум еще один буфер, не так ли?), с которой в GBA определенные проблемы; хотя многих деталей того же MPEG'а я не знаю. Этот стандарт где-нибудь есть в открытом доступе? Я не нашел.)

Без компенсации тоже все плохо - даже при блоке 4*4 и трех (!) ненулевых коэффициентах производительности скорее всего не хватит, не говоря о том, что это будет за картинка.

 

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

И потом, не забываем, что оригинал 24-битный. Размер составляет около 111 мб и 167 мб соответственно.

 

Согласен. Но вообще сдвиги - это то что ARM умеет лучше всего s=) Да и практический любой алгоритм сжатия использует энтропийное кодирование и следовательно требует работы с последовательностью битов, а не байтов. И с этим должен даже ГБА справиться. Надо только найти очень шустрый метод преобразовать сигнал в хорошо сжимаемый (вернее, шустрым должно быть обратное преобразование =) )

Да, насчет RGB/YUV, думаю это не так принципиально, можно изначально в RGB кодировать, переход в YUV дает только определенный выигрыш в качестве/сжатии.

 

ты хочешь примерно 1 кб на кадр... кстати, почти так (даже еще чуть меньше) обстоят дела в realvideo-файлах, в которых хранится этот сериал на данном сайте. Конечно, да, именно в таком виде я и смотрел всё в первый раз, и было понятно и нравилось, но ты уверен, что не хочешь, чтобы изображение было получше?

Изначально там 8 кадров в секунду, но даже RealVideo с его фрактальным сжатием во многих местах не уложился в 1 кб на кадр и был вынужден пропускать часть кадров, чтобы в оставшихся было видно хотя бы что-нибудь.

Ну, насчет 20 раз я конечно загнул)) А rmvb с этого сайта я смотрел. Качество ужасное. Но степень сжатия впечатляет. Особенно когда у тебя нет шустрого интернета...

 

Что касается этого, я думаю, он берется от:

1) шума в исходном видео

2) потерь от сжатия, в том числе - из-за несовершенства алгоритма, примененного мной

3) округления до 15 бит на дисплее GBA

4) приближений, примененных мной при распаковке

5) дополнительного округления, которое может делать эмулятор, если запущено не на реальной системе

 

Охотно верю)) Только мне кажется странным, что один и тот же пиксел (вернее целый блок) статичной (в пределах определенной погрешности) картинки может менять цвет от кадра к кадру, создавая "шум" - у кодера нет "временной устойчивости" (возможно в исходном сигнале цвет тоже меняется, но относительно незаметно, при этом колеблется возле "границы" и при округлении до 15 бит округляется в разные стороны)

 

Ну как все-таки работает кодер?

[Image Master 4]

Ладно, расскажу как это работает

(...)

Да, всё правильно. Здорово. И рассказать кратко - у меня бы не получилось (пытаюсь научиться).

Кстати, теперь я могу заслуженно сказать: "Я пишу понятный код".

 

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

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

 

В условиях отсутствия кэша это очень важно.

А зачем он вообще нужен?

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

Кстати, внутренняя память (в частности, из которой исполняется код в этой программе) на GBA без wait states, но всё равно обращение к памяти на ARM7TDMI - минимум три такта (чтение) или два такта (запись), быстрее не сделаешь.

 

- производительность и степень сжатия никак не зависят от входного сигнала

Это как раз одно из очень полезных качеств на "родине" этого алгоритма (или, может быть, ставилось как одно из требований при разработке).

Подробнее позже.

Хотя, полагаю, в общем случае, просто для сжатия изображений, оно скорее создает ограничения (прежде всего по степени/эффективности сжатия), чем помогает.

 

Недостатки:

- низкая степень сжатия

Это опять же, смотря с чем сравнивать, особенно в таких задачах (также частично см. ниже, частично - потом), для каких его делали.

Лично я бы, например, так не сказал. Совсем.

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

 

- создает характерные искажения

Это, но для каждого по-своему, думаю, можно сказать обо всех алгоритмах сжатия с потерями.

Так что зачисление этого в недостатки - самое большее, дело вкуса.

Лично меня, например, очень-очень сильно достали характерные искажения от любых ДКП-методов. И в том чсиле поэтому я был рад изучить алгоритм принципиально другой (хотя, конечно, другой не во всём, блочность-то осталась). И уж тем более был рад сам написать программу на эту тему. А что удалось еще и на его основе видео сделать, в некотором смысле полноценное (без пропуска кадров) - в это даже еще как-то до конца не поверил.

"Характерные"-то они да, но характерные по-другому. Например, в отличие от ДКП-методов, создающих неприятные осцилляции (ringing) на тонких линиях, резких границах и т.п., этот алгоритм очень хорошо сохраняет границы (а в мульфильме, когда попадается одна линия на однотонном фоне, она сохраняется так хорошо, что вообще не заметно, что оно сжато с потерями), что, насколько я знаю, явилось одной из главных причин выбора именно такого метода, а не ДКП-шного, там, где его применяют (или, опять же, такое требование ставилось при разработке).

Иногда попадаются изображения, сначала сжатые с потерями ДКП-квантованием, а потом распакованные и сжатые этим методом. Так вот, "из-под" него видно, что ранее изображение "побывало под" ДКП! Мне кажется, интересное наблюдение.

 

- вы этот алгоритм сами разрабатывали или он стандартный?

Стандартный.

Только, насколько помню, есть какое-то несущественное отличие, порядок битов обратный, кажется.

Если до сих пор не очевидно, могу сказать так:

ну кто наконец назовет его?

Получит приз! (как раз встреча скоро намечается)

 

- а как работает кодер? в частности, как выбираются цвета для палитры? теоретически это может заметно влиять на качество картинки

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

Кодер же у меня работает очень тормознуто и хреново. Вначале происходит индексация (нахождение палитры для приближения) 4х4-пиксельной картинки до двух цветов с использованием того же самого давнишнего тупого метода, который я написал и использовал в своих экспериментах по индексации полноцветного изображения до 16 цветов (или вообще до n). Здесь я в лоб использую тот же самый алгоритм (написанный мною чисто на основе фантазии, без малейшего представления о том, как работают коммерческие индексаторы), только в качестве количества цветов в него подставлено два. Потом еще применяется простейшая (уже во времена написания алгоритма сжатия придуманная) "оптимизация" (замедляющая процесс еще на порядок), после чего по найденным по палитре цветам выбираются ближайшие и записываются в результат.

Кстати, вначале я не верил, что при таком хранении может получиться вообще что-то похожее на оригинал. Первый опыт с двухцветной палитрой показал, что почти так и есть, хотя сходство прослеживалось. Потом я придумал "оптимизацию", и полученное изображение стало иногда вообще быть очень похожим на оригинал (но не во всех блоках). А дальше доводить до ума я частично поленился, частично попытался и не получилось (плохо попытался, с ошибкой). Наверняка методом, близким к полному перебору, можно даже при плохом начальном приближении получить что-то хорошее, но это будет очень медленно даже по сравнению с "оптимизацией", выставленной на 100 попыток перебора и потому уже весьма всё замедляющей (так был получен этот пример).

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

Сначала название метода в студию, а потом уже и об обсуждении работы кодера подумаем...

 

to be continued... Обидно, не очень много времени на столь интересный сюжет. Отвечать собираюсь в порядке поступления вопросов.

 

Десять лет занятий не прошли даром

Однако... super...

так вот в чем дело

Есть учебные заведения, где этому учат? Или в смысле - самостоятельного изучения по интересам?

 

Да и ARM - не первая архитектура, которую я изучаю. И даже не вторая

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

http://imtest.narod.ru/personal/misc/ADV2.DOC

Просто с GBA так совпало, что некоторое время назад купил m3 adapter для игр, а он же позволяет запускать любой код.

 

Называть это отладчиком как-то язык не поворачивается... Там даже breakpoint не поставишь. Visual Boy Advance.

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

Да с вами опасно иметь дело!

Почти удобен для отладки BATGBA, и в нем идет более-менее. Самый же удобный для меня Mappy, только жаль последний сильно не дописан (то, что я видел), там не будет работать.

 

ДКП ну очень вычислительно сложная штука.

Как мне показалось, в той статье автор донельзя упрощал и пропускал операции, и то, что осталось, работало заметно быстрее.

Я бы сказал, скорее громоздкая - большое кол-во однотипных операций.

 

Но компенсация движений требует много памяти (как минимум еще один буфер, не так ли?), с которой в GBA определенные проблемы

Да.

Для такого объема можно сказать, что проблемы. Имеющиеся 32 кб - это чуть меньше, чем полный кадр в 8-битном режиме.

Другая же память уже очень медленная для столь интенсивного обмена. Хотя теоретически, ради интереса можно попробовать что угодно - например, эта программа родилась как раз из аналогичного эксперимента ("а что получится, если...").

 

хотя многих деталей того же MPEG'а я не знаю. Этот стандарт где-нибудь есть в открытом доступе? Я не нашел.

Этот вопрос у меня уже как минимум с 2000 года, присоединяюсь.

 

Без компенсации тоже все плохо - даже при блоке 4*4 и трех (!) ненулевых коэффициентах производительности скорее всего не хватит, не говоря о том, что это будет за картинка.

Точно всё настолько плохо по скорости?

Однажды, кстати, я задавался вопросом, что будет, если оставить как раз 3 ненулевых коэффициента. Можно попробовать, что же это всё-таки будет.

А если делать блоки другого размера при том же числе ненулевых к-тов? Например, для блоков 8х8 будет быстрее или медленнее? Конечно, извини за дилетантский вопрос, давно не занимался внесением этого вида искажений.

 

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

Да мы же сами сейчас обсуждаем контрпример...

Если бы тут еще был разбор последовательности битов, это бы было жутко сложно, я бы не решился такое писать даже начать. А для простейшего алгоритма вон результат готов. Это я еще не говорю, как медленно бы работало это самое жутко сложное...

(в моей мега-примитивной программе (для компьютера), читающей JPEG, похоже, как раз декодер Хаффмана является самой медленной частью, хоть я делал это через двоичное дерево)

 

Надо только найти очень шустрый метод преобразовать сигнал в хорошо сжимаемый (вернее, шустрым должно быть обратное преобразование ^_^ )

Похоже, есть шанс на усовершенствование/альтернативы моего примера. Это всегда welcome, конечно.

 

переход в YUV дает только определенный выигрыш в качестве/сжатии.

Для меня - проигрыш. Сейчас очень модно всюду переводить в YUV и уменьшать разрешение U и V как минимум вдвое по обоим измерениям. И от этого изображение очень сильно портится, мне вообще хочется на такое не смотреть (при том, что о других видах искажений я еще даже не начал говорить) (кстати, мультфильм - хороший пример того, где так делать особенно не следует). Отсутствие этого вида искажений - еще одно облегчение, которое мне подарил пока еще не названный читателями алгоритм.

 

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

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

Плюс округление - больше всего заметна ведь граница между соседними 15-битными градациями и ее колебания туда-сюда по полю кадра, а ведь это как раз то самое место, где

в исходном сигнале цвет тоже меняется, но относительно незаметно, при этом колеблется возле "границы" и при округлении до 15 бит округляется в разные стороны

 

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

То, что часто колеблется целый блок, видимо, получается тоже из-за простоты алгоритма подбора и округления.

 

Ну как все-таки работает кодер?

Потом скажу. Хотя еще улучшать и улучшать. Можно опубликовать оригинал и провести конкурс: кто напишет алгоритм, приближающий лучше к оригиналу. Можно как чисто свой, можно как улучшение того, что уже есть у меня.

 

 

Пока, чтобы скрасить ожидание, интересующимся могу предложить следующие вопросы:

каким образом осуществляется синхронизация видео со звуком?

в каком формате хранится звук?

какова точная частота кадров видео?

 

Кстати, для желающих попробовать более вычислительно сложные алгоритмы на GBA есть еще графический режим номер 5 - разрешение 160x128, 15 бит rgb bitmap, 2 видеостраницы. Правда, я на реальной системе его еще ни разу не включал. Можно попробовать для "маленького" экрана что-то сделать...

 

 

update: Ну вот, творение номер 2, видео на том же движке для Sonic CD, enjoy:

http://narod.ru/disk/15672553000/soniccd.gba.html

P.S. На этот раз оригинал был в масштабе 100% и формате Intel Video 4.3, уже с очень сильными искажениями, так что выглядит далеко не так хорошо, как SatAM.

Изменено 5 декабря, 2009 пользователем Image Master

[Stormwind 202]

пробовал загрузить сатам на 3-в-1. Невлезаит.

[Image Master 4]

пробовал загрузить сатам на 3-в-1. Невлезаит.

Там я занял все доступные 32 мб. Попробуй Sonic CD (чуть выше ссылка), он поменьше.

Я не знаю, как работают разные flash-карты и пр. средства. Есть ровно 32 мб адресного пространства ROM-памяти, доступные для использования, вот я их и занял. M3 adapter достаточно точно имитирует фирменный картридж, и на нем у меня всё работает. Грузит файл с SD-карточки в свою flash-память и передает управление на ее начало, после этого отличия его от обычного ROMа и не обнаружишь. Но если устройство использует какую-то другую схему, часть памяти продолжает занимать под свои нужды, я не могу подсказать, как и что тут делать. Могу сделать GBA-файл поменьше, но не намного, примерно на 250 кб. Это поможет?

[Stormwind 202]

Нынешний размер твоего СатАМовского РОМа - 32601кб.

ССД попробую, как только найду кардридер.

[Image Master 4]

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

Изменено 8 декабря, 2009 пользователем Image Master

[Stormwind 202]

Есть мнение, что у него объём памяти - 32000 кб просто.

[Image Master 4]

Ровно 32 мегабайта, это 32768 кб, где 1 кб - это 1024 байта. Мне в начале немного не хватило, получилось 32.08 мб, но была секундная пауза в начале. Я из нее полсекунды выкинул, получилось как сейчас. Могу еще вторые полсекунды выкинуть.

Но если устройство, например, позволяет использовать 16-мегабайтные оригиналы, а 32-мегабайтные - нет, то этим мелким кусочком ничего не решить.

[Stormwind 202]

Попробован наконец ССД.

На эмуле идёт с нормальной скоростью даже с комплектом св/п (зум 4х, hq2x).

На 3-в-1 ром заливается, но не видится консолью вообще.

[Image Master 4]

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

Да, и еще, так и забыл сказать, т.к. это подразумевается. Я код просто компилировал, сигнатуры nintendo он не содержит. Я это не чувствую, т.к. при запуске m3 adapter подставляет свою (а большинство эмуляторов исполняют что есть без проверок). Но если сделать rom-картридж с этим кодом, он работать не будет (bios проверяет "фирменность" содержимого перед запуском). Соответственно не будут работать flash- и другие системы, опирающиеся на информацию из заголовка, которого здесь просто нет.

Вроде в интернете куча программ, автоматически добавляющих заголовок к коду, но можешь дать ссылку?

[Stormwind 202]

Юзаю вот этот, во вварианте для ДС Лайт

http://wiki.gbatemp.net/wiki/index.php?tit..._for_EZ-Flash_V

Третья ревизия кстати.

[Razor 2 184]

Да это лишь интро СатАМа\СЦД, решай сам

Изменено 21 декабря, 2009 пользователем Razor_ua

[Ky3R 1]

чистые понты, не более того

[softman 4]

чистые понты, не более того

[offtop]Как раз то, из чего состоит большая часть твоих сообщений [/offtop]

Изменено 21 декабря, 2009 пользователем total

[Image Master 4]

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

Все описания заголовка ROM, какие я видел, были неполными. Ты знаешь программы, добавляющие заголовок автоматически?

[Stormwind 202]

3в1 работает слегка подругому. Я копирую ГБАшные ромы на флэшку в ДСовском слоте, запускаю ДС, включаю специальный ДСный ром с программой управления 3в1, через эту программу записываю ГБАшный ром на 3в1, выхожу из этой программы и пытаюсь штатно загрузить ГБАшный слот.

 

Нет, таких программ не знаю.