Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
360p видео очень в тему
Пробежался по диагонали по ссылкам, но не совем понял, есть ли?
1. многопоточность
2. указатели
3. SIMD
4. структуры (value type без оверхеда, как в C#)
Я просто сильно сомневаюсь в возможности реализации всего этого в модели javasctipt. Или я ошибаюсь?
1. многопоточность
2. указатели
3. SIMD
4. структуры (value type без оверхеда, как в C#)
Я просто сильно сомневаюсь в возможности реализации всего этого в модели javasctipt. Или я ошибаюсь?
Можете ознакомиться github.com/kripken/emscripten
Ну, emscripten транслирует биткод в стандартный javascript, который сам по себе ничего из этого списка «не знает». Надежда на новые API в asm.js, хотя они призрачны.
Я это всё к тому, что я считаю, что «тяжелые» игры невозможны без этих четырёх фич. Причём именно в виде доступного API, а не на уровне скрытых внутренних JIT-оптимизаций. Буду рад ошибиться.
Я это всё к тому, что я считаю, что «тяжелые» игры невозможны без этих четырёх фич. Причём именно в виде доступного API, а не на уровне скрытых внутренних JIT-оптимизаций. Буду рад ошибиться.
2,4 реализуется с помощью typed array формата «хапнем побольше» и низкоуровневой работы с ним. По-моему asm.js и должен так работать. UnrealEngine многопоточность не должна требоваться (она в нем не так рано появилась, поэтому что-то урезанное точно должно быть), остается SIMD? А так он ли нужен, если рендер на GPU?
Typed array действительно вариант! Костыльный, ограниченный только value type, но всё же вариант.
А SIMD очень нужен. Даже в 2d играх, а тем более в 3d. Даже если рендер на GPU, всё равно куча математики (вся физика, как минимум, да и вообще) — векторная.
PS: Ну и нормальная многопоточность тоже жизненно необходима. Не знаю, как обходились в Unreal Engine, но в эпоху 4-ядерных процов, работать в одном потоке просто глупо.
PPS: WebWorker — не очень подходит, т.к. насколько я понял, не позволяет расшаривать данные между потоками, вместо этого в каждый воркер передается своя копия данных.
А SIMD очень нужен. Даже в 2d играх, а тем более в 3d. Даже если рендер на GPU, всё равно куча математики (вся физика, как минимум, да и вообще) — векторная.
PS: Ну и нормальная многопоточность тоже жизненно необходима. Не знаю, как обходились в Unreal Engine, но в эпоху 4-ядерных процов, работать в одном потоке просто глупо.
PPS: WebWorker — не очень подходит, т.к. насколько я понял, не позволяет расшаривать данные между потоками, вместо этого в каждый воркер передается своя копия данных.
Может тяжёлые и невозможно, но во многие старые лёгкие я бы играл в браузере с удовольствием
Поправьте если я не правильно понимаю, но
Т.о. Каждый мало-мальски привлекательный 3d движок будет занимать более миллиона строк кода. Однако, если он поддается портированию, то объединенной командой, размером с mozilla и epic вместе взятых, можно портировать(не написать) сферическую игру в вакууме за 4 дня, без геймплея, монстров и оружия и сделать из нее непонятный ролик.
Это определенно успех.
мы портировали унрил
а это более миллиона строк кода
Т.о. Каждый мало-мальски привлекательный 3d движок будет занимать более миллиона строк кода. Однако, если он поддается портированию, то объединенной командой, размером с mozilla и epic вместе взятых, можно портировать(не написать) сферическую игру в вакууме за 4 дня, без геймплея, монстров и оружия и сделать из нее непонятный ролик.
Это определенно успех.
Риторический вопрос: как можно защитить игровой код — интеллектуальную собственность компании-разработчика? Даже если собственно игры, выполненные на этой технологии, будут бесплатными, желание не давать исходники всему миру вполне понятно и объяснимо.
Сам принцип работы JS недружелюбен к «ААА»-проектам, на которые инженеры Мозиллы хотят замахнуться.
Сам принцип работы JS недружелюбен к «ААА»-проектам, на которые инженеры Мозиллы хотят замахнуться.
Вообще не пойму что дает выполнение в браузере для таких игр. Все равно играть лучше в полноэкранном режиме, и какая разница будет ли это окно браузера или отдельное приложение. К тому же качать сотни мегабайт яваскрипта как то не айс. Проще пойти и купить диск. Для каких нибудь онлайн магазинов, презентаций это хорошая штука будет, но не для игр.
Думаю переключение фулскрина точно будет, если еще нет. А на дисках игры все меньше покупают, с развитием магазинов вроде стима
Выполнение игры в браузере дает неплохую кросплатформенность для всех платформ где этот самый браузер может запускаться, что в свою очередь дает больший охват аудитории игры и в перспективе больше денег разработчикам/издателю. Другой вопрос как эти игры будут защищать — одно дело бинарники собрать для разных платформ, а тут открытый код всего: и движек, и логика, и графика со звуком — не думаю что производители топовых игр захотят такого.
Fullscreen API в современных браузерах уже есть :). Сотни мегабайт JS… Помнится, был порт Unreal Engine на флеш и про подобные проблемы я не слышал… Хотя может они и были, я, если честно, далёк от флеша
Ну нифига ж себе, вы сравнили…
Да самый заобфусцированый вдоль и поперёк js — это ничто, по сравнению с дизамблированным C++. Даже используя что-нибудь вроде IDA, разобраться в биткоде — это на порядок более сложная задача. Да что там на порядок, это зачастую просто несоизмеримо.
К тому же, любая более-менее серьёзная обфускация js (с eval'ами, фейковыми объектами и прыжками по меткам) тормозит by design. Для игр не подходит.
havelock прав, за что минусы не понятно.
Да самый заобфусцированый вдоль и поперёк js — это ничто, по сравнению с дизамблированным C++. Даже используя что-нибудь вроде IDA, разобраться в биткоде — это на порядок более сложная задача. Да что там на порядок, это зачастую просто несоизмеримо.
К тому же, любая более-менее серьёзная обфускация js (с eval'ами, фейковыми объектами и прыжками по меткам) тормозит by design. Для игр не подходит.
havelock прав, за что минусы не понятно.
Там JS используется фактически в качестве ассемблера, от исходной программы в нем остается не больше чем в x86 коде.
промахнулся с ответом
Так в приведенном случае использовался javascript llvm-backend. От дизассемблированного кода на C++ это будет не сильно отличаться.
Сам принцип работы JS недружелюбен к «ААА»-проектам, на которые инженеры Мозиллы хотят замахнуться.
Какие ещё ААА? Использование движка Unreal не делает из игры ААА. Думается мне, что в силу ограничений и тормознутости JS даже после всех оптимизаций, в первую очередь будут реализованы нетехнологичные игры, которые не грузят проц и видюху топового железа на 100%.
А для игр, в которых не так критична производительность, уже сейчас успешно используются .NET и Java, которые даже после обфускации обычно неплохо декомпилируются. И вообще, у относительно малого количества игр есть какие-то хитрые алгоритмы, которые ну никак нельзя раскрывать конкурентам. Ну, игроки чуть быстрее выяснят вашу формулу вычисления дамага или ещё какую-нибудь мелочь.
В Стиме дофига успешных игр на .NET и Java, некоторые даже не обфусцированы, ресурсы тоже очень часто незашифрованы. И что-то я не вижу, чтобы эти игры чаще или реже выкладывались на торренты, потрошились конкурентами, и вообще с ними происходили какие-то особые катаклизмы.
Не надо так трястись на битами и байтами. Берите пример с Джона Кармака, например.
Подозрительно знакомое демо. Хотя то, что производительность JS постепенно подтягивается до производительности Flash безусловно радует.
Очень любопытно насколько реализация UE3 под мозиллой требовательнее к ресурсам компа, в сравнение с обычным UE3…
Т.е. если раньше разговор шел о том, что с игрой надо было (точнее, автоматом вставали) нужные системные библиотеки, то теперь в качестве зависимости будет вставать, ни много ни мало, браузер?
Чего только не придумают, чтобы повысить процент своего присутствия на рынке. :)
Правда, я бы такого хода ождал от MS с их IE, от Яндекса с их Баром, тьфу, Яндекс.Браузером, даже от Рамблера или Mail.ru, но не от Mozilla. Им-то всегда как-то не особо была важна раскрутка «сторонними» методами…
Чего только не придумают, чтобы повысить процент своего присутствия на рынке. :)
Правда, я бы такого хода ождал от MS с их IE, от Яндекса с их Баром, тьфу, Яндекс.Браузером, даже от Рамблера или Mail.ru, но не от Mozilla. Им-то всегда как-то не особо была важна раскрутка «сторонними» методами…
Корпорация добра уже давно как на этом пути: NaCl.
И это не столько попытка попытка завязать на себя, сколько удовлетворение прогнозируемого в ближайшем будущем спроса.
Только ничего у них не выйдет, по моему мнению. Потому что играм нужна максимальная производительность, а браузерам безопасность. Несоединимо.
Например, даже Microsoft похоронила свой XNA, и призывает back to the native С++ в игропроизводстве. Именно по причине производительности. А ведь XNA (.net) это даже близко не JS и не браузер.
И это не столько попытка попытка завязать на себя, сколько удовлетворение прогнозируемого в ближайшем будущем спроса.
Только ничего у них не выйдет, по моему мнению. Потому что играм нужна максимальная производительность, а браузерам безопасность. Несоединимо.
Например, даже Microsoft похоронила свой XNA, и призывает back to the native С++ в игропроизводстве. Именно по причине производительности. А ведь XNA (.net) это даже близко не JS и не браузер.
Мне почему-то кажется, что здесь имеет место игра в «важно возглавить поток». У Спольски об этом очень хорошо было написано, что цель компаний типа MS — изобретать все время новые парадигмы, чтобы все гнались за ними, а когда приблизятся — изобретать новую, что оставляет у всех ощущение движения, а лидера все равно не догнать, т.к. за счет таких правил именно он диктует правила игры.
Старые подходы в играх никуда не делись: игры пишутся, тестятся, все работает, но надо же как-то движуху создавать?
Старые подходы в играх никуда не делись: игры пишутся, тестятся, все работает, но надо же как-то движуху создавать?
Интересно, как будет организовано хранение данных и кода игры — все локально или будет требовать постоянного подключения к интернету. Очень надеюсь на первое.
Как бы то ни было, со стимом под 3 основные платформы не вижу причин играть во что-то через браузер.
Как бы то ни было, со стимом под 3 основные платформы не вижу причин играть во что-то через браузер.
Думаю, это больше для людей, которые играют в социальных сетях. Сейчас игры там довольно однообразные, мультяшный флеш, как правило. Игры на Unity в социальных сетях как-то не встречались, кроме одного клона Майнкрафта, чтобы играть в который нужно постоянно донатить.
Технологии хранить все локально в браузерах давно есть:
LocalStorage, IndexedDB, AppCache.
Краткосрочный успех непонятен, долгосрочный — почему нет?
Веб-приложения наступают с лоу-енда — сначала казуальные игры. потом посильнее, потом еще сильнее…
Если делаешь игру не с супер крутой графикой, а берешь геймплеем, то выигрыш очень силен — не надо портировать на кучу платформ.
LocalStorage, IndexedDB, AppCache.
Краткосрочный успех непонятен, долгосрочный — почему нет?
Веб-приложения наступают с лоу-енда — сначала казуальные игры. потом посильнее, потом еще сильнее…
Если делаешь игру не с супер крутой графикой, а берешь геймплеем, то выигрыш очень силен — не надо портировать на кучу платформ.
Я просто надеюсь, что мы не придем к ситуации, когда все игры будут требовать подключения к интернету. А насчет портирования — мне кажется, что и так давно все идет к кроссплатформенным приложениям (в основном играм). Плюс не думаю, что такое количество разработчиков нативных игр и компаний, которые занимаются этим, перейдет на новые технологии, успех которых пока еще сомнителен.
Особенно будут рады новостям об OdinMonkey и Asm.js непримиримые любители нативных мобильных приложений.
Под iOs не появится OdinMonkey, так же как FireFox, так же как опера там не появилась на Presto. Так что остается только нативный код.
Речь не о том, где и что (или кто) появится или нет… речь в принципе об используемых технологиях для мобильных приложений. Apple конечно же пойдет своим путем, никого не пустит на свою платформу. Но вопрос в другом — в каком именно направлении все это будет двигаться. Сейчас только и разговоров о том, что под мобильные приложения возможен только натив и никак иначе. Но так ли это на самом деле?
inet777.ru/buduschee-mobilmznyih-prilozheniy-nativnyie-ili-html/8401
inet777.ru/buduschee-mobilmznyih-prilozheniy-nativnyie-ili-html/8401
Вы правда предлагаете читать километровую статью по мобильной разработке на сайте дизайн которого застрял в 90х?
А на самом деле есть яркий пример ФБ, который сделал ставку на HTML5, потом признал свою ошибку и несостоятельность такого варианта и переделал под натив. И мне пока не известны примеры успешных приложений, особенно хоть сколько нибудь требовательных к ресурсам и написанных не на натив коде.
А на самом деле есть яркий пример ФБ, который сделал ставку на HTML5, потом признал свою ошибку и несостоятельность такого варианта и переделал под натив. И мне пока не известны примеры успешных приложений, особенно хоть сколько нибудь требовательных к ресурсам и написанных не на натив коде.
1. о вкусах не спорят — это я о дизайне, на вкус и цвет… мне нравится — этого достаточно! более ничье мнение насчет дизайна сайта меня не интересует
2. на Цукерберга мы еще поглядим… еще не достаточно времени прошло, чтобы делать какие-то выводы… я думаю, те 2 года, что он занимался HTML5 он был точно так же абсолютно уверен в правильности выбранного им пути… но рановато пошел по нему… поглядим, что будет в последующие 2 года перехода ФБ на натив
2. на Цукерберга мы еще поглядим… еще не достаточно времени прошло, чтобы делать какие-то выводы… я думаю, те 2 года, что он занимался HTML5 он был точно так же абсолютно уверен в правильности выбранного им пути… но рановато пошел по нему… поглядим, что будет в последующие 2 года перехода ФБ на натив
«И мне пока не известны примеры успешных приложений, особенно хоть сколько нибудь требовательных к ресурсам и написанных не на натив коде. „
Я считаю, что как раз технологии подобные OdinMonkey и Asm.js как раз и помогут это решить.
Я считаю, что как раз технологии подобные OdinMonkey и Asm.js как раз и помогут это решить.
ФБ не делал ставку на HTML5. Это были его собственные расширения для HTML.
Интересно а как гуглевский Native Client развивается? Потенциал у этой технологии, мне кажется, больший, чем у ускоренного js с 3D.
Из последних новостей — переход на новый прокси, который облегчает обращение к браузеру в многопоточных приложениях, появление отладчика на основе gdb (при этом можно отлаживать даже на Chrome OS без переключения в dev-режим) и плагина для Visual Studio 2010 (нужна полная версия), появление компилятора для arm'a на основе gcc, исправление бага хрома с повреждением скачиваемых nexe, исправление багов с CORS. В ближайшем будущем собираемся перейти на новый валидатор, который в несколько раз быстрее старого, что должно немного ускорить запуск приложений.
Местами похоже на машинный перевод.
«визуальный опыт» (очевидно «visual experience»),
«для улучшения пользовательского опыта» (очевидно «user experience»).
по теме — при использовании asm.js они расчитывают получить код, который выполняется всего вдвое медленнее, чем нативный (буквально на днях была об этом статья), учитывая, что сейчас получаются довольно неплохие игры, работающие на мобильных устройствах, то написать игру, которая не будет тормозить в десктопном браузере — реально. А целесообразность покажет время.
«визуальный опыт» (очевидно «visual experience»),
«для улучшения пользовательского опыта» (очевидно «user experience»).
по теме — при использовании asm.js они расчитывают получить код, который выполняется всего вдвое медленнее, чем нативный (буквально на днях была об этом статья), учитывая, что сейчас получаются довольно неплохие игры, работающие на мобильных устройствах, то написать игру, которая не будет тормозить в десктопном браузере — реально. А целесообразность покажет время.
fightcodegame.com/robots/replay/761152 Нашел смачный бой ))))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mozilla предлагает создавать «тяжёлые» 3D-игры для web на их новом движке