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

Какое API выбрать для джойстиков? (4 стр)

Страницы: 1 2 3 4 5 Следующая »
#45
15:56, 26 сен. 2019

nes
> Приходит сообщение и в этот момент дергается каллбек,
> в оболочке Виндоуз все так работает,
> что не устраивает?
Это так работает для стандартных диалоговых приложений. Ты же не рисуешь сцену в WM_PAINT :)


#46
15:57, 26 сен. 2019

Мизраэль
>Ты же не рисуешь сцену в WM_PAINT :)
Не поверишь...

#47
12:19, 27 сен. 2019

nes
> Не поверишь...
Божечки, неужто ру.геймдев за последние 10 лет так сильно деградировал? Теперь наверное можно говорить, покажи мне свой message loop и я скажу какой ты программист.

#48
12:33, 27 сен. 2019

Мизраэль
А в чем заключается деградация?
Или у нас WINAPI стало работать по-другому,
за последние 20 лет?

#49
9:50, 30 сен. 2019

nes
> Или у нас WINAPI стало работать по-другому,
Я утрирую конечно. Игровой цикл работает параллельно с циклом сообщений окна. Они по функциям вообще не пересекаются обычно, там и скорости совсем другие. А тут и ввод и перерисовку кто-то делает в цикле окна. Раньше напрямую с драйверами оборудования работали, потом через DX, который довольно тонкий на самом деле. Теперь ключевую функцию игры (а ввод - это ключевая функция), делаем через один из самых тормознутых механизмов в системе - через события окна. Жесть в общем :)

#50
10:05, 30 сен. 2019

nes
> Приходит сообщение и в этот момент дергается каллбек,
> в оболочке Виндоуз все так работает,
> что не устраивает?

Инпут лаг не устраивает.  Больше 5мс для нативной программы неприемлемы.

#51
(Правка: 12:34) 12:33, 30 сен. 2019

Мизраэль
>делаем через один из самых тормознутых механизмов в системе - через события окна. Жесть в общем :)
Откуда вы такие беретесь?
Покажи мне пример, как опрос ввода в мейн лупе,
будет работать быстрее его обработки в сообщениях.

0iStalker
Если у тебя рендер кадра вешает мейн луп,
то один хрен где ты будешь ловить ввод (в мейн лупе или в сообщениях),
будет лаг.
Если только ты не выносишь обработку ввода в отдельный поток...

#52
(Правка: 13:01) 12:56, 30 сен. 2019

nes
> Если только ты не выносишь обработку ввода в отдельный поток...

ох... https://docs.microsoft.com/en-us/windows/win32/api/xinput/nf-xinp… inputgetstate

nes
> или в сообщениях)

Через сообщения оно вообще с непредсказуемым лагом прилетает и ты  не получаешь данные именно тогда когда они тебе нужны, а в следующем (или через 10) кадре.    Для быстросемплов, WM_ функции ещё оправданы, использовать же их в продакшене, - это какой-то не очень умный нонконформизм.

#53
13:06, 30 сен. 2019

0iStalker
Нужны тесты, а так все голословно, как доберусь до жостиков, тогда будет видно.

#54
20:34, 30 сен. 2019

0iStalker

ох... https://docs.microsoft.com/en-us/windows/win32/api/xinput/nf-xinp
inputgetstate

...а потом в монитор летит джойстик со словами проклятий авторам игры, которые не подумали, что между двумя кадрами игрок может успеть нажать кнопку, которую асинхронные проверки не заметят и не будет (прыжка над пропастью, выстрела в противника на последнем HP, выбери следующее).
#55
(Правка: 23:20) 23:12, 30 сен. 2019

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

Но это совсем не означает что игры предназначенные для игры на клавиатуре и мыше нужно переписывать с WM_KEYDOWN на что то еще. И тем более не следует использовать xinput для опроса клавиатуры.

#56
4:54, 1 окт. 2019

foxes

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

Аппаратные прерывания использовались для PS/2 мышек и клавиатур, которые почти вымерли.
Современные USB мышки и клавиатуры работают практически также как и джойстики - через polling состояния устройства системой с некоторой частотой.
Но это совсем не означает что игры предназначенные для игры на клавиатуре и мыше нужно переписывать с WM_KEYDOWN на что то еще. И тем более не следует использовать xinput для опроса клавиатуры.

Я не знаю по какому принципу работает xinput, но мне бы показалось странным, если бы приложению дали интерфейс для прямого опроса состояния устройства (не жирновато ли каждому приложению тыкать джойстик параллельно с неизвестной частотой?), а не закэшированного системой. Через Raw input и WM_INPUT как раз по идее и должны идти сообщения с той частотой, с которой система успевает опросить устройство (+лаг обработки очереди оконных сообщений приложением, но благо с сообщением ещё приходит и время его отправки).
#57
9:09, 1 окт. 2019

nes
> Покажи мне пример, как опрос ввода в мейн лупе,
> будет работать быстрее его обработки в сообщениях.
Рихтера читать не пробовал?

#58
9:36, 1 окт. 2019

gkv311
> ...а потом в монитор летит джойстик со словами проклятий авторам игры, которые
> не подумали, что между двумя кадрами игрок может успеть нажать кнопку, которую
> асинхронные проверки не заметят и не будет (прыжка над пропастью, выстрела в
> противника на последнем HP, выбери следующее).
Пусть цикл опроса устройств ввода будет 10мс, т.е. пользователь за 10мс успел нажать и отпустить кнопку?

gkv311
> но мне бы показалось странным, если бы приложению дали интерфейс для прямого
> опроса состояния устройства (не жирновато ли каждому приложению тыкать джойстик
> параллельно с неизвестной частотой?),
не поверишь, в DI ещё и эксклюзивный режим доступа к устройствам ввода есть и игры его даже устанавливают.

gkv311
> Через Raw input и WM_INPUT как раз по идее и должны идти сообщения с той
> частотой, с которой система успевает опросить устройство (+лаг обработки
> очереди оконных сообщений приложением, но благо с сообщением ещё приходит и
> время его отправки).
Раз уж мы заговорили о конкретных цифрах, хочу услышать частоту с которой система опрашивает устройства.
Потом попробуем оценить лаг обработки оконных сообщений, учитывая, что у нас всего 4 ядра и игра имеет потоки, которые интенсивно грузят эти ядра.

#59
9:52, 1 окт. 2019

gkv311
> между двумя кадрами игрок может успеть нажать кнопку, которую асинхронные
> проверки не заметят

Вообще во всех старых консолях 8/16 бит опрос геймпадов производился с частотой обновления телевизионного сигнала (50/60 герц) и был чисто state-базированным - каждый кадр вытягивалось полное состояние кнопок и сравнивалось с предыдущим.
Как мы знаем никто не жаловался.

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