prVovik
Ладно. Давай ждать комментариев, за счет какого конкретно простоя экономилось время.
Семен
Тебе же выше уже было сказано за счет чего экономилось время (пост 12)
Семен
имелся в виду простой во время Presentа. На одном потоке делается Present, который блокирует поток, и в этот же момент начинается просчёт следующего кадра.
Давайте все же разделять простой Present'a и всего остального.
Если только Present - объясните мне, глупому, почему плоха моя однопоточная схема? В ней можно запросто отставать от GPU кадра на 2-3. Хочется больше?
Семен
>Если только Present - объясните мне, глупому, почему плоха моя однопоточная схема? В ней можно запросто отставать от GPU кадра на 2-3. Хочется больше?
Проблема не в отставании а в простое CPU который будет вcегда, если сцена в игре достаточно сложная и GPU будет притормаживать. Т.е. игра всегда будет быстрее рендера, всегда впереди на максимальное кол-во кадров и поэтому на каждом кадре будет блокироватся, а CPU простаивать без дела. Ну сделает она при старте несколько быстрых кадров зато потом её на каждом следующем кадре будут блокировать.
LFlip
Видимо, я не понимаю чего-то глобального :)
Да, будет. Но раз GPU подтормаживает, значит CPU действительно нечего считать. Он просчитал на 3 (условно) кадра вперед карточки, карта не успевает это все отрисовать. И чем заняться то время пока мы ждем карту?
Обсчитывать 4-й кадр? Зачем?
Обсчитывать какиую-то физику и т.д.? Почему просто это не поместить в цикл вычислений?
Семен
>Да, будет. Но раз GPU подтормаживает, значит CPU действительно нечего считать. Он просчитал на 3 (условно) кадра вперед карточки, карта не успевает это все отрисовать. И чем заняться то время пока мы ждем карту?
Обсчитывать 4-й кадр? Зачем?
Ну, посчитали. Теперь у нас появился еще запас времени. Пятый обсчитывать? Потом шестой и так далее?
Бедный LFlip! Все сразу же принялись закидывать его грязью, даже не потрудившись разобраться в статье и прочитать ее хотя бы второй раз. Один лишь aruslan поддерживал коллегу.
Попробовал бы кто реализовать то что сказано в статье, а там уже на фактах дрался.
Леха! Не сдавайся.
Хотя ведь ты мог некоторые моменты более развернуто изложить. Да ты наверное уже готовишь статью-дополнение, я надеюсь.
Так что давайте попросим автора более развернуто изложить моменты в статье, которые вызвали критику. Если бы развернуть такие вопросы, как:
- цикл сообщений потока
- механизм диспетчеризации секций (вызова реакций на команды)
- объявление секций в программе (как экземпляров, а не как типов)
Если при этом все это сдобрить исходным кодом, то, IMHO, все было бы ясно народу, или во всяком случае мне, хотя и в таком виде статья довольно четко дает понять принцип работы МП-движка!
Всем, всего наилучшего,
особенно тебе, Леха!
Не надо так. Никто никого грязью не закидывал. Насчет 90% текста статьи не было возражений совсем.
На этих двух страницах обсуждается довольно узкий в контексте статьи момент.
Кстати, не забывайте, что юзер имеет привычку нажимать на кнопки, дергать мышью, джойстиком и т.д. А мы ему: "подожди, чувак, у нас физика уже на час вперед просчитана, так что ты не суетись" :-)))
Семен
>Не надо так. Никто никого грязью не закидывал. Насчет 90% текста статьи не было
>возражений совсем.
>На этих двух страницах обсуждается довольно узкий в контексте статьи момент.
Прошу прощения. ВОзможно я слишком резко выразился.
Первые посты были отрицанием того, что идет вразрез с собственными взглядами на то, как надо писать игры.
Однако ж (впоследствии автор пояснил, что статья не призывает всех строиться в ряд и использовать предложенную методику), мне показалось что (пост №1)
prVovik
>Сомневаюсь я в увеличении скорости...
и не попытался все обдумать. Рассказал как происходит переключение потоков и чем за это платить. Хотя в статье упоминается чем этот проигрыш компенсируется.
minorlogic пошел дальше
>prVovik
>Супер ! Я бы лучше не ответил !
Зачем отвечал тогда? Еще раз извините за резкость
>Действительно на современном оборудовании ( PC, XBOX ) Увеличение
>производительности при использовании многопоточности это просто выдумка автора
>(и большое заблуждение).
Сомнительный и непроверенный наезд, без должного испытания изложенного материала.
prVovik
>LFlip
>aruslan
>
>Вы слишком много писали для приставок :-)
А prVovik писал? Я тоже не писал. О чем горько сожалею. А так бы хотелось. Ан пока не судьба.
Я требую продолжения статьи (см. последний абзац моего последнего поста). Потому как со второго десятка посты пошли конструктивные и очень интересно было читать.
prVovik
Я думаю, что если бы ты что-нибудь понял из того, что здесь гововорили,
то такое
>Кстати, не забывайте, что юзер имеет привычку нажимать на кнопки, дергать мышью, джойстиком и т.д. А мы >ему: "подожди, чувак, у нас физика уже на час вперед просчитана, так что ты не суетись" :-)))
ты бы не писал
Kont
Самое первое слово в самом первом моем посте было: "Сомневаюсь". Я ничего не утверждал, просто высказал мысль, причем аргументированно. Я повторю: обсуждается не полезность многопоточности вообще, а разделение рендера и физики по разным потокам. Обрати внимание на постскриптум в моем первом посте. Далее я показал чем был достигнут прирост производительности, описанный в статье и показал как можно добиться тогоже прироста значительно меньшей кровью, без исользования сложной многопоточности и заморочек с сихронизацией. Я остаюсь при своем мнении, что классическая схема организации игрового процесса более оптимальна, чем предложенная в качестве примера (на картинке)
Gnom
Куда уж мне до Вас, уважаемый Гуру.
prVovik
Гуд ! Гуд !
Так его !
Kont
Реально я согласен с prVovik и не видел аргументов показывающих его неправоту.
Тема в архиве.