Проект Mozilla и компания Epic Game продемонстрировали (https://blog.mozilla.org/blog/2014/03/12/mozilla-and-epic-pr.../) возможность использования Web-бразуера Firefox в качестве платформы для запуска современных 3D-игр в Web. В частности, представлены транслированные в JavaScript демонстрации игр Soul и Swing Ninja, основанные на движке Unreal Engine 4. Указанные демонстрации работают в Firefox без применения плагинов с производительностью близкой к нативным программам.<center><iframe width="640" height="360" src="//www.youtube.com/embed/c2uNDlP4RiE?rel=0" frameborder="0" allowfullscreen></iframe></center>
Приемлемой для запуска игр производительности удалось достичь благодаря применению Asm.js (http://www.opennet.me/opennews/art.shtml?num=36468), низкоуровневого подмножества языка JavaScript со строгой типизацией. Наличие информации о типах позволяет использовать не только JIT, но и предварительную AOT-компиляцию, выполняемую для всего кода до начала его выполнения и генерирующую более простой и эффективный машинный код. Для вывода 3D-графики задействован WebGL. Трансляция игрового движка выполнена с использованием компилятора Emscripten (http://www.opennet.me/opennews/art.shtml?num=35313), преобразующего код проектов с языков C и C++ в представление на языке JavaScript.Внесённые за последние 12 месяцев оптимизации позволили заметно увеличить производительности web-приложений, использующих Asm.js. Производительность выполняемого в браузере кода в настоящее время составляет 67% от производительности нативных программ, в то время как год назад этот показатель составлял 40%. Отмечается, что реализация оптимизаций продолжается и будущем достигнутый результат будет улучшен.
Продемонстрированный уровень производительности открывает новые возможности для распространения современных 3D-игр в Web, для запуска которых достаточно web-браузера. Поставка игр через Web упрощает доставку игр до потребителей, делая их доступными через один клик по ссылке, расширяет спектр поддерживаемых платформ и снижает расходы за счёт упразднения лишних звеньев в цепочке распространения.
URL: https://blog.mozilla.org/blog/2014/03/12/mozilla-and-epic-pr.../
Новость: http://www.opennet.me/opennews/art.shtml?num=39294
Молодцы, только сказки про 67% не надо рассказывать, хватает тех, кто до сих пор считают, что джава и флеш работают также быстро как си.
>также быстро как сиПри желании, Си можно заставит работать медленнее скриптовых языков.
Капитан, ты?
При желании, си можно заставить не работать вообще. Но разве это доказывает хоть что-нибудь?
> При желании, Си можно заставит работать медленнее скриптовых языков.А если уж заставить медленно работать скриптовые языки... нууууууу.... AI считающий ход в BfW по 2 минуты на могучем проце я уже видел :).
> Молодцы, только сказки про 67% не надо рассказывать, хватает тех, кто до
> сих пор считают, что джава и флеш работают также быстро как
> си.Работая с Java и Flash надо просто иметь огромную силу воли чтобы не замечать недостатков с производительностью. Например Flash в который тормозит если использовано несколько анимированных объектов часть из которых время от времени меняет свое положение на экране. Такое часто наблюдается в современных online играх браузерных. Которые тормозят даже на современных мощных видеокартах. С Java тоже все просто это тормозной продукт, его применение в крупных проектах это способ оправдать наличие мощных вычеслительных ресурсов которые тратятся впустую.
На Си тоже можно писать корявый код который будет медленным, но он никогда не опустится до минимума. И уж точно не будет медленнее Java или Flash хотя сравнение с Flash считаю неуместным в данном случае
>> На Си тоже можно писать корявый код который будет медленным, но он никогда не опустится до минимума. И уж точно не будет медленнее Java или FlashТы недооцениваешь особо выделяющихся талантов обладающих скилом изобретать особо-неадекватные алгоритмы.
> Ты недооцениваешь особо выделяющихся талантов обладающих скилом изобретать особо-неадекватные
> алгоритмы.Странно что человек может намерено писать алгоритмы которые заведомо снижают производительность. Но с другой стороны так сложилось что сейчас почти всегда легче написать более высокие системные требования чем оптимизировать программный код.
> Странно что человек может намерено писать алгоритмы которые заведомо снижают производительность.Я, например, однажды сделал себе алгоритм тасования колоды, который перебирал случайной сортировкой всю колоду столько раз, сколько там карт ( for(var a in arr) arr.sort(function(){return Math.random()-0.5;}); ) Мало того, что это было чудовищно неэффективно, так ещё и результат не был действительно случайным. Почему я так сделал? Мне просто нужно было быстро и не задумываясь сделать что-то, что делает вид, что работает и это было проще, чем искать и потом понять и реализовывать простой и эффективный алгоритм Фишера-Йетса, о котором я узнал позже. А иногда такие фокусы так и остаются не исправленными и продолжают «жить».
> остаются не исправленнымиостаются неисправленными
А Вы с проектами какого уровня имели дело на java?
Видимо, человек писал хеллоуворлд под андроид и не смог дождаться загрузки эмулятора. Травма на всю жизнь теперь.
>не смог дождаться загрузки эмулятораэто потому что батарейка успела разрядится в процессе запуска
> успела разрядитсяразрядиться, ёпта
Тем не менее, демо вертится весьма быстро.
Любой достаточно простой код на жаваскрипте выполняется в современном браузере со скоростью, сопоставимой с нативной, ибо компилится на лету непосредственно в инструкции процессора. Используя промежуточное представление, удаётся лишь убрать сборщик мусора и показать стабильную работу независимо от выполняемого кода. На этом плюшки заканчиваются
> На этом плюшки заканчиваютсяТак уже очень неплохо.
> Тем не менее, демо вертится весьма быстро.Смотря с чем сравнивать. Если запускать на четвертинку экрана - тогда да. А если на весь - слайдшоу, однако.
уже Epic Game?
> уже Epic Game?Это название фирмы, Epic Game а движок называется так как написано в заголовке новости
Epic Games. а тебе стоит быть не настолько дремучим, может ты еще и об Unreal не слышал?
Но ведь графика 10-и летней давности...>> современных 3D-игр в Web
для всяких ферм хватит
А я вчера халву снова прошел =)
Довольно интересный проект с исходниками
https://developer.mozilla.org/en-US/demos/detail/bananabread
порт движка Cube2
Жалко что Quake Live для Linux прекратили выпускать.
>[оверквотинг удален]
> в настоящее время составляет 67% от производительности нативных программ, в то
> время как год назад этот показатель составлял 40%. Отмечается, что реализация
> оптимизаций продолжается и будущем достигнутый результат будет улучшен.
> Продемонстрированный уровень производительности открывает новые возможности для распространения
> современных 3D-игр в Web, для запуска которых достаточно web-браузера. Поставка игр
> через Web упрощает доставку игр до потребителей, делая их доступными через
> один клик по ссылке, расширяет спектр поддерживаемых платформ и снижает расходы
> за счёт упразднения лишних звеньев в цепочке распространения.
> URL: https://blog.mozilla.org/blog/2014/03/12/mozilla-and-epic-pr.../
> Новость: http://www.opennet.me/opennews/art.shtml?num=39294Что-то прослоек мало... Надо в ФФ встроить свою инновационную ОС, на ней запустить браузер, а в нем уже UE... Вот тогда точно в производительности выиграем!
Можно там запустить NetBSD
> Можно там запустить NetBSDБеллард вас уже обштопал - http://bellard.org/jslinux/
Без установки дров, без мытарства по торрентам и помойкам, игры идут к вам, чтобы зохавать ваш мозг и не дать вам задуматься, а в каком мире мы собственно живём. Теперь зомбировать народ будет ещё проще.
> Без установки дров, без мытарства по торрентам и помойкам, игры идут к
> вам, чтобы зохавать ваш мозг и не дать вам задуматься, а
> в каком мире мы собственно живём. Теперь зомбировать народ будет ещё
> проще.В смысле? Я что-то слабо верю, что это чудо запустится у вас, если у вас стоят обычные дрова без поддержки ускорения...
> Внесённые за последние 12 месяцев оптимизацииОфигеть, простите. А знакомый перец собрал игру под NaCl за полчаса...
Это еще что! Я кубик Рубика за 3 минуты собираю
Офигеть, прости, но ты путаешь тёплое с мягким. 12 месяцев вносили оптимизации в asm.js, а не движок Unreal 4, для его работы на asm.js.
> Офигеть, прости, но ты путаешь тёплое с мягким. 12 месяцев вносили оптимизации
> в asm.js, а не движок Unreal 4, для его работы на asm.js.Да, сначала создали себе проблемы путем использования JS а потом 12 месяцев дрючились с их решением. Малацца.
зато тушканчики теперь в восторге.
Бывают тупые люди. Они не понимают, что Unreal Engine взяли за основу для улучшения некоторых технологий, которые впоследствии пригодятся всем в других задачах. Но это не мешает им исходить сарказмом и капать ядом. Таких людей обычно не любят. Получайте заслуженный минус.
> людей обычно не любят. Получайте заслуженный минус.А мне пофиг. Я всего лишь прикалываюсь над бакланами которые пытаются микроскопом гвозди забивать вместо того чтобы пойти и взять кувалду.
> Да, сначала создали себе проблемы путем использования JS а потом 12 месяцев
> дрючились с их решением. Малацца.Да, сначала создали себе проблему путём использования Си, а потом 26 лет дрючились с их решением в gcc. Малацца.
глупости говоришь. и сам знаешь, что глупости.
> глупости говоришь. и сам знаешь, что глупости.Это была ирония, бро. Причём достаточно идиотски звучащая, чтоб её не спутать с реальным мнением. Мой наезд на Си не менее безоснователен, чем его на asm.js и немного ниже я написал почему.
извини, старею, без тэга уже никак.
> Да, сначала создали себе проблему путём использования Си, а потом 26 лет
> дрючились с их решением в gcc. Малацца.Си чем не угодил? Он то как раз на своем месте. А вот JS для игродельства никогда не делался. Ну и работает все это примерно как топор плывущий по реке: за 12 месяцев усиленной долботни *уже работавший и отлаженный* движок стал подавать признаки жизни и "не очень сильно тормозить". Есть некая разница между созданием с нуля и портированием. И год на доведение порта под +1 платформу это довольно много, валв вон под Linux портирование отбабахивает быстрее, при том что там объем работ куда больше.
Да всё с Си в порядке, тем более, что в Asm.js обычно из него и собирают. Просто наезд был на компилятор asm.js, а скорость его разработки и внесения в него улучшений не имеет ничего общего с созданием порта игры на +1 платформу. 12 месяцев это не время потраченное на портирование UE4, это время потраченное на оптимизацию asm.js. Т.е. они год вносили в него оптимизации, а где-то в течение этого периода за неизвестное время «портировали» на него движок UE4 (если сборку через clang+emscripten можно назвать портированием). Это на столько же разумно, как наезжать на gcc за то, что его 26 лет разрабатывали и оптимизировали. Тем более, что asm.js позволяет создавать универсальные порты на все платформы, где работает браузер, сразу, а не создавать порты под каждую платформу в отдельности. Вообще asm.js уместнее сравнивать с виртуальными машинами вроде Java, но только пока с прямым управлением памятью так-как своего сборщика мусора у него пока нет.Ещё кстати, скорость работы кода под asm.js принято сравнивать с «нативной», но такого понятия вообще-то не существует. Существует множество компиляторов и далеко не все из них выдают достаточно быстрый код. asm.js принято сравнивать со скоростью работы того же кода, собранного clang (в виду того, что си компилируют в asm.js при помощи clang+emscripten). Если тот же код собрать через gcc, то в некоторых случаях он будет работать быстрее, а в некоторых — медленнее, чем код собранный clang (в основном быстрее). А ведь существуют и другие компиляторы, и если их добавить в тесты, то может оказаться, что код собранный asm.js быстрее как минимум части из них. Так он тормозной? А это смотря с чем сравнивать. Собственно даже в сравнении с clang он в одном случае показал практически идентичный результат, а в ещё одном даже лучший, чем у clang. Со временем они ещё более приблизятся к clang, а сам clang к gcc, но на это уйдут годы и это совершенно нормально.
Нынче 67% - скорость близкая к нативной? Эх, где те времена, когда каждый такт выжимали...
> Эх, где те времена, когда каждый такт выжимали...Ностальгия… мы тогда с другом изобрели алгоритм построения линии, который давал 7-10 тактов на точку, не столь точный, как Брезенхема (200-500 тактов на точку), но на тех машинках это было существенным прорывом
А ещё можно в исходники старых игр позаглядывать и подивиться ухищрениям, на которые порой приходилось идти разработчикам, чтобы выжать побольше производительности, запихать побольше красивостей в более чем скромные по нынешним меркам объёмы памяти и т.п..
Поставка через браузер, это конечно, новый концепт.
А что делать с современными играми, которые занимают гигов эдак сорок?
Опухнешь тянуть.
А для нынешних разработчиков человек, который не подключен к инету - низшее существо. Особенно этим гугль грешит.
> Особенно этим гугль грешит.Конечно, ведь люди, у которых нет инета, [по определению] не могут смотреть интернет-рекламу. А такие люди гуглу не нужны.
О таких пока никто и не говорит. Может со временем, но не сейчас. А просто тянуть целиком и играть локально в том же Стиме как-то никто не опухает. Если сделать нормальное локальное хранилище для файлов, то и через браузер таких мамонтов доставлять можно будет.
у adobe была подобная технология которая при должном внимании развилась бы и до 3д. Вместо этого они купили flash, а технологию убили
Adobe FLASH - давний интернет-троян...