О, это хорошо. Спасибо за информацию — попробую в следующих своих интрах использовать gcc, а то замучался уже с абы какой поддержкой чистых сей студийным компилятором.
Это так, но выбор между размером и скоростью зависит от задачи. В той же сцене интра может грузиться хоть минуту, но самое главное — влезть в ограничение по размеру.
На неконтролируемом входном коде можно вообще схватить подчеркнутое той или иной опцией неопределенное поведение в стандарте языка.
Да, здравый смысл конечно 90% покрывает, а грубая сила нужна только для случаев «о боже, я вылез на 35 байт за пределы дозволенного!», да и вообще предполагает прежде всего крохотулечные проекты, потому что никаких серверов не хватит хромиум перебирать.
Кстати, -mfpmath=sse не круто с точки зрения размера — там водятся толстенные 7-байтные инструкции, тогда как олдовые fpu'шные укладываются в 2.
Для такой мелочи и win32-специфики лучше вообще использовать crinkler, но он не понимает объектники, генерируемые gcc (по крайней мере года четыре назад не понимал).
Впрочем, как вы правильно заметили, мы отдаляемся от темы этой статьи.
Прежде всего, котаны, надо писать хороший код — не злоупотреблять шаблонами в крестах и т.п.
Далее, выигрыш от конкретных опций gcc зависит от приложения, стиля кода, модной в этом сезоне версии gcc и фазы луны. Поэтому надо брать GC Masher, который автоматически грубой силой переберет все возможные параметры gcc с целью нахождения глобального минимума.
Ну и напоследок можно попробовать сжать бинарник каким-нибудь exe-пакером, типа UPX, или вовсе на коленке соорудить gzip-дроппинг.
В этом месте можно убедиться, что все предыдущие оптимизации размера сказываются на размере сжатого файла не монотонно, и, господи, зачем вообще я пишу этот комментарий.
Благодарю за апдейт.
Однако, беглый гуглёж показывает только громоздкие и не шибко эффективные решения, едва ли применимые в контексте USB-питания. А надежда была именно на это.
Увидев заголовок, я уж было понадеялся, что они как раз научились раздавать питание по оптике хотя бы минимальное.
А тут какой-то BREAKING NEWS — любой восьмиклассник может пойти в ближаший подвальный магазин радиодеталей и сделать свой собственный оптический USB-кабель с произвольной длиной и фотонами.
Для динамического заполнения атласа без удаления в моём случае очень хорошо работал крайне простой метод (до которого, к своему стыду, я догадался не сам, а подсмотрел у кого-то в бложике).
Сейчас, увы, не смог найти ссылку на оригинал, поэтому попытаюсь по памяти воспроизвести идею алгоритма:
Инициализируем список свободных прямоугольных зон одной записью размером со всю текстуру (да, с её размером нужно угадать)
При добавлении элемента проходим по списку зон последовательно, пока не найдём такую, в которую влезет наш фрагмент.
Если ширина зоны больше ширины нового фрагмента, то делим зону на две новые зоны так, чтобы ширина первой из них была равна ширине нового фрагмента. Новые полученные зоны вставляем в список на место старой зоны (это важно).
--//-- высота --//--
В этом месте размеры зоны и нового фрагмента равны. Блитим, удаляем зону из списка свободных зон.
PORBLEM SOVLED
Да, его можно запороть (откажется добавлять, хотя физически место будет) специально подготовленными данными, но на практике такое мне не попадалось.
(Ура, некропост!)
Самое смешное в этом вовсе не перевод, а то, что описываемый алгоритм не является шумом Перлина ни разу!
В основе Perlin noise лежит генерация псевдослучайных градиентов искомой функции в каждом узле сетки, а не непосредственно значений, как в этой статье.
Наложение же разночастотных шумов друг на друга — это совершенно другая техника, которая тоже к Перлину имеет опосредованное отношение.
Пока не знаю. Он (а) так себе чистый, (б) на плюсах с лёгким налётом си-стайла, (в) не шибко интересный — там много всякого сетапа и скукоты, суть тяжело добыть.
Могу, впрочем, поделиться некоторыми идеями:
1) По-максимум объединять шейдеры. Один эффект = один шейдер. Действительно, как вы говорили выше, цепочки эффеков тормозят. 640х480 превью не укладывается в 60фпс уже после трёх звеньев, наступает няшная боттлнека по памяти. Можно вообще написать либо убершейдер со всем и поставлять ему параметры, или написать синтезатор шейдеров. Я, впрочем, этого не делал — проще написать заново/скопипастить матрицы для RGB-YUV. И есть одно исключение — блюр, его надо делать в два этапа, причем тащить координаты сэмплов текстуры из вершинного шейдера как varying, не делая расчетов во фрагментном шейдере.
2) Пул переиспользуемых объектов. Все эффекты на самом деле работают на одном фреймбуфере с двумя пинг-понг текстурами. Самим звеньям-эффектам свои текстуры нафиг не нужны :D.
3) Для превью сразу делать маленькую текстуру с маленьким же фреймбуфером, а потом уже применять эффекты.
Правила, там, вроде, были менее жёсткие.
Я, например, забил на GPUImage (он толстый, тормозной и проблемный) и написал свой процессор цепочек эффектов с известно кем и чем, который позволил, среди всего прочего, показывать маленькие превьюшки всех доступных эффектов в реальном времени на плавных 30фпс (можно было сделать и все 60, но из самой камеры изображения приходят реже и неустойчивей).
Правда, это хороший пример того, как не надо было делать за два дня до дедлайна :D — когда у меня была готова core-часть с эффектами и захватом, оставался час, и не было уже никакого смысла даже браться за весь остальной гуй и функции.
Ха-ха, «одного»! Они в Новосибирске мост, построенный ещё в 2009 году, нарисовали только в конце 2011. Остальные — 2ГИС, OSM — обновились в течение месяца.
Или вот — с месяц назад ездил в Томск, так там тоже нарисованная трасса вокруг физической вьётся позорной синусоидой с амплитудой метров эдак 800.
Я — джентушник с 8-летним стажем и мако-этот-самый — с 3-летним. В прошлом году купил в личное пользование макбук-прошку, т.к. для ноутов с современными видюхами нет адекватных дров под линь (yes, fuck you, nvidia).
Спрашивайте свои вопросы.
(пятиминутка оффтопика) Квартус вообще отличная программа — последний раз, когда мне доводилось с ней работать (года два-три назад), половина её win32-версии при нативном WinAPI/MFC-гуи использовала cygwin для внутренних утилит сборки. В то же время Linux-версия имела все эти утилиты нативно, а гуй гоняла из-под winelib или чего-то подобного.
Потом они, вроде, начали гуй переписывать на Qt, но я дальше с ним уже не сталкивался.
Да, здравый смысл конечно 90% покрывает, а грубая сила нужна только для случаев «о боже, я вылез на 35 байт за пределы дозволенного!», да и вообще предполагает прежде всего крохотулечные проекты, потому что никаких серверов не хватит хромиум перебирать.
Кстати, -mfpmath=sse не круто с точки зрения размера — там водятся толстенные 7-байтные инструкции, тогда как олдовые fpu'шные укладываются в 2.
Впрочем, как вы правильно заметили, мы отдаляемся от темы этой статьи.
Далее, выигрыш от конкретных опций gcc зависит от приложения, стиля кода, модной в этом сезоне версии gcc и фазы луны. Поэтому надо брать GC Masher, который автоматически грубой силой переберет все возможные параметры gcc с целью нахождения глобального минимума.
Ну и напоследок можно попробовать сжать бинарник каким-нибудь exe-пакером, типа UPX, или вовсе на коленке соорудить gzip-дроппинг.
В этом месте можно убедиться, что все предыдущие оптимизации размера сказываются на размере сжатого файла не монотонно, и, господи, зачем вообще я пишу этот комментарий.
Однако, беглый гуглёж показывает только громоздкие и не шибко эффективные решения, едва ли применимые в контексте USB-питания. А надежда была именно на это.
А тут какой-то BREAKING NEWS — любой восьмиклассник может пойти в ближаший подвальный магазин радиодеталей и сделать свой собственный оптический USB-кабель с произвольной длиной и фотонами.
Сейчас, увы, не смог найти ссылку на оригинал, поэтому попытаюсь по памяти воспроизвести идею алгоритма:
Да, его можно запороть (откажется добавлять, хотя физически место будет) специально подготовленными данными, но на практике такое мне не попадалось.
Самое смешное в этом вовсе не перевод, а то, что описываемый алгоритм не является шумом Перлина ни разу!
В основе Perlin noise лежит генерация псевдослучайных градиентов искомой функции в каждом узле сетки, а не непосредственно значений, как в этой статье.
Наложение же разночастотных шумов друг на друга — это совершенно другая техника, которая тоже к Перлину имеет опосредованное отношение.
Там внутри самодельный CPU, самодельный синт, самодельные DSP-подобные шейдерные ядра, ну вы поняли.
Подробнее: www.linusakesson.net/scene/parallelogram/index.php
Могу, впрочем, поделиться некоторыми идеями:
1) По-максимум объединять шейдеры. Один эффект = один шейдер. Действительно, как вы говорили выше, цепочки эффеков тормозят. 640х480 превью не укладывается в 60фпс уже после трёх звеньев, наступает няшная боттлнека по памяти. Можно вообще написать либо убершейдер со всем и поставлять ему параметры, или написать синтезатор шейдеров. Я, впрочем, этого не делал — проще написать заново/скопипастить матрицы для RGB-YUV. И есть одно исключение — блюр, его надо делать в два этапа, причем тащить координаты сэмплов текстуры из вершинного шейдера как varying, не делая расчетов во фрагментном шейдере.
2) Пул переиспользуемых объектов. Все эффекты на самом деле работают на одном фреймбуфере с двумя пинг-понг текстурами. Самим звеньям-эффектам свои текстуры нафиг не нужны :D.
3) Для превью сразу делать маленькую текстуру с маленьким же фреймбуфером, а потом уже применять эффекты.
Я, например, забил на GPUImage (он толстый, тормозной и проблемный) и написал свой процессор цепочек эффектов с известно кем и чем, который позволил, среди всего прочего, показывать маленькие превьюшки всех доступных эффектов в реальном времени на плавных 30фпс (можно было сделать и все 60, но из самой камеры изображения приходят реже и неустойчивей).
Правда, это хороший пример того, как не надо было делать за два дня до дедлайна :D — когда у меня была готова core-часть с эффектами и захватом, оставался час, и не было уже никакого смысла даже браться за весь остальной гуй и функции.
Или вот — с месяц назад ездил в Томск, так там тоже нарисованная трасса вокруг физической вьётся позорной синусоидой с амплитудой метров эдак 800.
Спрашивайте свои вопросы.
Потом они, вроде, начали гуй переписывать на Qt, но я дальше с ним уже не сталкивался.