ПрограммированиеФорумОбщее

Игровой цикл (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
12:59, 2 мар 2017

dds
> А не лучше ли вынести в 2 разных потока Update и Render?
Render лучше оставить в основном))

#16
15:08, 2 мар 2017

Лучше придумате архитектуру, как делать параллельно Update для разных объектов в тред пуле и как делать Update на несколько кадров вперед (для объектов, которым не нужны синхронные данные, типа юзер инпута)

#17
15:17, 2 мар 2017

Hardcode
Зачем?

#18
15:22, 2 мар 2017

Mira
Атмосферу греть, понятно
Можно и на исходный вопрос ответить - "Бери юнити и не парься"

#19
15:32, 2 мар 2017

MrShoor
> А оконый цикл такой:
если делать так как ты предлагаешь и рисовать на WM_PAINT... кто же тебе этот самый WM_PAINT дергать будет?
ЗЫ ты забыл RedrawWindow RDW_INTERNALPAINT

#20
18:54, 2 мар 2017

1) Окно и обработчик сообщений должны быть там же где и рендер, т.к. в реальном мире у вендоров есть некоторый prediction, который в противном случае может дать сбой и плакал ваш рендер-тред с низким приоритетом.
2) В своих проектах использовал такой цикл:

do {
    if (PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    } else {
        DWORD time = getTime();
        if (time <= lastTime)
            continue;

        float delta = min(1.0f, (time - lastTime) * 0.001f);
        while (delta > EPS) {
            Core::deltaTime = min(delta, 1.0f / 30.0f);
            Game::update();
            delta -= Core::deltaTime;
        }
        lastTime = time;

        Game::render();
        SwapBuffers(hDC);
        #ifdef _DEBUG
            Sleep(20); // чтобы не греть атмосферу
        #endif
    }
} while (msg.message != WM_QUIT);

3) Если задача состоит в уменьшении Input Lag'а то есть всякие штуки типа glGet*, glFinish для синхронизации CPU-GPU и reprojection кадра для практически нулевой задержки при перемещении и вращении камеры. Изменение порядка render/update на практике, никакой роли не играет.

#21
20:38, 2 мар 2017

cNoNim
> если делать так как ты предлагаешь и рисовать на WM_PAINT... кто же тебе этот
> самый WM_PAINT дергать будет?
Update() и обработчики ввода буду звать InvalidateWindow(...);

Кто-то не может в Windows?

#22
22:48, 2 мар 2017

MrShoor
> Кто-то не может в Windows?
так ты и не можешь, все нормальные пацаны юзают RedrawWindow

#23
3:06, 3 мар 2017

cNoNim
> так ты и не можешь, все нормальные пацаны юзают RedrawWindow
Ну а поскольку ты можешь в винапи, я думаю ты знаешь, что InvalidateWindow - частный случай RedrawWindow, только с более простым синтаксисом вызова. М? Или не знаешь?

#24
9:40, 3 мар 2017

MrShoor
Ты лучше рассквжи чем инвалидейт отличается от редрав с интернал паинт

#25
10:14, 3 мар 2017

cNoNim
> Ты лучше рассквжи чем инвалидейт отличается от редрав с интернал паинт
Дай угадаю, тем что не работает с времен Windows Vista?

#26
10:32, 3 мар 2017

Че за инвалидейтвиндов?)
Я пользовался только invalidateRect редравы тоже не юзал

#27
10:44, 3 мар 2017

Mira
> Я пользовался только invalidateRect редравы тоже не юзал
Да, я оговорился, конечно же InvalidateRect имелся ввиду.

#28
13:54, 3 мар 2017

Посоны, а зачем ждать обработчика WM_PAINT вместо непосредственного вызова render/present?

#29
14:11, 3 мар 2017

XProger
> Посоны, а зачем ждать обработчика WM_PAINT вместо непосредственного вызова
> render/present?
Обработка инпута ближе к WM_PAINT. Как-то так:

Update();
ProcessInput();
Render();
Update();
ProcessInput();
Render();

Ну и бонусом - ты можешь сделать N раз Update, несколько раз обработать инпут, а рисовать в свободное от этого всего время. А коль винда из коробки предоставляет очень подходящий для этого WM_PAINT - то почему не пользоваться им?

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.