User Tag List

Показано с 1 по 10 из 305

Тема: Программирование

Древовидный режим

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #29

    Регистрация
    07.08.2008
    Адрес
    г. Уфа
    Сообщений
    8,391
    Спасибо Благодарностей отдано 
    763
    Спасибо Благодарностей получено 
    2,367
    Поблагодарили
    1,317 сообщений
    Mentioned
    39 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

    Если несколько больших (полноэкранных?) картинок, то использование upkr мне кажется жестоким по отношению к пользователю. Понимаю в деме предельных параметров распаковать 1-2 картинки, человек посмотрит ее один раз и успокоится. А если запускать игру несколько раз и там каждый раз upkr распаковывает картинки по 32 Кб, то терпение быстро иссякнет. Еще момент с местом под распаковку - при использовании "безбуферных" (выдающих полный результат) распаковщиков в сочетании с пикселями нужно дополнительно 32 Кб. Вместо этого можно использовать менее эффективные упаковщики, но с буферными (удобно на 256 байт) распаковщиками и потратить те 32 Кб на компенсацию меньшей степени сжатия. На мой взгляд приемлемыми компромиссами по скорости и степени сжатия являются rip и exomizer, плюс они умеют ограничивать длину и дальность ссылок, т.е. можно распаковывать в кольцевой буфер ограниченного размера.

    Никогда всерьез не занимался сжатием палитровых картинок, но насколько я понял из прочитанного, сейчас самый модный вариант - предсказатели+оптимизация палитры для согласования+сжимаем арифметическим кодером. Но тут еще надо найти эти экспериментальные упаковщики, сделать для них распаковщик для вектора и получить скорость скорее всего хуже upkr.
    Для полутоновых или нечто jpeg-подобное (с ДКП) или вейвлеты. Но тут сразу много вопросов - насколько приемлемы полутоновые картинки, устроит ли 8 оттенков желтого/зеленого/красного, распаковщик сложный и медленный. 16 отенков серого на ЧБ мониторе более интересны, но это специфическое решение. Кстати, для полутоновых векторное кодирование должно давать более приемлемые результаты, чем для палитровых. Еще можно вспомнить экзотику типа фрактальных, но это опять надо искать упаковщики и делать распаковщик.

    Возвращаясь на землю, я бы скорее всего ориентировался на rip. Если сжимать байты, то распаковываем на экран. Если сжимаем пиксели, то распаковываем в кольцевой буфер. Пиксели сжимаются лучше, но ограничение длины и дальности ссылок ухудшает сжатие, поэтому надо смотреть конкретные примеры. Также использование буфера позволяет распаковывать картинки произвольного размера, а не на полный экран.
    Последний раз редактировалось ivagor; 30.04.2023 в 14:33.

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Программирование на ассемблере
    от shuran33 в разделе Вектор
    Ответов: 341
    Последнее: 05.11.2025, 20:00
  2. Программирование на ассемблере
    от tnt23 в разделе Океан-240
    Ответов: 6
    Последнее: 30.10.2025, 12:56
  3. Программирование графики MSX
    от CityAceE в разделе MSX
    Ответов: 57
    Последнее: 23.10.2025, 08:53
  4. Программирование NES
    от Tronix в разделе Nintendo
    Ответов: 6
    Последнее: 08.07.2015, 21:21
  5. Программирование на пентеве.
    от Kakos_nonos в разделе Программирование
    Ответов: 2
    Последнее: 23.03.2013, 14:08

Ваши права

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