Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Красиво, ИМХО
Все это клево. Единственное что портит игру — это управление… нет мауслука… для управления взглядом приходится кнопку нажимать.
Автор демки уже интегрировал кое какое управление с дойстика, но из-за зоопарка браузеров и незаконченого API у меня с логитековским рулем не заработало.
Если нажать кнопку и увести мышь за пределы окна а потом отжать — получаете урезанный мауслук)
Мауслук? Так зажми ЛКМ и верти как хочешь. Всё есть ;)
Жду, когда появится возможность захвата мыши мыши в таких приложениях.
Причем сначала будет запрашиваться разрешение у пользователя (по аналогии с определением местоположения, полноэкранного режима и т.д.).
Причем сначала будет запрашиваться разрешение у пользователя (по аналогии с определением местоположения, полноэкранного режима и т.д.).
Уже пилиться, кстати.
Кое-какая инфа:
Кое-какая инфа:
Pepper and JavaScript apps can programmatically obtain mouse lock after full screen has been entered
For trusted sites, full screen is entered without a user prompt to confirm.
For untrusted sites full screen is entered and the user is prompted (see strings below). Mouse lock will not be possible until the user confirms fullscreen.
Attempts to lock the mouse prior to this will immediately fail.
Единственное, что портит игру:
1. Грузится 10 минут.
2. Ещё 10 минут она компилит чего-то там.
3. Страшно дрыгается экран, как в бешеном припадке.
4. На моём браузере она не работает, приходится качать (устанавливать и енаблить WebGL) на более другом.
Резюме: для просто попробовать WebGL подходит, для реального коммерческого применения — нет.
1. Грузится 10 минут.
2. Ещё 10 минут она компилит чего-то там.
3. Страшно дрыгается экран, как в бешеном припадке.
4. На моём браузере она не работает, приходится качать (устанавливать и енаблить WebGL) на более другом.
Резюме: для просто попробовать WebGL подходит, для реального коммерческого применения — нет.
FF 10 Win 7 не работает.
В лисе не заработала правда, а в хроме вроде ниче. Графика понравилась!
А это он так в портал прыгнул ссылка :))
А это он так в портал прыгнул ссылка :))
Браузер не умеет хватать мышь. Тут нужно или установка её координат яваскриптом или круговое замыкание пространства. Пока это не будет — с шутерами на webGL будет хреново. Но явно введут уже хотя бы для этого.
А в квейке этом какая-то полная жопа с коллизиями. В хроме раз 5 респаунился из-за того что не мог выйти из стены.
А в квейке этом какая-то полная жопа с коллизиями. В хроме раз 5 респаунился из-за того что не мог выйти из стены.
А если на body повешать mousemove, м? :) не спасёт?
Эту проблему решает Mouse Lock API. Кажется, в Хроме он уже работает.
В этом квейке ничего кроме графики не портанули, поэтому коллизии, идиотское перемещение и т.д.
Прикольно, но с мышкой еще надо поработать. Ну и поддержку в частности кваки этой не только хромом хотелось бы.
Жуть какая. 30-40 фпс в маленьком окошке, в то время как нативный квейк в 1920х1200 выдает под 400 фпс.
Я вот не понимаю: неужели неочевидно, что джаваскрипт не годится для таких тяжелых вещей?
Я вот не понимаю: неужели неочевидно, что джаваскрипт не годится для таких тяжелых вещей?
А вы про nodejs когда-нибудь слышали? А слышали-ли вы, то что можно на таком nodejs поставить?
Странные у вас сравнения. В nodejs большую часть процессорного времени занимает работа, которая выполняется таки в нативном коде, как пример — регулярные выражения и общение с БД. Вы же не пишете на джаваскрипте парсер регулярок?
А тут как раз таки все вычисляется на js. Я думаю, глупо спорить с тем, что скриптовые языки в разы (а иногда, как в данном случае — почти на порядок) оказываются медленнее грамотного кода на С, на котором был написан ку3
А тут как раз таки все вычисляется на js. Я думаю, глупо спорить с тем, что скриптовые языки в разы (а иногда, как в данном случае — почти на порядок) оказываются медленнее грамотного кода на С, на котором был написан ку3
Ну а ядро nodejs поставлено на чём? Оно поставлено на браузерном JS движке. Я думаю, что вы не допонимаете того, что делает браузер с JS, он работает с кодом точно так-же как и nodejs.
Где я утверждал обратное? Я к тому, что на nodejs никто не реализует сложные алгоритмы — это попросту нерационально.
Помоему мы друг друга недопонимаем. Я к тому, что и у nodejs и в браузере один и тот-же (V8) JS движок, который компилирует код в нативный код, для той или инной машины. Поэтому утверждать, что скорость JS медленна я бы нестал. Причина может быть в ботлнеках на разных уровнях архитектуры или по другим причинам.
И это только прототип. Если сделать полный порт и поставить в игру несколько ботов, то фпс спокойно и до 15-20 опустится, полагаю. Ну и кому такое надо? Вот Гугл это понял и пилит свой NaCl, за что им респект и уважуха. Ибо, право, поднадоело портирование всего чего ни попадя на js с многократным падением производительности
Вы правы, что производительность меньше гораздо, но компьютеры совершенствуются все быстрей, через пару лет, я думаю, можно будет спокойно портировать скайрим на js и он не будет тормозить на современных компьютерах. Вот, например, эта квака дает у меня стандартные 60 фпс. Конечно скользкий вопрос — «зачем???», но и на него найдутся ответы :-)
Вы так говорите, как будто они выпустили новую великолепную игру и продают её за бешеные деньги, но написали на JS. Это ведь делается только для демонстрации возможностей, ну и just for fun.
Я говорю о перспективах js (и WebGL) в геймдеве в целом. И эта демка — очень показательный пример. Как just for fun — безусловно интересная работа, хоть и безсмысленная
Вы сноб.
Нет, я просто не понимаю лютого восторга в посте и комментах, типа «игрушка показывает отличный показатель fps». Это ведь банальная неправда.
У меня стабильные 63 FPS. Работает плавно, четко, без тормозов. В браузере. Без Flash. Это вызывает восторг. А вы — сноб.
И вас ни разу не смущает, что оно работает в 8-10 медленнее, чем нативная версия? Пост у меня тоже вызвал восторг, до тех пор, пока я демку не запустил. Даже падение фпс в 2-3 раза я бы простил, но это уже за гранью добра и зла, а в реальной баталии от ваших 63 фпс осталось бы и того 20, что совершенно никуда не годится. Нормальных сетевых шутеров вроде того же квейка на js не предвидится именно по этой причине, а не потому, что я такой сноб и зануда. Не надо игнорировать факты просто потому, что вам так нравится идея работы этой демки без инсталляции и флеша. Не зря ведь Quake Live работает с помощью плагина в нативном коде
У меня уже из слов остались только маты. Вы сделайте также, а потом глотку рвите.
Сперва добейся, ага. У вас аргументы есть иные, кроме как «это круто»? Я довольно много времени в прошлом провел с программированием 3Д и прекрасно представляю, о чем говорю. 63 фпс при рендеринге голой карты с простыми коллизиями — это медленно. Адски медленно.
Вот приходите вы на собеседование в %companyname% как JS-dev и говорите: «Я тут игрушку сделал, вот можете посмотреть. Возьмете меня работать?». Вы думаете, что вам ответят «Нет, 63 FPS — это медленно»?
Ну во-первых, это лишь демка рендеринга карты — выдраный из контекста кусок. Игрой тут не пахнет и близко, реальная игра покажет фпс еще раза в 3 меньше.
По сути вопроса — не скажут, еонечно же, ведь это неплохая демонстрация способностей как js-программиста. Кто ж виноват, что единственный доступный инструмент не очень подходит для такого рода проектов? Собственно, как я писал веткой выше, всю эту проблему можно решить внедрением во все браузеры чего-то типа NaCl. И тогда всем будет хорошо — и высокие фпс, и работа в браузере без посторонних примочек
По сути вопроса — не скажут, еонечно же, ведь это неплохая демонстрация способностей как js-программиста. Кто ж виноват, что единственный доступный инструмент не очень подходит для такого рода проектов? Собственно, как я писал веткой выше, всю эту проблему можно решить внедрением во все браузеры чего-то типа NaCl. И тогда всем будет хорошо — и высокие фпс, и работа в браузере без посторонних примочек
Какая разница какой язык? Всё-равно основные вычисления ложатся на видяху и OpenGL API, а там хоть Asm, хоть Си, хоть JavaScript, хоть QBasic.
А квака работала хорошо в силу кучу мелких оптимизаций. Человек просто написал игру. Если по ней нескольким людям пройтись пару раз профайлером, то получим пятикратное ускорение и скорость, приближающуюся к Си-шному варианту.
А квака работала хорошо в силу кучу мелких оптимизаций. Человек просто написал игру. Если по ней нескольким людям пройтись пару раз профайлером, то получим пятикратное ускорение и скорость, приближающуюся к Си-шному варианту.
Всё-равно основные вычисления ложатся на видяху и OpenGL API
С каких это пор? Все вычисления и обработка происходит на стороне CPU. Видеокарта в данном случае тупо рисует массив треугольников с наложенными на них текстурами. Если бы всё было так, как вы говорите, то производительность была бы гораздо больше. Квейк3 вообще был довольно простой и прямолинейный в плане рендеринга. А тут это выливается в очень большие оверхеды на общение между JS и OpenGL API.
И да, еще раз — он не написал игру. Он нарисовал рисовалку карт формат Квейка 3, не более. Это на несколько порядков более простая задача, чем написать игру
С каких это пор? Все вычисления и обработка происходит на стороне CPU. Видеокарта в данном случае тупо рисует массив треугольников с наложенными на них текстурами. Если бы всё было так, как вы говорите, то производительность была бы гораздо больше. Квейк3 вообще был довольно простой и прямолинейный в плане рендеринга. А тут это выливается в очень большие оверхеды на общение между JS и OpenGL API.
И да, еще раз — он не написал игру. Он нарисовал рисовалку карт формат Квейка 3, не более. Это на несколько порядков более простая задача, чем написать игру
Ложатся ложатся.
Просто во времена Ку3 никаких шейдеров не было, и во времена Дума3 их тоже по сути еще не было.
Сейчас многое можно сделать по другому.
А 63 кадра для JS это очень хорошо.
Даже 20 кадров — это очень хорошо.
Уж больно много тупняков сидит в самих браузерах мешающих js работать.
Просто во времена Ку3 никаких шейдеров не было, и во времена Дума3 их тоже по сути еще не было.
Сейчас многое можно сделать по другому.
А 63 кадра для JS это очень хорошо.
Даже 20 кадров — это очень хорошо.
Уж больно много тупняков сидит в самих браузерах мешающих js работать.
И какие же такие вычисления тут, по вашему мнению, ложатся на видеокарту?
А их тут по сути два — T&L+Кривая анимация моделей ку3(keyframe+скелет) — уходят полностью.
BSP можно загрузить и выкинуть сразу. Деревья на js не работают.
Остается тупой брутальный рендер.
BSP можно загрузить и выкинуть сразу. Деревья на js не работают.
Остается тупой брутальный рендер.
И вы думаете, T&L тормозит весь процесс на современных видеокартах? В 99 году и то проблем не было.
А в чем проблема с реализацией BSP-дерева на js?
А в чем проблема с реализацией BSP-дерева на js?
Я не говорил что тормозит. Я на самом деле намекал что рендер уровня Q3 может состоять из двух комманд.
1. Настройка матрицы
2. Вызов displayList
Про BSP, как и _любые_ другие деревья я скажу просто — без возможности влиять на расположение нод в памяти нет возможности сделать быстрое дерево.
mm_prefetch и другие 16 байтные офсеты на листья.
В частности я не знаю ниодной реализации деревьев на js которые «имели бы смысл»
1. Настройка матрицы
2. Вызов displayList
Про BSP, как и _любые_ другие деревья я скажу просто — без возможности влиять на расположение нод в памяти нет возможности сделать быстрое дерево.
mm_prefetch и другие 16 байтные офсеты на листья.
В частности я не знаю ниодной реализации деревьев на js которые «имели бы смысл»
В уровнях Q3 дофига всяких динамических текстур. И они пересчитываются всё время. Небо то же… Так что вычислений на JS там предостаточно, и тупо поместить всю геометрию, скажем, в VBO, не выйдет
Кто пересчитывается?
Где?
Какой атрибут в шейдере( для публики — файл описания материала в Q3) за это отвечает?
Где?
Какой атрибут в шейдере( для публики — файл описания материала в Q3) за это отвечает?
Ну вот например
Тут — вращение (rotate) и расстягивание (stretch) текстуры. а glRotate и glScale выполняются целиком на CPU даже на видеокартах с аппаратным блоком T&L
{
clampmap textures/sfx/bullseye.tga
tcMod stretch sin .8 0.2 0 .2
tcmod rotate 200
blendFunc add
rgbGen identity
}
Тут — вращение (rotate) и расстягивание (stretch) текстуры. а glRotate и glScale выполняются целиком на CPU даже на видеокартах с аппаратным блоком T&L
> И вас ни разу не смущает, что оно работает в 8-10 медленнее, чем нативная версия?
Наверняка в WebGL версии тупо включен VSync.
Наверняка в WebGL версии тупо включен VSync.
За возможность играть в игры, не возясь с установкой многие склонятся в сторону JS. Сейчас браузеры делают то, что так и не сумела сделать Java, Flash и все остальные технологии — стать по-настоящему кросс-платформенной.
Для простеньких казуалок JS — это действительно классно. Но не для динамичных шутеров, в которых FPS — залог играбельности, особенно в мультиплеере.
А в чем, по-вашему, выражается неполная кроссплатформенность Java и Flash? Вроде как они есть везде, где можно
А в чем, по-вашему, выражается неполная кроссплатформенность Java и Flash? Вроде как они есть везде, где можно
Покажите мне deb'ку для java. Раньше были в дистрибутиве, но усилиями oracle по смене лицензии — теперь их нет. На офф. сайте deb'ок тоже нет.
Кросс-платформенное, да. Кое-как, со скрипом. Мне легче виндовое приложение запустить под wine'ом, чем возиться с ихним тарболом под линукс.
«FPS залог играбельности» — вопрос только в том, как оно написано и как быстро железо. И то и то устранимо. До выхода quake3 была масса 3D шутеров с меньшими требованиями и они были более чем успешны.
В этих условиях лично моё убеждение — как только проблемы роста закончатся, игры стремительно начнут переползать в браузеры. Хотя бы потому, что это тот самый легендарный SaaS, который должен будет решить проблемы пиратства, проблемы совместимости с железом и системами и т.д.
Кросс-платформенное, да. Кое-как, со скрипом. Мне легче виндовое приложение запустить под wine'ом, чем возиться с ихним тарболом под линукс.
«FPS залог играбельности» — вопрос только в том, как оно написано и как быстро железо. И то и то устранимо. До выхода quake3 была масса 3D шутеров с меньшими требованиями и они были более чем успешны.
В этих условиях лично моё убеждение — как только проблемы роста закончатся, игры стремительно начнут переползать в браузеры. Хотя бы потому, что это тот самый легендарный SaaS, который должен будет решить проблемы пиратства, проблемы совместимости с железом и системами и т.д.
Ну, Crysis пока, наверное, не получится, а вот вместо флешовых казуалок — самое то. Например для Chrome есть годная гоночка на WebGL + злые птички для Кроума тоже на вебгл вроде.
Прикольно, но имхо поиграть в такое не получится, много проваливался в текстуры, поворачивать не удбно. Тестировал за слабым компом (обычный квейк нормально идёт) увидел fps 4. WeGl хорошая вещь но имхо пока сыровата для полноценных игр
Следующим шагом, надеюсь, будет порт Half-life на WebGL :)
Видел эту демку полтора года назад и изменений кроме улучшенной производительности не заметил.
У Брендона еще есть карта из Quake2 и анимированная модель из Doom3.
У Брендона еще есть карта из Quake2 и анимированная модель из Doom3.
За 7 минут так и не загрузилось. Устал ждать :)
Вы шутите? Выглядит впечатляюще и работа хорошая, но Quake 3 здесь и не пахнет, по факту это всего лишь перемещение камеры по трехмерному миру, чем-то напоминающему Quake 3. Ни квейковского движка, ни оружия, ни пуль, никаких эффектов.
60 FPS, судя по кулеру, загрузка меньше 30%
Погонял на Logitech 510. Единственное что иногда заклинивает, и приходится респаунится.
Погонял на Logitech 510. Единственное что иногда заклинивает, и приходится респаунится.
Сколько раз на разных браузерах и разных системах ни пробовал, виснет на tesselating face 157 of 3358. Куда нажать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Quake 3 beta на WebGL