Ил2: Битва за Форс Фидбек (MS FFB2+TrackIR)

[l3VGV]

На гитхабе более стабильные версии, но задержка чуть выше. Но более надежны и совместимы с другим джойстиковским софтом. С логитехами и прочими с собственной реализацией драйверов - как повезет(обычно  везет).

 

https://github.com/l3VGV/FixFFBStutterH/releases

Брать просто последний релиз, класть как по инструкции, рядом с ЕХЕ игры, соответствующей битности. Работает с любыми играми, не только Ил2. И в рейсингах заработает. И в вафандре(если отключить античит, можно оценить как оно в пробном вылете против ботов).

 

 

Агрессивные, с минимальными задержками. По сути - эксперементальные. На нормальной машине, без лишнего хакерского софта управления джойстиками, заработают и эти.

32 бита https://forum.il2sturmovik.ru/applications/core/interface/file/attachment.php?id=101303

64 бита https://forum.il2sturmovik.ru/applications/core/interface/file/attachment.php?id=101274

 

 

Тестовая софтина чтобы оценить задержки. Если более нескольких единиц мс - плохо, беда, будут фризы.

https://github.com/l3VGV/FFBTest/releases/

Подхватывает первый ФФБ девайс в системе. 

 

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

[2BAG_Miron]

6 часов назад, l3VGV сказал:

для поклонников MS FFB2 я предложу решение аппаратное.

Расскажи, плз.

[l3VGV]

5 часов назад, 2BAG_Miron сказал:

Расскажи, плз.

 

Што именно? Воткнул туда джой, саму штуку в комп. Погнал.

 

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

Изменено 17 ноября 2020 пользователем l3VGV

[Harh]

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

[l3VGV]

1 минуту назад, Harh сказал:

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

 

1 минуту назад, Harh сказал:

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

 

 

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

Все помнят как умирающий HDD ставит колом всю систему и даже курсор мыши начинает прыгать? Все помнят, что вызовы Direct3D бессмысленно делать из разных потоков? Пока один не завершится, другой не начнется.

Привет архитекторам микрософта. Зачем так сделано? Скорее всего массовый набор пограмистов не очень высокого качества, сделал невозможным качественный истинно многопоточный подход.

 

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

 

Поэтому нужно делать маленькое тестовое приложение, кубик, вращаемый мышью и тракиром, и чтобы в фоне, в FFB шли данные, установка усилия 60раз в сек. И оттуда уже смотреть профилировщиком, что, кто, в какой момент. Опятьже насколько глубоко можно будет заглянуть, зависит от того сколько исходников даёт микрософт на директх.

 

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

 

[2BAG_Miron]

1 час назад, l3VGV сказал:

Воткнул туда джой, саму штуку в комп.

Такая штука уже есть? Сделать сложно? С игрой в обозримом будущем хз кто будет заниматься. Это проблема с РоФ.

А обратку в игре хочется. Т.ч. проще стразу "штуку-интерфейс" паять начать)))

[l3VGV]

35 минут назад, 2BAG_Miron сказал:

Такая штука уже есть?

 

Есть прототип такой штуки.

 

 

35 минут назад, 2BAG_Miron сказал:

Сделать сложно?

 

Кроме меня, похоже, никто не смог.

 

 

36 минут назад, 2BAG_Miron сказал:

Т.ч. проще стразу "штуку-интерфейс" паять начать)))

 

Вот пайка тут, совершенно ничтожный фактор. До пайки, ещё нужно дожить. 

 

 

 

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

[2BAG_Miron]

Ну что же, 11 лет ждали и ещё подождём

 

[propeler]

14 часов назад, l3VGV сказал:

Вопросов много. Догадок - валом

Проверь с помощью USBLyzer или чего то подобного время между пакетом от компа и ответом от девайса для мсффб и собственной разработки. Есть между ними разница? Мой деаайс в Ил не вызывает никаких понижений фремрейта. А майкрософтовсклго нет чтоб проверить.

[l3VGV]

37 минут назад, propeler сказал:

USBLyzer

 

У меня не работает. Если выбираю на ms ffb2, прога просто самовыпиливается, без сообщений об ошибках. И неважно напрямую в контупер вставлено или во внешний USB хаб.

 

На старой мамке с х58 такого небыло. А вот с новой, такое...

 

Более того, я там вижу только время события. А вот сколько прошло между запросом и ответом, это где смотреть? Такое видел только в аппаратных анализаторах. За большие и очень большие деньги.

 

 

Изменено 17 ноября 2020 пользователем l3VGV

[RED_REX]

Мда.

Вспомнил тут, как хорошо игралось на старичке на MSFFB2 и TrackIR 3 Pro на клипсе + РУД Х-52 и даже без педалей.

Ни фризов, ни конфликтов...

 

Всего-то проблем и споров было - правильность отрисовки преломления бронестекла ("Oleg"s bar"), улучшенный взгляд на 6 и "две недели". )))

[Strong]

Напомните. Если такая проблема в ДКС и других играх?

[l3VGV]

Да вопщемто, во всех.

 

https://forum.il2sturmovik.com/topic/26746-trackir-and-ffb-working-together-cause-terrible-stuttering/page/5/

 

https://steamcommunity.com/app/223750/discussions/2/3398435622555331926/

 

https://forums.codemasters.com/topic/34779-logitech-g27-causes-stuttering-when-plugged-in/

[l3VGV]

Вести с фронтов.

 

Заделал мелкое тестовое приложение, на базе https://github.com/walbourn/directx-sdk-samples/tree/master/DirectInput/FFConst

 

Цепляется к джойстику, создает эфект констант форс, и потом по таймеру(60Гц, 16мс) рандомно меняет параметры направления и силы.

 

Оказалось. И ms ffb2 и мой самопал, имеют одинаковое время работы функции g_pEffect->SetParameters, в случае моего настольного коньтукпера - 50мкс. Микросекунд. Немало, но всётаки СОМ и вот это вот всё. Тем не менее, такое значение никак не может быть причиной лагов или падения фпс. Значит косяк гдето внутри директикса? Всётаки чтото когото блокирует. Но не в коде приложения?

 

Но чтобы это затестить нужно сделать полноценное 3Д приложение. Кубик, взаимодействие с мышой, тракиром. 

 

Добровольцы, стройся!

 

 

Изменено 8 декабря 2020 пользователем l3VGV

[propeler]

Ил два не меняет параметры эффекта. Он рестартует их. Посмотри пакеты в каком порядке шлёт ил 

[l3VGV]

43 минуты назад, propeler сказал:

Ил два не меняет параметры эффекта. Он рестартует их.

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

В обычном режиме идёт потоком именно установка параметров.

 

 

43 минуты назад, propeler сказал:

Посмотри пакеты в каком порядке шлёт ил 

ил2.log.txt

Лог прямо изнутре контроллера приведу прикрепленным файлом. Он довольно большой, а как спйолеры делать на этом форуме я не понимаю.

 

Создание эффекта в логе это HIDPIDCreateNewEffectReport, обновление параметров HIDPIDSetConditionReport. Видно, что последний и есть основной в потоке. Остановки или удаления - вообще нет.

 

EFFECT_START, это последствие вызовов вида 

hr = g_pEffect->SetParameters(&eff, DIEP_DIRECTION |
        DIEP_TYPESPECIFICPARAMS |
        DIEP_START)

 

 

Таким образом, на основе задокументированных фактов - со стороны Ил2 не вижу осудительных действий. Ил2 - молодец.

 

***

 

Для порядка замерил и время создания эффекта g_pDevice->CreateEffect - примерно 3мс, опять одинаково в обоих случаях. 

Изменено 8 декабря 2020 пользователем l3VGV

[propeler]

Как вы интерпретируете эту повторяюшуюся последовательность? 

вам приходит первый спринг:

блок офсет 0 с нулями

блок офсет 1 с усилием

старт эффекта

и сразу за ним второй спринг:

блок офсет 0 с усилиями

блок офсет 1 с нулями

старт ейфекта

 

Эта последовательность повторяется. 

Как у вас два спринга и две синусоиды  в разных блок индексах?

HIDPIDSetConditionReport 455123
    effect_block_index 1
    effect_type EFFECT_SPRING
    block_offset 0
    cp_offset -1
    instance1 0
    instance2 0
    positive_coefficient -1
    negative_coefficient -1
    positive_saturation 0
    negative_saturation 0
    dead_band 0

***
HIDPIDSetConditionReport 455125
    effect_block_index 1
    effect_type EFFECT_SPRING
    block_offset 1
    cp_offset -1
    instance1 0
    instance2 0
    positive_coefficient 29
    negative_coefficient 29
    positive_saturation 59
    negative_saturation 59
    dead_band 0

***
HIDPID_SetEffect_Report 455127
    effect_block_index 1
    effect_type EFFECT_SPRING
    gain 255
    sample_period 0
    start_delay 0
    duration 65535
    direction_enable 1, direction_x 63, direction_y 0
    enable_axis_x 0, enable_axis_y 0
    trigger_button 255, trigger_repeat_interval 0

***
HIDPIDEffectOperationReport 455128
    EFFECT_START 1

***
HIDPIDSetConditionReport 455216
    effect_block_index 3
    effect_type EFFECT_SPRING
    block_offset 0
    cp_offset -1
    instance1 0
    instance2 0
    positive_coefficient 34
    negative_coefficient 34
    positive_saturation 68
    negative_saturation 68
    dead_band 0

***
HIDPIDSetConditionReport 455218
    effect_block_index 3
    effect_type EFFECT_SPRING
    block_offset 1
    cp_offset -1
    instance1 0
    instance2 0
    positive_coefficient -1
    negative_coefficient -1
    positive_saturation 0
    negative_saturation 0
    dead_band 0

***
HIDPID_SetEffect_Report 455220
    effect_block_index 3
    effect_type EFFECT_SPRING
    gain 255
    sample_period 0
    start_delay 0
    duration 65535
    direction_enable 1, direction_x 63, direction_y 0
    enable_axis_x 0, enable_axis_y 0
    trigger_button 255, trigger_repeat_interval 0

***
HIDPIDEffectOperationReport 455221
    EFFECT_START 3

 

Кстати вот коммент из кода на гитхабе:

Цитата

// Don't allow setting effect more often than
	// 100ms since every time an effect is set, the
	// device will jerk.
	//
	// Note: This is not neccessary, and is specific to this sample

Как думаете, почему?

Изменено 8 декабря 2020 пользователем propeler

[l3VGV]

22 минуты назад, propeler сказал:

старт ейфекта

 

Эта последовательность повторяется. 

 

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

 

 

22 минуты назад, propeler сказал:

Как у вас два спринга и две синусоиды  в разных блок индексах?

 

А где им быть, как не в разных блоках? по спрингу на ось, синусы это наверно вибрация какаято, также по одному на ось.

 

Откуда там в спрингах нули и зачем, вот незнаю. Пока не закончил силовую часть, не могу сказать что конкретно оно имеет в виду. Но может связано с тем, что разрешение по осям у меня довльно слабое а дёргал рячаг я весьма сильно, то в края то в центр, ну и самалет колбасило от души.

 

 

  

22 минуты назад, propeler сказал:

Как вы интерпретируете эту повторяюшуюся последовательность? 

 

Как обработку вызова g_pEffect->SetParameters. В зависимости от аргументов, происходит и разныая последовательность вызовов.

 

Вот заделал и лог для ForceTest, этот пружинам параметры обновляет без нулей, но страт - есть, но не всегда. Очень загадочно.

 

ForceTest.log.txt

 

 

***

 

Вот снял лог FFConst. Но тут только EFFECT_CONSTANT, нужно будет попробовать сменить на пружины, посмотреть, что будет...

 

 

FFconst.log.txt

 

 

 

Изменено 8 декабря 2020 пользователем l3VGV

[propeler]

Только что, l3VGV сказал:

А где им быть, как не в разных блоках? по спрингу на ось, синусы это наверно вибрация какаято, также по одному на ось.

Ну у меня один спринг и одна синусоида. В самом начале там где происходят HIDPIDCreateNewEffectReport вам приходит спринг, потом синус, потом опять спринг и опять синус. И вы отдаете два разных effect_block_index. Тоесть создаете по два еффекта и на спринг и на синус. Вот мне и интересно, это такая задумка, или не задумка. 

[l3VGV]

17 минут назад, propeler сказал:

В самом начале там где происходят HIDPIDCreateNewEffectReport вам приходит спринг, потом синус, потом опять спринг и опять синус. И вы отдаете два разных effect_block_index.

 

Ну, раз оно столько раз дёргает креайте ефект, то я ей и делаю...

 

 

17 минут назад, propeler сказал:

Вот мне и интересно, это такая задумка, или не задумка. 

 

Затрудняюсь обоснованно ответить почему так. Остальной софт так не делает.

 

Я думаю дело в том, что оно создало эфекты для Х и У раздельно потому что ООП или ещё чо. И надеюсь для оси Z тоже создаст отдельный эфект.

(т.е. блок 3 осфет 0 это Х, а блок 1 офсет 1 это У. Ну да, можно было и в один эфект, но...)

 

Ябы тоже раздельно запрограмил(но чисто из лени), тут просто нет смысла экономить. 

 

 

 

 

Изменено 8 декабря 2020 пользователем l3VGV

[l3VGV]

4 часа назад, propeler сказал:

Кстати вот коммент из кода на гитхабе:

Цитата

// Don't allow setting effect more often than
	// 100ms since every time an effect is set, the
	// device will jerk.
	//
	// Note: This is not neccessary, and is specific to this sample

Как думаете, почему?

 

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

 

Также, если посмотреть в лог, то число это мс, с момента старта мк. Можно обратить внимание, что новые параметры пружин приходят раз в  примерно 100мс, не смотря на то что я явно поставил 60фпс в конфиге ила.

[l3VGV]

А если посмотреть ещё и в лог FFConst, то можно увидеть, что и там данные входят также не чаще раза в 100мс! Ну и дела.

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

 

Это чтоже получается. Нагрузка на шину у нас крайне редкая, а тормоза и зафризивания адовые. Ану как оно тама внутре динпунского пида, ждёт эти 100мс крутя пустой цикл? Но при этом блокируя шину, чтоле.  Эх вотбы както внутрь то поглядеть а!

Изменено 8 декабря 2020 пользователем l3VGV

[l3VGV]

Продолжаем тяжелые позиционные бои.

 

Вчера находясь в полусонном состоянии, перепутал некоторое.

 

13 часов назад, l3VGV сказал:

А если посмотреть ещё и в лог FFConst, то можно увидеть, что и там данные входят также не чаще раза в 100мс! Ну и дела.

 

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

 

На всякий случай. FFConst_no100ms.zip

 

 

Лог также снял. Видно что теперь поток команд очень плотный.  ffconst_no100ms.log.txt

 

Никаких тормозов мыши,  когда шевелишь в окне FFConst - нету. Почемуже тогда есть в играх...

 

 

***

 

 

Также залез в конфиг ила. И что вы думаете.

 

[KEY = force_feedback]
    amplitude = 1.00000
    enabled = 1
    force = 1.00000
    update_freq = 10.000000
[END]

 

А ведь был уверен, что поставил 60!

 

 

Вот это совпадение...

 

 

***

 

 

  

13 часов назад, l3VGV сказал:

Эх вотбы както внутрь то поглядеть а!

 

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

 

Кто знает, как пройтись отладчиком по методу СОМ объекта? 

 

 

Изменено 9 декабря 2020 пользователем l3VGV

[HeXyaH]

28 минут назад, l3VGV сказал:

...

Также залез в конфиг ила. И что вы думаете.

 

[KEY = force_feedback]
    amplitude = 1.00000
    enabled = 1
    force = 1.00000
    update_freq = 10.000000
[END]

А ведь был уверен, что поставил 60!

...

На всякий случай - это у них частота опроса FFB-устройства, в герцах. Не уверен, что ставить > 10 имеет смысл ...

Но об этом лучше спросить непосредственно Петровича - это результаты его скромных усилий на ниве борьбы с лагами ФФБ.трэкир ...

[l3VGV]

52 минуты назад, =RNN=HeXyaH сказал:

Не уверен, что ставить > 10 имеет смысл .

 

А вот это нынче легко проверить. Когда есть вывод в лог!

 

Поставили да посмотрели.

 

 

 

Было

между Х и Х

HIDPIDSetConditionReport 464900
    effect_block_index 1

HIDPIDSetConditionReport 465000
    effect_block_index 1

 

между Х и У

HIDPIDSetConditionReport 464900
    effect_block_index 1

HIDPIDSetConditionReport 464989
    effect_block_index 3

 

 

Стало

между Х и Х

HIDPIDSetConditionReport 4786811
    effect_block_index 1

 

HIDPIDSetConditionReport 4786891
    effect_block_index 1

 

хм, кхм. чот всёравно много

 

 

а между Х и У

HIDPIDSetConditionReport 4786629

и
HIDPIDSetConditionReport 4786700
    effect_block_index 3

 

 

 

 эффект есть, но не такой значительный как ожидалось. Должно было упасть до, примерно, 16мс.

 

Сам вывод в лог тоже занимает какоето время, плюс каждая посылка это 1-2мс. Но тем не менее, тест на FFConst показывает разницу в 5-6мс

 

HIDPID_SetEffect_Report 31049
    effect_block_index 1

HIDPID_SetEffect_Report 31054
    effect_block_index 1

 

 

Изменено 9 декабря 2020 пользователем l3VGV

[l3VGV]

Намечается некоторый успех. Предлагаю всем неравнодушным немного позамирать сердцем.

 

!Возможно! найдена причина. И, следовательно, немного понятнее как БЖСЭ.

[l3VGV]

Смешное для дополнительного привлечения внимания к проблеме.

 

http://www.prepared3d.com/forum/viewtopic.php?t=132113
 

[ROSS_TaTaPuH]

10 часов назад, l3VGV сказал:

Намечается некоторый успех. Предлагаю всем неравнодушным немного позамирать сердцем.

 

!Возможно! найдена причина. И, следовательно, немного понятнее как БЖСЭ.

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

[l3VGV]

мышь ком опртовая хоть и не юсб но хид
тракир хоть и не хид но юсб
обычная мышь и ффб джой и хид и юсб а джой ещё и пид
а тормозят все вместе! патчиму!?

 

 

Основная причина фризов, это блокировка потока вызывающего SetParameters !системой! в момент работы внутре dinputа. Блокировка происходит потому что те кто програмировал системную часть вот этого вот всего, были не так ответственны как того хотелосьбы.

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

dinput:

-Ага. WriteFile(hiddevice, КусокПамяти)

Дьявол в нюансах. 
Изначально я сделал тестирование скорости в 1 эфект и зациклил ему изменение параметров 60раз в сек. Получил время работы функции 50мкс. Хм, подумал я. А гдеже тормоза? Сделал больше эфектов, как в игре, 4. И тормоза вот они, раскрылись.

Время работы функции стало 12500мкс. Т.е. пока эфект был один, он успевал уйти по шине до того как потребуется делать следющее действие, т.е. какойто буфер там внутри всёже есть, иначе время отправки сразуже былобы равно времени отклика джойстика * количество пакетов(обычно 2-3 пакета), это былибы 2-3мс для времени отклика в 1мс(а у мс ффб приемный ендпоинт 4мс). А получалось почти в 50 раз меньше.

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

 

Понятно никто не будет для нас патчить легаси dinputа. Наше спасение в наших руках.

 

 

Важно понять и принять, что дело не в том сколько данных пересылается, а сколько требований на пересылку происходит, следующая пересылка может начаться только в слеющий интервал.
В нашем случае нужно мыслить количеством посылко в сек. Если нужно засунуть команд ещё, а интервал ещё не начался или прошлый эфект занимающий 2-3 интервала ещё не отработал, то оно будет блокирующе ждать, вот вам и фриз.

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

 

Уже понятно почему введение обещего таймера обновлений не принесло существенных улучшений? Эфекты идущие один за другим(а предидущий ещё не выгрузился) всёравно приводили к блокировке. Нужно не просто Х раз в секунду делать ВСЁ и уменьшать Х для ускорения. Нужно делать всё постоянно, но между каждым действием иметь паузу достаточную для ухода по шине. Это программа Минимум.

 

Ну и дополнительные оптимизации. Это программа Максимум.

 

 

 

Вижу такой План.

Минимум.
Легко посчитать, что если ms ffb2 имеет интервал на прием ффб команд 4мс. Значит в 1с это 250 посылок. Одно полное обновление параметров одного эфекта это пусть 3 посылки(см лог). Значит 83 обновления в сек. Для 4х эфектов это 20-21 обновление. Это если не вдаваться в оптимизации. И просто обновлять эфекты с флагом DIEP_NODOWNLOAD, а потом в отдельном потоке с паузами между командами их отсылать в девайс. Остылать их в основном потоке взаимодействия с пользователем(где сейчас похожде висит мыша и тракир и прочее) - нельзя, паузы будут заметно сказываться на отзывчивости. Т.е. как минимум нужно добавить в SetParameters флаг DIEP_NODOWNLOAD, и создать ещё один поток с выгрузкой(метод эфекта Download) в девайс.
(если объеденить эфекты по осям, не делать раздельно для Х и У, то количество обновлений удвоится)
(для девайсов где интервал 1мс, число обновлений возрастает пропорционально)

Максимум.
Предлагается объеденить эфекты для осей Х и У в один, это сразу сократит количество посылок в 2 раза. Хотя и усложнит код, тут ещё вызывает опасение а как игра справится с педалями, где только 1 ось. Также нужно внимательно отнестись и к необходимости обновлений. Судя по логу, в устройство летят кучи посылок совершенно одинакового содержания, увы dinput не контролиурет были или нет изменены значения или въехали ровно теже что и были раньше, это нужно делать самостоятельно.
Внимательно отнестись к тому что именно мы обновляем. врятли у пружин постоянно меняется направление, скорее всего только cp_offset и то только когда изменяются параметры тримирования. А усилие, в зависимости от скорости, меняется почаще. 

Требуется понимание какие параметры идут в каких пакетах, например есть эфекта GAIN и DIRECTION, это пакет SetEffect_Report, а есть cp_offset смещение ценра у пружины и positive_coefficient positive_saturation влияющие на усилие это SetConditionReport. Не нужно слать то что не менялось! Внимательность к флагам  DIEP_DIRECTION и DIEP_TYPESPECIFICPARAMS, при установке параметра поднимать только нужные флаги.

    
Также предлагается убрать постоянный старт, это отдельная посылка. Старт предлагается делать только 1 раз. Это сократит количество посылок ещё на треть. Был старт или нет, активен эфект или нет нужно помнить самостоятельно. И не посылать без нужды. Это флаг DIEP_START.

Внимательно отнестить к эфекту тряски. если тряски от разных источников разные, то нужно сделать несколько разных эфектов и их только запускать и останавливать, а не изменять параметры уже загруженных эфектов.
Эфекты тряски также желательно объеденить по осям.

Таким образом можно будет увеличить количество полезных обновлений в секунду раз в 5-6. А если делать посылки только когда эфекты действительно менялись, то и вообще рай!

 

Также требуется пересмотреть механизм собственно обмена с устройством. Предлагается разделить собственно обновление эффекта и его выгрузку в девайс. Обновление без выгрузки всегда происходит за примерно 10мкс(SetParameters с флагом DIEP_NODOWNLOAD). А вот собственно выгрузку нужно производить в отдельном фоновом потоке, который будет иметь в себе простой вечный цикл, бегающий по всем созданным эфектам, проверяющий что они были обновлены и их нужно отправить, и если отправил то делать паузу. Величину паузы можно для каждой модели джоя можно завести соответствие, благо джоев в ффб немного, или воообще вынести в настройки, поставив по умолчанию безопасное значение(16мс дадут минимум 60 посылок в сек, это много если не посылать лишнего).

Тут кажется разумным развести ООП, контейнеры, инкапсуляцию и прочую абстракцию. Создать свой менеджер эфектов, где через сеттеры проверять будет фактическое изменение или нет, и если оно было то смотреть в какой части, апдейтить реальный эфект только в той части что менялась.

 

 

 

Создал тестовый софт, который эмулирует работу игры. Можно потыкав в кнопочки задать количество эфектов, паузы между посылками и своими глазами убедиться в

действенности предлагаемого метода. Потребуется джойстик с FFB, рекомендуется MS FFB2.

 

Бинарник для юзеров и исходник для ознакомления с нюансами брать там: https://github.com/l3VGV/FFBTest

 

 

 

Нажимаем кнопку Start
Кнопками спинбокса регулируем задержку
У меня резкий рывок времени происходит при изменнии с 7 на 8

PS 
также думается что симптомы можно ослабить если написать дарайвер и реализовать кеширование там. Тогда и игры не надо будет переписывать. И работать будет сразу во всех играх.

 

 

Вся эта боль нужна только потому, что те кто делал dinput, совершили абсолютный минимум работы, что типично для микрософта. И теперь это боль помножена на количество проектов которым нужен FFB. Слава микрософту.
А если предположить что ктото извне нашел решение и запетантовал его? Тогда остальным ничего кроме боли не остается. Слава микрософту дважды.

(выражаю благодарность проектам WINE и ReactOS)

 

 

[SDV_ZoZo]

17.11.2020 в 05:14, l3VGV сказал:

Возможно - программного решения нет. Если это получится подвердить, тогда для поклонников MS FFB2 я предложу решение аппаратное.

В БоБ не фризит и нормально связка trackir и ffb работает.

18.11.2020 в 21:11, Fuhrer сказал:

Напомните. Если такая проблема в ДКС и других играх?

В ДКС тоже связка трекир и MSFFB2 работает без проблем.

08.12.2020 в 23:00, l3VGV сказал:

Таким образом, на основе задокументированных фактов - со стороны Ил2 не вижу осудительных действий. Ил2 - молодец

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

Цитата

Имя сбойного приложения: Il-2.exe, версия: 1.0.0.1, метка времени: 0x5f3a7f47
Имя сбойного модуля: pid.dll, версия: 10.0.19041.1, метка времени: 0xf385cf53
Код исключения: 0xc0000005
Смещение ошибки: 0x000000000000266e
Идентификатор сбойного процесса: 0x1874
Время запуска сбойного приложения: 0x01d688fb41d6dd86
Путь сбойного приложения: E:\Games\IL-2\bin\game\Il-2.exe
Путь сбойного модуля: C:\Windows\System32\pid.dll
Идентификатор отчета: 8cb10a41-a439-448b-b41e-c388b7d33269
Полное имя сбойного пакета: 
Код приложения, связанного со сбойным пакетом: 

 

Цитата

- Provider       [ Name] Application Error

- EventID 1000       [ Qualifiers] 0

Version 0

Level 2

Task 100

Opcode 0

Keywords 0x80000000000000

- TimeCreated       [ SystemTime] 2020-09-12T11:56:02.5301420Z

EventRecordID 3551

Correlation

- Execution       [ ProcessID] 0       [ ThreadID] 0

Channel Application

Computer HOME-PC

Security

 

[ROSS_TaTaPuH]

35 минут назад, SDV_ZoZo сказал:

В БоБ не фризит и нормально связка trackir и ffb работает.

В ДКС тоже связка трекир и MSFFB2 работает без проблем.

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

У меня как раз тоже самое с ил2. Жду решения с этим,  наблюдаю и надеюсь все получится с решением проблемы. В БОБ не за метил фризов собственно и в ДКС тоже их нет, вот проверить бы в цирке , есть ли там фризы в связке с трекир 5. Интересно а связка МС ФФБ2 и оупентрек как работает в ил2? ЕСТЬ ФРИЗЫ?

[propeler]

1 час назад, l3VGV сказал:

Предлагается объеденить эфекты для осей Х и У в один

То что я раньше писал. Если на криэйт еффект для синуса и пружины отдать один блок еффект то будет слать в два раза меньше. Я у себя в прошивке отдаю на оба запроса по криэйт спринг один блок, создаю один спринг эффект. Мне приходит в два раза меньше пакетов.

 

1 час назад, l3VGV сказал:

Максимум.
Предлагается объеденить эфекты для осей Х и У в один, это сразу сократит количество посылок в 2 раза. Хотя и усложнит код, тут ещё вызывает опасение а как игра справится с педалями, где только 1 ось. Также нужно внимательно отнестись и к необходимости обновлений. Судя по логу, в устройство летят кучи посылок совершенно одинакового содержания, увы dinput не контролиурет были или нет изменены значения или въехали ровно теже что и были раньше, это нужно делать самостоятельно.
Внимательно отнестись к тому что именно мы обновляем. врятли у пружин постоянно меняется направление, скорее всего только cp_offset и то только когда изменяются параметры тримирования. А усилие, в зависимости от скорости, меняется почаще. 

Требуется понимание какие параметры идут в каких пакетах, например есть эфекта GAIN и DIRECTION, это пакет SetEffect_Report, а есть cp_offset смещение ценра у пружины и positive_coefficient positive_saturation влияющие на усилие это SetConditionReport. Не нужно слать то что не менялось! Внимательность к флагам  DIEP_DIRECTION и DIEP_TYPESPECIFICPARAMS, при установке параметра поднимать только нужные флаги.

    
Также предлагается убрать постоянный старт, это отдельная посылка. Старт предлагается делать только 1 раз. Это сократит количество посылок ещё на треть. Был старт или нет, активен эфект или нет нужно помнить самостоятельно. И не посылать без нужды. Это флаг DIEP_START.

 

Идеальный вариант - старт всех нужных эффектов с infinite duration и потом только обновлять эффект через соответствующий репорт. Так делают подавляющее большинство автосимов например. Но. Кто будет эту часть в движке переписывать?  Для двух калек у которы FFB :)

[l3VGV]

25 минут назад, propeler сказал:

То что я раньше писал. Если на криэйт еффект для синуса и пружины отдать один блок еффект то будет слать в два раза меньше.

 

Два разных эфекта в один блок или две оси?

 

 

27 минут назад, propeler сказал:

Я у себя в прошивке отдаю на оба запроса по криэйт спринг один блок, создаю один спринг эффект. Мне приходит в два раза меньше пакетов.

 

Это очень смелый хак. Я на такое не готов

Так считаю что если пользователь просит 2 спринги то ему нужно и дать 2. А уж как он ими будет распоряжаться это его дело, не моё. А ну как вторая это вообще часть какогото временного спецефекта?

7 часов назад, ROSS_TaTaPuH сказал:

Для простого обывателя

 

С пользовательской стороны ничего не сделать.

Вариант со спец девайсом это не решение проблемы а отложение симптомов.

Либо тяжелое хакерство(написание своих драйверов) либо уповать на разработчиков, что выделят времени и заделают обход проблемы. Решить её не в наших силах, только найти как БЖСЭ.

1 час назад, SDV_ZoZo сказал:

В ДКС тоже связка трекир и MSFFB2 работает без проблем.

 

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

[l3VGV]

12.12.2020 в 08:05, ROSS_TaTaPuH сказал:

Для простого обывателя

 

В припадке хакерства, для простого обывателя, сообразил следующее. 

(на драйвер градуса накала припадка хакерства не хватило)

 

 

dinput8.zip

Это нужно достать из архива и положить в папочку игры рядом с файлом il-2.exe

 

 

 

Фризы уйдут. 

 

Там в полной мере, но хакерским способом, реализовано то что я выше описал как План Максимум.

 

 

Жалко конечно, что всё так получилось. Я уже плату развёл под растормаживатель(tm) (рабочее название) и даже мелкоконтроллеров закупил. Начал мечтать как невероятно разбогатею на его продажах. А оказалось...

Хоть и хакерство и косяк микрософтовский, но софтовое решение реально. Конечно если разработчики сделают всё в игре, то и ещё лучше будет. Зовите их сюда уже, кто умеет.

 

 

***

 

Работать должно в любой игре 64х битной игре. Классть рядом с исполняемым файлом. Для старых игр, под 32 бита, потом соберу.

 

***

 

 

17.11.2020 в 06:15, 2BAG_Miron сказал:

Расскажи, плз.

 

Всё, кина не будет. За неимением смысла в таковом.

Изменено 13 декабря 2020 пользователем l3VGV

[Harh]

1 час назад, l3VGV сказал:

Зовите их сюда уже, кто умеет.

 

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

[Oraclenok]

1 час назад, l3VGV сказал:

Фризы уйдут.

Не ушли.

[l3VGV]

17.11.2020 в 00:14, l3VGV сказал:

Так что, @AnPetrovich, не в "перегрузке пакетами" шины ЮСБ дело(помню вы озвучивали такую догадку).

 

А кстати.

 

@AnPetrovich получается почти прав. По сути вся проблема была в перегрузке шины, не по данным, а именно по посылкам. Даже учитывая что пропускной способности по байтам хватает в избытке, но исчерпывается количество интерупт запросов. Т.е. не перегрузка пакетами, а запросами.

Зря я тогда сразу отмёл эту догадку, на основе того что СОМ мыша тормозит. Ну, я думал что шина блокируется вся, а раз и на СОМ тормозит, то не в шине дело. Неверная логика. Но вот такого что функция вызова будет блокироваться я както не ожидал. Вот и...

 

 

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

 

***

 

12.12.2020 в 08:05, ROSS_TaTaPuH сказал:

Для простого обывателя

 

тем временем, версия для 32х бит. Ну как где ещё в играх ффб тормозить будет. 

https://github.com/l3VGV/FixFFBStutterH/releases

 

 

 

20 минут назад, oraclenok сказал:

Не ушли.

 

Подождем ещё отзывов. У меня ушли полностью.

 

Сделайте пока скриншот вот этой программой. 

https://www.ftdichip.com/Support/Utilities/usbview.zip

 

У меня, как видно, вообще на одной ветке с тракиром живёт, и теперь всё отлично.

 

[ROSS_TaTaPuH]

3 минуты назад, l3VGV сказал:

 

А кстати.

 

@AnPetrovich получается почти прав. По сути вся проблема была в перегрузке шины, не по данным, а именно по посылкам. Даже учитывая что пропускной способности по байтам хватает в избытке, но исчерпывается количество интерупт запросов. Т.е. не перегрузка пакетами, а запросами.

Зря я тогда сразу отмёл эту догадку, на основе того что СОМ мыша тормозит. Ну, я думал что шина блокируется вся, а раз и на СОМ тормозит, то не в шине дело. Неверная логика. Но вот такого что функция вызова будет блокироваться я както не ожидал. Вот и...

 

 

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

 

***

 

 

тем временем, версия для 32х бит. Ну как где ещё в играх ффб тормозить будет. 

https://github.com/l3VGV/FixFFBStutterH/releases

 

 

 

 

Подождем ещё отзывов. У меня ушли полностью.

 

Сделайте пока скриншот вот этой программой. 

https://www.ftdichip.com/Support/Utilities/usbview.zip

 

У меня, как видно, вообще на одной ветке с тракиром живёт, и теперь всё отлично.

 

Смогу затестить трекир5 про + МС ФФБ2 + ил2 БЗС только в феврале. Агромнейшее спасибо, что помогаете нам избавиться от фризов при пользовании джоя с обраткой.

[Oraclenok]

 

В Ил-2 пробовал пока мало, фризов ещё не заметил. А вот в РОФ они появились минут через пять. Да такие, что летать стало невыносимо, пришлось перенастраивать оси назад на обычный джойстик.

[l3VGV]

10 минут назад, oraclenok сказал:

В Ил-2 пробовал пока мало, фризов ещё не заметил. А вот в РОФ они появились минут через пять.

 

Будем разбираться. Хотя РОФ у меня гдето и валялся... найти его ещё надо.

 

Возможно потребуется прикрутить сквозную систему профилирования и логирования. А так, там просто нет мест чтобы тормоза появились "потом". Если началось нормально то должно так и быть. Но кто его знает, какие ещё особенности может скрывать от нас dinput.

Изменено 13 декабря 2020 пользователем l3VGV