Как стать автором
Обновить

Комментарии 102

Удивительно, но большинство содержательных технических статей приходит из песочницы)
Где игру можно посмотреть? =)
Это оно нет?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Потому что автор даже ссылку на игру в посте не дал, потому что не в игре суть. Вы блог перепутали.
НЛО прилетело и опубликовало эту надпись здесь
Конкретно про фору flash вам человек привел цифры.

И да, игра примитивная, некрасивая и скучная. Но она бегает очень резво и об это как раз и идет речь.
НЛО прилетело и опубликовало эту надпись здесь
Если вы цепляетесь к этой фразе, то, возможно, она действительно плохо сформулирована и ее следует поправить.

В выводе речь о том, что уже сейчас можно не бояться начинать использовать HTML5 вместо флэш, так как он может выдавать достойные результаты — это и пытается донести автор. Если у вас есть претензии к этому тезису, вам нужно было с самого начала их формулировать и писать в развернутой форме, а не писать «во говно, автор лох». Естественно вы с таким подходом огребли минусов в карму, не удивляйтесь.
НЛО прилетело и опубликовало эту надпись здесь
вот вам ссылка, поглядите на игру на html5. Кроме того, фреймворк, на котором сделана эта игра и ее соседи — в опернсорсе. На подходе использование 3D в мобильных браузерах, откуда флеш почему-то ушел.
И да, те, кого не интересует кармодрочерство не говорят о нем вовсе.
НЛО прилетело и опубликовало эту надпись здесь
Окей, давайте я вам немного помогу найти нужное — вот оно
НЛО прилетело и опубликовало эту надпись здесь
Там есть двойной рендер, это во-первых, во-вторых — процент оперы на мировом рынке довольно мал (хотя есть еще любимый ослик), в-третьих — это только один пример. Вот вам еще один движок, который вполне можно использовать в коммерческих играх (поглядите на механику и техническую реализацию топовых игр ВК и ФБ например)
НЛО прилетело и опубликовало эту надпись здесь
Конечно они на флеше, я не об этом говорю. Я говорю о том, что механика игр вполне походит под реализацию их на HTML5 и конкретно на этом движке. То есть, технически, ничего сложного в отрисовке изометрии на канвасе нет, а значит уже можно зарабатывать на этой технологии. Проблема в другом — на флеше можно и обезьяну научить программировать, так хорошо там сформирована иерархия классов, а вот толковых людей пишущих на JS — весьма мало, это либо энузиасты, как автор статьи, либо уходящие в дебри веб-приложений, ООП и node.js.
Может звук и был через Флеш раньше, но сейчас я проверил (Флеш у меня только по клику включается), всё ок, звук идёт через ХТМЛ5.
Про процент оперы Вы это зря, процент достаточный чтобы решать разрабатывать что-то на какой-либо не поддерживаемой ей технологии или не разрабаты.

Чёрт, не туда комент ушёл.( к посту там где процент использования оперы оговаривался)
НЛО прилетело и опубликовало эту надпись здесь
> Меня не интересует кармодрочество. Ваши друзья и вы можете засыпать меня минусами, мне всё равно.

Вы спросили, почему вас минусуют, я вам ответил. Извините, если что не так.

> фейсбук отказывается от html5, большинство авторитетных разработчиков наконец-то начинают говорить, что html5 отвратительно работает на мобильных платформах. А количество успешных игр можно пересчитать по пальцам. Какие аргументы имеются на этот счет?

Слушайте, ну вы бы с самого начала так написали, к вам бы вообще вопросов никаких не было.
Я не занимаюсь разработкой игр, поэтому мое мнение довольно профанское и по большей части относится к разработки под Web вообще.

Так вот, единый открытый стандарт под Web — это очень круто и это должно быть. И я не вижу ничего плохого в том, что автор, приводя конкретную аргументацию, пытается популяризировать этот стандарт. И если вы видели в этой аргументации слабые стороны, вы бы могли бы написать об этом, и сделать хабр лучше, светлее и чище. Но вы вместо этого полезли бросаться говном, а потом вздыхать, что хабр уже не тот.
НЛО прилетело и опубликовало эту надпись здесь
Я не оспаривал вашу точку зрения, я лишь привел вас к тому, что вы наконец начали приводить объективные аргументы, а не клеймить автора непонятно за что.

А по теме я сказал одно — единый стандарт это хорошо, другого стандарта кроме HTML5 на арене не виднеется, даже если технология пока немного сырая (хотя, судя по комментариям, есть варианты), популяризировать ее — это правильное и хорошее дело. Если вы считаете это глупым, то ок, удачи.

И если бы вы не задали вопрос «За что минусуете», я бы вам вообще не отвечал.
НЛО прилетело и опубликовало эту надпись здесь
Конкретику вам предоставил автор. Если вас не устраивают «результаты, которые были 8-9 лет назад», вас никто не заставляет этим пользоваться.

И как только вы перестали бычить и стали подробно объяснять, почему это плохо и неправильно — к вам сразу потянулись люди. А агрессию в комментариях никто не любит.
Судя по этой статье, можно сделать вывод, что ребята с фейсбука не до конца разобрались с технологией.
Да, цифры не касаются flash, но и фору можно дать не только в производительности. Попробуйте получить 60 fps во flash приложении на Android-ном устройстве и все станет понятно (кстати, Вы уже удалили его со своего телефона?). я не собирался как-то обидеть флэшистов, просто на мой взгляд, JS сейчас, с появлением Canvas, вполне себе конкурент flash-у.
НЛО прилетело и опубликовало эту надпись здесь
То, о чем вы говорите — AIR. И кстати, он не так давно стал пригоден к употреблению, только с 3 версии. Не имею ничего против, сам пишу на нем код. Но HTML5 это все таки в браузере.
НЛО прилетело и опубликовало эту надпись здесь
Согласен, толку сейчас от HTML5 на мобилках практически никакого, в контексте создания игр. Если остальные браузеры подтянутся за оперой и мы сможем ипользоватьб WebGL, то тогда уже можно будет о чем-то говорить. С другой стороны, на мой взгляд, более перспективным будет поддержка открытых стандартов и инструментов.
Извините, был не прав. Буквально на выходных занялся вопросом изучения HTML5 на мобилках. Существуют программные оболочки, в которые вы можете запаковать свою HTML5 игру без изменения кода и оболочка будет рендерить вашу игру на мобильном устройстве используя аппаратное ускорение. Как минимум 2 таких движка я уже нашел — Cocoonjs и appMobi, возможно есть еще.
А вот пример игры, использующая cocoonjs и которая на моей старенькой первой галактике отлично работает
Biolab Disaster
Исходя из моего опыта, на eee pc 901 потенциальный фпс с таким количеством рендеринга должеен быть порядка 30000 во флеше. Конечно, такой фпс сделать никто не даст, а вот увеличить количество рендеринга в 500 раз можно.
ФЗ: ФФ 17, Убунта — кнопки в самом начале просто тупо не жмутся…
Ну, собственно, там тот же адрес, что и у тестов, только без # (который просто позволяет вводить чит-коды, без заморочек с консольным режимом, хоть и он тоже есть). Только на данном этапе развития, называть ее игрой, откровенно говоря, я бы не рискнул пока. Это скорее proof of concept движка игры + некоторые идеи, воплощенные вчерне (так сказать — задел на будущее).
НЛО прилетело и опубликовало эту надпись здесь
Вам не приходило в голову, что автор просто изучает технологию, а не пытается сделать что-то великое?
НЛО прилетело и опубликовало эту надпись здесь
Извините его, что он потратил пару дней своей жизни, чтобы рассказать нам что-то интересное и новое, и вам это показалось скучным и неправильным.

Простите его.

Он не нарочно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Как вы пишите — такой и троллинг, извините. Я не смог придумать более достойного ответа.

И если на статью автора, который явно потратил на нее определенные усилия, пишут «говно», не объясняя толком человеку причин, то хабр изменился, да.
НЛО прилетело и опубликовало эту надпись здесь
Полностью потдержу!
Все время следил за HTML5, и доси не понимаю всего бреда вокруг него, как и с шумихой вокруг Ajax в свое время, притом что DHTML изначально был, хрен знате сколько лет и прекрасно работал.
Потдавшись шумихе… таки решил попробовать переписать свою игру с Flash на HTML5… в итоге убил тучу времени, но понял что это тупик.!!! Причем тупик по всем фронтам.
1. Код полностью открытый! Нафиг оно мне такое нужно? Я сам взломал много таких игр и быстро пропал интерес… код раскрыт и делай что хочешь.
2. Как мою игру отдать всем в онлайн, на томже Facebook если оргомная аудитория пользователей прекрасно сидит на ХП с IE8 в котором толком ничего не заработает. даже не все framework стабильно работают под IE9.
3. Провел пару тестов на плантшетах с АРМ 6/7 и был в ужосе.

т.е. Чтобы создать свою, допустим соц.игру на HTML5, мне придется убить просто огромное кол-во времени, собирая все покусочкам, оптимизируя безконечно. И писать тучи вариантов игры, чтобы не потерять часть аудитории?

И при всем при этом, вижу почти каждый день, как минусуют любого кто хоть както заступится за Flash. Похоже на хабре это слово стало синонимом с Microsoft, и несет за собой падение кармы упоминувшего в суе. И это IT-шники? :(
Facebook перестал принимать игры на html?
вы о чем? как ваш вопрос относится к выше сказаному?
Тем, что не обязательно использовать Flash, чтобы делать игры для Facebook.
Вы так говорите, как будто игры на Флеше не ломаются или не декомпилируются.
Любой exe тоже можно вскрыть, но это могут еденицы и код программы еще не дает шанса все сломать. Также и Флеш игры, получив ресурсы и часть скриптов Флеша еще не значит что вы тутже вмешаетесь в процесс игры. А вот с HTML5 можно прямо в браузере толи IE толи Хром, следить за соурсом и вмешиваться в процесс.
А тем более это важно для Энтерпрайз приложений. Я планировал перейти с Flex на HTML5, из-за шунихи вокруг смерти Флеша и Флекса… но я не рискну написать энтерпрайз приложение на открытом коде, это бред полный.
Да и не каждый Флеш можно декомпилировать. У Адоба давно есть методы защиты Флеша от декомпиляции той о которой вы говорите.
Не знаю как на других платформах, а на Маке есть iHaxGamez, ломает что угодно на чём угодно. Вводишь цифру жизней, помираешь, вводишь на цифру меньше, ищешь ещё раз. «Морозишь» это значение, всё.
это больше говорит о ламерстве девелоперов, которые не защищают свой продукт от таких вот вмешательств. Продуманная онлайн игра, обычно закрыта от таких вмешательств и н еобщается с сервером в октрытом виде. Это аналогично sql иньеккциям в веб продуктах, если девелопер безрукий, то это незначит что PHP убогий и в него можно вмишаться.
Мы с вами говорим совсем о разных вещах.
Наверное о разных. Но вы знаете, я как-то пытался смотреть код Gmail… Это мне ничего не дало.
Пусть каждый занимается своим делом. Для создания коммерчески успешной игры необходима работа дизайнеров разного толка, менеджеров, рекламистов и так далее.

И конечно, программистов. И автор, в качестве программиста, показал мне, как непрограммисту, что технология работает и может быть использована для создания целостных продуктов. Другим же программистам указал на некоторые подводные камни разработки.
Если по существу, то я программист, а не гейм-дизайнер, не игровой сценарист, и ни не Кармак. Впрочем я и не претендовал. Тем не менее, мне кажется, что все идет к тому, что браузерные приложения очень даже скоро станут конкурентоспособными, а на мобильных девайсах будут доминировать. И мне показалось интересным пощупать возможности современного JS и HTML5. Если Вас смущает тег Game Development, то это просто следствие выбора темы для экспериментов (я вроде ее постарался обосновать вначале).
вставив фразу «даст фору флешу»… вы сделали огромную ошибку, и не потому что ибидели флеш, а потому что совершенно незнаете ничего о его достижениях. Видимо вы потдались общей теме Хабры, что Флеш уже похоронили…
Флеш как раз все дальше и дальше отрывается от HTML5 и шансов что HTML5 когдато догонит Флеш, практически никаких. Разве что если Adobe таки решиться его похоронить.
Конкретно на сегодня:
— Флеш уже давно не рендерит весь слой в 2D а только ту часть, в которой происходит изминение что дает максимальный ФПС. Тотже HTML5 все еще делает по старому, каждый фрейм идет рендеринг, и еще не скоро дойдет до этапа аналогичному во Флеш.
— Флеш уже прошел все пути в 2D, и сейчас просто ищет оставшиеся пути его ускорения и оптимизации… больше там развивать нечего для них
— развитие в 3D у Флеша уже дальше чем HTML5 в 2D

По этому «фора Флешу»… вы или неправельно выразились, так нужно было сразу исправить. Или вы далеки от понимания, но решили чисто не забыть кинуть камень в сторону Флеша как это любят делать на Хабре и заработать себе лишнюю карму.
Oh Really? Вы, если следите за флешом и НЕ следите за Canvas — изучите матчасть для начала, дабы не «ибидеть» всех остальных.

1. Canvas может перерисовывать как часть себя, так и себя всю полностью. Все зависит от радиуса кривизны рук программиста, а не технологии.
2. То же самое можно сказать и о Canvas'e! Как ускорить «setPixelColor()» я, честно говоря, сомневаюсь, что кто-то знает.
3. Canvas — всего-лишь инструмент, а не сборка технологий с IDE в упряжке. Не сравнивайте токарный станок Порше с автомобилем Порше.

В общем, RTFM/
Вижу что безсмыслено чтото доказывать тем кто решил для себя что Флеш зло и ему пора исчезнуть.
Отвечу просто — нету нИ одной задачи на канвасе которую флеш не сможет выполнить да еще с лучшими показателями. В тоже самое время — колосальное кол-во задачь которые HTML5 просто не в состоянии осилить, даже при большом желании.

После долго мучение с портированием Флеш игры в HTML5 я для себя понял одно! Мне проще и быстрее в сотни раз, переписать 2D игру в 3D. И это было проверено на практике. Имея такие фреймворки как Away3d, Alternativa3D, Flare3D и др., уже вчера можно было в очень короткие сроки, реализовать свои идеи.

Потому HTML5 завтра все еще будет предлагать сырую 2D платформу, а Флеш уже вчера предлагал полноценную 3D платформу и не только.
Ни одной? Вот так уж действительно?

Вот вам первая задачка — загрузить флеш-игру при установленном в Chrome плагине FlashBlock.
Вторая вторая задачка — не съедать 120% CPU при размере отрисовки 300х400px на MacOS.

Да, и еще. Раз вы такой большой фанат 3D — в уме пересчитать матрицу поворота сможете? Знаете, почему она вообще нужна? Если нет и знания будут добываться в википедии — скажите, какой смысл доказывать о том, что флеш предлагает 3D «искаропки»? Вы же не знаете, о чем говорите. Тем более в Canvas'e так же давно есть 3D — github.com/mrdoob/three.js/
Дело не в RTFM и заявленных фичах, а в реализации конкретных задач. В реальных задачах Канвас очень слаб. Безусловно, это временное явление и с годами допилят производительность и появятся сотни удобных фреймворков. Но на данный момент времени, если вам требуется хоть сколько-нибудь сложная анимация — никаких альтернатив флешу нет.
Мы делали анимацию звездных систем, планеты вращающиеся вокруг звезды с некоторыми эффектами подсветки при наведении мыши на объекты анимации. В итоге мы потратили больше года на манипуляции и попытки заставить работать анимацию одинаково хорошо в разных браузерах. В ФФ анимация на основе канваса как в чистом виде, так и с использованием самых разных фреймворков просто обрушивала браузер, предварительно нагружая любой процессор до 100%. Анимация на чистом HTML (манипуляция обычными div'ами) не была плавной. Попробовали решить эту задачу на SVG, но тут выяснилось, что Chrome положил болт на векторную графику и там даже не работают элементарные события вроде mousemove или click для многих видов объектов.
Промучавшись год с этой задачей мы в итоге были вынуждены отказаться полностью от анимации, тк либо нужно писать несколько разных ее видов на основе разных технологий, чтобы это работало во всех основных браузерах, либо использовать флеш. Так что как гейм программист могу вам сказать, что в данном виде, в котором пребывают на данный момент HTML5.Canvas и SVG им флеш не победить никогда. Однако уверен, что с годами ситуация изменится.
Никакого холивара. Я вам говорю о конкретной задаче, а не о статике. Вы суете всем в нос то, что сделано другими людьми для других целей.
Давайте я вам выдам ТЗ по той анимации, о которой я говорил и вы сами попробуете сделать. Вы пытаетесь убедить людей, работавших с канвасом в реальных задачах, но сами при этом, судя по всему, понятия не имеете о чем говорите. Даже вот ваш пример — красивая картинка. А как насчет обработки событий? А в опере пробовали открывать? А на планшете? Красивые демонстрашки это круто, но это не имеет никакого отношения к повседневным задачам.
А вот давайте. Присылайте ТЗ.
Суровые мужики =)))
Ну, слово — не воробей, однако, я не думаю, что предпоследнее слово в последнем абзаце не стоит затеянного холливара. А бросать камни в кого-бы то ни было, и тем более в своих коллег-программистов я бы уж точно не стал. Замечу, что я немного поизучал клиентскую сторону вот этого движка. Так что я не совсем уж не разбираюсь в вопросе. Тем не менее, для большинства областей применения, в которых сейчас используется flash, более чем достаточно «нативной» поддержки JS и Canvas. И вот тут-то эта пара уже вполне конкурентна.
gasizdat пишет:
Не так давно мне стало любопытно, насколько сносно современные браузеры поддерживают HTML5 и я не нашел лучшего
способа, чем написать простейший 2D платформер. Помимо удовольствия от разработки игрушки и улучшения навыков в использовании JavaScript, в ходе развлечения кропотливой работы был накоплен определенный опыт и эмпирическим путем были найдены основные грабли, на многие из которых мне пришлось наступить. В этой статье я попробую кратко и с примерами резюмировать то, что вынес для себя из проделанной работы.


Вопрос вам MixailV, где тут хоть что-нибудь про комерциализацию, продажу игры за $1000, поиск издателя и т.д.? Автор же явно дал понять, что его цель — изучить HTML5, Canvas, и особенности реализации их в браузерах.

Хабр (ИМХО) в первую очередь технический сайт, тут принято общаться на технические темы, обсуждать код и т.д. И если вы действительно ожидали увидеть тут статью про коммерческий успех игрушки, то хабр действительно изменился, изменился в худшую сторону.
Аргумент «сперва добейся». Типичная софистика.
По рендеру есть еще хитрый способ — можно кадровую логику (перемещения например) расчитывать при помощи таймаута, а рендерить уже состояние по requestAnimationFrame
Пока мне не очень ясно какие преимущества это даст. Если у Вас есть какой-то положительный опыт с таким подходом, было бы интересно услышать. Но, КМК, браузеры выполняют JS в одном потоке и все отложенные вызовы будут выполняться псевдоасинхронно. Потому суммарное время выполнение кода не сократится, а может даже вырасти, т.к. движку придется планировать несколько вызовов в контексте одного единственного потока.
Понятное дело, что однопоточно, но таким образом можно избежать «захлебывания» кадра, когда пора уже рисоватся новому, а еще старый ненарисован.
то есть, попробуйте такой код, быть может покажет прирост производительности:
var renderLoop = function () {
//game logic
setTimeout(renderLoop, 30);
}

смысла рисовать 2 раз один и тот же кадр нету
Согласен. Но рендер будет только по необходимости и если переключена вкладка — рендера не будет. А вот игровая логика все так же будет отрабатывать.
Не надо рисовать. Если состояние не изменилось, ничего не делаем.

Примерно так:
this.doDraw = function()
{
	if(fNeedRedraw)
	{
		fNeedRedraw = false;
		fGameMap.Draw(fBuffer);
	}
}

this.doAnimationLoop = function()
{
	requestAnimFrame(fInstance.doAnimationLoop);
	fInstance.doDraw();
}
но при этом будет перерисовываться весь фрейм? а не область изминения? в отличие от Флеш который анализирует и смотрит, какую область фрема отреднерить а какую не трогать и оставить статичной.
Условно, requestAnimationFrame — это событие «Я отрисовал предыдущее задание и готов рисовать снова». Что Вы положите в функцию отрисовки — решать Вам.
Вы для заманухи взяли картинку из очень крутых экспериментов по анимации через смещение в палитре www.effectgames.com/demos/canvascycle/?sound=0 рассказали бы об этом еще ;)
Мне самому бы разобраться. Но, согласитесь, вдохновляет!
В дополнение к предыдущему. Хабр съел:

И после этого — на файл Bitmap.js
Грубо говоря — вся картинка передается в виде массива пикселей, в котором есть обозначения, какие пиксели анимировать, какие — нет. После этого анимированные пиксели перерисовываются циклично в пределах одного цвета (R/G/B) на совсем малое смещение.
Но работа, конечно, очень. У меня бы терпения отлаживать не хватило ^_^
Спасибо! Я после просмотра этих экспериментов влюбился в работы художника Mark'а Ferrari! Потрясающе красивые миры!
Плюсую. Но измерение в «попугаях» — не серьёзно.
Посмотрите на kothic.org/js/ (гуглить kothic.js)
Не следует напрягать движок реализацией классов при помощи прототипирования – выгода сомнительна, а код замедляется в разы (Opera)! Сложное прототипное наследование и честно организованный перенос базового функционала к наследникам сбивают и без того не самую лучшую оптимизацию.

5. Замыкания и свойства – враги быстродействия

Эээ.
Я бы таки хотел посмотреть на тесты, в которых выявлены такие интересные факты.
Для того, чтобы в тесте сравнить быстродействие псевдоклассов и наследования, построенных на прототипировании, нужно сильно перекроить имеющуюся объектную модель. Скажу только, что начинал я именно с этого, но результат, мягко скажем, был никакой, как в плане производительности, так и в плане поддержки. Что касается замыканий и свойств, то ссылка на код теста есть прямо в том же пункте. Я не исключаю, что я где-то сильно заблуждаюсь, но вероятность этого мне кажется мала.
> Для того, чтобы в тесте сравнить быстродействие псевдоклассов и наследования, построенных на прототипировании, нужно сильно перекроить имеющуюся объектную модель. Скажу только, что начинал я именно с этого, но результат, мягко скажем, был никакой, как в плане производительности, так и в плане поддержки.

Ну тогда так и пишите — перевести существующий код на прототипы оказалось дорого. Откуда такие широкие обобщения?

> Что касается замыканий и свойств, то ссылка на код теста есть прямо в том же пункте. Я не исключаю, что я где-то сильно заблуждаюсь, но вероятность этого мне кажется мала.

А, нашел, прошу прощения.

  function type1()
  {
    var _x1 = 0, _x2 = 0;
    this.setx1 = function(v) { _x1=v; };
    this.setx2 = function(v) { _x2=v; };
    this.sum = function() { return _x1+_x2; };
  }

  function type2()
  {
    this.x1 = 0;
    this.x2 = 0;
    this.setx1 = function(v) { this.x1=v; };
    this.setx2 = function(v) { this.x2=v; };
    this.sum = function() { return this.x1 + this.x2; };
  }

  function type3()
  {
    var _x1 = 0, _x2 = 0;
    Object.defineProperty(this, "x1", {get: function(){  return _x1; }, set: function(v){ _x1 = v; } });
    Object.defineProperty(this, "x2", {get: function(){  return _x2; }, set: function(v){ _x2 = v; } });
    Object.defineProperty(this, "sum", {get: function() { return _x1 + _x2; } });
  }


Два вопроса:
1. Как вы полагаете, что вы проверили этим тестом?
2. Каким образом из этих тестов вы делаете широкий вывод, что «замыкания и свойства — враги быстродействия»?
1.
var t1 = new type1(); var t2 = new type2(); var t3 = new type3(); 
for(var i = 0; i < loops; i++)  { t2.x1 = i; t2.x2 = i + 5; sum += t2.sum(); } //прямой доступ к полям объекта и вызов метода (без замыкания)
for(var i = 0; i < loops; i++)  { t1.setx1(i); t1.setx2(i + 5); sum -= t1.sum(); } //доступ к внутренним переменным через замыкания
for(var i = 0; i < loops; i++)  { t2.setx1(i); t2.setx2(i + 5); sum += t2.sum(); } //доступ к полям объекта через методы (без замыкания)
for(var i = 0; i < loops; i++)  { t3.x1 = i;  t2.x2 = i + 5;  sum -= t2.sum;  } //доступ к внутренним переменным через свойства с замыканиями.

2. Методом индукции.
Но, тон Вашего вопроса мне говорит, что Вы на него ответите лучше меня :)
В хороших книжках по оптимизации JS сказано, что время на поиск свойства в объекте — критичная штука. И в рендерЛупе вообще лучше _все_ переменные по возможности делать локальными. А некоторые даже рекомендуют, что если к свойству или элементу массива вы обращаетесь более 1 раза, то их надо тоже вносить в локальную переменную, особенно это касается DOM элементов.
P.S. Под хорошими книжками я понимаю книжки написанные Николасом Закасом, Дугласом Крокфордом и Стефаном Стояновым.
А некоторые, например, проверяют, а не доверяют.
jsperf.com/local-var-vs-3-dots
В FF, к примеру, в некоторых кейсах обращение к параметру через три точки на 17% быстрее, чем сохранение в локальную переменную.

В хороших книжках по оптимизации написан не свод правил, а предложение думать головой, проверять и подходить к каждому кейсу индивидуально, а не заниматься обобщениями «замыкания тормозят».
Большинство оптимизаций, к которым я пришел — вышло из практики их применения. Раньше я обращался через точку, потом решил попробовать локальную переменну — случился прирост FPS, что, кстати, подтверждает приведенная вами ссылка. А думать головой надо всегда, даже когда написан «свод правил»;)
И наверное я некорректно выразился, когда говорил о локальных переменных, вот я сделал тест, который отражает положение дел в моем коде.
Вы шутите? Мелкопроцентный прирост при пустом теле? Это полностью нивелируется погрешностями. Когда внутри цикла есть серьёзные вычисления — эти все спичечные оптимизации не дают никакого эффекта. Прирост даёт оптимизация отрисовки в первую очередь — отрисовка в целые координаты, перерисовка только необходимого, избегание сглаживания, кеширование вектора. А переносить свойства в локальную — это для редких случаев, когда есть один метод, который обрабатывает десятки тысяч раз в секунду и требуется его локальная оптимизация. Ну, например, просчёт лучей в ray-casting'е. Но это два-три метода на весь код, а не основная практика.
я говорю именно о renderLoop, где у меня проходятся объекты в массивах. оптимизации, о которых вы говорите уже сделаны, в том числе и те оптимизации, о которых вы говорили в своих статьях.
Ну возможно есть узкий стек приложений, где оптимизации из серии выноса в локальную переменную актуальны, не спорю)
Но такие вещи стоит ловить профайлером и убирать, а не писать в статьи, как best practices, имхо)
А я помню откуда картинка к статье! habrahabr.ru/post/100255/. Уж больно оно мне запомнилось тогда.
Какой неожиданно эффективный вброс! Я уже надеялся что холивары на тему «флеш мертв» вышли из тренда. )) gasizdat, вы всего одной фразой смогли в статье изначально акцентированной на технических нюансах вызвать бурление. За статью — спасибо, мне нравится такая сжатая подача информации, вы молодец.
Спасибо. Впредь мне наука — пишешь про один ЯП, не упоминая всуе другой. В общем сам не ожидал.
"gasizdat… вполне позволяют писать производительные интерактивные графические приложения, которые в большинстве задач дадут фору традиционному flash программированию"
100%! HTML+JS дадут фору Macromedia Flash 1.x-6.x, но вот тем что позже и тем, которые стали Adobe Flash — уже нет. Назначение разное, возможность использования ресурсов, исполнение кода и т.д. На JS разве что СуперМарио делать. Хотел бы я взглянуть на Танки Онлайн, сделанные на JS )))))

А за исследование — респект, замечательный материал.
Исследование дельное, но объясните мне пожалуйста, ЧТО толкает вас на использование Comic Sans в тестах?
Дык прикольненько же!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории