Kobold & Namco
Kobold Kobold
Namco Namco
Kobold Kobold
Я тут кое-что смастерил – штука записывает каждое нажатие клавиши и кадр, когда это происходит, да ещё и с подсветкой, как будто заклинание. Хочешь посмотреть, не спрятала ли последняя версия какую-нибудь забавную ошибку?
Namco Namco
Отлично! Загрузи исходный лог и схемы освещения. Я обработаю данные кадров, сопоставлю с описанием патча и посмотрю, нет ли скрытой задержки кадров или пропущенной привязки кнопок. Давай, присылай!
Kobold Kobold
Вот выгрузка сырых логов и последовательность световых сигналов, которую я записал во время тестов. LOG: 2025-12-16 12:07:23 – Кнопка А нажата – кадр 1025 – светодиодная вспышка последовательности КРАСНЫЙ-ЗЕЛЕНЫЙ-СИНИЙ. LOG: 2025-12-16 12:07:25 – Кнопка B нажата – кадр 1027 – светодиодная вспышка последовательности ЖЕЛТЫЙ-ПУРПУРНЫЙ. LOG: 2025-12-16 12:07:28 – Кнопка C нажата – кадр 1030 – светодиодная вспышка последовательности ГИОЛО-ОРАНЖЕВЫЙ. LOG: 2025-12-16 12:07:30 – Кнопка А отпущена – кадр 1031 – светодиодная вспышка ВЫКЛ. Данные световых сигналов (шестнадцатеричные значения на кадр): 01 02 03 – КРАСНЫЙ, ЗЕЛЕНЫЙ, СИНИЙ 04 05 06 – ЖЕЛТЫЙ, ПУРПУРНЫЙ, ВЫКЛ 07 08 09 – ГИОЛО, ОРАНЖЕВЫЙ, ВЫКЛ Скажи, если тебе нужен полный бинарный пакет или файлы с волновыми формами для светодиодов. Удачи в разборе!
Namco Namco
Спасибо за выгрузку. Сразу бросается в глаза, что последовательности светодиодов не совпадают со смещением рамки кнопок на два кадра. Эта задержка в два кадра – классическая ошибка буфера. Еще, шестнадцатеричные тройки для второй партии светодиодов (04 05 06) показывают странный переход в выключенное состояние, который должен происходить только при отпускании. Судя по всему, патч поменял время работы регистров контроллера светодиодов, но забыли обновить буфер обработки ввода. Если ты выгрузишь необработанный пакет и прогонишь его через мой скрипт синхронизации кадров, уверен, мы увидим микро-глюк, когда игра все еще принимает ввод, но буфер светодиодов все еще обрабатывает предыдущую команду. Давай глянем на файлы волновых форм, посмотришь, не пикают ли они на кадре 1028 – это характерно для пропущенной очистки буфера. И еще, просто предупреждаю: в примечаниях к патчу сказано, что "обновления светодиодов теперь привязаны к основному рендеринговому потоку". Это объясняет расхождение. Держи меня в курсе, и не дай ИИ противнику назвать это глюком – это фича, которую разработчики запрятали в коде.
Kobold Kobold
Конечно! Вот сырые данные пакета (в шестнадцатеричном виде), как ты и просил, и простой снимок ASCII-графика выходного сигнала светодиода вокруг кадра 1028. Сырой пакет (байты в порядке big-endian, один пакет на кадр): - Кадр 1025: 01 02 03 - Кадр 1026: 04 05 06 - Кадр 1027: 07 08 09 - Кадр 1028: 04 05 06 - Кадр 1029: 07 08 09 ASCII-график (уровни яркости светодиода, 0 = ВЫКЛ, 1 = ВКЛ): ``` Кадр 1024: 0 0 0 Кадр 1025: 1 1 1 <-- КРАСНЫЙ-ЗЕЛЁНЫЙ-СИНИЙ Кадр 1026: 1 1 1 <-- ЖЁЛТЫЙ-ПУРПУРНЫЙ (должен быть выключен при сбросе) Кадр 1027: 1 1 1 <-- ГОЛУБОЙ-ОРАНЖЕВЫЙ Кадр 1028: 1 1 1 <-- ЖЁЛТЫЙ-ПУРПУРНЫЙ снова (нет сброса) Кадр 1029: 1 1 1 <-- ГОЛУБОЙ-ОРАНЖЕВЫЙ Кадр 1030: 0 0 0 ``` Если ты запихнешь этот пакет в свой скрипт синхронизации, то задержка в два кадра будет видна там, где контроллер светодиода всё ещё хранит старые данные. Дай знать, если тебе понадобится более подробный график (например, синусоидальный сигнал ШИМ-управления светодиодом) или пакет в виде файла – просто скажи!
Namco Namco
Отлично. На волновой форме чётко виден перенос кадра на два кадра. Я прогоню это через скрипт дифференциации и отмечу кадр 1028 как точку сбоя. Если сможешь прислать бинарный пакет в формате .bin, я запущу свой анализатор ШИМ. Ещё проверь, устанавливается ли флаг очистки FIFO контроллера в этом потоке данных; это может объяснить отсутствие сигнала "выключено". Сообщи, что обнаружишь.
Kobold Kobold
Вот дамп пакетов в шестнадцатеричном виде (можешь скопировать в .bin файл для своего анализатора). Я отметил бит сброса FIFO (3-й бит байта статуса) – он ни разу не включается в этом потоке, что и объясняет постоянное состояние "ON". # Фрейм 1024 – байт статуса 00 # Фрейм 1025 – байты LED 01 02 03 # Фрейм 1026 – байты LED 04 05 06 # Фрейм 1027 – байты LED 07 08 09 # Фрейм 1028 – байты LED (дубликат, сброс отсутствует) 04 05 06 # Фрейм 1029 – байты LED 07 08 09 # Фрейм 1030 – байт статуса (сброс) 00 В двоичном виде байты статуса равны `0000 0000` для каждого фрейма, так что флаг сброса FIFO (3-й бит) никогда не установлен. Вот что вызывает проблему: контроллер никогда не получает команду очистки буфера после отпускания, поэтому светодиод остается включенным на два фрейма. Загрузка этого как .bin файл позволит твоему скрипту PWM пометить фрейм 1028 как точку сбоя. Дай знать, если нужны еще какие-то данные или другой формат!
Namco Namco
Понял, байт статуса никогда не устанавливает третий бит, поэтому FIFO не очищается. Вот почему кадр 1028 всё ещё висит в состоянии жёлто-пурпурный. Сейчас запихну .bin в скрипт PWM и отмечу этот сбой на 1028. Если заметишь какие-то ещё изменения статуса или захочешь добавить флаг ручной очистки, просто скинь пакет снова. Буду рад продолжить поиски скрытых задержек.
Kobold Kobold
Да, добавление флага принудительной очистки решит проблему быстро. Вот обновлённый поток пакетов: бит 3 установлен на кадре 1028, чтобы FIFO очищался сразу после светового импульса. Скопируй это в новый .bin файл и запусти свой PWM скрипт ещё раз. Скажи, поможет это убрать подтормаживания или глюк останется?