• Рендеринг UTF-8 текста с помощью SDF шрифта
    0

    Потому что текстура черно-белая в формате GL_LUMINANCE

  • 7 полезных плагинов для Sketch
    0

    А нет ли плагина, который добавит объектам custom properties, которые экспортировались бы потом в SVG(XML)?
    Просто использую Sketch для дизайна игровых уровней и сейчас все кастомные свойства приходится лепить в имя...

  • Как это сделано: мобильный кроссплатформенный движок
    0

    У меня пока нет полной статистики, чтобы сравнить с чистым адмобом. Могу сравнить между агрегаторами: Fyber, Appodeal, Heyzap, Adtoapp. Последние два оказались совсем хиленькие. А Fyber и Appodeal примерно на равне.

  • Как это сделано: мобильный кроссплатформенный движок
    0

    Они пиарятся за счет конкурсов, в условия которых прячут уловки. Лично мое отношение к ним это подорвало.

  • Как это сделано: мобильный кроссплатформенный движок
    0

    Такое вполне допустимо и встречается почти во всех SDK. Например:


    • save/load прогресса на своих серверах
    • сегментация игроков для кастомизации игры (покупающим игрокам показываем один магазин, остальным — другой)
    • проверка in-apps на сервере (при обнаружении взлома имеет смысл обнулить прогресс игрока)
    • A/B тестирование
    • загрузка/обновление конфигов/уровней

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

  • Конкурс на лучшую публикацию про разработку, дизайн или тестирование мобильного приложения
    +1
    В следующий раз, пожалуйста указывайте, что в конкурсе могут участвовать только граждане РФ!
    Здорово, что это указано в пункте 4.1 в PDF, которую непонятно где вообще смотреть, не подкопаешься.
    Но на вашу репутацию это плохо влияет.
    p.s.: 1е, 3е и 4е места занимают мои статьи.
  • Рендеринг капли с прозрачностью и отражениями на OpenGL
    0
    Depth test в нашем случае отключен т.к. рендерим плоский квад. Сам discard не так страшен, как if(gradient<=0.0), в который он помещен. Однако после discard у нас еще идут 5-8 вызовов texture2D(), которые в сумме более тяжелые для GPU чем один if(). На глаз это никак не определить, нужны только тесты на девайсах. И именно тесты показали, что в этом шейдере от discard польза таки есть.
  • Рендеринг капли с прозрачностью и отражениями на OpenGL
    +2
    Помню вашу игру и статью :) Рескин пошел игре заметно на пользу, поздравляю с выходом на tvOS!
  • Рендеринг капли с прозрачностью и отражениями на OpenGL
    +3
    У вас смотрю поверхностное натяжение довольно точно реализовано, здорово выглядит! На счет ценности — у нас из этого игра вышла :)
    Кстати вот капельки в динамике
  • Рендеринг капли с прозрачностью и отражениями на OpenGL
    0

    Согласен, discard вообще стоит избегать. Проверял на всевозможных девайсах и именно в этом шейдере на iPad2 без дискарда FPS падал до 40. Все таки после discard идет 5-8 выборок из текстуры (в зависимости от кол-ва материала) и это перевешивало тормоза от бранчинга.

  • Рендеринг капли с прозрачностью и отражениями на OpenGL
    +2

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

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0

    Поправил в статье. Однако в шейдере с рамкой один clamp все же нужен, чтобы был цвет рамки/переход/цвет текста.

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0

    Код упаковки хороший, спасибо! Плз поправьте меня, если я не верно понял. SDF шрифт мы все равно делаем заранее (в том числе читаем .fnt файлы) и видимо как-то его все таки режем или здоровенной одной текстурой храним? А потом в рантайме, когда нам попадаются новые символы, добавляем их в кеш-текстуру? Или же заранее смотрим какие у нас будут строки и строим кеш-текстуру? А потом точно так же рендерим текст, но уже из кеш-текстуры. Верно?

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0

    params.y — это контраст и значение будет около 10-20. Этот результат мы потом умножаем на прозрачность текста. Вот для чего нужен clamp, иначе выставив прозрачность 50% мы ее не получим. Можно заменить на min(1.0, ...).

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    +1

    Ок, прикинем по кол-ву операций и их примерной тяжести:


    а) Генерация надписи в FBO и ее последующий вывод без ресайза и контраста.


    • Часто надпись динамическая. Например выводим очки юзеру "Score: 142" и цифры бегут. Каждый фрейм изменять FBO будет явно медленнее. К тому же на этом FBO тоже надо шрифт как-то выводить. Замкнутый круг.
    • Если же шрифт битмапный статический, то ресайз у него занимает ровно столько же времени, сколько и в SDF. Однако хороший статический битмап будет по размеру раза в два больше (считаем что для хорошего качества на retina нам нужен скейл 2х). А вывод бОльшей текстуры однозначно будет медленнее, к тому же тут будет даунскейл в 2 раза, а в SDF текстура будет примерно совпадать.
    • Итак разница только во фрагментном шейдере. Добавили clamp, умножение и сложение. На FPS это никак не повлияло ни на одном из девайсов.

    б) Векторный шрифт. Если нам не нужна рамка, то может быть и быстрее будет.


    • Однако сложно сказать сколько нужно полигонов для хорошего результата.
    • К тому же мы никак не контролируем сглаживание краев и на маленьких размерах получим жуткую рябь.
    • Для рамки же придется выводить символ два раза, но! хорошую рамку мы все равно не получим т.к. скейл!=рамка.

    Раньше я использовал 2х битмапы, контур добавлял заранее в фотошопе, а разные сочетания цвета шрифта и рамки хранил в разных текстурах. Вот это было глупо и неудобно. Пока не попробовал SDF. При всем старании, минусов в этой технике не вижу.

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0

    В любом случае, спасибо за UBFG! Так же хочу порекомендовать вашу утилиту Cheetah-Texture-Packer для запаковки текстурных атласов. Именно на ее основе я добавил в сборщик проекта автогенерацию атласов из папки.

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0

    Да, конвертирую в WEBP без потери качества "-lossless -q 100".
    Остановился на SDF, потому что альтернативы:
    а) генерируют битмап шрифт на лету. А это время, ресурсы, зачем? И все равно для хорошего качества атлас должен быть здоровый. Да и бордюров нет.
    б) рендерят векторный шрифт. Тут у меня много вопросов к скорости. И опять так бордюры :)
    За stb спасибо! Смотрю у них много других полезных библиотек есть.

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0

    Взял последнюю доступную версию для мака 1.1. Вот сравнение:



    Видно, что в UBFG радиус размытия больше. И это может быть хорошо, если нужна широкая рамка. Но для ровных краев не подходит. Конечно можно скейлить в 8 раз и в UBFG. Но сделать SDF в UBGF для шрифта размером 400pt занимает очень много времени! ImageMagick пока что лидер по скорости и качеству создания SDF.


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

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0
    Все верно, так и есть. В порезанном шрифте Quivira в одной текстуре помещены ascii и умляуты, что покрывает большинство европейских языков. В других текстурах лежат более специфические символы — отдельно турецкий, греческий и редкие умляуты. Отдельно идет кириллица и отдельно символы, валюты, римские цифры.
  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0
    Ок, постараюсь посвятить отдельную статью графике.
  • Как это сделано: мобильный кроссплатформенный движок
    0
    Особой необходимости в скриптах пока не было. Вернее, уровни созданные в левел-билдере на webGL конвертировались в логику на С++. Но это была внутренняя логика игры и в движок ее не выносил. Если понадобятся в будущем скрипты, то буду использовать Lua. В AppStore вроде использовать Lua не запрещено.
  • Как это сделано: мобильный кроссплатформенный движок
    0
    Сори, поменял уровень приватности. Пожалуйста, смотрите.
  • Как это сделано: мобильный кроссплатформенный движок
    0
    Можете посмотреть сайт, указанный в моем профайле.
  • Как это сделано: мобильный кроссплатформенный движок
    0
    Буду рад, пытайте :) Частицы использовались в нескольких проектах, а значит пора их выносить в модуль. Лоды, скелетная анимация и горы тоже были, но только в одном проекте, поэтому пока выносить их в движок не спешу. Стоит уточнить, что у меня нет задачи создать универсальный движок. Появляются новые проекты и моя цель максимально ускорить процесс создания игры с минимальным портированием.
  • Как это сделано: мобильный кроссплатформенный движок
    +2
    Ок, смотрим Apple Hardware GPU Information. Например iPad 2 не поддерживает OpenGL 3.0 и далеко не во всех играх нужна тесселяция. Поднимать версию без веской причины не вижу смысла.
  • Как это сделано: мобильный кроссплатформенный движок
    +1
    Пожалуй mainloop — это самое важное, что есть в основном классе. Именно там происходит управление fps, обработка тачей/кнопок, выполнение тасков в основном потоке (особенно для OpenGL без shared context актуально и изменений UI из фоновых потоков), поддержка слоев (аля окна), смена стейтов приложения (меню/уровень/магазин/.../лоадинг скрин). Видимо это еще одна тема для статьи :)
  • Как это сделано: мобильный кроссплатформенный движок
    0
    Вы абсолютно правы, именно в Classes находятся самые главные файлы. В одну статью все не поместилось, буду конкретизировать в продолжениях.
    Например для симуляции использую физику верле. Рендер оптимизирует смену стейтов, занимается камерой/проекциями, группами, подбором нужного шейдера и его настройкой.
    «Чтение/запись файлов» упрощает работу с fopen, fread, fwrite и т.д. Из полезного — расшифровывает файлы, понимает по каким путям где что лежит, читает ресурсы непосредственно из apk. Стриминг (fstream) не использую, как-то не нужен нигде был.
  • Как это сделано: мобильный кроссплатформенный движок
    0
    Да, вполне легко. Собственно тестируя игру под разные платформы, вы в любом случае запускаете разные IDE и собираете проект там. При этом сам код и ресурсы игры единые. Ну почти единые, конечно для телефона и телевизора будут отличия и в управлении, и в UI. Но эти отличия спокойно помещаются в одном .cpp файле.
    Лично я 80% времени тестирую и пишу игру под OSX (именно запускаю собранную игру), по простой причине — скорость компиляции и запуска. Когда запускаешь игру по 20 раз в час, то скорость запуска сильно бережет нервы.
    К тому же под OSX могу менять размер окна и сразу видеть как игра смотрится на телефонах и планшетах разных размеров, ура резиновым интерфейсам. На самих девайсах же запускаю более детальные тесты, например отладить чувствительность управления гироскопом и т.д.
  • Как это сделано: мобильный кроссплатформенный движок
    0
    Согласен, сейчас многие достойные движки стали доступны инди-разработчикам. Свой движок — это не простой путь, однако он весьма… познавательный.
  • Как это сделано: мобильный кроссплатформенный движок
    +1
    Движок закрытый. Это первая часть серии статей. Следующие статьи будут разные, не только о движке. Например про шейдер катающейся капли напишу, а так же про левел-билдер на WebGL. И вообще буду рад написать обо всем, что люди попросят описать подробнее в каментах. Так что это не пиар, надо куда-то слить знания, а то голова пухнет :)
  • Как это сделано: мобильный кроссплатформенный движок
    0
    Целиком исходники не покажу, но отдельные модули буду скидывать в след. статьях. Например модуль ReplayKit и модуль для захвата видео игры под OSX (при чем 1080p 60fps, что помогло в создании промо-видео к игре), выложу полностью. Да, писал один. Последняя глобальная переделка движка была в 2014г. В посте ниже подробнее описал историю создания движка.
  • Как это сделано: мобильный кроссплатформенный движок
    0
    О Мармеладе слышал много хорошего (с ним много работает дружественный мне издатель), но сам с ним не работал. Делал все действительно сам, и это не мудрено, если занимаешься мобайлом с 2008 года и за плечами порты игры Race illegal: High Speed 3D на J2Me, iOS, OSX, Android, WP8, Tizen и недавно еще tvOS добавился, правда для другой игры (та что в шапке и о которой будет отдельная статья). Движок родился в процессе разработки, был несколько раз переделан с нуля, а финансирование — мои же игры, на этом же движке.
  • Устройство WebP
    0
    Да да, именно так и делаю при сжатии на компе командой
    cwebp image.png -m 6 -alpha_filter best -o out.webp
  • Устройство WebP
    +1
    Я использую WebP формат в мобильных играх, что значительно сократило конечный размер билда — примерно в два раза. Раньше приходилось использовать libjpegturbo для непрозрачных картинок и libpng для прозрачных, теперь все что нужно есть в WebP. Собирается libwebp отлично и под iOS, и Android, 32bit и 64bit. Время кодирования и декодирования также вполне приемлемое. Приятным сюрпризом оказался скейлинг картинки на лету при декордировании, время декодирования при даунскейлинге сокращается. Есть еще интересный формат BPG. Размер картинки в BPG меньше примерно на 10-20% чем WebP и на картинках с градиентом результат лучше. Но есть и минусы:
    1) декодирование примерно в два раза дольше чем WebP, кодирование вообще раз в 10 дольше.
    2) на картинках с мелкими деталями BPG начинает их «смазывать».
    3) чтобы собрать под моб. платформы придется повозиться.
    Конечно в «узких» местах все равно необходимо использовать сжатые текстуры (pvrtc, etc1, s3tc), но для большинства арта, UI, заставок и прочего оформления WebP пока что остается лидером.
  • Загрузка PNG и JPEG картинок в Android NDK
    0
    Быстрый поиск выдал мне эту страничку, на которой есть заметки по x86, надеюсь это подойдет.
  • Загрузка PNG и JPEG картинок в Android NDK
    0
    Тогда надо добавлять в код исходники libpng и libjpeg и компилить под x86 как часть вашего кода, но, на сколько я помню, с первого раза скомпилить не получится. Сейчас я настоятельно рекомендую использовать формат webp и соответственно либу libwebp, которая легко компилится под android/ios/x86 etc включая 32/64bit, к тому же конечный размер файлов меньше, а настроек сжатия больше.
  • Мой Boot Camp — куда хочу, туда и ставлю
    0
    Наверняка не скажу, полагаю для GPT важно начинать разделы с 40го, а для MBR все равно т.к. этот раздел ему не сильно и нужен. Могу ошибаться т.к. уже не сильно помню детали. Последние разы, когда мучил систему использовал утилиту gdisk, особенно когда у меня добавился еще один хард (на одном харде стоял Maveriks, а на другом Lion и Windows).

    Могу подсказать только куда копать:
    diskutil list — смотрим, что на каком диске находится и какие имена дисков.
    sudo gdisk /dev/disk1 — меняем нужный нам диск.
    Жмем r — recovery and transformation options (experts only).
    Далее жмем h — make hybrid MBR.
    Дальше он будет спрашивать какие диски и какого типа мы хотим добавить в MBR. Перед этим делом стоит конечно почитать в нете про gdisk hybrid MBR.
    Но суть такая, что с gdisk все манипуляции с MBR становятся гораздо проще, хотя бы не нужно высчитывать вручную начало и конец дисков.
  • Tizen Native programming. Пишем «Hello Habrahabr» для ОС Tizen
    0
    OpenGL 1.1 на реальных Tizen девайсах еще более глючный, чем в супер-глючном Tizen эмуляторе (который к тому же процессор на все 100% загружает). Лучше избегать любых OGLES extensions, даже если они есть в списке поддержки. На практике рендеринг в текстуру (FBO) не работал, а если юзать много текстур девайс рандомно падал. Пришлось урезать графику до уровня iPhone 3G или простенького андроида. А в остальном (OpenAL звук, тачскрин, акселерометр и прочие стандартные ф-ции девайса) все достаточно вменяемо работает и хорошо описано в доках.
  • Оптимизация JavaScript и jQuery из-под HTML и CSS при разработке сайта
    0
    Выполнить то выполнит, но совершит много лишних действий, что может ударить по производительности.
  • Оптимизация JavaScript и jQuery из-под HTML и CSS при разработке сайта
    +1
    Спасибо за статью, не знал про margin. На счет селекторов стоит изучить эту страничку.
    На собственном опыте убедился, что $(document.getElementById('foo')) гораздо лучше чем $('#foo')
    Так же просто спасительным для меня решением в проекте с CSS анимацией стала такая оптимизация:
    -webkit-transform: translate3d(100px, 100px, 0px);
    -webkit-transition: -webkit-transform 0.5s ease;
    

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