Дмитрий Александров

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

Раз вопрос поставлен таким боком то правильное решение будет не использовать вулкан. Очень вероятно что и чистый opengl поставит в ступор поэтому ищите готовые библиотеки по opengl в которых все максимально абстрагировано и завернуто в более удобный api.

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

Хм

setdone(true);

чет падазрительна.

В linux системах смотри /proc/asound/card0/codec#номер , в нем ноды а в них есть поле Pin-ctls вот по значению в нем можно определить подключено что то или нет. Так же есть много вариаций в виде библиотек.
В окнах есть апи
Про смартфоны выше ответили.

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

В С++ существует миллиард и 1 способ как отстрелить себе ногу или обеспечить головной боли на пару недель маленькой строчкой причем на разных компиляторах это число и холоднокровные трюки разнятся. К примеру классический

#define false true

Во, откопал древний веселый прикол .

Базово существует 3 подхода:
1) Путем чтения\записи памяти. Самый простой вариант это поиск нужного адреса памяти а далее воля фантазии в виде замены значения дав себе +1000 хп или просто чтение значения к примеру чтобы сделать wallhack. Самый простой вариант и делается очень легко.
2) Путем инжекции в игру\программу. Пример игра использует некую стороннюю библиотеку library.dll, в случае если она опенсурс то цепляются в ней к методу типа init() и дальше копаются в игре или на асме инжектятся в нужную функцию. Сложность в том что придется восстанавливать структуры данных, искать функции и т.д. а уже потом дергать нужные с нужными параметрами.
3) Типа MItM, пишут простенький прокси сервер который ловит весь трафик между игрой и сервером. Придется разбираться в пакетах и также восстанавливать структуры если они есть, быть очень быстрой и хранить очень много данных. Самый профитный среди всех и одновременно самый сложный. Не так давно подобным способом роняли ММ в КСГО, роняли сервера в ОВ, загубили пару онлайн ММО но давно(вечная память разрабу той универсальной софтины).

Как правило 95% читов относятся к 1 категории public и private, оставшиеся 5% ко 2й и 3й personal и именно они самые дорогие и делаются под заказ ограниченному числу людей(часто ценник уходят за 1к бакс и выше).

Как, да просто.
1) Взять талмут особенностей карт nvidia и такой же amd.
2) Взять талмут особенностей винды\линукса\макось.
3) Изучить матан,геометрию и все связанное.
4) Изучить и овладеть с\с++ на очень хорошем уровне, лучше даже быть одним из лучших.
5) Дальше оп и двиг готовый какраз на уровне ue4, ce, unity или фростбайта.

Для 3д игр, особенно сетевых писать свой собственный двиг нынче почти нереально(именно на уровне что это будет нормально работать у всех, быть удобным и красиво выглядеть). Этим занимаются огромные команды спецов всех областей и не 1 десяток лет ежедневной работы.

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

Если так хочется с\с++ то попробуйте для начала сделать простенький 2д двиг и игру на нем, думаю желание отпадет где то в самом начале =)

На С++ писать сложнее чем на джаве. Наговнокодить можно на любом языке и будет очень медленно и прожорливо, по потреблению ресурсов впринципе потеряете не так много если сравнивать java vs c++, если конечно не будете в рекурсивном цикле создавать миллиарды строк текста.
В любом случае, как писали выше, язык это дело вкуса и серебрянной пули несуществует вообще. Игры можно писать на готовых движках. Скажем если выбор падет на юнити то тут балом правит C# и JS. Если выберете Unreal то С++ или скриптовый блюпринт. Если же выберете путь писать двиг самому особенно для мобилок то тут будет адская смесь явы и с++. Если возьмете некий "полудвижек" или фреймворк то там вас привяжут к конкретному языку или скриптовому языку. Кроме того на каждой платформу правят свои языки и кроме того их может быть много. На андроиде это java и намного реже с++(в основном гемор из за невероятного числа костылей) или примеси html5. На IOS это objective-c и swift и так же иногда с костылями html5. На Windows С++\С\С# и реже все остальное, на маках objective-c в основном, на линуксах С++\С\Mono\Java\Python\Perl\Lua\NodeJS\Go и еще туча другого добра. Если же пишут многопользовательскую игру то сервера очень часто пишут на питоне\го\джаве\ноде.
В общем если желаете нацелиться на максимально возможное с минимальными затратами то начинайте учить джаву или с#(эти языки очень похожи и выучить другой будет легко) а дальше берите фреймворк или готовый двиг и творите. Задумывать о том что тот язык медленный\прожорливый\etc Вам не имеет смысла вообще никакого т.к. абсолютно все языки примерно одинаковы по скорости если их "хорошо готовить" и основная разница только в следующем:
1) Сложность синтаксиса языка.
2) Скорость изучения языка.
3) Сложность изучения языка и его принципов.
4) Скорость написать программы.
Обобщенный пример: Java или C# очень простые языки и можно уже через пару недель писать довольно серьезные программы но они будут медлительны по одной простой причине, для того чтобы понимать что вот это медленно и надо писать по другому пройдет очень много времени и стажа т.к. многие моменты коварно абстрагированы в недрах VM. Ситуация с С\С++ другая, языки в 10ки раз сложнее особенно новичку, для написать сколь нибудь сложной софтинки придется усиленно изучать язык пол года и больше но за счет необходимости читать и понимать и большего времени изучения у вас изначально код будет быстрее просто потому что уже будет хоть небольшое но понимание почему так медленнее а так быстрее и почему так ресурсов кушается больше а так меньше. То же самое относится и к переносимости языка на другие платформы, джава сильно абстрагирует api от железа и OS и программист просто пишет 1 код и он просто работает везде где есть джава. На С++ огромное число граблей при переносе софтины с win на линуксы и наоборот, почти весь код который как то работает с OS или железом придется переписывать заново. Ну и про скорость написания софта, java\c# сильно впереди, чужой код в сотни раз проще понять чем чужой код на с\с++, программист думает именно над алгоритмом исключая думы над тонкостями работы с памятью и т.д.
Выбор полностью за вами =D.

Репозиторий microemulator на гитхабе, гуглокод немного уже не в тренде и не так удобен. Покопался в нем это именно то что надо, чистенькая реализация CLDC и MIDP на обычной java se, еще и портирован на все что можно.

Android NDK очень плохо документирован. Надо брать в расчет что процессоры разные (armeabi armeabi-v7a x86) и есть небольшие расхождения (небольшая информация тут). Так же необходимо учесть что нормально писать и компилить NDK лучше на линуксах. Так же стоит учитывать что NDK богатством функционала тоже разнится от версии к версии, так же это зависит и от конкретного девайса(производители очень любят залезть в ядро и стандартные либы и переиначивать их). Без JAV'ы совсем не получится, хотя бы минимально она будет. С GUI тоже все печально, нужна java или NativeActivity который опять же труба через JNI.
В общем литературы по NDK катастрофически мало, сюрпризов очень много, без java кода максимум можно сделать что то консольное, что в чем то даже удобно.
Мельком глянул сейчас, вроде бы появились фреймворки с нативными UI для NDK, к примеру juce.com.

А что Вы хотите узнать от движка которому 3 дня от роду?)

Подойдет?