Если это не основной счетчик - то просто смотрите сразу ваттметр и все. Проще будет. Но легализировать его не получится 100% - никто с него показания считывать не будет. Можете поставить обычный счетчик и СРАЗУ за ним ваттметр - будет то же самое почти.
Дизасемблировать реально, подойдет любой дизасм.
А вот изменить и собрать обратно, да так чтобы винда приняла этот файл и не выеживалась - вот это очень не факт что получится - вроде длл можно тоже подписать, да и чексуммы никто не отменял. +высок шанс что после обратной сборки что то не будет работать )
openSL наверняка сможет и подойдет по платформам.
Но Wav реально проще вычитать обычным fopen и не париться с либами - формат простейший. Только правильно потом раскидать по каналам и частотам
https://www.gamedev.ru/terms/Normalization
Нормализация выдает вектор единичной ДЛИНЫ, но того же направления. Понятное дело что при движении под углом координаты не могут быть единицами - а вот длина может.
На любую специальность, где есть:
- хоть какое то программирование - пофиг какое - все равно доучиваться
- есть хотя бы базовый курс комп.графики
- неплохо дают всякую математику - дискретку, матрицы, вот это всякое.
Нужно читать конкретное лицензионное соглашение и Terms of Use.
Чаще всего в нем прописано, что вмешательнство в логику недопустимо. Ну и там же про последствия нарушения можете почитать ;-)
Теоретически - это вполне возможно - подключаете обычные библиотеки (dll и прочие) и работаете с ними. Но надо понимать что тогда вам вручную надо поддерживать их под все платформы. Можно и на другие более низкие уровни вмешиваться, в общем - это возможно.
Если вас так пугает c# (что между прочим зря - хороший удобный язык) - то стоит посмотреть конечно в сторону других движков. Но не забывайте о таргет платформах ;-)
Язык на кой то черт в тегах указали, а ось - нет. Да и требования (только пуш-пулл, или надо хорошо лазить по истории) https://git-scm.com/downloads/guis - вот вам основные клиенты, с сортировкой и прочим. Выбирайте.
Личный выбор:
- fork
- ide
- консоль
Разница в том, что вы не знаете последовательность вызова апдейтов.
Т.е. вот в таком случае как у вас в коде - позиции будут меняться сторого в той последовательности, как элементы расположены в списке.
А если вы им передадите координаты и они сами будут в апдейтах двигаться - то последовательность в рамках кадра не определена.
Это не значит что это плохо или хорошо - это факт, который просто надо учитывать.
В остальном это только вопрос архитектуры
