Cheb's Game Engine

[Cheb]

Ну вот сам и ответил, что библиотека не доработана, реагирует на мышь...

Тролль добавлен в чёрный список.
Всего хорошего.

[Alex2013]

Ну вот сам и ответил, что библиотека не доработана, реагирует на мышь...

Тролль добавлен в чёрный список.
Всего хорошего.

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

[Cheb]

Ну ты приятель крут

Ибо здесь вам не тут.

а древний "кубик" и т.п. как я понимаю не в счет

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

[Seenkao]

Тролль добавлен в чёрный список.

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

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

[runewalsh]

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

Так ты либо не читал то, на что отвечаешь этой

Ну вот сам и ответил, что библиотека не доработана, реагирует на мышь...

цитатой, либо не очень догадливый.

Смотри, меню по своей природе — штука спокойная, там максимум травка колышется какая-нибудь, много FPS ему не нужно.
Но если мышь двигается — потенциально начинается миниатюрный экшн, в ходе которого элементы GUI двигаются, подсвечиваются или экран сменяется. Поэтому FPS временно повышается.

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

[Seenkao]

При таких настройках, когда FPS не выше 30 (даже если не выше 60-ти), без соответствующей нагрузки, компьютер на как не должен (практически) реагировать на движение мыши или ещё каких процессов, которые не занимают много процессорного времени.

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

А этого не должно происходить (практически) ни в какой момент времени, ведь ограничение на все процессы были сделаны, а мышь вдруг отдельный процесс? )))

Это как на машине дворники пока не работают, машина стабильно едет, а как включаешь дворники, вдруг двигатель сильнее работать начинает. )))

[runewalsh]

ведь ограничение на все процессы были сделаны

Потому что ты так сказал? FPS — только для графики. Ограничение может быть реализовано как таймер, который по таймауту постит окну (потоку) сообщения WM_TIMER, в ответ на которые обновляется сцена и триггерится перерисовка. Нет таких сообщений, или они приходят реже — окно обрабатывает другие, в том числе от других таймеров, тем самым занимается другими процессами (в смысле «занятиями») в рамках своих ответственностей в приложении. В чём проблема? (Это риторический вопрос, проблемы нет и никто, кроме графики, не страдает, наоборот, им остаётся больше CPU.)

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

Потом, задавать желаемый FPS может не только мышка, но и сам экран приложения (спокойное меню — поменьше, геймплей — побольше, окно деактивировано — вообще до 0 опустить), тогда сущность, всё это дело контролирующая, выбирает наибольшее из пожеланий. (Я независимо хотел так сделать как-нибудь, но мне лень :P.)

[Seenkao]

Потому что ты так сказал?

Потому что есть только два вида приложений: оконное или полноэкранное (не псевдо-полноэкранное, а именно переключенное под приложение).

Изучайте основы.

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

б) Мы сами обрабатываем все приходящие сообщения, в том числе и мышь и экран. Что так же не влияет на частоту вывода изображения на экран!!! У мыши так же независимый обработчик, который !!!ПОДГОТАВЛИВАЕТ!!! данные для вывода курсора на экран.

При полноэкранном режиме, всё происходит как во втором варианте для оконного режима.

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

Отсюда вывод - в обработку мыши засунули прорисовку экрана, или привязали обработку экрана так же к запросам мыши.

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

[runewalsh]

Если вы хотите вникнуть как работает окно

Я больше хочу вникнуть, что у тебя в голове.

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

Ну если ты сам создал такое и после этого продолжаешь вот это всё рассказывать, то у меня для тебя плохие новости, ибо ты абсолютно ни с чем не угадал, даже не вижу смысла что-то всерьёз оспаривать. Ладно если бы неверные утверждения составляли 10% поста или 50, но не все же 100.

Попробую последний раз объяснить, что я имею в виду, вдруг ты только прикидываешься нейронетипичным:

Код: Выделить всё

procedure SetFPS(const fps: float);
begin
    SetTimer(..., FPS_TIMER_ID, round(1000 / fps), ...);
end;

// startup
SetFPS(30);

// WindowProc
case msg of
    WM_PAINT: narisovat_scenu();
    WM_TIMER:
        if wParam_timerID = FPS_TIMER_ID then
        begin
            obnovit_scenu();
            if fps_vystavlen_v_60_a_myshka_ne_dvigalas_vot_uzhe_sekundu then SetFPS(30);

            // вообще-то вместо InvalidateRect прямое narisovat_scenu() не является преступлением, и даже эффективнее так-то:
            // у меня на простой сцене прямое narisovat_scenu() даёт 6000 FPS против 4500,
            // т. е. один вызов InvalidateRect занимает аж 1/4500 - 1/6000 = 55 микросекунд,
            // что означает, что при 60 кадрах в секунду вызовы InvalidateRect займут 3 миллисекунды — 0,3% от всего времени!
            // Но, для чистоты.
            InvalidateRect(window, ...);
        end;
    WM_MOUSEMOVE:
        begin
            SetFPS(60);
        end;
end;

Мы можем использовать и не GetMessage + таймер, а PeekMessage + Sleep, тогда желаемый FPS будет влиять на время сна.

[Seenkao]

runewalsh, а теперь возьмём даже ваш код и вставим одну проверочку:

прошёл определённый интервал времени?
да - прорисовываем (InvalidateRect(... )).
нет - продолжаем/заканчиваем процедуру

это было так сложно...

А ведь можно делать это всё, ещё до запросов сообщений... получим вообще "максимальное FPS"...

[runewalsh]

↑ До кого не дошла комичность ситуации, этот предлагал мне «изучать основы» низкоуровневого создания окон, а как теперь (ожидаемо) выясняется, абсолютно не понимает, среди прочего, значений слов WindowProc, InvalidateRect и SetTimer.

[Seenkao]

Да ладно с этим, пусть не знаю. Объясните мне, каким образом на прорисовку должна влиять мышь?
Особенно, когда мы будем ограничивать частоту кадров.

[Сквозняк]

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

[Alex2013]

Да ладно с этим, пусть не знаю. Объясните мне, каким образом на прорисовку должна влиять мышь?
Особенно, когда мы будем ограничивать частоту кадров.

Мда ... "это фантастика" ...
Мышь ни на что не влияет влияет обработка событий от мыши ( там может быть накручено очень много включая анимацию и влияние на рендеринг ). А вообще совершенно беспредметный спор! (текущей сборки движка в открытом доступе нет, а что были несколько лет назад не актуальны в принципе)
Зы
Но все-же я вполне представляю как можно воспроизвести описываемою ситуацию и то что при движении мыши FPS РАСТЕТ (а не падает ) говорит не об ошибке, а наоборот о правильной реализации рендеринга меню.

[Seenkao]

имеет место межпоточное взаимодействие

крутое объяснение!!! Зачёт!

У меня с соседями тоже "межпоточное взаимодействие"... но видимо, (если мне прописали лекарства три раза в день в определённое время) когда соседи будут ходить по общему коридору, я буду чаще принимать лекарства... потому что у меня "межпоточное взаимодействие"...

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

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