Особой необходимости в скриптах пока не было. Вернее, уровни созданные в левел-билдере на webGL конвертировались в логику на С++. Но это была внутренняя логика игры и в движок ее не выносил. Если понадобятся в будущем скрипты, то буду использовать Lua. В AppStore вроде использовать Lua не запрещено.
Буду рад, пытайте :) Частицы использовались в нескольких проектах, а значит пора их выносить в модуль. Лоды, скелетная анимация и горы тоже были, но только в одном проекте, поэтому пока выносить их в движок не спешу. Стоит уточнить, что у меня нет задачи создать универсальный движок. Появляются новые проекты и моя цель максимально ускорить процесс создания игры с минимальным портированием.
Ок, смотрим Apple Hardware GPU Information. Например iPad 2 не поддерживает OpenGL 3.0 и далеко не во всех играх нужна тесселяция. Поднимать версию без веской причины не вижу смысла.
Пожалуй mainloop — это самое важное, что есть в основном классе. Именно там происходит управление fps, обработка тачей/кнопок, выполнение тасков в основном потоке (особенно для OpenGL без shared context актуально и изменений UI из фоновых потоков), поддержка слоев (аля окна), смена стейтов приложения (меню/уровень/магазин/.../лоадинг скрин). Видимо это еще одна тема для статьи :)
Вы абсолютно правы, именно в Classes находятся самые главные файлы. В одну статью все не поместилось, буду конкретизировать в продолжениях.
Например для симуляции использую физику верле. Рендер оптимизирует смену стейтов, занимается камерой/проекциями, группами, подбором нужного шейдера и его настройкой.
«Чтение/запись файлов» упрощает работу с fopen, fread, fwrite и т.д. Из полезного — расшифровывает файлы, понимает по каким путям где что лежит, читает ресурсы непосредственно из apk. Стриминг (fstream) не использую, как-то не нужен нигде был.
Да, вполне легко. Собственно тестируя игру под разные платформы, вы в любом случае запускаете разные IDE и собираете проект там. При этом сам код и ресурсы игры единые. Ну почти единые, конечно для телефона и телевизора будут отличия и в управлении, и в UI. Но эти отличия спокойно помещаются в одном .cpp файле.
Лично я 80% времени тестирую и пишу игру под OSX (именно запускаю собранную игру), по простой причине — скорость компиляции и запуска. Когда запускаешь игру по 20 раз в час, то скорость запуска сильно бережет нервы.
К тому же под OSX могу менять размер окна и сразу видеть как игра смотрится на телефонах и планшетах разных размеров, ура резиновым интерфейсам. На самих девайсах же запускаю более детальные тесты, например отладить чувствительность управления гироскопом и т.д.
Движок закрытый. Это первая часть серии статей. Следующие статьи будут разные, не только о движке. Например про шейдер катающейся капли напишу, а так же про левел-билдер на WebGL. И вообще буду рад написать обо всем, что люди попросят описать подробнее в каментах. Так что это не пиар, надо куда-то слить знания, а то голова пухнет :)
Целиком исходники не покажу, но отдельные модули буду скидывать в след. статьях. Например модуль ReplayKit и модуль для захвата видео игры под OSX (при чем 1080p 60fps, что помогло в создании промо-видео к игре), выложу полностью. Да, писал один. Последняя глобальная переделка движка была в 2014г. В посте ниже подробнее описал историю создания движка.
О Мармеладе слышал много хорошего (с ним много работает дружественный мне издатель), но сам с ним не работал. Делал все действительно сам, и это не мудрено, если занимаешься мобайлом с 2008 года и за плечами порты игры Race illegal: High Speed 3D на J2Me, iOS, OSX, Android, WP8, Tizen и недавно еще tvOS добавился, правда для другой игры (та что в шапке и о которой будет отдельная статья). Движок родился в процессе разработки, был несколько раз переделан с нуля, а финансирование — мои же игры, на этом же движке.
Я использую 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 пока что остается лидером.
Тогда надо добавлять в код исходники libpng и libjpeg и компилить под x86 как часть вашего кода, но, на сколько я помню, с первого раза скомпилить не получится. Сейчас я настоятельно рекомендую использовать формат webp и соответственно либу libwebp, которая легко компилится под android/ios/x86 etc включая 32/64bit, к тому же конечный размер файлов меньше, а настроек сжатия больше.
Наверняка не скажу, полагаю для 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 становятся гораздо проще, хотя бы не нужно высчитывать вручную начало и конец дисков.
OpenGL 1.1 на реальных Tizen девайсах еще более глючный, чем в супер-глючном Tizen эмуляторе (который к тому же процессор на все 100% загружает). Лучше избегать любых OGLES extensions, даже если они есть в списке поддержки. На практике рендеринг в текстуру (FBO) не работал, а если юзать много текстур девайс рандомно падал. Пришлось урезать графику до уровня iPhone 3G или простенького андроида. А в остальном (OpenAL звук, тачскрин, акселерометр и прочие стандартные ф-ции девайса) все достаточно вменяемо работает и хорошо описано в доках.
Спасибо за статью, не знал про margin. На счет селекторов стоит изучить эту страничку.
На собственном опыте убедился, что $(document.getElementById('foo')) гораздо лучше чем $('#foo')
Так же просто спасительным для меня решением в проекте с CSS анимацией стала такая оптимизация:
в таком случае включается аппаратное ускорение, это в разы лучше чем анимировать любыми способами атрибуты top и left. К тому же дивы можно еще и плавно уменьшать или поворачивать.
Например для симуляции использую физику верле. Рендер оптимизирует смену стейтов, занимается камерой/проекциями, группами, подбором нужного шейдера и его настройкой.
«Чтение/запись файлов» упрощает работу с fopen, fread, fwrite и т.д. Из полезного — расшифровывает файлы, понимает по каким путям где что лежит, читает ресурсы непосредственно из apk. Стриминг (fstream) не использую, как-то не нужен нигде был.
Лично я 80% времени тестирую и пишу игру под OSX (именно запускаю собранную игру), по простой причине — скорость компиляции и запуска. Когда запускаешь игру по 20 раз в час, то скорость запуска сильно бережет нервы.
К тому же под OSX могу менять размер окна и сразу видеть как игра смотрится на телефонах и планшетах разных размеров, ура резиновым интерфейсам. На самих девайсах же запускаю более детальные тесты, например отладить чувствительность управления гироскопом и т.д.
cwebp image.png -m 6 -alpha_filter best -o out.webp
1) декодирование примерно в два раза дольше чем WebP, кодирование вообще раз в 10 дольше.
2) на картинках с мелкими деталями BPG начинает их «смазывать».
3) чтобы собрать под моб. платформы придется повозиться.
Конечно в «узких» местах все равно необходимо использовать сжатые текстуры (pvrtc, etc1, s3tc), но для большинства арта, UI, заставок и прочего оформления WebP пока что остается лидером.
Могу подсказать только куда копать:
diskutil list — смотрим, что на каком диске находится и какие имена дисков.
sudo gdisk /dev/disk1 — меняем нужный нам диск.
Жмем r — recovery and transformation options (experts only).
Далее жмем h — make hybrid MBR.
Дальше он будет спрашивать какие диски и какого типа мы хотим добавить в MBR. Перед этим делом стоит конечно почитать в нете про gdisk hybrid MBR.
Но суть такая, что с gdisk все манипуляции с MBR становятся гораздо проще, хотя бы не нужно высчитывать вручную начало и конец дисков.
На собственном опыте убедился, что $(document.getElementById('foo')) гораздо лучше чем $('#foo')
Так же просто спасительным для меня решением в проекте с CSS анимацией стала такая оптимизация:
в таком случае включается аппаратное ускорение, это в разы лучше чем анимировать любыми способами атрибуты top и left. К тому же дивы можно еще и плавно уменьшать или поворачивать.