Думаю это вопрос тонкостей реализации, даже в наших условиях, когда резко происходит смена разметки (что, кстати, не часто бывает) автопилот не обязан куда-то резко дергаться, он может сманеврировать вполне безопасно для остальных участников ДД. В примере с разметкой понятно, что можно продолжать какое-то время двигаться по прежней траектории, т.к. дорожная ситуация «по мановению» разметки резко не изменится.
Пилотов держат по еще одной небольшой причине — в мировой гражданской авиации в автоматическом режиме посадка практически не осуществляется, если вообще где-либо осуществляется на регулярной основе. Тут вопрос в наличии соответствующих аэропортов (CAT IIIC), которых не очень много по миру и лайнеров, в таких условиях посадка с ручным управлением предпочтительна хотя бы ради набора опыта, без которого далеко не улетишь.
Что за оптимизации такие, расскажите, желательно со ссылками на какие-либо исследования или источники от разработчиков.
С такими заявлениями желательно уточнять, о какой linq реализации идет речь, в том же linq to objects вы не получите практически никаких оптимизаций, насколько мне известно, ну, разве что лишний Select(x => x) будет убран или будет вызван Count, вместо обхода по коллекции и подсчета элементов.
Непонятно также о каком конвеере идет речь и я сильно сомневаюсь что «ступени» там что-то знаю друг о друге, разве что конкретный провайдер, зная запрос целиком, может как-то оптимизировать и перестраивать дальнейшие вычисления.
В российских городах помимо Москвы и Питера очень даже есть пробки и приличные.
Вождение очень плохо параллелится с аудиокнигами, это факт. Просто вы обязаны большую часть времени уделять вождению, иначе вам следует прекратить этим заниматься. Если вы уделяете большую часть времени вождению, мозгом будет усваиваться не так много информации, тобишь подходит только для прослушивания каких-нибудь детективчиков.
В Питере, например, большую часть пути до работы я преодолеваю на скорости порядка 110-120 км/ч, как-то мозгу совсем не до аудиокниги становится. Иногда бывает разве что в глухую пробку попадешь.
Ничего странного в принципе. Инкапсуляция это один из столпов ООП, т.е. достаточно общее понятие и как раз был бы странно сводить ее к модификаторам доступа (Delphi и его облучающие материалы разумеется не являются авторитетными в вопросах теории ООП). Что касается инпсуляции, то это скорее сокрытие логики реализации. Модификаторы доступа можно считать производным механизмом, применяемым (опционально) в реализации ООП.
Потому что достоверно известно, что, например, крестьяне на Руси вообще были 100% трезвенниками.
Серьезно? Есть какие-либо источники? Потому как скорее достоверно известно то, что пили, а если и не пили, то только в связи с отсутствием возможности (запреты, дороговизна разрешенного алкоголя), да и это только снижало уровень потребления.
В Питере пишут, что также требуется полис ОМС (кто-то писал, что даже нового образца). На сайте УЭК про полис также сказано. Сам хочу пойти получить, но т.к. ОМС нет, решил сначала с ним разобраться.
Но так я, например, имею возможность ипользовать конструкции типа param.Where().OfType<TA>().
По поводу этого: перед созданием каждого подписчика (вызов Subscribe) можете навешивать индивидуально разной лапши, те же Where, подписчику элемент попадает уже в виде TSomeType, но там его тоже можно обернуть в Observable и продолжить заниматься извращениями.
И как они работают в оффлайне, расскажите. В «родных» гуглокартах под iOS отсутствует загрузка оффлайн карт. В сабже не знаю, но в описании ничего подобного не видно.
Меня несколько смутило что FPS из кадровой частоты превратился в частоту обновления состояния мира.
В интерполяции как таковой ничего особенно сложного не вижу. Были мысли на счет того, что необходимо грамотно выделять и описывать интерполируемые свойства объектов дабы избежать дублирования, ну и в принципе, унифицировать и автоматизировать формирование логики интерполяции свойств объектов.
Хм, с интерполяцией в общих чертах все понятно, на мощном железе за счет нее мы получаем больший FPS без накопления ошибки, т.к. не приходится хранить состояние…
Я не знаю на каком железе она будет запущена, и я не предлагаю программировать под 25, либо под 125.
Мои рассуждения выше были «иллюстрацией» к последнему примеру организации game loop'а, я вопрошая описывал принцип его работы.
Я пытаюсь понять для себя суть всех этих наворочек. Правильно ли я понимаю, исходя из вашего комментария, что вы все же предлагаете «обсчитывать» мир с большей частотой, но делается это не через updateGameState, а через интерполяцию (хитрым для меня способом). Т.е. суть в том, что на мощном железе мы хотим чаще рисовать, но будем делать это еще чаще чем можем через updateGameState благодаря интерполяции?
Мне как раз интересно, как оно выглядит в серьезных движках, возможно я тороплю события по циклу статей, но так уж получилось, возник вопрос. Ведь интерполяция выглядит достаточно сложно, она должна учитывать динамику всех игровых объектов, т.е. процесс может пересекаться, даже быть частью updateGameState. Т.е. чтобы последний пример выглядел логично мы можем/должны сделать что-нибудь вроде движка.
Не очень понятно зачем заниматься интерполяцией в рендере на мощном железе, вот ради чего?
Т.е. мы зафиксировали, допустим, 25 кадров, игровое состояние у нас обновляется 25 раз в секунду (казалось бы, зачем вообще привязывать частоту обновления игрового состояния и FPS?).
После чего мы говорим: а ну его вообще нафиг эти 25 кадров в секунду, мы можем нарисовать 125 кадров, приделываем костыль в виде интерполяции и рисуем.
Доп. вопрос: почему мы не можем просто на мощном железе 125 раз в секунду обновить игровое состояние и вызвать рендер? Имхо получается тоже самое, но интерполяцию можно не прикручивать.
С такими заявлениями желательно уточнять, о какой linq реализации идет речь, в том же linq to objects вы не получите практически никаких оптимизаций, насколько мне известно, ну, разве что лишний Select(x => x) будет убран или будет вызван Count, вместо обхода по коллекции и подсчета элементов.
Непонятно также о каком конвеере идет речь и я сильно сомневаюсь что «ступени» там что-то знаю друг о друге, разве что конкретный провайдер, зная запрос целиком, может как-то оптимизировать и перестраивать дальнейшие вычисления.
Вождение очень плохо параллелится с аудиокнигами, это факт. Просто вы обязаны большую часть времени уделять вождению, иначе вам следует прекратить этим заниматься. Если вы уделяете большую часть времени вождению, мозгом будет усваиваться не так много информации, тобишь подходит только для прослушивания каких-нибудь детективчиков.
В Питере, например, большую часть пути до работы я преодолеваю на скорости порядка 110-120 км/ч, как-то мозгу совсем не до аудиокниги становится. Иногда бывает разве что в глухую пробку попадешь.
Серьезно? Есть какие-либо источники? Потому как скорее достоверно известно то, что пили, а если и не пили, то только в связи с отсутствием возможности (запреты, дороговизна разрешенного алкоголя), да и это только снижало уровень потребления.
По поводу этого: перед созданием каждого подписчика (вызов Subscribe) можете навешивать индивидуально разной лапши, те же Where, подписчику элемент попадает уже в виде TSomeType, но там его тоже можно обернуть в Observable и продолжить заниматься извращениями.
Там смотрите по ключевым словам «shared observable» (это чтобы создать поток элементов для нескольких подписчиков): вызов Publish/Connect, в т.ч. тут можно почитать http://leecampbell.blogspot.ru/2010/08/rx-part-7-hot-and-cold-observables.html.
После создания расшареного потока просто навешиваете на него нужное число подписчиков/обработчиков.
Касательно параллелизации посмотрите SubscribeOn/ObserveOn, например на http://leecampbell.blogspot.ru/2010/06/rx-part-6-scheduling-and-threading.html.
Собственно дальше изучайте остальные возможности и делайте еще более клевые штуки в пару call'ов.
В интерполяции как таковой ничего особенно сложного не вижу. Были мысли на счет того, что необходимо грамотно выделять и описывать интерполируемые свойства объектов дабы избежать дублирования, ну и в принципе, унифицировать и автоматизировать формирование логики интерполяции свойств объектов.
Мои рассуждения выше были «иллюстрацией» к последнему примеру организации game loop'а, я вопрошая описывал принцип его работы.
Я пытаюсь понять для себя суть всех этих наворочек. Правильно ли я понимаю, исходя из вашего комментария, что вы все же предлагаете «обсчитывать» мир с большей частотой, но делается это не через updateGameState, а через интерполяцию (хитрым для меня способом). Т.е. суть в том, что на мощном железе мы хотим чаще рисовать, но будем делать это еще чаще чем можем через updateGameState благодаря интерполяции?
Мне как раз интересно, как оно выглядит в серьезных движках, возможно я тороплю события по циклу статей, но так уж получилось, возник вопрос. Ведь интерполяция выглядит достаточно сложно, она должна учитывать динамику всех игровых объектов, т.е. процесс может пересекаться, даже быть частью updateGameState. Т.е. чтобы последний пример выглядел логично мы можем/должны сделать что-нибудь вроде движка.
Т.е. мы зафиксировали, допустим, 25 кадров, игровое состояние у нас обновляется 25 раз в секунду (казалось бы, зачем вообще привязывать частоту обновления игрового состояния и FPS?).
После чего мы говорим: а ну его вообще нафиг эти 25 кадров в секунду, мы можем нарисовать 125 кадров, приделываем костыль в виде интерполяции и рисуем.
Доп. вопрос: почему мы не можем просто на мощном железе 125 раз в секунду обновить игровое состояние и вызвать рендер? Имхо получается тоже самое, но интерполяцию можно не прикручивать.
В реализации каких тайтлов вы участвовали?