Вопрос по логике кода из [Как написать игру на Qt — Урок 1. Управление объектом]

GetAsyncKeyState, Qt, WinAPI

Рекомендуємо хостинг TIMEWEB

Стабільний хостинг, на якому розміщується соціальна мережа EVILEG. Для проектів на Django радимо VDS хостинг.

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

Дело в том, что переопределение метода void keyPressEvent(QKeyEvent *event) не позволяет определить, что клавиша всё ещё зажата в определённый момент времени без горожения целой кучи кэшей. Это во-первых.
А во вторых, если попытаетесь одновременно зажать несколько клавиш, то тоже в данном методе разгребать это будет очень сложно. Ну и до кучи ещё и лаги будут добавляться с этим методом, а так мы сразу обращаемся к API операционной системы и получаем без лишних задержек нужный результат в нужный момент времени.
К тому же, данный метод будет переопределён для конкретного виджета или графической сцены, а если фокус по какой-то причине перейдёт на другой виджет, который не относится к графической сцене, то данный метод просто не сработает. Например, нажали кнопку меню, вышли из меню, а фокус остался на этой кнопке. Метод, который был переопределён в графической сцене просто не будет тогда срабатывать.

И в описании этого метода isAutoRepeat написано примечание, что если было зажато несколько клавиш, то его результат будет неопределённым. Если этот метод будет возвращать неопределённый результат, то и поведение KeyEvent тоже скорее всего будет неопределённым. К тому же eventFilter имеет такое свойство, что если этих фильтров навешано много, то и события будут генерироваться в порядке очереди.
А в применении к геймдеву, если уж говорить о том, с какой статьи начался данный топик, мы получим ничем не обоснованные лаги, поскольку будем иметь задержку на ровном месте в получении результата по нажатым кнопкам.
Также, когда событие повторится, то можем получить ситуацию, когда кнопку уже отпустили, а событие будет повторено с нажатой кнопкой. Библиотека Qt всё-таки не такая быстрая и у неё есть свои очереди событий.
Так что здесь нужно рассматривать конкретную ситуацию под конкретным углом.

P/S/ А так, спасибо за дополнение.

Вот я просмотрел уже третий урок и возник у меня еще один вопрос:
В классе widget есть 4 указателя:

    QGraphicsScene  *scene;     /// Объявляем графическую сцену
    Triangle        *triangle;  /// и треугольник
    QTimer          *timer;     /* Объявляем игровой таймер, благодаря которому
                                 * будет производиться изменения положения объекта на сцене
                                 * При воздействии на него клавишами клавиатуры
                                 * */
 
    QTimer              *timerCreateApple; 

В конструкторе класса они создаются с помощью new, но в деструкторе мы не освобождаем память, например вот так:

Widget::~Widget()
{
    delete ui;
    delete triangle;
    delete timer;
    delete timerCreateApple;
}

Разве не правильней будет освобождать память в деструкторе?

Андрей, Вы совершенно правы. Освобождать память в деструкторе будет правильным. Я допустил оплошность в данном случае, но эта оплошность была вызвана тем, что я хотел применить одну из особенностей самого Qt фреймворка. Но в итоге тоже забыл про это )))

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

То есть корректная запись должна была выглядеть так:

QGraphicsScene        *scene = new QGraphicsScene(this)
// this - это будет указатель на widget

Если следовать этому правилу, то тогда нет нужды удалять такие объекты в деструкторе. Фреймворк Qt гарантирует их удаление.