Проектирование системы для считывания данных с устройств ввода (Часть первая)

[Sinatr]

Язык по видимому C++/CLI (net)?

Определение alias — это pseudonym, т.к. все переменные — это имена, то можно было это слово вообще не использовать. Просто уберите его из всего: Action, GetState, action_forward, и т.д.

с минимальным количеством кода

Программирую на C#, как-то стремно выглядит загрузка json (в C# это две строчки) и инициализация, не врете насчет «минимального»? Трижды вложенные циклы — это тоже нормально, Dictionary в С++ нет чтоли? Не критикую (т.к. языком не владею), а скорее интересуюсь.

[ENgineE]

Имена это вкусовщина, и не может быть предметом обсуждения. Хочется поразбиратся в С++, то просьба перейти на соответввующие обучающие ресурсы по С++.

Суть статьи донести идею лежащую в основе системы, само собой моя имплементация, это одна из вариантов имплементации, в вашем исполнения она будет другой, и это нормально.

Просьба давать коментарии по существу.

[Sinatr]

Ни на один из моих вопросов вы не ответили прямо. Чем ваш велосипед лучше/хуже других?

в поисках вдохновения я просматривал исходники других игровых движков

Каких именно? В статье отсылок нет. Было бы интересно почитать/сравнить с тем, как делают другие. А так статья — просто реализация, в стиле «смотрите как я могу», причем вы сами говорите, что «в вашем исполнения она (имплементация) будет другой».

Я объясню чем именно вызван мой интерес к статье: Destiny 2, и вообще все Bethesda игры — многоплатформенные игры, в которых полно косяков, один из самый раздражающих — это, как вы выразились, «хардкод» — непереопределяемый клавиши. И мне не понятно, почему это так сложно это сделать для компаний у которых сотни программистов. Может быть ВЫ пойдете работать в Bungie и научите их как надо? ;)

[cyberonix]

создавать велосипед, я в этом не вижу ничего плохого, главное что бы этот велосипед был с педалями

[GrimMaple]

А почему бы не сделать так?

typedef void ( __stdcall *btn_event_t)(param1, param2, ...)

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

[ENgineE]

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

[GrimMaple]

Ну, еще есть небольшая вероятность того, что с проверкой состояний вы просто «проморгаете» нажатие, если оно произошло достаточно быстро, и стейты поменялись с «нажат» на «не нажат» быстрее, чем ваш код успел на это отреагировать :) С событиями, как только поменялось состояние — сразу же вызвался код, что гарантирует обработку нажатия.
И маленькое имхо: подход с событиями кажется более объектно-ориентированным, чем дёрганье состояний, которое выглядит как Сишный код.

[qw1]

У колбеков свои минусы: непонятно, в каком потоке он вызван и нужна синхронизация, чтобы, например, сдвиг игрока при падении вниз и кнопкой «вперёд» не привели к гонке.

Безопаснее всего в колбеке включить флажок, что кнопка нажималась, а где-то в игровой логике этот флажок проверить (и не забывать эти флажки сбрасывать, чтобы нажатие «граната» в конце раунда не выстрелило в начале следующего).

[ENgineE]

Вы описываете сценарий, когда апдейст стейтов происходит в одном потоке, а код, опрашивающий стейты, происходит в другом потоке. В однопоточной реализации, как это сделано в коде статьи, подобный сценарий невозможен. Тема работы с многопоточностью, это отдельная тема. К тому же, использование эвентов не спасает от необходимости синхронизации, так как если будет дергаться код по обработки действия из потока, в котором обновляются контролсы, то надо этот код оборачивать критическими секциями, чтобы ничего не сломать. В общем, вопросы работы с мультипоточностью не являються темой статьи.

[GrimMaple]

В таком случае, подобный сценарий все еще возможен — из-за того, что сам код, опрашивающий киборду и джойстики, не успеет отреагировать на очень быстрый тап клавиши. Но это уже не проблема кода обработчика, это проблема кода, опрашивающего устройства.

[ENgineE]

Если расматривать не штатные условия, что игра/приложение адски тормозит и выдает пол кадра в секунду, тормозя тем самым всю систему, то конечно до драйвера не дойдет понимание, чтобы была нажата кнопка, но это совсем другая история, и проблема не в эвентах или стейтак, а в том, что все тормозит :)

[GrimMaple]

Вы недооцениваете лапы геймеров :) Я протестировал себя, и, как выяснилось, могу тапать кнопки со временем нажатия 20мс, чего будет достаточно, чтобы проворонить нажатие при чуть меньше 50фпс (1000/20). Еще не забываем, что для многих игр выдавать всего 30 кадров в секунду (33,3мс) вполне нормально. Так что проблема более обширная, нежели вы думаете. Я еще и не самый адский мэшер в плане клавиатуры, многие наверняка могут и побыстрее.

Скриншот

[qw1]

В хардкорных играх, в файтингах, например, есть буфер команд. При вводе комбо некоторые последующие движения можно ввести, пока не закончена анимация предыдущего удара. В-общем, обсуждать «абстрактный игровой движок» мало смысла, детали зависят даже от жанра игры.