Комментарии 32
> А еще у нас есть свой скайп-бот
Скайп? Неожиданное решение :)
Неужели, у вас вся внутренняя коммуникация в скайпе? Почему бы не взять какой-нибудь слак или хипчат, которые:
1. куда удобнее для этого кейса
2. предоставляют хорошее API для ботов
Скайп? Неожиданное решение :)
Неужели, у вас вся внутренняя коммуникация в скайпе? Почему бы не взять какой-нибудь слак или хипчат, которые:
1. куда удобнее для этого кейса
2. предоставляют хорошее API для ботов
Смотрели на них. Но так уж исторически сложилось, что изначально был скайп. Так-как команда была всего 8 человек. А сейчас преходить особого смысле нет.
Подключить к боту скайп заняло около двух дней. Подключить все остальное — больше месяца, точно. Получается, что и с этой стороны переход бы нам ничего не дал.
Подключить к боту скайп заняло около двух дней. Подключить все остальное — больше месяца, точно. Получается, что и с этой стороны переход бы нам ничего не дал.
А под виндой как WOT Blitz делали? Хаки были?
Из того что приходит на ум:
- На телефонах дали возможность уменьшить разрешение рендера в два раза. Так-как некоторые аппараты откровенно не тянули необходимый филлрейт. Но это было еще до официального релиза платформы, возможно что-то изменилось.
- На десктопах, кроме развлечений с мшкой и клавиатурой, вроде все спокойно.
.
Про j2me можно сильно, сильно больше рассказать. О запихивании всего приложения в 3-5 классов — чтобы отыграть нужные сотни байт. Про первые IDEN моторолы с поддержкой j2me где товарищи разрабочики прешили, что если в стандарте написанно что поддержка прозрачности в png опциональная — то ее не нужно делать. И портирование игр под эти телефон — из серии режем картинку на куски по 4x4 пикселей, если там 2 непрозрачных пикселя и больше — то рисуем целиком. Этакий пиксель арт в пиксель арте.
Про BREW — ну это не грязный хак, но на части телефонов флешка и память была столь медленная, а процессоры по тем временам вполне быстрые — что держать в и на диске и в памяти все данные в zip-е и распаковывать при обращении на лету было быстрее, чем напрямую.
Или про первый мобильный телефон с 3д ускорителем и с j2me — уж не помню какая Моторола — которой мы радовались, пока не выяснилось, что заодно просто fillrate за счет большого экрана отнимал 30% от всего рендеринга, сводя на ноль пользу 3д ускорителя по сравнению с другими телефонами.
Про BREW — ну это не грязный хак, но на части телефонов флешка и память была столь медленная, а процессоры по тем временам вполне быстрые — что держать в и на диске и в памяти все данные в zip-е и распаковывать при обращении на лету было быстрее, чем напрямую.
Или про первый мобильный телефон с 3д ускорителем и с j2me — уж не помню какая Моторола — которой мы радовались, пока не выяснилось, что заодно просто fillrate за счет большого экрана отнимал 30% от всего рендеринга, сводя на ноль пользу 3д ускорителя по сравнению с другими телефонами.
Промахнулся. Ответ ниже.
В Motorola RAZR другой глюк еще был. Долго не могли понять, почему приложение не может нормально распарсить HTTP-ответ сервера, хотя на эмуляторе и других устройствах было ок. В итоге решили вывести ответ сервера на экран телефона, а там «HTTP/1.0 200 OK\r\n» и далее по списку, т.е. в потоке все тело ответа вместе с шапкой.
Ну это легко детектиться, а вот помнится когда iOS решило кэшировать результаты POST запросов — вот это была радость понять, что не так.
В мотороллах вообще HTTP-протокол странно обрабатывался. К примеру, было что-то мутное с длинной буфера. Вот выжимка из исходников моего древнего SMS Send:
// Motorola implementation of connection class is something very
// strage having no relation to standard J2ME connections behavoir
boolean bMotor = («com.mot.cldc.io.j2me.http.Protocol».equals(m_httpConn.getClass().getName()));
if (bMotor)
body = new byte[len+4];
else
body = new byte[len];
// Motorola implementation of connection class is something very
// strage having no relation to standard J2ME connections behavoir
boolean bMotor = («com.mot.cldc.io.j2me.http.Protocol».equals(m_httpConn.getClass().getName()));
if (bMotor)
body = new byte[len+4];
else
body = new byte[len];
Или про первый мобильный телефон с 3д ускорителем и с j2me — уж не помню какая Моторола
До моторолы точно была nokia 3410 — она была с монохромным экраном, но с 3D графикой
Ну все таки подобная графика, и наличие, на телефоне 3д ускорителя (по моему это был где-то 2004 год) и поддержка оным jst-184 сильно различные вещи. Если говорить о подобном 3д — я так 3д танчики (с видом из башни) писал еще для https://ru.wikipedia.org/wiki/Cybiko — что было раньше чем эта Нокия появилась на свет
Не знаю, насчет jsr-184, но API там было, и использовалось не только в этой java игре, а еще и в других java играх, а так же в самой системе, в роли 3D «хранителей экрана» и пр.
Про 3-5 классов расказал же :)
С Моторолкой этой не работали. Но с графикой была другая штука: пару игр выпустили на Nokia S60 с отрисовкой через нокиевский API, и все понять не могли почему же так педалит. Потом доперло рисовать png через родные методы j2me.
В BREW мы LZO вроде все упаковывали и в один файл. Но «на лету» вроде не стримили.
3D на j2me — миновала меня чаша сия.
С Моторолкой этой не работали. Но с графикой была другая штука: пару игр выпустили на Nokia S60 с отрисовкой через нокиевский API, и все понять не могли почему же так педалит. Потом доперло рисовать png через родные методы j2me.
В BREW мы LZO вроде все упаковывали и в один файл. Но «на лету» вроде не стримили.
3D на j2me — миновала меня чаша сия.
вызов двух апдейтов логики на одну отрисовку.
это решение выглядит… странно.
почему не считать сколько прошло времени и не вызывать соответствующее количество апдейтов?
С двумя фиксированными на выходе должна быть полная непредсказуемая ахинея.
Хотя нормальное решение выглядит весьма просто:
const int UPDATE_PERIOD = 100;//ms
int TotalTime = 0;
while (!finished){
//Render
TotalTime += deltaTime;
while (TotalTime>=UPDATE_PERIOD){
//Update
TotalTime-=UPDATE_PERIOD;
}
}
Ну я и не писал, что это идеальное решение на все случаи жизни. Все, само-собой, не настолько однозначно, как я описал. Просто, если расписывать все варианты, то можно смело делать из этого отдельную статью.
Когда все было совсем туго со временем апдейта, приходилось писать что-то, что позволяло вычислять сколько же апдейтов надо запустить перед отрисовкой (если быть более точным, то мы пропускали вызов отрисовки). Бывало, что логика разделялась на две части, и одна обновлялась несколько раз за кадр, а другая только один. Но чаще отрисовка, работающая в другом потоке, занимала больше времени чем даже три апдейта. Поэтому можно было не стесняться.
Кроме всего прочего, игры часто адаптировались под каждый конкретный телефон, и там этот цикл настраивался индивидуально.
Когда все было совсем туго со временем апдейта, приходилось писать что-то, что позволяло вычислять сколько же апдейтов надо запустить перед отрисовкой (если быть более точным, то мы пропускали вызов отрисовки). Бывало, что логика разделялась на две части, и одна обновлялась несколько раз за кадр, а другая только один. Но чаще отрисовка, работающая в другом потоке, занимала больше времени чем даже три апдейта. Поэтому можно было не стесняться.
Кроме всего прочего, игры часто адаптировались под каждый конкретный телефон, и там этот цикл настраивался индивидуально.
Распарсить JS проще и быстрее, чем добавить упрощённый метод в бэкенде? На чём у вас бэкенд был написан? На брейнфаке? :-)
JS на мобильных устройствах выполняется весьма неторопливо…
Главный вопрос не на чем, а кем. Писалось это все командой которая поддерживала в первую очередь WoT, а во вторую WoWP и не вышедший еще тогда WoWS. А Blitz был больше эксперементальным проектом. И ясное дело, что ресурсы на это ни кто в срочном порядке выделять не стал.
Под J2ME ещё могу вспомнить обильное использование глобальных и статических объектов, и явное зануление указателей у уже ненужных объектов (чего-то там с GC не всего было предсказуемо). Уменьшение количества классов — это да, ну а какие-нибудь анонимные классы (например в качестве слушателей) никому в голову не приходило даже использовать.
Про J2ME можно вспомнить много веселого. Там каждая модель телефона глючила по-своему. Нынче с андроидами это тоже есть, но не так заметно.
Был плагин к ProGuard, который позволял мержить классы при обфускации. Выручало при сборке для всяких нокий S40 с ограничением размера джарника в 1 мегабайт. Правда работало это только на определенной версии прогварда и далеко не всегда стабильно (иногда падало, иногда выдавало нерабочий код), приходилось шаманить с настройками и тщательно тестировать после сборки.
Про зануление указателей тут уже писали — «помощь» GC, из-за чего все работало быстрее.
Еще помню были проблемы со статической инициализацией переменных — после обфускации и мержинга она могла пропасть. Грубо говоря, код
такого лучше было избегать, потому что внезапно оказывалось, что там ноль. И если нужна была именно начальная инциализация статических переменных, то лучше было ее выносить в отдельный метод, который дергать при запуске приложения.
Еще были «особенности» управления подсветкой на разных моделях, на тех же нокиях, если нужно было, чтобы подсветка не гасла во время работы приложения, надо было в цикле постоянно вызывать ее включение. А так же работы с звуком, где-то надо было заранее префетчить плееры и держать наготове в таком состоянии.
Еще помню были проблемы с отрисовкой, в частности, нативная заливка области была жутко тормозной, и реализация ее своими же средствами выходила значительно быстрее.
Был плагин к ProGuard, который позволял мержить классы при обфускации. Выручало при сборке для всяких нокий S40 с ограничением размера джарника в 1 мегабайт. Правда работало это только на определенной версии прогварда и далеко не всегда стабильно (иногда падало, иногда выдавало нерабочий код), приходилось шаманить с настройками и тщательно тестировать после сборки.
Про зануление указателей тут уже писали — «помощь» GC, из-за чего все работало быстрее.
Еще помню были проблемы со статической инициализацией переменных — после обфускации и мержинга она могла пропасть. Грубо говоря, код
public class MyClass {
private static int variable = 5;
...
}
такого лучше было избегать, потому что внезапно оказывалось, что там ноль. И если нужна была именно начальная инциализация статических переменных, то лучше было ее выносить в отдельный метод, который дергать при запуске приложения.
Еще были «особенности» управления подсветкой на разных моделях, на тех же нокиях, если нужно было, чтобы подсветка не гасла во время работы приложения, надо было в цикле постоянно вызывать ее включение. А так же работы с звуком, где-то надо было заранее префетчить плееры и держать наготове в таком состоянии.
Еще помню были проблемы с отрисовкой, в частности, нативная заливка области была жутко тормозной, и реализация ее своими же средствами выходила значительно быстрее.
Мы классы мержили обычно в процессе написания. Ограничение на jar для первых Nokia S40 было 64k :)
Ну а в плане звука каждый телефон был очень яркой индивидуальностью. Даже тот же префетч нужно было вызывать в определенном порядке с другими методами. Где-то для каждого звука необходимо было создать отдельный объект плеера. Иногда на подбор правильного решения, чтобы звук заиграл на новом телефоне, могла уйти неделя.
Ну а в плане звука каждый телефон был очень яркой индивидуальностью. Даже тот же префетч нужно было вызывать в определенном порядке с другими методами. Где-то для каждого звука необходимо было создать отдельный объект плеера. Иногда на подбор правильного решения, чтобы звук заиграл на новом телефоне, могла уйти неделя.
Ради экономии делали поддержку dxt сжатия, что было эффективнее чем png, который на малых объемах файлов не так эффективен чем dxt+jar дожатие, да и качество экранов позволяло. Единственной проблемой оказалось, что приложение распаковывается при запуске и занимало много памяти в таком виде до загрузки ресурсов.
Кроме того, использовали rar для подкручивания размеров словаря zip-сжатия, с последующим преобразованием в jar. Увеличение словаря, пока запускалось на телефонах, давало приличное дожатие.
Кроме того, использовали rar для подкручивания размеров словаря zip-сжатия, с последующим преобразованием в jar. Увеличение словаря, пока запускалось на телефонах, давало приличное дожатие.
Спасибо, понастальгировал :)
p.s. ещё до всяких WoT, были у нас танчики на J2ME с сетевым режимом игры по Bluetooth до 8ми игроков… ну и работа с Синезубом была не менее весёлой, чем со звуком и графикой — производители не спешили поддерживать все варианты работы протокола, а то что поддерживали — работало как всё на J2ME + «нестабильность радио-волн» — проблемы начинались уже с поиска устройств по-соседству…
Кто знает, будь технология стабильной, может быть мультиплеер и раньше бы стрельнул — в исполнении Bluetooth, закрепился бы с появлением Wi-Fi Direct — всё-равно школьники рядышком тусовались ;) С текущими скоростями мобильных сетей, не актуально теперь, конечно — всё-бы всё-равно перетекло в глобальную сеть.
p.s. ещё до всяких WoT, были у нас танчики на J2ME с сетевым режимом игры по Bluetooth до 8ми игроков… ну и работа с Синезубом была не менее весёлой, чем со звуком и графикой — производители не спешили поддерживать все варианты работы протокола, а то что поддерживали — работало как всё на J2ME + «нестабильность радио-волн» — проблемы начинались уже с поиска устройств по-соседству…
Кто знает, будь технология стабильной, может быть мультиплеер и раньше бы стрельнул — в исполнении Bluetooth, закрепился бы с появлением Wi-Fi Direct — всё-равно школьники рядышком тусовались ;) С текущими скоростями мобильных сетей, не актуально теперь, конечно — всё-бы всё-равно перетекло в глобальную сеть.
Под J2ME было много приколов с использованием одной и той же графики под разные нужды, чтобы экономить место. А еще сборки под Самсунг частенько перерабатывались и урезались в функционале, по сравнению с СониЭриксонами и Нокиями, потому что у них был какой-то свой взгляд на степень поддержки MIDP2.0. С тех пор прошло 10 лет, а доверие к телефонам от Самсунга так и не восстановилось — психологическая травма, можно сказать
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Грязные трюки мобильной разработки от J2ME до Android