ТС, я категорически с вами не согласен. Фулстек это просто термин обозначающий компетенции во фронте (мобайле) и беке, а не философия. Но за то что так доходчиво и развёрнуто поделились своим видением — жирный плюс.
5) фулстеки-одиночки задействованы на MVP. В одно лицо гораздо проще быстрее и дешевле сделать MVP. Да, БД будет не оптимизирована, вместо вёрстки бутстрап и прочие недостатки. НО без стендап митингов, согласований между командами, и прочего, MVP будет готов через неделю, а не месяц. А потом, если MVP «зайдёт» можно выделить фронтов с дизанеромам, беков с девопсами, аналитиков и запилить уже полноценный проект по этим вашим скрамам с аджайлами.
Время на отправку инпут данных, обработку на сервере, получение кадра обратно — сравнимо с временем рендера кадра локально. И это время меньше чем длительность отображения 1го кадра при 60FPS
Это значит что Stadia технически способна выдавать производительность не ниже PS4.
60FPS — это мировой стандарт фреймрейта для игр. Пусть он вас и не устраивает.
В зуево-кукуево на ADSL сервисом не воспользуешься нормально. Никто и не заявлял поддержки в деревнях и весях. в Мегаполисах и просто крупных городах у гугла всё в порядке с наличием серверов
видимо да. я как раз на себе застал переход от CRT к LCD и ожидал что 4ms это именно частота развёртки, ведь ощущения при взгляде на такой монитор сродни взгляду на CRT с 120+Гц. Но судя по всему это связано с другой физикой процесса отрисовки кадра
Это никак не минимум от рендера которому вы зачем-то его приравняли. Это минимально возможное время показа следующего кадра при 60FPS. Это ваша проблема, что вы не можете нормально прочитать 1 абзац текста на английском
Minimum theoretical input lag for the overall system означает, что даже если у нас игра работает локально, под капотом топовое железо с двумя TITAN V в SLI выдающие по кадру в 1ms, но монитор 60Hz — то мы всё равно 17ms будем наблюдать один и тот же кадр. И только после этих 17ms следующий
вы неправильно его прочитали (:
17ms — время между первым и вторым кадром при 60FPS
система не зависает на эти 17ms в это время она кадр рисует, считает, общается по сети и т.п.
Задача любой игровой платформы (софт/железо) — успеть подготовить следующий кадр за эти 17ms.
где вы взяли 17ms минимум от рендера? вы эти 17ms сами придумали (:
17ms — задержка между двумя кадрами при 60FPS. Если кадр не нужно вычислять — обычная современная видеокарта может выдавать намного больший FPS. просто 60 — приятный для глаз минимум, на который и оперируются все существующие производители железа и софта.
5-10ms — идут в то же время в которое 1 кадр показывается на экране. Точнее занимают ~половину этого времени.
Расходы на обработку ввода уже включены в эти 5-10ms (обычная периферия имеет задержку в десятые доли ms. а геймерские вообще в сотые)
Расходы на обработку кадра — это как раз ~8ms — оставшаяся половина от наших 17ms.
И если даже топовая домашняя игровая карта на 1080p может выдать сотни FPS — условно 3ms на генерацию кадра, то сколько нужно тому зверю от AMD который Stadia имеет в своих ЦОДах?
Ещё раз хронология кадра с учётом пинга в 10ms
0 — пользователь нажимает на кнопку
0,1ms — обработка нажатия кнопки системой
5,1ms — данные долетели до сервера Stadia
6,1ms — сервер обработал кадр (за условные 1ms, хотя можно быстрее)
11,1ms — кадр вернулся в девайс пользователя
11,2ms — кадр готов к выводу на монитор
Какой смысл смотреть на частотность развёртки монитора? Мы же говорим о частоте кадров!
Самая топовая консоль PS4Pro выдаёт максимум 60FPS. а обычная сонька на 1080p вполне себе и до 30 опускается.
Частота монитора — это совершенно другая тема, которая практически не затрагивает игровой FPS уже лет 20 как.
давайте ещё раз посчитаем
У нас есть ~10ms задержка между отправленным инпутом и полученным кадром. У сервера есть ещё вплоть до 7ms на вычисление этого кадра.
Мощность сервера «запредельная» + варьируемая, так что для людей с низким ~5ms пингом можно кадр считать дольше, а для людей с высоким ~10 — нужно считать быстрее. И то и то вполне себе реальные сегодняшние цифры, а не взятые откуда-то из будущего.
P.S. Может для вас, обладателя двух Nvidia TITAN V в SLI, не признающего FPS ниже 150, Stadia не зайдёт. Но нам обычным людям — более чем.
A videogame console or PC will send out a new frame once it has finished performing the necessary calculations to create it. The rate at which this is achieved is measured with the frame rate. Using common 60 Hz monitor as an example, the maximum theoretical frame rate is 60 FPS (frames per second), which means the minimum theoretical input lag for the overall system is 17 ms (1 second/60FPS).
У Stadia заявлена поддержка именно 60FPS. Технически возможно получить лаг в 1 кадр. Это отнюдь не «ОЧЕНЬ много».
у меня пинг до сервера моего провайдера ~10ms
это совсем не 200мс о которых идёт речь.
тут же суть в ОГРОМНОМ количестве серверов которые рядом с каждым из пользователей
Многие продукты загибались из-за попытки выйти раньше своего времени.
Но игры через видеостриминг уже давно ждали своего большого релиза. Технологии уже есть, аудитория есть. Все знали что когда-то это появится. Даже если у гугла не выйдет — выйдет у FB, или Amazon, или у Valve(Steam).
Не удивлюсь если кто-то из них сейчас рвёт волосы на голове с наполовину готовым аналогичным продуктом.
В первую очередь хотелось бы сказать ловите наркомана
А во-вторую: если это пустит JS разработчиков в embeded сегмент — то очень даже клёво. Разумеется это будет совершенно не так производительно как аналоги, но она далеко не везде нужна.
А сама проблема лежит глубже — REST смешивает транспортный и прикладной уровень, и подход "200 на все" эту проблему решает (правда, делая REST не нужным вообще).
а к чему это тогда? используйте RPC или что вам ближе. Топик всё-же про REST. и выбирая его как протокол взаимодействия всё же стоит придерживаться рекомендаций этого стандарта.
А так да, вас никто не держит за руки. Кто-то пилит псевдо-REST через одни POST запросы, передавая {type: GET|POST|UPDATE|etc} в теле. Кто-то отдаёт 200 на всё, даже ошибки. Кто-то делает 1 ендпоинт а все параметры переносит в query аля GET: /api/users/:id/books/ -> /api?model=users&id=:id&field=books. Каждый строчит как он хочет
Но когда я начинаю работать над уже существующим проектом, я молюсь чтобы авторы легаси использовали стандарты а не своё "видение". Ибо "видение" очень часто в итоге превращается в боль
Это значит что Stadia технически способна выдавать производительность не ниже PS4.
60FPS — это мировой стандарт фреймрейта для игр. Пусть он вас и не устраивает.
Времена CRT прошли уже давно
Это никак не минимум от рендера которому вы зачем-то его приравняли. Это минимально возможное время показа следующего кадра при 60FPS.
Это ваша проблема, что вы не можете нормально прочитать 1 абзац текста на английском
Minimum theoretical input lag for the overall system означает, что даже если у нас игра работает локально, под капотом топовое железо с двумя TITAN V в SLI выдающие по кадру в 1ms, но монитор 60Hz — то мы всё равно 17ms будем наблюдать один и тот же кадр. И только после этих 17ms следующий
17ms — время между первым и вторым кадром при 60FPS
система не зависает на эти 17ms в это время она кадр рисует, считает, общается по сети и т.п.
Задача любой игровой платформы (софт/железо) — успеть подготовить следующий кадр за эти 17ms.
17ms — задержка между двумя кадрами при 60FPS. Если кадр не нужно вычислять — обычная современная видеокарта может выдавать намного больший FPS. просто 60 — приятный для глаз минимум, на который и оперируются все существующие производители железа и софта.
5-10ms — идут в то же время в которое 1 кадр показывается на экране. Точнее занимают ~половину этого времени.
Расходы на обработку ввода уже включены в эти 5-10ms (обычная периферия имеет задержку в десятые доли ms. а геймерские вообще в сотые)
Расходы на обработку кадра — это как раз ~8ms — оставшаяся половина от наших 17ms.
И если даже топовая домашняя игровая карта на 1080p может выдать сотни FPS — условно 3ms на генерацию кадра, то сколько нужно тому зверю от AMD который Stadia имеет в своих ЦОДах?
Ещё раз хронология кадра с учётом пинга в 10ms
0 — пользователь нажимает на кнопку
0,1ms — обработка нажатия кнопки системой
5,1ms — данные долетели до сервера Stadia
6,1ms — сервер обработал кадр (за условные 1ms, хотя можно быстрее)
11,1ms — кадр вернулся в девайс пользователя
11,2ms — кадр готов к выводу на монитор
Самая топовая консоль PS4Pro выдаёт максимум 60FPS. а обычная сонька на 1080p вполне себе и до 30 опускается.
Частота монитора — это совершенно другая тема, которая практически не затрагивает игровой FPS уже лет 20 как.
давайте ещё раз посчитаем
У нас есть ~10ms задержка между отправленным инпутом и полученным кадром. У сервера есть ещё вплоть до 7ms на вычисление этого кадра.
Мощность сервера «запредельная» + варьируемая, так что для людей с низким ~5ms пингом можно кадр считать дольше, а для людей с высоким ~10 — нужно считать быстрее. И то и то вполне себе реальные сегодняшние цифры, а не взятые откуда-то из будущего.
P.S. Может для вас, обладателя двух Nvidia TITAN V в SLI, не признающего FPS ниже 150, Stadia не зайдёт. Но нам обычным людям — более чем.
17ms — это лаг в 1 кадр. Это вообще теоретически минимальный возможный лаг для игры на 60FPS
У Stadia заявлена поддержка именно 60FPS. Технически возможно получить лаг в 1 кадр. Это отнюдь не «ОЧЕНЬ много».
это совсем не 200мс о которых идёт речь.
тут же суть в ОГРОМНОМ количестве серверов которые рядом с каждым из пользователей
Но игры через видеостриминг уже давно ждали своего большого релиза. Технологии уже есть, аудитория есть. Все знали что когда-то это появится. Даже если у гугла не выйдет — выйдет у FB, или Amazon, или у Valve(Steam).
Не удивлюсь если кто-то из них сейчас рвёт волосы на голове с наполовину готовым аналогичным продуктом.
В первую очередь хотелось бы сказать ловите наркомана
А во-вторую: если это пустит JS разработчиков в embeded сегмент — то очень даже клёво. Разумеется это будет совершенно не так производительно как аналоги, но она далеко не везде нужна.
я тоже не могу прочитать первое слово заголовка без тупой улыбки в стиле
а к чему это тогда? используйте RPC или что вам ближе. Топик всё-же про REST. и выбирая его как протокол взаимодействия всё же стоит придерживаться рекомендаций этого стандарта.
А так да, вас никто не держит за руки. Кто-то пилит псевдо-REST через одни POST запросы, передавая
{type: GET|POST|UPDATE|etc}в теле. Кто-то отдаёт 200 на всё, даже ошибки. Кто-то делает 1 ендпоинт а все параметры переносит в query аляGET: /api/users/:id/books/->/api?model=users&id=:id&field=books. Каждый строчит как он хочетНо когда я начинаю работать над уже существующим проектом, я молюсь чтобы авторы легаси использовали стандарты а не своё "видение". Ибо "видение" очень часто в итоге превращается в боль
согласен. я думаю что мой подход стоит пересмотреть.
но ваш подход вносит гораздо больше неопределённости и излишнего усложнения, по причинам которые я расписал выше.