База данных IDA от void17

Да я тоже бы хотел минимализма для таких целей. Есть же code::blocks и тулчейн MSYS2, но к сожалению GCC и LLVM-Clang не поддерживают ABI MSVC.


Хотя, наверное, можно написать накрученный ассемблерный(к слову, GCC и Clang поддерживают только неудобный AT&T синтаксис ассемблера, который не поддерживает и не отображает IDA Pro) макрос для вызова игровых функций, бла бла бла...
но честно говоря проще использовать Visual Studio 2017 и компилятор MSVC с минимальным количеством плагинов и CMake, этого достаточно вполне. Редактировать код где угодно, а билдить можно хоть с консоли.

Кстати вопрос технического характера.
Вот в .ехе-шнике игры есть свои operator new, operator delete, а также malloc, realloc, free и прочие вещи для контроля динамической памяти.
Стоит ли сделать глобальную перегрузку которая будет вызывать соответствующие .ехе-шные функции, по крайней мере для контейнеров, чтобы dll использовал кучу .ехе-шника? Это сильно скажется на скорости, но разве это не должно быть впринципе так? Ради безопасности. Потому что куча .ехе-шника своя и у .dll своя, так стоит делать вообще? Если они разные, это ни на что не влияет?
upd.: на скорость практически не повлияет, нашел ответ на stackoverflow, но все же стоит ли это делать ради безопасности?

 

There is almost no overhead to having a separate DLL. Basically, the first call to a function exported from a DLL will run a tiny stub that fixes up the function addresses so that subsequent calls are performed via a single jump through a jump table. The way CPUs work, this extra indirection is practically free.

Например я захочу удалить память выделенную в .ехе-шнике местным оператором new с помощью оператора delete из .dll, это сработает вообще?
Мне кажется нет. Но я не проверял.

Такие вещи у Хероманта надо спрашивать, кмк. Они там в ВОГе постоянно обсуждают какие-то манипуляции с памятью - я так ни разу и не смог вникнуть в тему и так и не понял - для чего все это нужно.

Спрошу на stackexchange у знатоков. Но мне кажется если оверхед нулевой, почему бы и нет.
Да и у нас разный подход к моддингу. У нас это С++ и .dll модули, у них ассемблерные костыли

Цитата:

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

Использовать для определения типа вместо typedef это как раз таки я придумал, а сама эта функция в игре просто вызывается для неописанных функций других заклинаний и возвращает нуль, ну действительно слишком сложно описать логику оценивания, например, силового поля.

Цитата:

*) Можно переписать все, чтобы сделать из AI вообще архимага

Да. К тому же, как я описал выше, можно научить ИИ кастовать заклинания, которые оригинальный ИИ не умеет. Список: силовое поле, огненная стена, зыбучие пески, мины, убрать препятствие

Цитата:

Вот в .ехе-шнике игры есть свои operator new, operator delete, а также malloc, realloc, free и прочие вещи для контроля динамической памяти.
Стоит ли сделать глобальную перегрузку которая будет вызывать соответствующие .ехе-шные функции, по крайней мере для контейнеров, чтобы dll использовал кучу .ехе-шника? Это сильно скажется на скорости, но разве это не должно быть впринципе так?

Я не вижу смысла вызывать "родные" функции работы с памятью. Во-первых, менеджментом памяти занимается ОС и ей виднее, как лучше работать с кучей. Во-вторых, от "изнанки" того, как реализованы и работают new, delete и т.д., не зависит то, как работает игра. Поэтому нет смысла париться с вызовом "родных" функций (я видел, так делают): смело используйте стандартные.

Цитата:

Но мне кажется если оверхед нулевой, почему бы и нет.

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

Цитата:

Использовать для определения типа вместо typedef это как раз таки я придумал, а сама эта функция в игре просто вызывается для неописанных функций других заклинаний и возвращает нуль, ну действительно слишком сложно описать логику оценивания, например, силового поля.

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

Цитата:

Да. К тому же, как я описал выше, можно научить ИИ кастовать заклинания, которые оригинальный ИИ не умеет. Список: силовое поле, огненная стена, зыбучие пески, мины, убрать препятствие

Кому-то нужно этим заняться. В оригинале AI ещё и Берсерк не кастует, но где-то видел фикс.

Цитата:

Да я тоже бы хотел минимализма для таких целей. Есть же code::blocks и тулчейн MSYS2, но к сожалению GCC и LLVM-Clang не поддерживают ABI MSVC.

Вроде как, поднял себе минимализм в Code::Blocks + Cygwin64 + MinGW:

Код: Выделить всё

-------------- Build: Release in A7 (compiler: GNU GCC Compiler)---------------

i686-w64-mingw32-g++.exe -Wall -DBUILD_DLL -O2 -std=c++17 -fpermissive  -c D:\Projects\A7\main.cpp -o obj\Release\main.o
i686-w64-mingw32-g++.exe -shared -Wl,--output-def=bin\Release\libA7.def -Wl,--out-implib=bin\Release\libA7.a -Wl,--dll  obj\Release\main.o  -o bin\Release\A7.dll -s  -luser32

Теперь можно С++17 использовать, коли надо будет. Всё собирается прекрасно. Правда, dll-ки получаются побольше (~30 КБ).

GCC не поддерживает MSVC ABI. Там нет ключевых слов __thiscall, __fastcall и прочего, нужно написать обертку __attribute__((...))
https://gcc.gnu.org/onlinedocs/gcc/x86- ... butes.html

Это я еще ничего не пишу про pragma pack, битовые поля и прочие вещи, которые в каждом компляторе по своему сделаны. Я проверю, можно ли будеи использовать GCC/Clang для моддинга и добавлю поддержку в свою API.

Я люблю GCC/Clang, они генерируют код получше, быстрее и компактнее, но ради совместимости лучше использовать v141_xp build tools и MSVC.
Насчёт веса бинарника можно не заморачиваться, у нас 2023 год на дворе.
К слову можно спокойно использовать оптимизации с инструкциями начиная, например, с Пентиума. В MSVC такой гибкой настройки нет.

Код: Выделить всё

-msse -msse2 -msse3 -mssse3


Цитата:

GCC не поддерживает MSVC ABI. Там нет ключевых слов __thiscall, __fastcall и прочего, нужно написать обертку __attribute__((...))

Не знаю. У меня поддерживает. Пример плагина из темы компилируется с __stdcall, __fastcall и работает. #pragma pack() тоже работает. Проверил даже пару плюшек С++17 (например, std::clamp()).

А эти функции точно правильно вызываются, чистят стек и загружают аргументы? Если да, то авторы MinGW большие молодцы.

Проверь еще, собирается и работает ли правильно с clang.