Что-то я очень сомневаюсь, с большой вероятностью вы бы начали вылетать с out of memory, хотя все зависит от размера одного кадра.
Собственно, memory footprint для такого решения 1в1 такой же, как и для Sprite Sheet, описанного в статье (+- мелкие расходы на разные Bitmap). Может, прочитаете?
зайцы — это отдельная сказка, особенно без чернения. собственно, почти на любом советском металлическом объективе так.
А мыло как раз и меняется от модели к модели. Все, что продают по 500р точно будет мылить. Есть резкие как скальпель, особенно на чуть прикрытой дырке, хотябы до 2,8. Киты с 3,5 и дешевым стеклом и рядом не стояли.
на вкус и цвет…
44-ки сильно отличались в разных годах и с разными индексами. К примеру, разрешение и картинка у 44M-7 на уровень лучше, чем у 44-2. А были и экземпляры без чернения лепестков диафрагмы с соответствующими артефактами на солнце. Да еще и многие берут затертый до дыр дедушкин Гелиос 44, ставят через кольцо за $2 без регулировки дифрагмы и снимают с небольшого растояния на открытой дырке… А потом с ужасом смотрят на закрученный спиралью фон и абберацию и поносят «ужасную картинку».
Зная количество кадров и геометрию расположения, мы можем как-угодно масштабировать большую картинку — код не изменится. Например, под разные разрешения можно спокойно держать битмапы в папках drawable-hdpi, drawable-xhdpi и пр.
В «правильной» же реализации для каждого фрейма хранится отдельное описание, включая координаты, размер и параметры кропа. Тот же Zwoptex может генерить такие файлы в любом формате, включая и cocos2d.
Раз началась волна принудительных апдейтов, то могут и по всем платформам пройтись, никого не спрашивая.
Многие пользователи Мака давно зависли на версии 2.8.0.866 и с ужасом ждут, когда их переведут принудительно на не-юзабельную 5ю ветку :(
Поигрался еще немного, обнаружил такие данные о QuickTime записях:
— частота 60 fps (если мощности процессора хватает, при большом разрешении не хватает)
— кодек Motion JPEG 2000 (иногда есть артефакты, агресивно конвертирует цвета, картинка становится блеклой)
— сильно тормозит при записи фул-скрина или вообще чего-то сравнимого с Full HD
— окошка при съемке не видно
— курсор спрятать нельзя, только подсветить клики
— настроек почти никаких, фрейм выбора не сохраняется
Интересно, сколько будет занимать нормальное h264 видео с тем же контентом и качеством? Если речь об 2х размере, но выигрыше в совместимости с браузерами и фулскрин мобильными — почему бы и нет?
А где же пункт — адские проблемы с тестированием? Сначала одни «забыли» в спешке про юнит-тесты, потом другие «сэкономили» на тестерах и проект проверяли все-подряд, затем отчеты «тестеров» в аське, скайпе, почте и оупенсорс баг-трекере стали жутко пересекаться, ссылаться друг на друга, теряться и обрастать слухами…
Как результат — потерянное время, нервы, сорваные несколько раз сроки и натянутые отношения всей команды вплоть до момента релиза. И в той или иной мере это бывает везде, где считают «да ну, потестить продукт может и сам заказчик, или сват-брат по дороге на работу».
Я говорю как раз об обратной крайности — когда люди оптимизируют собственные проекты и изобретают свои контейнеры/логеры/лямбды, потому что «библиотечное слишком generic и дает гибкость в ущерб скорости». Так вот это утверждение как раз в корне неверно, что нам и показал автор статьи и за что ему отдельное спасибо.
Сейчас набежит кучка любитилей экономить на спичках и будут с пеной у рта утверждать, что если сделать собственную коллекцию с жесткой типизацией, то она будет работать в разы быстрее без всяких трюков, потому выводы статьи не актуальны и «лучше» делать велосипеды на каждый случай :(
Ведь действительно, если у нас есть std::hash_map с именами файлов в качестве ключей, то можно придумать в разы более эффективную коллекцию и хэш функцию. И тогда будет в цикле 100000 поисков выполняться не 600мс, а 400мс.
Собственно, memory footprint для такого решения 1в1 такой же, как и для Sprite Sheet, описанного в статье (+- мелкие расходы на разные Bitmap). Может, прочитаете?
Главное, чтобы новая продукция КМЗ была постабильнее
А мыло как раз и меняется от модели к модели. Все, что продают по 500р точно будет мылить. Есть резкие как скальпель, особенно на чуть прикрытой дырке, хотябы до 2,8. Киты с 3,5 и дешевым стеклом и рядом не стояли.
44-ки сильно отличались в разных годах и с разными индексами. К примеру, разрешение и картинка у 44M-7 на уровень лучше, чем у 44-2. А были и экземпляры без чернения лепестков диафрагмы с соответствующими артефактами на солнце. Да еще и многие берут затертый до дыр дедушкин Гелиос 44, ставят через кольцо за $2 без регулировки дифрагмы и снимают с небольшого растояния на открытой дырке… А потом с ужасом смотрят на закрученный спиралью фон и абберацию и поносят «ужасную картинку».
В «правильной» же реализации для каждого фрейма хранится отдельное описание, включая координаты, размер и параметры кропа. Тот же Zwoptex может генерить такие файлы в любом формате, включая и cocos2d.
В моем случае это не особо нужно было, потому и прямоугольник каждого кадра очень просто определяется по формуле:
где height — высота большого битмапа (sprite sheet), width — его ширина, деленная на кол-во кадров, frame — номер кадра.
Многие пользователи Мака давно зависли на версии 2.8.0.866 и с ужасом ждут, когда их переведут принудительно на не-юзабельную 5ю ветку :(
— частота 60 fps (если мощности процессора хватает, при большом разрешении не хватает)
— кодек Motion JPEG 2000 (иногда есть артефакты, агресивно конвертирует цвета, картинка становится блеклой)
— сильно тормозит при записи фул-скрина или вообще чего-то сравнимого с Full HD
— окошка при съемке не видно
— курсор спрятать нельзя, только подсветить клики
— настроек почти никаких, фрейм выбора не сохраняется
Но, посыпая голову пеплом, соглашусь, для поставленной задачи мне бы действительно вполне хватило QuickTime.
Ну что ж, будем считать потраченное время инвестицией в собственные знания и необычные решения :)
Как результат — потерянное время, нервы, сорваные несколько раз сроки и натянутые отношения всей команды вплоть до момента релиза. И в той или иной мере это бывает везде, где считают «да ну, потестить продукт может и сам заказчик, или сват-брат по дороге на работу».
Ведь действительно, если у нас есть std::hash_map с именами файлов в качестве ключей, то можно придумать в разы более эффективную коллекцию и хэш функцию. И тогда будет в цикле 100000 поисков выполняться не 600мс, а 400мс.