Применение многопоточности в играх. (Комментарии к статье) (3 стр)

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-й кадр? Зачем?

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

Ну, посчитали. Теперь у нас появился еще запас времени. Пятый обсчитывать? Потом шестой и так далее?

Бедный LFlip! Все сразу же принялись закидывать его грязью, даже не потрудившись разобраться в статье и прочитать ее хотя бы второй раз. Один лишь aruslan поддерживал коллегу.
Попробовал бы кто реализовать то что сказано в статье, а там уже на фактах дрался.

Леха! Не сдавайся.
Хотя ведь ты мог некоторые моменты более развернуто изложить. Да ты наверное уже готовишь статью-дополнение, я надеюсь.

Так что давайте попросим автора более развернуто изложить моменты в статье, которые вызвали критику. Если бы развернуть такие вопросы, как:
- цикл сообщений потока
- механизм диспетчеризации секций (вызова реакций на команды)
- объявление секций в программе (как экземпляров, а не как типов)
Если при этом все это сдобрить исходным кодом, то, IMHO, все было бы ясно народу, или во всяком случае мне, хотя и в таком виде статья довольно четко дает понять принцип работы МП-движка!

Всем, всего наилучшего,
особенно тебе, Леха!

Не надо так. Никто никого грязью не закидывал. Насчет 90% текста статьи не было возражений совсем.
На этих двух страницах обсуждается довольно узкий в контексте статьи момент.

Кстати, не забывайте, что юзер имеет привычку нажимать на кнопки, дергать мышью, джойстиком и т.д. А мы ему: "подожди, чувак, у нас физика уже на час вперед просчитана, так что ты не суетись" :-)))

Семен
>Не надо так. Никто никого грязью не закидывал. Насчет 90% текста статьи не было
>возражений совсем.
>На этих двух страницах обсуждается довольно узкий в контексте статьи момент.

Прошу прощения. ВОзможно я слишком резко выразился.

Первые посты были отрицанием того, что идет вразрез с собственными взглядами на то, как надо писать игры.

Однако ж (впоследствии автор пояснил, что статья не призывает всех строиться в ряд и использовать предложенную методику), мне показалось что (пост №1)

prVovik
>Сомневаюсь я в увеличении скорости...

и не попытался все обдумать. Рассказал как происходит переключение потоков и чем за это платить. Хотя в статье упоминается чем этот проигрыш компенсируется.

minorlogic пошел дальше
>prVovik
>Супер ! Я бы лучше не ответил !
Зачем отвечал тогда? Еще раз извините за резкость
>Действительно на современном оборудовании ( PC, XBOX ) Увеличение
>производительности при использовании многопоточности это просто выдумка автора
>(и большое заблуждение).
Сомнительный и непроверенный наезд, без должного испытания изложенного материала.

prVovik
>LFlip
>aruslan
>
>Вы слишком много писали для приставок :-)
А prVovik писал? Я тоже не писал. О чем горько сожалею. А так бы хотелось. Ан пока не судьба.

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

prVovik

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

>Кстати, не забывайте, что юзер имеет привычку нажимать на кнопки, дергать мышью, джойстиком и т.д. А мы >ему: "подожди, чувак, у нас физика уже на час вперед просчитана, так что ты не суетись" :-)))

ты бы не писал

Kont
Самое первое слово в самом первом моем посте было: "Сомневаюсь". Я ничего не утверждал, просто высказал мысль, причем аргументированно. Я повторю: обсуждается не полезность многопоточности вообще, а разделение рендера и физики по разным потокам. Обрати внимание на постскриптум в моем первом посте. Далее я показал чем был достигнут прирост производительности, описанный в статье и показал как можно добиться тогоже прироста значительно меньшей кровью, без исользования сложной многопоточности и заморочек с сихронизацией. Я остаюсь при своем мнении, что классическая схема организации игрового процесса более оптимальна, чем предложенная в качестве примера (на картинке)

Gnom
Куда уж мне до Вас, уважаемый Гуру.

prVovik
Гуд ! Гуд !
Так его !

Kont
Реально я согласен с  prVovik и не видел аргументов показывающих его неправоту.