Сервис OnLive - революция подкралась незаметно

[S!N]

   OnLive — система цифровой дистрибуции компьютерных игр, интернет-сервис, использующий концепцию облачных вычислений, седьмое поколение игровых приставок. Система OnLive была анонсирована на международном мероприятии Game Developers Conference 2009. Разработкой и поддержкой сервиса занимается одноименная компания OnLive совместно с дочерним предприятием «Mova». Сама же компания OnLive является дочерным предприятием венчурной компании Rearden. Сервис OnLive является игровым эквивалентом облачных вычислений: игра располагается и обрабатывается на стороне удалённого сервера, а пользователям поставляются лишь результирующие данные (видео и звук) через интернет-соединение.
При использовании сервиса OnLive такие неотъемлемые явления индустрии компьютерных игр, как несанкционированное копирование игр и читерство в сетевых играх, станут невозможными.

Полный вариант статьи здесь. Обязательно прочитайте!


На создание темы, натолкнул просмотр часовой презентации этого сервиса, где на престарелом ноутбуке играли в Crysis на ультра качестве. Все это кажется нереальным и ненужным, но дело в том, что разработка велась с 2002 года в строжайшей секретности, и только сейчас, когда по сути все готово к массовому запуску, систему показали всему миру. Бета-тест начнется уже в середине этого лета. Жаль мы не сможем поучаствовать, сказываются ограничения в расстоянии от сервера до абонента.

[k1T4eR]

Если скорость интернет соединения с зарубежом в норме, то о таком варианте стоит говорить, но если она не достаточная, то зачем использовать такой сервис, ну разве что при недостатке производительности ПК!
ЗЫ Проголосовал за Мне нравится идея, но я все же за "дедовский метод", так как эту систему надо ещё усовершенствовать, но для начала уже неплохо...

[Edd.Dragon]

Жаль мы не сможем поучаствовать, сказываются ограничения в расстоянии от сервера до абонента.

Если бы он был ближе, большинство все-равно не смогло бы из-за узких каналов ))) Это ж какой минимально канал нужен, чтобы получать 30-50 fps Кризиса без потери качества!

При использовании сервиса OnLive такие неотъемлемые явления индустрии компьютерных игр, как несанкционированное копирование игр и читерство в сетевых играх, станут невозможными.

Ну это они в слишком далекое будущее заглянули. До такого кол-ва дешево продаваемых централизованных мощностей, которые смогли бы обеспечить бОльшую часть игроков - еще ого сколько...

[S!N]

Если скорость интернет соединения с зарубежом в норме, то о таком варианте стоит говорить...

дело в том, что это пока "с зарубежом", в последствии это будет наподобии базовых станций сотовых операторов, но щоб стояв у кожний хати прежде, чем это получит всемирное рампространение, пройдет несколько лет, минимум, да и в последствии я думаю 2 метода будут сосуществовать.

[k1T4eR]

дело в том, что это пока "с зарубежом", в последствии это будет наподобии базовых станций сотовых операторов, но щоб стояв у кожний хати прежде, чем это получит всемирное рампространение, пройдет несколько лет, минимум, да и в последствии я думаю 2 метода будут сосуществовать.

Всёравно широкий канал нужен будет, да и потом, у нас такие сервера появятся только через несколько лет полсе появления зарубежом, а желающих поиграть в игры через такой способ будет ой как не мало!

[S!N]

Если бы он был ближе, большинство все-равно не смогло бы из-за узких каналов ))) Это ж какой минимально канал нужен, чтобы получать 30-50 fps Кризиса без потери качества!

Для игры с 640х480 на телике хватит 1,5 мегабитного канала, для игры в HDTV необходимо 5 мегабит. Даже у нас в Украине это уже не редкость. Более того, эти требования к каналу указаны по сути максимальные, то есть расчитаные на пиковую загрузку, большую часть времени будет требоваться скорость намного ниже.

Я бы вам залил часовую презентацию с русской озвучкой, но это как бы пиратство, т.к. ролик с Игромании.
Посмотрите на ютубе сами.

[Ivanko1]

Мне нравится идея, но я все же за "дедовский метод"
Всё-таки широкополосный доступ в Украине в абсолютном меньшинстве.

[Edd.Dragon]

большую часть времени будет требоваться скорость намного ниже.

Да щаз. Покалькулируй

1280х1024х32bit = 1280х1024х4 байта = 5 метров (1 кадр). 150 метров - 1 сек в 30fps. 150 метров = 1200 мбит! Даже если ты будешь сжимать этот видеопоток без потери качества в 10 раз в среднем, то получишь требование - 120 мбит в среднем.

А 5 мбит со звуком и в HD-разрешения - это неплохого качества фильма в 25 fps. При этом артефакты сжатия видны на глаз. О высокой "кристальности" картинки, к которой мы привыкли в играх, и речи быть не может. Кстати игровые видеозаписи жмутся куда хуже обычного кино, т.е. в 5 мбит при большом разрешении для огромного кол-ва игр мы получим ужаснейшую картинку!

В итоге, тебе куда приятнее будет играть с плохими настройками силами своего ноута, чем получать ультра-хай в битрейте 5 мбит. По крайней мере, уровень вкусности картинки что так, что так - низкий. Разве что, невкусность при этом разного толка - там настройки низкие, а тут из-за сжатия потеряна резкость, динамичность и детали, заменные на артефакты сжатия

Посмотрите на ютубе сами.

Скриншоты бы посмотреть

[Phantom of the Opera]

<<Мне нравится идея, но я все же за "дедовский метод">>
Для нас це ще неблизьке майбутнє. В нас поки ще побудують ті серверні особняки
А на рахунок працездатності технології - так скоро побачимо, бета-тест в Америці вже скоро почнеться. Розробникам ігор це вигідно, оскільки в піратів будуть дуже серйозні проблеми. Може за рахунок зменшення піратства і збільшення доходів ігри подешевшають
А поки в нас це почнеться, інтернет вже буде достатньо швидким у більшості. Та і аренда гри на день за менші гроші - можливість досхочу напробувати купу проектів за ті самі гроші.

[k1T4eR]

Розробникам ігор це вигідно, оскільки в піратів будуть дуже серйозні проблеми. Може за рахунок зменшення піратства і збільшення доходів ігри подешевшають

За то нам не очень выгодно! Чтобы играть в такие игры нужен безлимит - безлимит чаще всего в час пик очень загружен, плюс ещё к тому что все начнут в такие игры играть, изза этого провайдерам нужно будет начинать думать об увеличении скорости канала, соответственно поднимется плата за интернет!
ЗЫ На каждый + найдётся свой -

[Edd.Dragon]

Кстати, есть подозрения, что игрокам с большими аппетитами (в смысле проводимого за играми времени) пользование такой системой будет обходиться не меньше, чем покупка лицензионных игр для приставок.

Добавлено: 07 Червень 2009, 22:25:32

безлимит чаще всего в час пик очень загружен, плюс ещё к тому что все начнут в такие игры играть

Ну, все у нас тянут торренты, так что замена 5 мбит торрентов на 5 мбит видео ничего не изменит. Хотя... Торренты друг от друга качают, а тут - каждому свой личный поток нужен...

[S!N]

За то нам не очень выгодно! Чтобы играть в такие игры нужен безлимит - безлимит чаще всего в час пик очень загружен, плюс ещё к тому что все начнут в такие игры играть, изза этого провайдерам нужно будет начинать думать об увеличении скорости канала, соответственно поднимется плата за интернет!
ЗЫ На каждый + найдётся свой -

Еще неизвестно какая будет абонплата за сервис А учитывая "наше" пристрастие все игры качать на халяву, то большинство скажет: та ну его на...!!!
Хотя я уверен, что столько средств и времени просто так не потратили бы, и рано или поздно внедрение сервиса будет неизбежно, хотя опять же, традиционный метод распространения думаю будет тоже существовать.
А разрабы только поддержат! И вот почему, во-первых конечно же гарантия того, что игру не заполучат, не заплатив, то есть отсутствие пиратства, далее - экономия на носитилях, тиражировании и прочих сопутствующих расходах.

[Edd.Dragon]

соответственно поднимется плата за интернет!

А плата за сервис тебя не оч. интересует?

Добавлено: 07 Червень 2009, 22:28:05

и рано или поздно это будет неизбежно

Ну да, лет через 10-20 вполне возможно пойдет уклон в централизованные вычисления. При чем толчок и стимул этому не сколько игры сколько остальные вычисления будут давать. В первую очередь конечно же бизнес и наука\исследования

[k1T4eR]

Ну, все у нас тянут торренты, так что замена 5 мбит торрентов на 5 мбит видео ничего не изменит. Хотя... Торренты друг от друга качают, а тут - каждому свой личный поток нужен...

Вот-вот!

Хотя я уверен, что столько средств и времени просто так не потратили бы, и рано или поздно это будет неизбежно, хотя опять же, традиционный метод распространения думаю будет тоже существовать.

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

[pohgejib]

я за! але залежно якими будуть тарифи.
не зовсім зрозуміло в якому вигляді будем отримувати зображення. відео чи картинки?
якщо перше, то для 720р достатньо 3 мбіт/с (при Н264). а дивлячись який рівень розвитку у нас ІТ-індустрії то OnLive побачим десь через років 10-15.

[k1T4eR]

А плата за сервис тебя не оч. интересует?

Интересует, дело в том, что если цена будет такая же, что и за игры на дисках, то в этом нет никакого смысла, а если дешевле, то смысл есть, но опять таки - скорость доступа в интерент

[pohgejib]

реєстрація на http://www.onlive.com в якості бетатестера платна? чи я за 5-м разом вгадав Zip Code? 

[S!N]

не зовсім зрозуміло в якому вигляді будем отримувати зображення. відео чи картинки?

Видео. Причем по качеству практически не отличимое от обычной картинки, формируемой сигналом.

[Phantom of the Opera]

Розробники обіцяли багато різних схем оплати, а не тільки дві. Тому з оплатою не все так пасмурно.
На рахунок швидкості - так наразі орієнтовано на Америку. Там, думаю, більшість проблем з широкими каналами вирішена. Ну а добра інфраструктура інтернет-послуг в країні може бути вимогою.
На рахунок якості зображення - думаю буде як доброї якості jpeg - артефакти є, але їх не дуже видно, тим-більше в русі. Хоча, звісно, це не та якість і роздільна здатність, яка зараз є. Самому цікаво, як буде
На Україну цей сервіс і не орієнтується, тому міряти треба на реалії розвинутіших в економічному плані країн. А нам ще довго чекати

[linuxdrom]

А почему незаметно? Уже давно все знают 

Собственно пока единственный толковый комментарий тут от Edd'а. Остальные одели розовые очки, то ли от радости, то ли от незнания...
К уже названым проблемам, в виде не качественной картинки, и требовательности к пропускной способности интернет соединения, еще стоит отметить и проблему с отзывчивостью управления. Ведь, во первых, будут задержки кодирования потока, во вторых, еще и пинг до сервера OnLive.

не зовсім зрозуміло в якому вигляді будем отримувати зображення. відео чи картинки?

У вигляді презентації PowerPoint 
Відео

якщо перше, то для 720р достатньо 3 мбіт/с (при Н264)

лол

Видео. Причем по качеству практически не отличимое от обычной картинки, формируемой сигналом.

ЩИТО?

[βεερ_βooρ]

К уже названым проблемам, в виде не качественной картинки, и требовательности к пропускной способности интернет соединения, еще стоит отметить и проблему с отзывчивостью управления. Ведь, во первых, будут задержки кодирования потока, во вторых, еще и пинг до сервера OnLive.

Эти проблемы вполне решаймы на теперешний момент. Ну чисто теоретически, как минимум.

А вот не решаймая на данный момент - Cloud Computing. Это "новое веяние моды(с)" более чем 20-летней давности - время активной разработки дизайна Plan9 - середина 80-х - наало 90-х годов. А большинство пользователей до сих пор насилует Винду, которая по своему дизйна устарела даже перед Юникс, устаревание которого послужило причиной создания Plan9. Так что пока коммерция не перестанет нас отшвыривать в 70-е, облачных вычислений мы еще долго не увидим. И единичные попытки OnLive тут как капля в море. Снчала надо перейти от батареек и дизель-генераторов к электросети, а потом уже пускатьслюнки на подобные сервисы.

[linuxdrom]

Эти проблемы вполне решаймы на теперешний момент. Ну чисто теоретически, как минимум.

Чисто теоретически мы давно должны жить в идеальном мире
А чисто практически, на данный момент нет кодеков которые позволяли б кодирование потока 720р/60 с битрейтом до 4 мбит с действительно "кристальным качеством" и задержкой в 1 мсек.
Да, они пишут, что придумали такой чудо-кодек, ну вот почему я им не верю? Наверно потому, что если б они действительно изобрели кодек, превосходящий на голову все что существует сейчас, то вряд ли б ограничились его применением только в OnLive. Это просто глупо, учитывая возможную прибыль, многократно превышающую тут, что они получат с OnLive ближайшие годы.
Еще чисто практически, если б такой кодек существовал, то он должен быть очень ресурсоемким, и потому про игру на нетбуках и и прочих системах со слабым ЦПУ можно забыть. Хотя конечно можно поверить в еще одно чудо 

Так же нужны огромные аппаратные серверные ресурсы. Для обещанной производительности на каждого игрока требуется хотя бы эквивалент C2D E7*** и HD 4850. Если счет пользователей пойдет на десятки тысяч, то top500.org должен обзавестись новым лидером.

Теперь вернемся к интернетам - для нормальной работы нужно будет стабильное неразрывное соединение или с скоростью многократно превышающей 5 мб/с, нужных для передачи, или с гарантированной постоянной скоростью. И то и другое, даже в мире стоит не дешево, не то что у нас. Незадача.
Бороться с латентностью сети, вообще не получиться никаким другим способом, кроме как размещением оборудования на площадке провайдера. Что кстати позволит решить проблему и со скоростью. А пока попробуйте попинговать Санта-Кларе, Калифорнию и Виржинию 

В итоге, если поверить в чудо-кодек, и если размещать сервера OnLive на площадке провайдеров, действительно проблемы решаемы.

А вот не решаймая на данный момент - Cloud Computing.

Да, тут ты прав. Если б мы опять таки жили в идеальном мире, то старый-новый Cloud Computing уже давно б стояв у кожній хаті.

[βεερ_βooρ]

Еще чисто практически, если б такой кодек существовал, то он должен быть очень ресурсоемким, и потому про игру на нетбуках и и прочих системах со слабым ЦПУ можно забыть. Хотя конечно можно поверить в еще одно чудо

В кодек кк ни странно струдом, но поверить можно. Вы с эдом не учли одну важную особенность - картинка н экране игры не является набором пикселей. То что вы описали - вещание ХД видео Дело в том, что (с учетом развития современных ИТ-технологий) отображаемая игровая сцена и просто произвольная картинка имеет разную колмагорову сложность.

На примере:
Вместо того, то бы передать сообщение:

14159 26535 89793 23846 26433 83279 50288 41971 69399 37510

я могу сказать:

взять первые 50 знаков числа pi

Что будет намного короче.
Возможно использование колмагоровой сложности тут сильно поможет, но это очевидно тебует полной коренной переработки движка игры.(Впрочем в случае с супер-кодеком это все равно было бы необходимо). Кроме того следует учитывать рзницу в типе сцен, котоы рендеит каждая игра  т.д.

Теперь вернемся к интернетам - для нормальной работы нужно будет стабильное неразрывное соединение или с скоростью многократно превышающей 5 мб/с, нужных для передачи, или с гарантированной постоянной скоростью.

Для идеального мира это мелочь

Бороться с латентностью сети, вообще не получиться никаким другим способом, кроме как размещением оборудования на площадке провайдера.

Тут мы упираемся в то же, что и с Cloud Computing. Ethernet и пдавляющие большинство совремнных сетей исользуют коммутацию пакетов, что значительно затрудняет QoS, они практически не могут гарантировать стабильные латентность и полос передачи, они не для этого проэктировались. Кто/кому звонили поскайпу должен помнить иногда встречающиеся хаактерное "бульканье".  Основа кампуной сети КПИ построен на АТМ, которая является сетью с коммутацией ячеек. Коммутация ячеек позволяет избавится от бульканья, бспечивает гарантированый QoS и прочие. Но в КПИ естьвысококвалифицировный песонал, который может поддерживть это довольно сложное и дорогое решение. А абсолютное большинство админов про АТМ вообще не слышали, они жауются что их грузят в институте ненужным матаном и не уат обжимать витую пару(все желающие отправляются в поиск по форуму). В результате имеем технологию которая имеет дорогое оборудование, и требует дорогой персонал. В результате 99% провайдеров(а точнее ихних менеджеров) разного уровня говорят "фтопку!"

[Vjatkin]

А где вариант: Верится с трудом...? 

[Edd.Dragon]

В кодек кк ни странно струдом, но поверить можно. Вы с эдом не учли одну важную особенность - картинка н экране игры не является набором пикселей. То что вы описали - вещание ХД видео  Дело в том, что (с учетом развития современных ИТ-технологий) отображаемая игровая сцена и просто произвольная картинка имеет разную колмагорову сложность.

На примере:
Вместо того, то бы передать сообщение:
14159 26535 89793 23846 26433 83279 50288 41971 69399 37510
я могу сказать:
взять первые 50 знаков числа pi
Что будет намного короче.

Т.е. ты предлагаешь серверу обработать логику игры, подготовить текстуры, создать тени и прочие расчитываемые текстуры и передавать клиенту этот материал + скрипт для рендеринга из него сцены? Где ж в таком случае концепция тонкого клиента? Такой вариант спасает игроделов от пиратства, но это не Cloud по своей сути. А если не отходить от сути, то клиент должен получать только результат. И то, используя "интеллектуальное" кодирование видео мы и так даем клиенту не совсем результат, а в чем-то даже материал + скрипт. Только скрипт четко определен и не зависит ни от игры, ни от происходящего в ней. Итого: максимум что можно сделать, это разработать кодек(и), оптимизированные под игровой контент. Но именно конечный, рендеренный контент, так как нагружать слабые машины рендерингом не имеем права. Будет немного лучше чем универсальный XVid или h.264. Но не на порядок. Потому что, минимальную калмагорову сложность мы получаем при установке игры на свой комп и рендеринге ее своими силами. Распределение рендеринга "часть на сервере + меньшая часть на компе" - это уже не то. Хотя золотая середина возможно где-то здесь.

Кроме того, необходимо еще иследовать, сколько исходного материала перелопачивается движком игры допустим за 1 час игры. Со скоростью 5 mbps за час мы сможем принять около 2 Gb данных. Таким образом, в таких играх как Кризис, при быстром бегании и смене декораций только на передачу исходных для рендеринга данных может уйти почти весь наш канал. А в каждый конкретный момент времени мы вообще не можем гарантировать, что например в следующие две секунды нам не понадобится для рендеринга резко 20 метров данных, которые клиенту еще не передавались вовсе, т.е. цельных 160 мбит. Так что, рендерить как ни крути надо на месте, а передавать уже то, для чего можно сказать, что это что-то "почти всегда будет не более 5 mbps". Т.е. это что-то должно быть достаточно близко к более-менее стабильному видео-потоку.



Добавлено: Mon Jun  8 13:31:04 2009

Для обещанной производительности на каждого игрока требуется хотя бы эквивалент C2D E7*** и HD 4850.

Это только для рендеринга, а для кодирования ядер подкинь )))

[linuxdrom]

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

В итоге, на практике так и есть 

На примере:
Вместо того, то бы передать сообщение:я могу сказать:Что будет намного короче.

Ну собственно современные кодеки тоже не описывают каждый пиксель в каждом кадре  . Кроме сжатия кадра аля джейпегом, потом нужные пиксели зачастую получают описанием типа "а возьми их 5 кадров назад, передвинь чуть влево, и сделай темнее". H264 в этом плане вообще гениален, с моей точки зрения. Да и чего только CABAC стоит 

Возможно использование колмагоровой сложности тут сильно поможет, но это очевидно тебует полной коренной переработки движка игры.(Впрочем в случае с супер-кодеком это все равно было бы необходимо).

Объясни подробней как ты это видишь 

Кто/кому звонили поскайпу должен помнить иногда встречающиеся хаактерное "бульканье".

Кстати хороший пример, а ведь OnLive где-то в сотню раз требовательней.

Добавлено: 08 Червень 2009, 14:39:03

Это только для рендеринга, а для кодирования ядер подкинь )))

Обещают что кодирование будет делаться аппаратно "специальным секретным чипом" ™

[Edd.Dragon]

Обещают что кодирование будет делаться аппаратно "специальным секретным чипом" ™

Ну ладно, специальных секретных ядер подкинь )))))))
Хотя если аппаратно и архитектуру этого чипа не постигнет удача аппаратного PhysX, то тогда конечно можно разгуляться.



Добавлено: Mon Jun  8 13:44:45 2009

В итоге, на практике так и есть

Ну раз выставляют четкие и достаточно низкие ограничения на битрейт, то явно передаваемый клиенту контент малозависим от происходящего в игре, в которой в следующую секунду все может измениться коренным образом, к чему умный клиент будет не готов и канала не хватит его вовремя подготовить. Так что клиент обязан быть тупым, чтобы хоть что-то гарантировать. Максимум, это что-то чуть более умное чем "а возьми их 5 кадров назад, передвинь чуть влево, и сделай темнее"

[βεερ_βooρ]

Т.е. ты предлагаешь серверу обработать логику игры, подготовить текстуры, создать тени и прочие расчитываемые текстуры и передавать клиенту этот материал + скрипт для рендеринга из него сцены?

Еще и физике не забываем. Она тоже может немало жрать.

Где ж в таком случае концепция тонкого клиента?

Драсте не тонкий. Х-протокол по твоему что попиксельно передает как выгледит чье окошко?
И кто сказал что тонкий клиент - это телик+клава+мышь? Ты похоже путаешь тонкие клиенты с  терминалами

Такой вариант спасает игроделов от пиратства, но это не Cloud по своей сути.

А то тогда суть Cloud Computing?

Облачная обработка данных — это парадигма, в рамках которой информация постоянно хранится на серверах в сети Интернет и временно кэшируется на клиентской стороне, например на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т. д.

Запрета на обработку этой информации нет

А если не отходить от сути, то клиент должен получать только результат.

Нет, он осылает запрос облаку и получает результат. Который может дальше использоваться в соих целях.

И то, используя "интеллектуальное" кодирование видео мы и так даем клиенту не совсем результат, а в чем-то даже материал + скрипт. Только скрипт четко определен и не зависит ни от игры, ни от происходящего в ней.

Почему ты так решил?

Итого: максимум что можно сделать, это разработать кодек(и), оптимизированные под игровой контент. Но именно конечный, рендеренный контент, так как нагружать слабые машины рендерингом не имеем права. Будет немного лучше чем универсальный XVid или h.264. Но не на порядок.

Как раз то на порядок а может и больше.
Беру вот такую програмку на Хаскель:

Код Виділити Розширити

f n = if n==1 then 1 else n*(f (n-1))
main = mapM_ (y -> putStrLn $ show y) (map f [1..100])
93 байта.
При этом:

Код Виділити Розширити


bash-3.1$ a.out|wc -c
7091

Она сгенерировала 7091 байт данных. 2 порядка разницы.
Идем дальше. Чуть-чуть модернизируем:

Код Виділити Розширити

f n = if n==1 then 1 else n*(f (n-1))
main = mapM_ (y -> putStrLn $ show y) (map f [1..1000])
94 байта

Код Виділити Розширити

bash-3.1$ a.out|wc -c
1178743
Вот так просто и непринужденно я запаковал больше мегабайта данных в 94 байта.
Фокус в том что исходные данные имеют очень маленькую Колмагорову сложность, поэтому вместо того что бы передавать мегабайт данных, содержащий факториалы чисел от 1 до 1000, я просто написал что хочу: "дйте мнефактоилы чисел от 1 до 1000"
XVid или h.264 или любой другой видео-кодек не может достичь такой компресии данных даже близко по той простой причине, что  они работают на более низком уровне - для них входные данные можно сказать случайны и они пытются найти в них определенные взаимосвязи.
Вот простенький тест:

Код Виділити Розширити

bash-3.1$ a.out|wc -c
1178743
bash-3.1$ a.out|gzip|wc -c
503643
bash-3.1$ a.out|bzip2|wc -c
457559
Хотя bzip2 и смог ужать данные более чем в 2 раза, но не зная и стуктуры до моих 94 байт ему далеко

Потому что, минимальную калмагорову сложность мы получаем при установке игры на свой комп и рендеринге ее своими силами.

Нет
Колмагорова сложность не зависит от того кто орабатывает данные Она зависит толко от данных и в дном случае не изменится, поскольку рендерится будет одна и таже картинка.

Распределение рендеринга "часть на сервере + меньшая часть на компе" - это уже не то.

Покупай канал пошире и ставь сервер у провайдера. И то что я описал очень даже то Оно по краней мее эфективно использует попукную пособность канла и аппаратуру клиента



Добавлено: 08 Червень 2009, 15:29:20

Ну собственно современные кодеки тоже не описывают каждый пиксель в каждом кадре  Улыбка. Кроме сжатия кадра аля джейпегом, потом нужные пиксели зачастую получают описанием типа "а возьми их 5 кадров назад, передвинь чуть влево, и сделай темнее". H264 в этом плане вообще гениален, с моей точки зрения. Да и чего только CABAC стоит  Строит глазки

См. мой ответ Эду

Объясни подробней как ты это видишь  Обеспокоенный

Ну приблизительно как написал Эдд. Сервер обрабатывет логику, физику, проводит частичный рендеринг картинки и отправляет клиенту полуфабрикат. Кстати еще один вариант тут эконоии трафика - вместо того что бы скажем передавать клиенту все текстуры(а точнее результат ихнео наложения) каждый раз заново(что при видео-кодировании неизбежно), мы можем просто сказать: "Я вот тут отрендерил сцену, натяни сюда текстуру 1, сюда текстуру 2 и показывай"

Кстати хороший пример, а ведь OnLive где-то в сотню раз требовательней.

Родственики в Австралии + Скайп = личный опыт(тм)

Ну раз выставляют четкие и достаточно низкие ограничения на битрейт, то явно передаваемый клиенту контент малозависим от происходящего в игре, в которой в следующую секунду все может измениться коренным образом, к чему умный клиент будет не готов и канала не хватит его вовремя подготовить. Так что клиент обязан быть тупым, чтобы хоть что-то гарантировать. Максимум, это что-то чуть более умное чем "а возьми их 5 кадров назад, передвинь чуть влево, и сделай темнее"

Из перого не следует второе

[Edd.Dragon]

И кто сказал что тонкий клиент - это телик+клава+мышь? Ты похоже путаешь тонкие клиенты с  терминалами

Нет, я имел ввиду именно тонкий клиент.

"Тонкий клиент (англ. thin client) в компьютерных технологиях — бездисковый компьютер-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер."
Игры на диске у нас нет. У нас только интерфейс к ней, ну и оперативка для кеша. Чем меньше мы сами что-то делаем, тем лучше. В этом суть облачных вычислений.

Нет
Колмагорова сложность не зависит от того кто орабатывает данные

Тьху, ты понял что имелось ввиду ))))
Минимально необходимое описание результата

А то тогда суть Cloud Computing?

Ну не как не подготовка материалов и указаний как их расчитать
А сами расчеты

"Облачная обработка данных — это парадигма, в рамках которой информация постоянно хранится на серверах в сети Интернет и временно кэшируется на клиентской стороне, например на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т. д."
Запрета на обработку этой информации нет

А в чем же тогда заключается суть слова "обработка" в парадигме обработки? Ты привел подсуть, которая находится в рамках общей сути вычислений на сервере.

Нет, он осылает запрос облаку и получает результат. Который может дальше использоваться в соих целях.

Несомненно. Но в данном случае ТЗ явно требует обеспечить слабую машину, не способную провести вычисления в режиме реального времени результатом этих вычислений.

Почему ты так решил?

Потому что нам не последовательность картинок дают, а в основном куски кадров, иногда ключевые кадры. При этом всем нам известен скрипт, по которому мы из этих кусков строим каждый кадр последовательности.

Как раз то на порядок а может и больше.

Примеры реализации хоть чего-то подобного?
Или OnLive - первопроходцы, которые реализовали на практике то, о чем несложно догадаться, но лениво сделать?

Вот так просто и непринужденно я запаковал больше мегабайта данных в 94 байта.

Прикольно, а разве в свете  OnLive речь шла об играх с материалом, генерируемым по формулам?
Или ты можешь показать, что игровой процесс имеет такую же низкую сложность, если речь идет не о той 94-килобайтной "игре", а о Кризисе?
Ты хоть тресни, а на кадре из Кризиса полно не формализуемых текстур. Хоть ты их по отдельности передай + скрипт, хоть передай сжатые кадры, а чуда не выйдет 

"Чудо" будет только в том случае, если игровой контент мы будет планомерно пхать по 5 mbps, а игровой процесс будет заведомо ограничен так, чтобы не потребовать резко и много того, чего еще нет. Ну а наш CPU и GPU на клиенте будут в поте лица все это рендерить. В итоге мы в основном на пловину разгрузим CPU (и более сильно в случае физики) и почти не разгрузим ни оперативку, ни GPU. Таким образом, потребуется машина, на которой если отключить физику можно без проблем резаться на минимальных (а то и выше) настройках безо всяких там OnLive. В чем же смысл тогда?

Или это очередная замануха в стиле "Каша из топора", в результате которой мы и бабло платим и рендерить продолжаем сами? )))))))

Фокус в том что исходные данные имеют очень маленькую Колмагорову сложность, поэтому вместо того что бы передавать мегабайт данных, содержащий факториалы чисел от 1 до 1000, я просто написал что хочу: "дйте мнефактоилы чисел от 1 до 1000"

Так во втором абзаце я писал, что захотеть игра может в одну секунду 1 метр доп. данных, а в следующуюю - 20. И как быть тогда, если их еще в кеше нет? Спустись на землю и кроме теории взгляни и на цифры. 5 мбит для видио не подходят? Ты не против такого заявления? А почему ты против заявления, что эти 5 мбит точно так же не подходят и для концепции полурендеринга? Современная игра содержит около 60 000 мбит исходных данных, на которых базируется сложность игрового потока. И ты никак не докажешь, что как-минимум сами данные ты будешь всегда успевать переджавать по 5-мбитному каналу. А вот передачу видеопотока, пусть и с неприятной глазу картинкой ты уже можешь гарантировать с достаточно большой надежностью.

Оно по краней мее эфективно использует попукную пособность канла и аппаратуру клиента

Тогда это уже концепция распределенных вычислений. Да, абсолютно согласен - такое возможно. Только в такой ситуации невозможна гарантия столь низкого требования к каналу. Разве что, игры доработать, чтобы они как в Undercover синели и замирали, когда подкачка не успевает.



Добавлено: 08 Червень 2009, 16:09:48

мы можем просто сказать: "Я вот тут отрендерил сцену, натяни сюда текстуру 1, сюда текстуру 2 и показывай"

Я это и имел ввиду. Кроме того, клиенту еще нужно будет их фильтровать самому. Да и освещение самому расчитывать или же слать его в виде текстур, которые следует наложить поверх того, что срендерит клиент...

[linuxdrom]

Ну ладно, специальных секретных ядер подкинь )))))))
Хотя если аппаратно и архитектуру этого чипа не постигнет удача аппаратного PhysX, то тогда конечно можно разгуляться.

В это так раз вполне вериться. К примеру чипы для аппаратного кодирования в тот же Н264 существуют, только их сфера применения не "писишная"    

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

По имеющейся информации передаваемый контент зависим от происходящего в игре. 4 мб/с это максимальный, а средний ниже.  

Максимум, это что-то чуть более умное чем "а возьми их 5 кадров назад, передвинь чуть влево, и сделай темнее"

Если что, "а возьми их 5 кадров назад..." - это было утрирование. Посмотри доки по х264, и попробуй придумать что-то более умное, а то пока никому не удалось.

Х-протокол по твоему что попиксельно передает как выгледит чье окошко?

Окошко - нет, а растровая графику - да. Игры = растр.

XVid или h.264 или любой другой видео-кодек не может достичь такой компресии данных даже близко

Может   Просто потери полезной информации будут плачевными.

См. мой ответ Эду ;)Ну приблизительно как написал Эдд. Сервер обрабатывет логику, физику, проводит частичный рендеринг картинки и отправляет клиенту полуфабрикат.

Это убивает идею и возможность игры на калькуляторах в Кризис  

[sddd]

Мне нравится идея, но я все же за "дедовский метод на ближайшие лет 10-15, думаю

[linuxdrom]

Ох Edd и накатал  . Еще в общем и правильно  

[Edd.Dragon]

Если что, "а возьми их 5 кадров назад..." - это было утрирование. Посмотри доки по х264, и попробуй придумать что-то более умное, а то пока никому не удалось.

Не удалось, потому что нет ограничений на входящие данные. Универсально всегда сложнее. А в случае разработки кодека чисто под Кризис наверняка можно много чело придумать

По имеющейся информации передаваемый контент зависим от происходящего в игре. 4 мб/с это максимальный, а средний ниже.

А если имелось ввиду, что при кодировании в average bitrate максимальный битрет ограничивается кодеком на уровне 4 mbps, а средний - меньше. Сколько - не назвали, т.к. отталкивается кодек либо от таблично заданного битрейта для каждой игры, либо от приемлимого уровня квантизации при кодировании. Но - не больше чем 4 mbps.

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

ББ, разве не так?


Добавлено: 08 Червень 2009, 16:23:32

Может   Просто потери полезной информации будут плачевными.

Ну он то имел ввиду без потерь
Что с потерями все возможно - это понятно

[linuxdrom]

Не удалось, потому что нет ограничений на входящие данные. Универсально всегда сложнее. А в случае разработки кодека чисто под Кризис наверняка можно много чело придумать

Например?
Ну, ведь и не только чисто под Кризис. Доступных тайлов сейчас 16 - http://www.onlive.com/service/hot_new_games.html
И отличаются они друг от друга визуально существенно.

А если имелось ввиду, что при кодировании в average bitrate максимальный битрет ограничивается кодеком на уровне 4 mbps, а средний - меньше. Сколько - не назвали, т.к. отталкивается кодек либо от таблично заданного битрейта для каждой игры, либо от приемлимого уровня квантизации при кодировании. Но - не больше чем 4 mbps.

А я разве не это написал 

[Edd.Dragon]

А я разве не это написал

Неа, ты написал

"По имеющейся информации передаваемый контент зависим от происходящего в игре. 4 мб/с это максимальный, а средний ниже."

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

Т.е. эти слова не противоречат обеим теориям, так что, мне не совсем было понятно в свете которой из них ты их сказал

[linuxdrom]

А отсюда можно так же предположить, что мы имеем дело не с обычным видео, а действительно с неким нечтом

У вигляді презентації PowerPoint 

Известно что будет обычное видео, потому теорию про "нечто" я не поддерживаю, и вроде не давал повода так думать. 

[βεερ_βooρ]

Может  Подмигивающий Просто потери полезной информации будут плачевными.

Ну а прикол в том, то я сжал мегабайт до 94 байт БЕЗ ПОТЕРИ ИНФОРМАЦИИ. Так что h.264 может искать подходящию стенку

Это убивает идею и возможность игры на калькуляторах в Кризис  Обеспокоенный

Видеокодирование как опсано выше убьет ее даже для вполне нормльных ПК.
Еще один тест с моим примером на Колмагорову сложность.
25 раз сгенерируем факториалы от 1 до 1000:

Код Виділити Розширити


f n = if n==1 then 1 else n*(f (n-1))
loop 1 cmd = cmd
loop i cmd = cmd >> loop (i-1) cmd
main = loop 25 (mapM_ (y -> putStrLn $ show y) (map f [1..1000]))

Аж 156 байт

Код Виділити Розширити


bash-3.1$ a.out|wc -c
29468575
bash-3.1$ time a.out > /dev/null

real  0m1.862s
user  0m1.577s
sys   0m0.043s
bash-3.1$ a.out > fac.txt
bash-3.1$ gzip -c fac.txt|wc -c
12561415
bash-3.1$ bzip2 -c fac.txt|wc -c
11447904
bash-3.1$ time gzip -c fac.txt > /dev/null

real  0m5.367s
user  0m4.723s
sys   0m0.037s
bash-3.1$ time bzip2 -c fac.txt > /dev/null

real  0m14.542s
user  0m12.942s
sys   0m0.113s

bzip2 при намного меньшей компресии понадобилось больше 14 секунд. Компьютор один и тот же Только динамическое вычиление данных оказалось в 14 раз быстрее ихней компресии с использовнием bzip2.
Декомпресия конечно лучше, но не намного. Вот результат для bz2:

Код Виділити Розширити


bash-3.1$ time bunzip2 -c fac.txt.bz2 > /dev/null

real  0m5.221s
user  0m4.166s
sys   0m0.037s

Все равно в 4-5 раз медленей.
И заметьте никакого мошейничества и нечестной игры: просто я знаю что в файле fac.txt 25 раз подряд записаны факториалы чисел от 1 до 1000,  bzip2 не знает

Вообщем у калькуляторов есть надежда

Добавлено: 08 Червень 2009, 17:17:25

Окошко - нет, а растровая графику - да. Игры = растр.Может  

Ну немного неудачный приер но суть все та же.

[linuxdrom]

Ну а прикол в том, то я сжал мегабайт до 94 байт БЕЗ ПОТЕРИ ИНФОРМАЦИИ.

Информация информации рознь.
И если быть честным, ты не сжал - ты написал программу генерирующую информацию .
И, что смешно, игра тоже именно такая программа, ведь те нескольких мегабайт/гигабайт которые она занимает, способны создать практически бесконечное количество информации 

Вообщем у калькуляторов есть надежда

С играми - нет 

[βεερ_βooρ]

Не удалось, потому что нет ограничений на входящие данные. Универсально всегда сложнее.

Потому как в саом общем случае универсального компрессора(типа bz2) входные данные можно считать поти случайными. А случайные данные как раз и имеют максимально возможную Колмагорову сложность, равную дине входных данных +О(1)

А в случае разработки кодека чисто под Кризис наверняка можно много чело придумать

Не сильно много масимум учесть палитр уи некоторые особенности картинки. Но скажем последие на данный момент довольно сложная задача из области ИИ.

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

ББ, разве не так?

Нет, пропускную способность можно оценить исходя из граничных условий задачи(так как известно что больше такого-то к-ва полигонов в кадре игра не выдает,  в среднем столько-то, не более 3 игроков и т.д.). В любом случае она будет намного еньше таковой для видео. Так что твой пример с видео - это постройка собачей конуры высотою 1,2м из напряженного железобетона. Зато точно знаешь что в зиму под снегом на голову Шарику не обвалится.

Пример для моего случая с факториалами.
Так сказать мини-скрипт для генерации сцены:

f n = if n==1 then 1 else n*(f (n-1))
loop 1 cmd = cmd
loop i cmd = cmd >> loop (i-1) cmd
main = loop <параметр - сколько раз посчитать факториал> (mapM_ (y -> putStrLn $ show y) (map f [1..1000]))

Предположим нам известно что в "примитивных сценах" надо посчитать факториалы раз 10-15, а в сложных 1000-2000.
Имеем требованиядля пропукной способности канала: от 156 до 158 байт без учета сжатия.
Сравниваем с некомпресоваными данными: 1 пчка фкториалов от 1 до 1000 как уже было посчитато весит 1178743 байт. Получаем оценку для канала: от  11.241369 Мб/с до 2248.2738 Гб/с. Верхняя граница - это почти полная пропускная способность каналов КПИ на UA-IX. Но зто по твоей логике мы точно знаем что как минимум 3 студента(если учесть возможность сжатия) из 50 000 в КПИ смогут гарантировано поиграть
Я конечно утирую на модельном примере, но в реальности при применении колмагоового сжатия/ видеокодеков разница на не один порядк все равно останется.


Добавлено: 08 Червень 2009, 16:42:00

И если быть честным, ты не сжал - ты написал программу генерирующую информацию Подмигивающий

А какая разница? Дело в том что никто не мешает мне расматривать программу как данные.  Я могу по этим данным однозначно востановить информацию.
Или тебе надо описание формата и пример референсной релизации декомпрессора?

Добавлено: 08 Червень 2009, 17:42:46

С играми - нет  Рот на замке

Ну на кофеварках с дискретными видеокартами зато точно пойдут

[Edd.Dragon]

Известно что будет обычное видео

Вообще да. Пока мы тут обсуждали теорию, практика для меня стала более туманна и недосказана ))))))

просто я знаю что в файле fac.txt 25 раз подряд записаны факториалы чисел от 1 до 1000,  bzip2 не знает

Вообщем у калькуляторов есть надежда

ББ прекрати жульничать!
Игрокам нужен Кризис, который не записывается формулами и дистр которого весит 8 гиг, что сравнимо с несколькочасовыми роликами игрового процесса. А массив значений факториала, хоть и жмется шикарно, но игрокам не нужен

Вообщем у калькуляторов есть надежда

Если выпустят игру "Сожми факториал!"

С играми - нет

Калькуляторы будущего с нынешними играми - да. Как нынешние - с досовскими играми )))))

Потому как в саом общем случае универсального компрессора(типа bz2) входные данные можно считать поти случайными.

Это ты себе статическое фото Лары Крофт представил или же о видео-потоке думал, в котором есть зависимость между кадрами и зачастую очевидная даже для самых тупых кодеков?

Нет, пропускную способность можно оценить исходя из граничных условий задачи(так как известно что больше такого-то к-ва полигонов в кадре игра не выдает,  в среднем столько-то, не более 3 игроков и т.д.). В любом случае она будет намного еньше таковой для видео

Да что ты!?
В таком случае объясни, на кой для комфортного быстрого рендеринга компу необходимы хотя бы несколько линий PCI-Ex и хотя бы 512 Mb быстрой(!) памяти? Что ж там тот клятый Кризис гоняет, если ему было бы достаточно в каждую конкретную секунду пропускной способности 10-20 mbps и кеш в таком случае спокойно мог лежать хоть даже на винте, а тем более в обычной оперативке?

О каком "намного меньше" речь, если одна сцена может содержать десятки метров негенерируемых текстур и фоток?

А вот если бы ты говорил о тетрисе, ну или хотя бы об NFS 2 SE, но в разрешении 720p - вот тогда ты был бы прав как никто!

Или ты считаешь, что все материалы уже на клиенте давно?

Предположим нам известно что в "примитивных сценах" надо посчитать факториалы раз 10-15, а в сложных 1000-2000.
Имеем требованиядля пропукной способности канала: от 156 до 158 байт без учета сжатия.

Вернись на землю - у нас Кризис, уууууу! А не тетрис с одной текстурой на всю игру и та на заставке.

[βεερ_βooρ]

Нет, я имел ввиду именно тонкий клиент.

"Тонкий клиент (англ. thin client) в компьютерных технологиях — бездисковый компьютер-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер."
Игры на диске у нас нет. У нас только интерфейс к ней, ну и оперативка для кеша. Чем меньше мы сами что-то делаем, тем лучше. В этом суть облачных вычислений.

Тьху, ты понял что имелось ввиду ))))
Минимально необходимое описание результата
А сами расчеты
А в чем же тогда заключается суть слова "обработка" в парадигме обработки? Ты привел подсуть, которая находится в рамках общей сути вычислений на сервере.
Несомненно. Но в данном случае ТЗ явно требует обеспечить слабую машину, не способную провести вычисления в режиме реального времени результатом этих вычислений.

Ладно, тут мыуже фактиески вдаемся в тонкости переода и кто как что понимает.

Или OnLive - первопроходцы, которые реализовали на практике то, о чем несложно догадаться, но лениво сделать?

Догадаться не так уж сложно, более того это широко применяется  тех же играх,но в дргом ключе: при игре по сети не передаетсяинфомация отом что у кого на экране. Клиенты обмениваются между собой сообщениями о действиях игоков, где они находятя и т.д. При этом естественно подрауевать что каждый клиент знает как нарисовать БФГ и это объяснять ему не надо Другое дело что тут придется передвать какую-то информцию, которой в процессе игры различные части программы обмениваются между собой "не выходя во внешний мир". Думаю это будет довольн сложно

Прикольно, а разве в свете  OnLive речь шла об играх с материалом, генерируемым по формулам?

А разв игры - это набор скриншотов?

Или ты можешь показать, что игровой процесс имеет такую же низкую сложность, если речь идет не о той 94-килобайтной "игре", а о Кризисе?
Ты хоть тресни, а на кадре из Кризиса полно не формализуемых текстур. Хоть ты их по отдельности передай + скрипт, хоть передай сжатые кадры, а чуда не выйдет 

А прикол в том-то что текстуры передавать не надо. Мы передаем - "вот я тут расчитал как должно выглядеть вон то дерево, натяни на это такие-то текстуры"(которые у клиента есть изначальнои поэтому не будет резких всплесков трафика в канале когда нужно что-то догрузить)

Ну а наш CPU и GPU на клиенте будут в поте лица все это рендерить. В итоге мы в основном на пловину разгрузим CPU (и более сильно в случае физики) и почти не разгрузим ни оперативку, ни GPU. Таким образом, потребуется машина, на которой если отключить физику можно без проблем резаться на минимальных (а то и выше) настройках безо всяких там OnLive. В чем же смысл тогда?

Ну GPU можно тоже существенно разгрузить, проведя чсть расчетов вместо него на сервере. GPU же строет сцену не всю за раз

[linuxdrom]

какая разница? Дело в том что никто не мешает мне расматривать программу как данные.  Я могу по этим данным однозначно востановить информацию.

Рассматривать ты можешь, но ты (и кто либо другой) не можешь написать программу, которая будет создавать такие "данные".  Вот и разница.

Добавлено: Mon Jun  8 17:20:07 2009

Мы передаем - "вот я тут расчитал как должно выглядеть вон то дерево, натяни на это такие-то текстуры"(которые у клиента есть изначальнои поэтому не будет резких всплесков трафика в канале когда нужно что-то догрузить)

Ты описал классическое взаимодействие ЦПУ и ГПУ в играх. И трафик получается огромный. Хотя у клиента видеокарты текстуры есть изначально в видеопамяти 

[Xella]

Ого-го, узнаю простыночки BB, да и Edd смотрю тоже старается не отставать 

[linuxdrom]

Ого-го, узнаю простыночки BB, да и Edd смотрю тоже старается не отставать 

Для приличия, хоть бы написал, что-то типа  "это какая-то ненужная туфта, диски и апгрейды рулят!" 

[Xella]

Для приличия, хоть бы написал, что-то типа  "это какая-то ненужная туфта, диски и апгрейды рулят!" 

Апгрейды рулят в любом случае - если не железа, то каналов передачи данных.

[Edd.Dragon]

Догадаться не так уж сложно, более того это широко применяется  тех же играх,но в дргом ключе: при игре по сети не передаетсяинфомация отом что у кого на экране.

Да, но этим ты снимаешь с себя условие "я обсуждаю теоритическую возможность реализации конкретно поставленных условий" и начинаешь придумывать новые условия, гораздо слабее поставленных в первом сообщении.

Я еще в начале согласился, что да передавать скрипты (описывающие сугубо игровой процесс без графического материала или же пачку факториалов) - это просто! Но помимо этого отлично сжимаемого материала у нас гигабайты плохосжимаемого материала, необходимость в котором возникает крайне неравномерно и часто большими неожиданными (из-за действий игрока) порциями, что делает невозможным выполнение условия "не более 4-5 mbps", которое по сути говорит "в любых подряд идущих 20-30 кадрах используется не более 0.5 мегабайта новой информации". Таких игр уже 100 лет как нету.

А разв игры - это набор скриншотов?

Игра - нет. А многие текстуры - да. При чем оставшиеся если и генерировались, то с упором на качество, а не на скорость. Т.е. для реализации описываемых тобой фокусов нужны игры, которые изначально под OnLive будут задумываться.

которые у клиента есть изначально

"При использовании сервиса OnLive, в соответствии с моделью облачной обработки данных, все вычисления, необходимые для компьютерной игры (графический, физический, звуковой, ИИ движки и др.), производятся на удалённом сервере. Также на сервере размещены все файлы игры, а также профили пользователей и сохранённые игры. Для игры пользователю необходимо иметь средства для ввода (клавиатура, компьютерная мышь и др.) и вывода (дисплей, колонки) информации, простейшую компьютерную платформу (например, нетбук) и достаточно широкое (минимум 1.5Мбит/сек) и стабильное интернет-соединение"

Началось с того, что ты сказал, что теоретически возможно решить проблемы, связанные с этой задачей 
В которой клиент начинает с нуля

[βεερ_βooρ]

ББ прекрати жульничать!

Мне мама сказала что это может пригодится в жизни

Игрокам нужен Кризис, который не записывается формулами и дистр которого весит 8 гиг, что сравнимо с несколькочасовыми роликами игрового процесса. А массив значений факториала, хоть и жмется шикарно, но игрокам не нужен Показывает язык

Тебе понятие "модели" знакомо

Если выпустят игру "Сожми факториал!"

Это будет мего хит
Раз уж пошло такое дело, мне удалось учушить предыдущий результат в 156 байт:

Код Виділити Розширити


f n=product[1..n]
main=mapM_(\_->mapM_(y->putStrLn$show y)(map f [1..1000]))[1..25]

Теперь 25 раз факториалы от 1 до 1000 всего в 84 байтах!

Это ты себе статическое фото Лары Крофт представил или же о видео-потоке думал, в котором есть зависимость между кадрами и зачастую очевидная даже для самых тупых кодеков?

Я написал в самом общем случае. Bzip2 понятия не имеет о ключевых кадрах.

Да что ты!?
В таком случае объясни, на кой для комфортного быстрого рендеринга компу необходимы хотя бы несколько линий PCI-Ex и хотя бы 512 Mb быстрой(!) памяти?

Потому что видеокарта для построения сцены(которую мы потом пошлем коиенту) должна снаала попотеть

Да что ты!?
О каком "намного меньше" речь, если одна сцена может содержать десятки метров негенерируемых текстур и фоток?
А вот если бы ты говорил о тетрисе, ну или хотя бы об NFS 2 SE, но в разрешении 720p - вот тогда ты был бы прав как никто!

Не, ну где я написал, что я буду процедурно генерироват контент?
Что ли схемку нарисовать что я имел ввиду:

Код Виділити Розширити


Игрок - [b]обработка входных данных - ИИ - физика - расчет сцены[/b] - показ сцены

Жирным выделено что делает Сервер. Клиент только показывает уже просчитаную сцену.

Да что ты!?
Или ты считаешь, что все материалы уже на клиенте давно?

Ну а хули мне 8Гб кризиса каждый раз передавать на клиент по кусочкам?

Вернись на землю - у нас Кризис, уууууу! А не тетрис с одной текстурой на всю игру и та на заставке.

Подставить другие цифры оставляется как д/з для читателя. И вот тебе кризисный способ выисления факториала:

Код Виділити Розширити


-- explicit type recursion with functors and catamorphisms

newtype Mu f = In (f (Mu f))

unIn (In x) = x

cata phi = phi . fmap (cata phi) . unIn


-- base functor and data type for natural numbers,
-- using locally-defined "eliminators"

data N c = Z | S c

instance Functor N where
  fmap g  Z    = Z
  fmap g (S x) = S (g x)

type Nat = Mu N

zero   = In  Z
suck n = In (S n)

add m = cata phi where
  phi  Z    = m
  phi (S f) = suck f

mult m = cata phi where
  phi  Z    = zero
  phi (S f) = add m f


-- explicit products and their functorial action

data Prod e c = Pair c e

outl (Pair x y) = x
outr (Pair x y) = y

fork f g x = Pair (f x) (g x)

instance Functor (Prod e) where
  fmap g = fork (g . outl) outr


-- comonads, the categorical "opposite" of monads

class Functor n => Comonad n where
  extr :: n a -> a
  dupl :: n a -> n (n a)

instance Comonad (Prod e) where
  extr = outl
  dupl = fork id outr


-- generalized catamorphisms, zygomorphisms and paramorphisms

gcata :: (Functor f, Comonad n) =>
           (forall a. f (n a) -> n (f a))
             -> (f (n c) -> c) -> Mu f -> c

gcata dist phi = extr . cata (fmap phi . dist . fmap dupl)

zygo chi = gcata (fork (fmap outl) (chi . fmap outr))

para :: Functor f => (f (Prod (Mu f) c) -> c) -> Mu f -> c
para = zygo In


-- factorial, the *hard* way!

fac = para phi where
  phi  Z             = suck zero
  phi (S (Pair f n)) = mult f (suck n)
 

-- for convenience and testing

int = cata phi where
  phi  Z    = 0
  phi (S f) = 1 + f

instance Show (Mu N) where
  show = show . int


Не, ну неужели непонятно что пальцы не похожи на высшие материе, которые с помощью них объясняют?

Добавлено: 08 Червень 2009, 18:46:18

Рассматривать ты можешь, но ты (и кто либо другой) не можешь написать программу, которая будет создавать такие "данные".  Вот и разница.

Я не могу этосделать в общем случае. Но в конкретном случае это возможно. Просто движок вместо того что бы командовать видеокртой пишет как клиенту командовать видеокартой.

Ты описал классическое взаимодействие ЦПУ и ГПУ в играх. И трафик получается огромный. Хотя у клиента видеокарты текстуры есть изначально в видеопамяти

Ага, прям сразу все загрузили и посчитали.

"При использовании сервиса OnLive, в соответствии с моделью облачной обработки данных, все вычисления, необходимые для компьютерной игры (графический, физический, звуковой, ИИ движки и др.), производятся на удалённом сервере. Также на сервере размещены все файлы игры, а также профили пользователей и сохранённые игры. Для игры пользователю необходимо иметь средства для ввода (клавиатура, компьютерная мышь и др.) и вывода (дисплей, колонки) информации, простейшую компьютерную платформу (например, нетбук) и достаточно широкое (минимум 1.5Мбит/сек) и стабильное интернет-соединение"

Началось с того, что ты сказал, что теоретически возможно решить проблемы, связанные с этой задачей  Обеспокоенный
В которой клиент начинает с нуля

Ну убедил, да признаю я зарвлся в стремлении сжать трафик
Но основную идею использования колмагорового сжатия оно не отменяет

[Edd.Dragon]

Раз уж пошло такое дело, мне удалось учушить предыдущий результат

Я верю в тебя и уже купил попкорн! Это становится интересным 

Тебе понятие "модели" знакомо

Угу, мне когда-то рассказывали преймущества ручной сборки автотехники на примере деревянного самоката на подшипниках!

Я написал в самом общем случае.

Ну а хули мне 8Гб кризиса каждый раз передавать на клиент по кусочкам?

Я всего-лишь пытался заставить тебя вернуть на место те незыблимые и уже данные нам граничные условия модели сервиса, которые ты ушло (по совету мамы) смыл в унитаз 

А так, если их смыть, то все верно - игра у нас есть и мы знаем что это Кризис, только просим 2+2 сложить на сервере, а нам показать пальцем шо куда

[linuxdrom]

Первый (?) обзор со скриншотами - http://www.pcper.com/article.php?aid=859&type=expert
Какчество впечатляет 

Вибачте, але ви не маєте права на перегляд спойлерів.

З.Ы. Там и видео есть, но по сути оно бесполезно, так не дает реального представления о качестве.

[pohgejib]

особисто я згоден на більш убогіше зображення. на нетбуці ганяти ігри без установки, без сумнівів - революція