Дмитрий

Вдруг завтра уже наступило, а я не заметил

наступило уж хз когда. Просто есть 2 вида пользователей LLM'ок:
Кто задаёт странный one-shot вопрос с неподходящим контекстом, а то и без него и пытается получить из него ответ. Туда-сюда копи-пастит, получает кучу галлюцинаций, кривого нерабочего кода, бомбит, что нейросети ваши только котиков рисовать и сидит злой, смотрит, как другие за день месячные задачи закрывают.

А есть второй вид, который берёт нормальный инструмент (Cursor, Refact, Windsurf, RooCode, Cline), изучает его и пользуется. Да, надо потратить время на изучение! Изучить prompt engineering, обмазаться инструкциями к проекту, системными промптами, подкинуть документацию, context7, подключить MCP, RAG, разобраться, как пользоваться агентом, воткнуть кастомный режим типа memory bank, поставить улучшайзер промптов типа supercode.sh, мультиагента типа Roo Commander. И кодинг одной кнопкой левой пяткой станет реальностью.

Но есть проблема. Всё это нужно изучать. LLM'ки развиваются такими темпами сейчас, что пока ты ищешь какой плагин поставить, выходят ещё несколько. Громадное количество времени нужно тратить на это всё. 1-2 часа в день приходится уделять, чтобы быть в курсе всех сумасшедших темпов развития и изменений.

В идеале, чтобы ИИ понимал, что такое структура проекта

Это не в идеале, это чуть ли не единственный рабочий вариант. LLM это языковая модель, token predictor. Она ничего больше не умеет, кроме как предсказывать следующий токен(букву, слово, строку, и т. п.). Без контекста проекта ему нечего предсказывать, грубо говоря. Это рулетка рандомная получится, если не давать ей контекст.

Я знаю, что я слишком многого хочу

То, что ты хочешь, LLMки уже умели года 3 назад. Главное написать правильный prompt.

однозначно твоя задача красиво не решается, а еще она очень специфическая, онозначно нужно разрабатывать ИИ агентов под это дело

уже давно всё разработано, надо просто изучить, как это работает. Ничего специфического в задаче нет. Люди успешно портируют LLMками софт с языков, которые никогда в публичном доступе не были и использовались для 1-2 проектов в дремучих 70-х годах, а вы говорите, что задача описать, как работает код на современном языке, специфическая? Более чем тривиальная.
LLMки при грамотном использовании могут сейчас буквально всё, что можно придумать: пишут код, тесты, прогоняют эти тесты, смотрят на линтеры, исправляют ворнинги, отлаживают сами код, закрывают задачи на трекерах, делают запросы в базу, решают теоремы используя солверы и всякие Wolfram'ы, даже реверс-инженерят бинарники без исходников! Объяснить, как работает функция — это не запрос, это ничто.

а потом ещё расписыет, что и зачем он сделал

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

Для чег ои хочу приемлемый плагин сразу поставиь, чтобы тратить время только на полезное

Так не работает. Для крутого результата надо 8-10 инструментов поставить, изучить их, связать для работы вместе. Это тупо конструктор, один плагин не даст никакого результата.

Постоянно — ассоциация с людьми, которые говорят, что ЛЛМки не работают:
когда купил себе рабочую станцию под 10к баксов, а всё, что на ней делаешь, это почту проверяешь, погоду, рецепты ищешь, в одноклассниках сидишь. Написать в чат без контекста и ждать, что он ответит как нужно это из пушки по воробьям, а не нормальное использование громадных возможностей.
Или другая аналогия: установил блокнот и пытаешься там код скомпилировать, автодополнение получить, тип переменной узнать. Так это же блокнот, он просто чтобы текст писать и читать, для остального нужно поставить компилятор, настроить, узнать какие флаги передать. Отдельно настроить автодополнение, понимать, что есть разные его типы: можно по токенам показывать, можно семантически полностью разбирать. Зависит от настроек и от того, как читалась документация (и читалась ли вообще).
Нет пока что варианта "установить одной кнопкой и всё завайбкодится". Нужно очень много приложить усилий, но они окупятся.

Локальная LLMка не нужна, если у тебя не супер-секретные данные, которые ни в коем случае нельзя светить, иначе смерть. Железка, которая потянет это всё на уровне сервиса за 20 баксов, будет стоить под десятку зелени. Если у тебя не госразработка, ядерные исследования и прочие чувствительные данные, нет никакого смысла ставить локальную молотилку за громадные деньги, заплати 20 баксов за Курсор и ещё 20 за ChatGPT/Claude для research-режимов и это покроет 90% задач.

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

Адекватно отлаживать код можно только на той платформе, для которой он пишется. Иначе никак.
C++ -- он и в Африке C++. Можно писать хоть в блокноте, главное тулчейн, которым он собирается. А у C++ с кросскомпиляцией всё не так уж радужно на практике, как это рисуют в теории.

Смотря для какого API вы писать хотите, для какой системы. Например, в Убунте тулчейны более древние, чем в Арче. Это накладывает весомый отпечаток на боль, которую придётся испытывать в разработке и отладке.

при работе по SSH некорректно работают практически все функции glut

При работе по ssh вообще сложно пробросить графический сервер, чтобы он работал адекватно. А ещё есть как минимум X и Wayland. У них разные методы удалённой отладки будут.

Проще будет VNC поднять и отлаживать таким образом, чем городить костыли.
И, как уже сказала копи-паста из бота, используйте GLFW или SDL, они намного проще собираются и отлаживаются, чем говно мамонта под названием GLUT.

Попробуйте Import and Export Settings -> Reset all settings

но годных в гугле так и не нашел

Значит, не искали. Их там кучи. Другое дело, что подавляющее большинство платное. Бесплатных качественных довольно мало.

https://www.proxifier.com/

А гуглить не пробовали? Говорят, помогает...

Так студия же пишет логи и делает бекап, когда конвертирует. Вот их и смотрите.

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

Далее, там используется процедурное генерирование. Т. е. текстуры, звуки, эффекты генерируются по формулам, каким-то шаблонам, фракталам, и т. д.

Всё это, по сути, спорт, состязание демо-групп. Реальные вещи на этом делать слишком долго и затратно. Но в плане теории, можно хорошо подтянуться. Поковыряйте исходники движка, на котором написан кригер, они открыты, но довольно устарели уже.

Для реальных вещей, начните учить, например, OpenGL 3.2+, шейдеры, различные технологии, типа abmient occlusion, post processing effects.

А 40 мегабайт планка... это МНОГО. Если учить чистое графическое АПИ, и ничего лишнего не писать, у вас будет всё весить сотни килобайт. Но, опять же, это всё необходимо только для изучения основ и понимания, как оно всё там работает. Для реального продакшена или даже прототипирования лучше возьмите попсовый движок, тот же юнити или анрил. Будет и проще, и быстрее, и удобнее. Ибо, мобильные видеоадаптеры это костыль-driven development. Обычно видео-драйверы там ОЧЕНЬ сырые, ОЧЕНЬ баганые, их реализации графических апи могут абсолютно не соответствовать стандарту. То, что у вас запустилось на Mali, может совершенно не работать на PowerVR или другом чипе. Поэтому не советую привязываться к низкому уровню в мобильной разработке, берите уже проверенный временем движок, в котором решена большая часть этих проблем, и костыли уже расставлены на своих местах. Иначе, будете биться с косяками производителей видеочипов, а не работать с графикой.