Jump to content

    
__inline__

Allwinner A13 SoC уделал DSP C6745. Смеяться или плакать?

Recommended Posts

3 часа назад, __inline__ сказал:

Мы когда делаем игры, поступаем так: сжимаем всё что сжимается ZLIB и кладём на SD карту.  Затем когда что-то нужно подгрузить для конкретного уровня игры - лезем в динамический список - грузим и разжимаем в память то что нужно. 

Нее, так не хотят, хотят, чтоб нажав на кнопку сразу появилась картинка, причем на весь экран! Я как-то делал динам. подзагрузку, когда дело было на более простом МК - сразу фи.. а чет так думает, хочу сразу чтобы)))

Share this post


Link to post
Share on other sites
9 hours ago, mantech said:

Нее, так не хотят, хотят, чтоб нажав на кнопку сразу появилась картинка, причем на весь экран! Я как-то делал динам. подзагрузку, когда дело было на более простом МК - сразу фи.. а чет так думает, хочу сразу чтобы)))

 

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

 

Тоесть в образе прошивки скомпонованы ресурсы сжатые ZLIB (на ПК предварительно с самым сильным сжатием -9 ), а при обращении к ним делается прозрачная распаковка(из памяти конечно).

 

В играх так и сделали: заменили fopen, fread, fclose на свои - которые читают из памяти якобы файлы (на самом деле - сжатые образы в памяти).  Правда тогда нужно будет организовать некий хедер (наподобие как таблица FAT) из которого как минимум будут извлекаться: имя ресурса, его размер и смещение относительно базового адреса ресурса.  Что-то типа  своего Data-Bundle.   Так кстати в играх укатывают все ресурсы данных в один файл, который можно пристыковать к программе (GCC это может "изкаропки", для остальных - через конверсию bin to h) .

 

А если взять smart-RLE-сжатие, то можно прямо побайтно налету разжимать картинки ))) Но по степени сжатия RLE хуже ZLIB.

 

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

 

Кстати, грядёт новый стандарт Си, надеюсь разработчики компилеров не прозевают и сделают все __полезные__ нововведения: https://habr.com/ru/company/badoo/blog/503140/

 

Особенно вот это наконец-то будет кросс-платформенно:

 

Quote

Включение двоичных файлов в исходный файл

Включение двоичных данных из файлов в исполняемый файл — невероятно полезная для всех игроделов возможность :

 

const int music[] = {
   #embed int "music.wav"
};

 

 

 

10 hours ago, Obam said:

Чёт он на Сильвестра не похож: овал лица не тот, "баландын", без сигареты в углу рта и без зеркальных "Авиатор"-ов ;-). Фальшивка.

 

Мне здесь больше дерзкая китайская выходка против игровых копирасторов понравилась :biggrin:

 

И решь шла не о Кобре-Сталлоне, а о японском Кобре.

 

Вот этот товарищ:

 

360

 

И этот :

 

x1000

 

- разные люди, не пересекающиеся друг с другом. :lol2:

 

Edited by __inline__

Share this post


Link to post
Share on other sites
10 часов назад, __inline__ сказал:

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

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

10 часов назад, __inline__ сказал:

Включение двоичных файлов в исходный файл

Никогда этим не пользовался, но неужели этого еще нет в сях??

Share this post


Link to post
Share on other sites
54 minutes ago, mantech said:

Никогда этим не пользовался, но неужели этого еще нет в сях??

 

В ARMCC это делается через эмбид ресурсов через ASM-файлы.

В GCC это делается через objdump + внешние extern

В других, где эмбида нет - только конверсией BIN to H.

 

56 minutes ago, mantech said:

Будет слайд-шоу, особенно на анимации

 

А если разом всю анимацию из памяти(1) разжать в память(2), затем играть из памяти(2)?   Затем освободить память(2),  а из памяти (1) новую анимацию в память(2) ит.п.?

 

Share this post


Link to post
Share on other sites
1 минуту назад, __inline__ сказал:

А если разом всю анимацию из памяти(1) разжать в память(2), затем играть из памяти(2)?   Затем освободить память(2),  а из памяти (1) новую анимацию в память(2) ит.п.?

Так и делаю, иначе при требовании под 1 кадр 2-4 мегабайта, никакой памяти не хватит. Распаковку провожу в то время, пока клиент что-то делает не касаясь терминала.

Share this post


Link to post
Share on other sites
16 minutes ago, mantech said:

Так и делаю, иначе при требовании под 1 кадр 2-4 мегабайта, никакой памяти не хватит. Распаковку провожу в то время, пока клиент что-то делает не касаясь терминала.

 

Декодер H264 напрашивается. Там хорошее сжатие между фреймами и опенсорцный.  Можно настроить качество не хуже JPEG.

 

 

Странные клиенты. Чем ведро многоядерное по типу планшета их не устроило?

Edited by __inline__

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.