Динамически подключаемые библиотеки (dynamic link libraries, DLL) используются для уменьшения объема исполняемого файла, за счет выделения некоторых функций в отдельный файл. Более того, функции из DLL могут использовать разные загрузочные модули, что особенно важно для жизнедеятельности Windows (например в KERNEL32.DLL содержаться функции управления памятью процессами и потоками). Для создания DLL в среде C++ Builder необходимо выбрать File\New\Dll при этом автоматически генерируется проект, компиляция которого и дает искомый результат. Для написания экспортируемых функций используется следующий синтаксис: __declspec(dllexport) void nameFunc(); При компиляции, кроме прочих, создаются файлы с расширениями *.LIB и *.DLL, содержащие экспортируемые функции. Подключение DLL в C++ Builder возможно явным и неявным способом. При неявной компоновке в секцию директив необходимо добавить строку вида: #pragma link ”nameFile.lib” а, в секцию прототипов добавить описание прототипа функции: void nameFunc(); При неявной компоновке функция вызывается по имени, необходимы файлы с расширениями *.LIB и *.DLL. Библиотека подключается к процессу в момент загрузки процесса и выгружается вместе с процессом. Явная компоновка требует использования функций WINAPI LoadLibrary() и GetProcAddress(). В данном случае функция вызывается по номеру, который ей присвоен при создании DLL. C++ Builder упорядочивает экспортируемые функции DLL в алфавитном порядке их имен. Номер функции в DLL можно получить с помощью утилиты tdump с ключом -ee. Функция LoadLibrary() принимает в качестве параметра имя библиотеки, а возвращает переменную типа HINSTANCE. Функция GetProcAddress() имеет следующий прототип: void *GetProcAddress (HINSTANCE, const char *); она принимает переменную типа HINSTANCE и символическую константу, а возвращает указатель на функцию. В приведенных листингах демонстрируется создание, неявная и явная компоновки DLL. //Пример создания DLL #include <vcl.h> #pragma hdrstop int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*) { return 1; } //Выше находится заголовок DLL, генерируется автоматически double dblValue(double); double halfValue(double); __declspec(dllexport) int AreturnValue(bool); __declspec(dllexport) int CreturnValue(bool); __declspec(dllexport) int BreturnValue(bool); int CreturnValue(bool i) { i= true; return(2); } int BreturnValue(bool i) { i= true; return(3); } int AreturnValue(bool i) { i= true; return(1); } double dblValue(double value) { return value * value; }; double halfValue(double value) { return value / 2.0; }
//Пример неявной компоновки DLL #ifndef useDllU1H #define useDllU1H #include <Classes.hpp> #include <Controls.hpp> #include <StdCtrls.hpp> #include <Forms.hpp> //-------------------------------------------------------- class TForm1 : public TForm { __published: // IDE-managed Components TLabel *Label1; TLabel *Label2; TLabel *Label3; TButton *Button1; void __fastcall Button1Click(TObject *Sender); private: // User declarations public: // User declarations __fastcall TForm1(TComponent* Owner); }; //-------------------------------------------------------- extern PACKAGE TForm1 *Form1; //-------------------------------------------------------- int AreturnValue(bool); int CreturnValue(bool); int BreturnValue(bool); #endif
int (*returnVa1)(bool); int (*returnVa2)(bool); int (*returnVa3)(bool); //-------------------------------------------------------- __fastcall TForm1::TForm1(TComponent* Owner):TForm(Owner) {//Создание формы hinst=LoadLibrary("dll_cb_c.dll"); returnVa1=(int (*)(bool))GetProcAddress(hinst, MAKEINTRESOURCE(1)); returnVa2=(int (*)(bool))GetProcAddress(hinst, MAKEINTRESOURCE(2)); returnVa3=(int (*)(bool))GetProcAddress(hinst, MAKEINTRESOURCE(3)); } //На форме имеется одна кнопка и три метки void __fastcall TForm1::Button1Click(TObject *Sender) { bool buf_b; int j; buf_b=false; if(returnVa1==NULL) Label1->Caption=AnsiString("Error"); else { j=returnVa1(buf_b); Label1->Caption=AnsiString(j); } Label2->Caption=AnsiString(returnVa2(buf_b)); Label3->Caption=AnsiString(returnVa3(buf_b)); } MAKEINTRESOURCE — макрос для создания символической константы. Переменная типа HINSTANCE создается глобально. Загрузка библиотеки и присвоение указателей на функции производится в момент создания формы. Количество и тип параметров в описании функций (сигнатура функции) в DLL и указателя на функцию, в вызывающем модуле должны совпадать, совпадение имен не обязательно. DLL выгружается из памяти при завершении работы вызывающего модуля. Принудительная выгрузка DLL осуществляется функцией FreeLibrary(HINSTANCE).
Чтобы убрать "тормоза в игре" или одним словом улучшить производительность необходимо открыть в ХЕКС-редакторе (см. ссылку сверху) XR_3DA.exe, там в коде с помощью поиска найти цифры 45 78, найти их просто - ввести в поиске GlobalMemoryStatusEx . Далее изменить их на 00 00 и сохранить изменения. Всё. Теперь всё будет работать нормально. Способ нашёл не я - Rolan.
(С) _Призрак_ Инструкция по изменению плотности травы. Параметр меньше 0.02 не ставить - Колмогор писал что начинает лагать 1. Открываем айда 2. Открываем айда_виев 3. Теперь ищем что нам нужно найти. Нам сейчас нужно найти r__detail_density? Тогда жмем ctrl+t и вводим r__detail_density 4. Находим функцию и тщательно ее разбираем (я ее полностью разбирать не буду, а только укажу где задаются параметры: fld ds:flt_10064400 --нижнее ограничение равное 0.6 or dword_1007CACC, 8 sub esp, 8 fstp [esp+30h+var_2C] mov ecx, offset unk_1007CA9C fld ds:flt_10064380 --верхнее ограничение равное 0.2 fstp [esp+30h+var_30] push offset aSs; "ЪЩЩ>" push offset aR__detail_dens; "r__detail_density" call ds:??0CCC_Float@@QAE@PBDPAMMM@Z; CCC_Float::CCC_Float(char const *,float *,float,float) push offset sub_1005E080; void (__cdecl *)() call _atexit add esp, 4 Если вы заметили, то что бы трава стала плотней нужно уменьшить параметр, а что-бы травы стало меньше нужно параметр увеличить 5. Нам нужно увеличить плотность травы: следовательно нужно изменить верхнее ограничение. Как это сделать? Есть 3 варианта:
Первый и самый логичный вариант: изменить переменную которая задает. Но тут есть небольшой подвох на котором я попался. Этой переменной может пользоваться не одна функция, а несколько. И не ясно что вы можете сломать, поменяв одну циферку в переменной...
Второй: взять другую уже существующую переменную. Хороший вариант которым я и воспользовался. Но и тут есть недочет - переменных в ддлке не так уж и много и можно просто не найти нужную
Третий: создать переменную. Отличный вариант. Единственный минус - я не знаю как это сделать
Я пошел по второму пути. Два раза шелкнув на ds:flt_10064380 айда отправила меня в дебри под названием .rdata. Там я нашел переменную которая называлась - flt_1006452C и которая имела значение 0.0720999 Вообще-то, как я понял, flt_1006452C - не является названием переменной. Это так сказать сборка из 2 показателей - (тип числа)_(оффсет) В нашем случае это число типа float которое находится в 1006452C. Ну чтож приступим к редактированию! 6. Отправляем в самое начало файла. Как? Сверху есть что-то типа статус бара - строка состоящая из синего,серого,черного цвета. Нажимаем там в любом месте мышкой и ведем влево до конца 7. Опять ищем r__detail_density. Находим в этой функции fld ds:flt_10064338. Дальше самое интересное. Жмем на ХЕКС_ВИЕВ и там у нас выделяются какие-то цифры. Это наше 10064338 только написано наоборот. Сравните: 38 43 06 10 10 06 43 38 Похоже, не правда? Начинаем редактировать. нам нужно поменять 4338 на 452C т.к. в этом и есть различие. Жмем правой кнопкой мыши на этих цифрах и выбираем пункт Edit. Меняем 38 43 на 2С 45. Дальше жмем где нибудь в коде. Это нужно сделать обязательно. После этого жмем правой кнопкой мыши и выбираем commit changes. Но айда не меняет исходный файл. В нашем случае мы можем только создать файл изменений. Делается это так - Файл - Produce file - Create DIF file. Назовем его test. DIF файл можно открыть при помощи блокнота и посмотреть что вы сделали. Теперь так сказать соединит этот файл и дллку. Это можно сделать при помощи bpatch. Качаем и смотрим и запускаем bpatch.cmd. Я думаю что вы сможете его изменить сами если нужно будет. Там все элементарно.
Сообщение отредактировал RETRIX - Воскресенье, 04.03.2012, 23:11
Эфекты от удара монстров лежат в постпроцессинге как и выброс итд.
Добавлено (22.11.2011, 00:20) --------------------------------------------- RETRIX, Прыжок снорка в игре уже есть да и химера прыгает не слабо, к какому мутанту думайте применить?
Да. Это несомненно настраивается эффекторами, если есть что настраивать, если есть это в движке =)
А вообще, чего греха таить, хочется восстановить раскачку оружия. Вот , помниться , была у меня подобная идея, ноя детали уже забыл, а без деталей- никуда не годится...
Добавлено (22.11.2011, 00:32) --------------------------------------------- Скайлоадер говорит о том, что больше уже никогда не восстановить раскачку оружия. Я считаю, что можно.
RETRIX Давай поговорим с тобой о твоих .... желаниях. 1. Двери для автомобилей сделать чисто теоретически, если нам повезет можно и скай прорабатывает этот вариант, но насколько я знаю успехи у него пока скудны. С другой стороны ПЫС могли вырезать/закомментировать часть кода и тогда нас поможет только врезка в код. О ней читай ниже. 2. Удар псевдогиганта в прыжке. Ситуация та же. Сейчас не могу к сожалению проверить остались ли методы для прыжка в классе псевдогиганта, но опять же как карта ляжет. ПЫС могли или закомментировать или оставить затычку. 3. Статик вырезали полностью. Статик нет смысле возвращать без возможности его использования в скриптах. Статик вырезали не просто так. Я думаю этих аргументов хватит 4. Эффекты от ударов ПОЛНОСТЬЮ делаются при помощи пост эффектов. НИЧЕГО в двигателе игры не настраивается. Но если вы любитель садомазо, то пожалуйста, флаг вам в руки, реализуйте 10 строчный код (на LUA) в виде 200 строчного на ассемблере. 5. Глобальная карта, так-же как и ПДА в билде 3120 вырезана подчистую. Код просто напросто переписали. Поздняк метаться.
Итого из 5 идей только 2 возможны в реализации и имеют смысл.
Врезка в код: Давайте рассмотрим 2 ситуации. 1 ситуация (врезка в код на LUA (или С/С++/Pascal/C#/Object C/perl/Pyton и т.д. и т.п.)) Хотим мы чтобы у нас при получении предмета вызывалась наша функция. Мы находим нужную функцию, которая вызывается при получении предмета и вставляем туда вызов нашей функции. ВСЕ 2 ситуация. Врезка в скомпилированный код (врезка на ассемблере) Хотим мы чтобы у нас при получении предмета вызывалась наша функция. Мы находим нужную функцию. Но проблема в том что нам негде вставить вызов нашей функции! Файл идет непрерывно и его можно дописать только в конец или писать поверх! Причем в скомпилированном коде есть несколько различных разделов: в одних хранится код, в других хранятся константы и т.д. Что делать? Приходится добавлять через костыли новый раздел для кода и в этом разделе писать нашу функцию. Но все равно остается вопрос куда сувать вызов функции. Для этого часть кода переносится в нашу функцию, тем самым освобождая место для вызова. Но твою мать, необходимо еще сохранить показания регистров/стека. Если мы их не сохраним то в памяти компьютера произойдет невообразимая бойня! Фактически Бородино в компьютерном масштабе. Если состояния регистров можно сохранить в стеке, то как мы будем сохранять значение указателя стека? Нам нужно всегда неусыпно следить за ним. А это большой труд, ибо чуть ли не треть всех команд изменяют его.
И это я не говорю о самой сложности языка. Банальный вывод строки "Hello, World!" Превращается в настоящую эпопею! Там нужно получить указатель на устройство вывода, получить строку, еще какую то хрень, загнать это все в стек и только тогда можно вызывать функцию вывода на экран. Вообщем программа, которая на С занимает 4 строки кода, на ассемблере занимает 20 строк.
И еще один момент я забыл. Код на ассемблере все равно придется компилировать, потом скомпилированный код придется вручную/при помощи костылей переносить в длл, вручную прописывать вызовы функций и т.д.
Поэтому вы пыл то по-уменьшите. Если бы все было бы так просто, то почему до сих пор только один человек смог ввести новый функции в игру при помощи ассемблера
А то что Скай мделал больше чем маландринус... Тут явно видно что вы не выходили за пределы АП про и не слышали о X-Ray extensions, которые появились гораздо раньше модификации ская
Ой немогу Сколько же бреда и псевдодогадок тут понаписано Да вы (это я к личностям типа RETRIX), и десятой части незнаете возможностей движка, которые уже лежат на поверхности, а пытаетесь вытянуть на свет залоченые. А ещё называете себя ковырятелями движка. Хотя конечно понятно, что восстановить то, что видели, куда интересней, чем разобраться в том, что уже есть (это сарказм)
Quote (Oblivion)
Quote (RETRIX) Хм...Это ещё более интересно, если вы говорите, всё же скрывают. Ранее я был уверен, что именно из-за простоты движка сталкер не стал таким широким, оказывается из-за лени пысов...а значит двигатель как и был широким, так и остался... Не из-за лени ПЫСов а из- за издателя. Да и слишком уж много всего они напридумывали, а на допиливание времени уже не было.
вы в курсе, что команда разрабочтиков (движка в том числе) неоднократно менялась? и ещё до прихода THQ, т.е. это были только внутрикомандные споры и дрязги. В кодах ТЧ/ЧН/ЗП осталось дофига ещё с первых билдов (в ЗП меньше, там хорошо почистили), а каждая новая команда вместо того, что-бы вникнуть в то, что писали их предшественники, писали своё аналогичное.
Quote (a8758099)
Кстати, в той теме и Kolmogor побывал. А он, как мы знаем, сейчас в одной команде с Dezodor'ом. Кто знает, что он там наворотил..
колмогор уже больше года, как незанимается модингом сталкера вообще. "Натворил" он там не так много, но существенно - дальность отрисовки травы. Остальное понемногу восстанвливают неофиты Скайлоадер/_Призрак_
Quote (Virus_UA)
письмо Прохорову бредово звучит, да и пысы ничего не дадут
одна из самых трезвых мыслей в этой теме!
Итог: тема бред полный - надо закрыть во избежания лишнего флуда. Всё равно за 6 страниц ни одного сообщения по существу, одни бредни про коллективное письмо и щедрость пысов в раздаче движков.
Почитал всё это, поржал от души:) Восстанавливать вырезанные фишки - нет смысла, они были вырезаны из-за того, что не имели превосходного вида, они были не доработанны, а время на их доработку не было. Так что вы пытаетесь восстановить забагованные фишки. RETRIX, Ну да, конечно, можно и добавить новое оружие не через конфиги, а через движок, так практичней. Дело в том, что X-Ray технология в которой оснавная фишка редактирование ресурсов, вот по этому, не надо придумывать что-то через движок, на это есть конфиги и скрипты. _Призрак_, если я тебя правильно понимаю, то всё это большое дело можно заменить маленьким, как? А почти просто. Качаем перехватчик LUA для ТЧ или ЧН,ЗП дабы есть сылка, и пишем модуль. Точно таким же способом Амикрон и Диксарес написали поддержку mp3. Я это видел, интересная реализация, но mp3 воспроизводил не движок, а модуль, тоесть движ как и раньше воспроизводил *.ogg, а модуль по верх него играл *.mp3. Дело это запускалось из скриптов, я думаю можно было бы точно так же внедрить такую функцию в тот же мафон на базе Долга. P.S. Модуль тот был написан на С++, но как я понял, его можно писать на чём угодно, хоть на БрайнФаке.
он, но мне эта функция до лампочки, так же как и раскачка оружия (которую толком так никто и не смог объяснить). Со слов колмогора, раскачку он восстанавливал для каждого класса оружия, а не одним кликом для всего сразу. Но мне эта "раскачка" не интересна, поэтому силно в детали не вникал. хм. сейчас припоминаю, что вроде открытие дверей мутили с ним на ТЧ совсем недавно (около года назад), но так и забросили ввиду отсутствия интереса.
Сейчас трезво взглянув на всю информацию мне кажется, что реально для ЛА используеться один из отладочных билдов ТЧ времен 4 патча (с частью рабочих функций). Очень много странных кусочков. Потому как опять же с колмогором сидели пытались вернуть блодмарки на ТЧ, в то время, как по идее они уже им были возвёрнуты в ЛА, т.е. технология как-бы уже должна быть известна, аналогично с дверьми авто. Странно всё это.
В плане реализации или в плане, что это вообще такое?
Если первое, то я выше приводил ссылку на GAMEINATOR. Там было написано про файл (исходник, разумеется) WeaponsHUD.cpp и camera_bobbing. Вроде как это подсказал один из бывших разработчиков; А если второе, то можно посмотреть в любом геймлейном ролике старых билдов, к примеру, тут (1935).
Раскачка оружия - не в анимациях ли дело? Если просто создать анимацию для того или иного оружия, что не будет такого же эффекта? Прыгающий псевдогигант? Вы смеётесь, такого физически невозможно. А вообще сталкер изначально делался без какой-либо строгой концепции, так что эта "фишка" могла быть просто для прикола разработчиков.
По поводу раскачки оружия. Мне тоже кажется, что всё намного проще. Но как её восстановить пока непонятно. Всмысле того, что точного плана по восстановлению нет.
Никто, кстати, не пробовал редактировать Хекс редактором сталкерский ДЛЛ?
RETRIX, успокойся ты, сколько бессмысленного трепа. Жвижок ковыряли и ковыряют, просто для эхтого надо быть талантливым и образованным в даной сфере человеком, коих в фанкомьюнити сталка очень мало.