TNT - 2D игра-головоломка.

[Хакер]

Сделал тестовую карты для проверки массовых взрывов (там же есть редактор) - тоже нет ошибок.

Я делал массовые взрывы таймером, и тоже ничего не поймал. И FireFox у меня не замешан никак.

Однако в обоих случаях вылета ошибка была именно во время массовых взрывов.

[ger_kar]

что ошибка происходит в момент массовых взрывов.

Ну как я и говорю:

Я думаю, что дело в какой-то ситуации в духе нехватки ресурсов или неудовлетворяемом одновременном обращении к ресурсу. В ходе которого ядерная часть даёт код ошибки, который конвертируется в итоге в E_FAIL.

Кстати по ресурсам. У меня старенький древний одноядерный Athlon 3200+ на котором ролики с ютюба можно смотреть только если больше ничего не потребляет ресурсов. Даже если во время просмотра начать двигать мышь, то звук начинает заикаться. Может в этом все дело, и поэтому на более мощных компах ошибка может и не возникать.

[ger_kar]

Протестировал версию, которую дал мне Хакер, специально для того, чтобы я воспроизвел ошибку.
Ошибку с нескольких попыток я поймал. Вот ее сообщение:

---------------------------
DirectSound Error
---------------------------
DSBStep.SetCurrentPosition() failed: Error code: 0x80004005 Description: Automation error
---------------------------
ОК
---------------------------

[Хакер]

Поймали ещё раз ошибку:

---------------------------
DirectSound Error
---------------------------
DSBFire.SetCurrentPosition() failed:
Error code: 0x80004005
Description: Automation error
---------------------------
ОК
---------------------------

На этот раз уже другой буфер, но тот же метод. Mikle, у меня пока предварительное подозрение, что может быть есть какие-то ограничения на перестановку текущей позиции у клонированных буферов?

[ger_kar]

Сделал тестовую карты для проверки массовых взрывов (там же есть редактор) - тоже нет ошибок.

Да уж взрывы там феерические, но вот ошибка на этой карте не хочет ловиться. Чаще всего ошибка бывает на 3 карте, чуть реже на 4. Один раз ловил на 5 и 9.

[Mikle]

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

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

[Хакер]

Итак, провели мы сеанс коллективной отладки с ger_kar'ом. Я расставил брекпоинты в отладчике, затем он играл и пытался спровоцировать сбой, затем я подключился и оценил улов в отладчике.

Если коротко, то есть два важных вывода:

1. Ошибка выбрасывается методом SetCurrentPosition, хотя из всех методов он один в документации не имеет такой ошибки (какую имеем) среди списка возможных ошибок.
2. Фактически я оказался прав в своём предположении, которое делал ранее:

   Но вскоре понял, что ни в каких if-блоках проверок юзермодной части DirectSound такой код ошибки не фигурирует, а все обращения так или иначе стекаются к вызову DeviceIoControl и обращению к ядерной части аудиоподсистемы (KS — Kernel Streaming). И я почти уверен, что ноги у сбоя растут оттуда.

Теперь подробнее:
Во-первых, я метод SetCurrentPosition вообще до этого не изучал и реверсить не пытался, свято веря в то, что он такую ошибку выкидывать не может. Как только мы выяснили, что дело в нём — я залез его изучать и оказалось, что его «начинка» вообще существенно проще, чем у остальных методов, которые я перед этим начинал реверсить.

Но опять же, сохраняется тот же принцип: какие-то проверочные if-блоки, которые я вижу, если и есть, то их деятельность направлена на формирование совершенно других ошибок (другие коды), и все внутренние проверки, которые там есть, не могли бы дать нам E_FAIL — значит надо было рыть глубже и смотреть вызываемые («вложенные») функции и методы, потому что ошибка может всплыть только оттуда.

Так я в скором времени, даже ничего не реверся, а беглым взглядом дошёл до уже знакомой функции PostDevIoctl, которая, как понятно из названия, является DirectSound-овской обёрткой над DeviceIoControl. На выходе из неё был поставлен условный брекпоинт, чтобы словить момент возврата при сбойном вызове, но эта тактика ничего дала — ошибка упорно не хотела возникать.

Тогда я сделал предположение, что наличие присоединённого отладчика как такового, а в большей степени — наличие условного брекпоинта портит всю картину и оказывает влияние на протекающие процессы, поэтому мы и не имеем ошибки. Тут надо понимать, что «conditional breakpoint» — это изнутри самый обычный брекпоинт, просто отладчик постоянно делает проверку условия. Это значит, что много раз в секунду процесс напарывается на этот брекпоинт и между отлаживаемым процессом и отладчиком постоянно шлётся поток отладочных событий (debug events), то есть имеет место межпроцессное взаимодействие, которое видимо и портит всю картину. И было решено отказаться от условных брекпоинтов в пользу безусловных — безусловный поставить на тот участок кода, который выполняется уже после того, как DeviceIoControl вернёт сбой. Тогда никаких лишних IPC между отладчиком и процессом-жертвой не будет до тех пор, пока ошибка не будет поймана. Результат не заставил себя ждать: ошибка была поймана менее чем через минуту.

Вот обратная трассировка стека, демонстрирующая цепочку вызовов от обращения к DirectSound из VB-кода до обращения к DeviceIoControl из нутра DirectSound:

stk_exp.png

По сути, в прямом порядке:

• Функция TNTAdd вызывает функцию SoundFire.
• SoundFire делает вызов DSBFire(FireInd).SetCurrentPosition 0
• Со стороны библиотеки DSound.dll реализацией интерфейса IDirectSoundBuffer8 является шаблонный класс CImpDirectSoundBuffer<CDirectSoundSecondaryBuffer>, у которого метод SetCurrentPosition является обёрткой над одноименным методом класса CDirectSoundSecondaryBuffer.
• CDirectSoundSecondaryBuffer::SetCurrentPosition вызывает CKsSecondaryRenderWaveBuffer::SetCursorPosition
• Он в свою очередь делает вызов к CKsRenderPin::SetCursorPosition
• CKsRenderPin::SetCursorPosition вызывает функцию KsSetProperty
• KsSetProperty вызывает PostDevIoctl
• PostDevIoctl вызывает DeviceIoControl — она то возвращает сбой, код ошибки, получаемый от GetLastError при этом равен ERROR_GEN_FAILURE (0x1F)
• По этому поводу PostDevIoctl сравнивает полученный код ошибки с некоторыми заранее известными кодами (например с ERROR_IO_PENDING, который вообще-то означает не ошибку вовсе, а тот факт, что операция будет завершена асинхронно), и если ни один код не подходит, вызывается WIN32ERRORtoHRESULT, которая и конвертирует код ERROR_GEN_FAILURE (0x1F) в E_FAIL (0x80004005) — дальше этот код просто всплывает наверх вплоть до VB, где превращается в ошибку.

Вот, собственно, код PostDevIoctl, которая является обёрткой над DeviceIoControl и вызывает оную:

2_.png

test eax, eax // jz dsound.73ed3d7c — это собственно прыжок на блок обработки ошибки в случае, если DeviceIoControl сбойнула.

Вот этот блок (начиная с вызова GetLastError):

3.png

(Вот тут-то мы ошибку впервые и поймали). Обратите внимание справа на то, LastError = ERROR_GEN_FAILURE.

MSDN даёт вот такое толкование этой ошибке:

May be used to indicate that the device has stopped responding (hung) or a general failure has occurred on the device. The device may need to be manually reset.

Ещё раз напоминаю, что эту ошибку выдаёт DeviceIoControl, которая является мостом между пользовательской частью и ядерной частью, позволяющим послать драйверу IRP типа IRP_MJ_DEVICE_CONTROL. Кто не знает: в ядре драйверы принимают входящие IRP и отсылают IRP другим драйверам (точнее устройствам), аналогично тому, как в user-mode WindowProc-и принимают оконные сообщения и шлют сообщения другим оконным классам (точнее окнам).

На всякий случай, я пустил отладчик дальше, чтобы посмотреть, какой был индекс буфера при обращении к объекту-буферу:

obj_ind.png

Как видно отсюда, FireInd = 1, то есть сбой произошёл при обращении к буферу-клону, а не к буферу-оригиналу. Не могу точно сказать, что все сбои касаются клонов, но интуиция подсказывает, что механизм клонирования может быть замешан в этом.

Если кто не понял, 4183B8 это адрес глобальной переменной FireInd и по нему содержится число 1, а 4183AC — это адрес поля pvData структуры SAFEARRAY переменной-массива DSBFire.

mov eax, [ecx*4+edx] — обращение к элементу массива (получение ссылки на объект-буфер).

Ну и сама ошибка после того, как отладчик отпустил отлаживаемый процесс в дальнейшее свободное выполнение:

err.png

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

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

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

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

[Mikle]

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

Дело не в том, что там везде 0, а в том, что возможно между буфером-клоном и буфером-оригиналом сохраняется какая-то связь (общая память под данные)

Да, так и есть, у этих буферов общие аудиоданные, все остальные данные индивидуальные - частота дискретизации, текущая позиция и т. п.

пока оригинал играется, нельзя у клона трогать указатель.

Опыты показывают, что можно, оно для того и предназначено, чтобы одновременно использовать несколько копий одного семпла, не занимая лишнюю память.
И в данном контексте совершенно непонятна связь с фоновым FireFox.

[Mikle]

Tiranas сделал ещё четыре карты, на мой взгляд - отличные: https://gamedev.ru/files/?id=131053
Так же добавил эту ссылку в п.0.

[Хакер]

Прошёл.
13-й — не простой.

Ещё моменты по игровой механике:
1) Неплохо бы, чтобы при подрыве ГГ исчезал с карты.
2) При взрыве TNT-ящиков частенько бывает, что взрыв некоторого ящика уничтожает соседний ящик (тот исчезает в момент взрыва первого), однако пустое место на месте исчезнувшего второго ящика начинает дымиться и через секунду уже на пустом месте возникает взрыв. Это баг.

[Teranas]

Странно, проверял, ковырял, всё работает, ничего не вылетает, даже на тестовой карте и под IDE.
Видимо из меня паршивый тестер.

[Mikle]

Неплохо бы, чтобы при подрыве ГГ исчезал с карты

Ну, или как-то показать, что он мёртв, например, оставлять чёрный силуэт ГГ на фоне взрыва.

частенько бывает, что взрыв некоторого ящика уничтожает соседний ящик (тот исчезает в момент взрыва первого), однако пустое место на месте исчезнувшего второго ящика начинает дымиться и через секунду уже на пустом месте возникает взрыв. Это баг.

Если так - то баг, только я никак не могу этого заметить. Но есть в любом случае один недостаток - малозаметно, что ящик загорелся, надо будет сменить в момент возгорания его спрайт на другой.
Есть ещё пара недостатков - у спрайтов ГГ есть еле заметная прямоугольная канва, надо будет подчистить. Ещё - текстовые заставки ("Победа", "Смерть") пропускаются нажатием Esc, логичнее, наверное, заменить на Enter, лишний раз нажав Esc, можно выйти из игры, а Enter, всего лишь, перезапустит карту, но в момент показа заставки карты всегда новая, это не проблема.
Поднакоплю ещё исправлений, и обновлю игру.

Видимо из меня паршивый тестер.

Тут, скорее, аппаратная/системная зависимость.

[Хакер]

Если так - то баг, только я никак не могу этого заметить.

Всё даже хуже, чем я описал.

1) Бывает так, что взрыв первого уничтожает сразу и второй, а потом пустое место в позиции второго издаёт вторую вспышку и взрыв.
2) А бывает так, как в п.1, только на месте второго потом ещё возникает третий взрыв. Т.е. взрывается 2 кубика TNT, а взрывов по факту 3.

Наблюдать второе явление можно, например, в уровне #8 при движении по такой траектории:

traj.png

[Хакер]

Есть ещё пара недостатков - у спрайтов ГГ есть еле заметная прямоугольная канва, надо будет подчистить.

Там три проблемы с этим:

sprite_bugs.png

[Debugger]

Классная игра!

Единственное - раздражает низкая скорость перемещения по лестнице. Но это скорее соображения баланса.

[ger_kar]

Mikle писал(а):Есть ещё пара недостатков - у спрайтов ГГ есть еле заметная прямоугольная канва, надо будет подчистить.Там три проблемы с этим:

А стоит ли вообще обращать внимание на такие мелочи. Играть они ну никак не мешают и впечатления от игры не портят. Я бы их даже и не заметил.

[Mikle]

А бывает так, как в п.1, только на месте второго потом ещё возникает третий взрыв. Т.е. взрывается 2 кубика TNT, а взрывов по факту 3.

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

А стоит ли вообще обращать внимание на такие мелочи.

Это не сложно, поэтому специально из-за этого релиз не обновляю, но вместе с другими обновлениями подчищу.

[Хакер]

Их и должно быть три, ты забываешь про то, что взрывается лифт

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

А стоит ли вообще обращать внимание на такие мелочи. Играть они ну никак не мешают и впечатления от игры не портят. Я бы их даже и не заметил.

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

[Teranas]

Сделал ещё 4 карты:

[Mikle]

Прошёл все. Карта №14 особенно хороша.

[ger_kar]

Сделал ещё 4 карты:

Да у тебя прямо талант. Я так не умею

[Teranas]

Да у тебя прямо талант. Я так не умею

Спасибо! Просто эта игра мне нравится.

[Teranas]

Забацал ещё 4 уровня для одной извилины, для второй, не осилил.

[Mikle]

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

[Teranas]

Буду ждать отзывов

[Mikle]

Сложность этих карт выше, народ притих.
18-ю прошёл.

[Teranas]

Гыы... а я хотел, следующие ещё усложнять, наверно не стоит...

[Mikle]

наверно не стоит

Стоит, интересно.

[Хакер]

Сложность этих карт выше, народ притих.

Я, например, ещё не качал последние 4 карты.
Пак из 11—14 скачал и прошёл в день выкладки, карты интересные, но какой-то у них у всех уклон на злоупотребление диномитом. Подход «успей пробежать пока дорожка не взорвалась» наскучил, хочется или каких-то новых хитрых тактических ловушек, или прост мест, где одни и те же динамические (уничтожаемые) элементы и мешают и помогают одновременно, и момент, когда их нужно уничтожать должен игроком тщательно продумываться.

Может последние карты и такие, я ещё не знаю.

[Teranas]

Уровней «успей пробежать, пока дорожка не взорвалась» вроде всего 4 или 5 из 21, 25%, к тому же, если уровень не нравится, его можно пропустить, хотя для коммерческой реализации, правильней было бы, что бы прохождение одного уровня открывало возможность играть в следующий, повысить интерес.