Курилка программистов

[НаноБот 705]

 

 

и делает функция ровно то, что описано

Не понятно, но судя по скрипту удаляет динамит то, из инвентаря актора, а не Волка. А в комментарии написано удаляет из Волка, т.е. из его инвентаря.

[НаноБот 705]

Тоже самое с bool и BOOL, и другими типами.

bool - sizeof 1 byte

BOOL - sizeof 4 bytes

Это особенно важно, если ковыряешь движок в проекте XRay-Extensions.

А для си пляс пляс вроде как, не столь важно. Я не очень понял, почему где-то используется BOOL, а где-то bool, разве только что BOOL побыстрей будет, да наверно ещё от конкретной ассоциации с типами зависит. В общем, ассемблер гораздо проще и одновременно сложней си пляс пляс (нету идиотских заваротов).

Изменено 6 Ноября 2015 пользователем НаноБот

[НаноБот 705]

Интересно, если ЯП типа ассемблера, но в тоже время имеющий синтаксис  высокого уровня. Например:

function primer(int A, B, C);
eqi param1 = 500;
begin
eax = 2000;
ebx = 1000;
eax = eax + ebx;
esi.param1 = eax;
eax = A;
eax = eax + C;
eax = eax + B;
end;

MASM может в какой то мере использовать  синтаксис высокого уровня.

Но вся же почему пишут: mov eax, [esi+param1] а не eax = esi.param1, или даже eax = this.param1, где this заранее определён как esi т.е. указатель на собственный объект.

ЗЫ

Лет 15-18 назад у меня была такая идея, скрестить бэйсик и ассемблер 8080, ещё когда программировал на 8-ми битном Партнере 01.01, то есть, сделать свой собственный ассемблер с синтаксисом бэйсика "микрон", но реализовать мне это тогда было не реально. 

Изменено 2 Декабря 2015 пользователем НаноБот

[НаноБот 705]

@Malandrinus, я наверно не совсем правильно выразился, суть в том что инструкции называются максимально просто и имеют формат близкий к высокоуровневом ЯП.

Можно например и так: eax += ebx, уже не перепутаешь.

Или (xmm0.3 = xmm0.0, xmm0.2 = xmm0.0, xmm0.1 = xmm0.0, xmm0.0 = xmm0.0)(это просто пример, можно и покороче придумать) код ассемблера shufps xmm0, xmm0, 00000000b из нулевого элемента копируем во все остальные, векторная арифметика. Само собой такой ассемблер и нормальные команды должен понимать.

Кстати, более подробное изучения SSE показывает мощную оптимизацию по сравнению С++ кодом, т.е. низкоуровневый Fvector4 (xmm) компилятор студии почему-то не понимает. Есть маза переписать на ассемблер, в точности баллистику, с использованием SSE+SSE2+SSE3 для ТЧ, у ЧН и ЗП алгоритм баллистики слишком сложный и не реальный, переписывать его на асм дело не благодарное, и по этому делаем в виде альтернативы не трогая оригинальные функции, а. в конфигах можно включать баллистику или от ТЧ или новую баллистику на основе ТЧ (более продвинутый алгоритм на основе реальных алгоритмов бал. моделей) ну или пользоваться старой.

В общем, мне не нравится программировать на С++ из-за больших проблем с компиляцией, и сложностей распространения, людям проблематично скачивать огромные студии и компилировать проекты по 40 минут только одна xrGame.dll, да ещё для ТЧ, ЧН, ЗП надо разные студии (2008, 2010, 2013, 2015 для разных проектов), а это около 17-19 ГБ живого веса. Не чета простому проекту XRay-Extesions_portable с жалкими мегабайтами и моментально компиляцией (17 сек для ТЧ для xrGame.dll). Это я про конкуренцию ассемблера и С++ в рамках проекта модинга движка.

Изменено 3 Декабря 2015 пользователем НаноБот

[НаноБот 705]

А кстати, есть такой ЯП, который высокого уровня и при этом, очень близок к ассемблеру, это С-- сфинкс, жалко что уже не развивается. 

А про модинг движка, если правка простая, то порой проще написать эту правку на асме, чем мучится с С++ и долгой компиляцией, напоминаю, что я в С++ если не дуб дубом, то плохо понимаю его синтаксис и не которые замороченные принципы. Например, есть задача создать новый класс объекта, робота ХЕНа, той самой стальной курицы с пулемётом из билда 1098. Как это сделать в С++ я не очень хорошо понимаю, но я знаю что надо делать на классе сталкера CAI_Stalker и подсоединяем ему класс CCarWeapon для интегрированного оружия. В XRay-Extesions_portable я просто добавлю в класс сталкера возможность отыгрывать анимацию только самого робота хена, пропуская все остальные и придумаю что нибудь на счет оружия, при атачу класс CCarWeapon или ещё что нибудь придумаю. Хотя возможно робота хена надо на классе монстра делать. В билде 1098 у хена класс монстра по ходу был, сталкер то же наследует класс кастоммонстра. Конечно это всё надо делать в С++, класс все же отличается от самого сталкера и существенно, но мне так проще.

Изменено 3 Декабря 2015 пользователем НаноБот

[НаноБот 705]

Забавно, я тут малость тупанул из-за не достатка инфы.

МАСМ понимает много чего из языков высокого уровня, и на нем реально можно делать много чего.

http://dsmhelp.narod.ru/environment.htm

invoke, .if,.elseif, .else, .endif, .while, .repeat и т.д.

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

Изменено 4 Декабря 2015 пользователем НаноБот

[НаноБот 705]

 

 

Объясни пожалуйста, а что мешает тогда просто взять СИ и его использовать?

Проблема настройки визуала для меня не преодолимы, плохое для практического программирования знание С++, всё это сводит на нет преимущества сложной среды разработки. Поверь, если бы я хорошо знал Си, и в точности непосредственно Visual C++, то я бы не стал ассемблером пользоваться. На данный момент для меня MASM единственный язык программирования движка XRay, и у меня не плохо получается, работаю уже не посредственно с классами, переназначаю классы, удаляю не нужные, и могу на их место определять новые. Главное, я понял как эта инкапсуляция,  наследование и полиморфизм работает на уровне кодов, чтение книг по этой теме мне понимание не дало почти совсем. Так сказать, если хочешь понять как работает прибор, разбери его

[НаноБот 705]

Интересно, ковыряя код турели OGSE для лимитного боекомплекта с толкнулся с проблемой двойного апдейта объекта, т.е. для одного объекта вызывается два метода апдейта за один фрейм. В результате пулемёт у меня продолжал строчить когда у него закончились патроны, абсолютна такой баг был в билде 1098 с М134. А почему, а потому что шибко умные программисты с моей точки зрения не правильно понимают ООП. И прикрутили контрол биндер на нажатии клавиш, у которого свой апдейт, выглядит круто, типа, о да, ты крутой программист, но вот проблема.  В результате в одном апдейте шла команда прекратить стрельбу и тут же в другом шла команда продолжить огонь, и всё это было не явно, что начал думать что это глюки, то ли движка, то ли ЛУА. Проблему вылечил ГЛОБАЛЬНО, движковой правкой; теперь для биндеров где есть активный владелец, холдер, оружие, предмет в руках вызываются колбеки на нажатия клавиш. В реальности реально можно не заморачиваться с этим контролбиндером.

 

ЗЫ

И я заметил, по сложному пути идут часто программисты с хорошими знаниями, решает задачу сложно, но ему кажется что это правильно, он же крутой программист. Другим примером может мод ShWM 2.1 решения аплета, всё круто вот только игра дико конфликтует с антивирусами и реально можно было проще сделать на основе XRay-Extensions. У меня была такая мысль одно время, переделать шокермод 2.1 в 2.5 но полностью на XRay-Extensions. Но там уже 3.0 на подходе, решено не заморачиваться.

Изменено 23 Апреля 2016 пользователем НаноБот

[НаноБот 705]

Ради интереса прикрутил холдер вертолёту и это всё на ассемблере, но делал как на С++ (пришлось помучится, там ещё базу данных наследования классов вручную пришлось настраивать), т.е. если делать на С++, то  получится почти тоже самой. И кстати, если я бы всё это в студии делал, не факт что я бы сделал быстрей. Ну да ладно. Вот только вертолёт не хочет слушать команды как надо, из -за большой задержки, блин, может проще класс CCar научить летать, чем актёра вертолётом управлять. Или сделать специальный режим работы  для вертолёта, летим туда-то по вектору и разворачиваем куда вектор укажет.

 

 

 

Прикольно это слышать от программиста, который фигачит на ассемблере, при наличии исходников

Сложный путь, это именно изучения С++, и студии в частности, среда разработки очень простая у меня, изучать даже ни чего не надо, я все силы бросаю на сам код, хотя программировать на ассемблере сложней чем на С++, но это только для программиста который освоил С++ и саму студию. Для меня как раз сложный путь это программирования на С++, в качестве примера когда надо было изучить базу данных наследования, я смотрел код smart_cast.cpp и... ни хрена не понял как он работает, я во обще не понял как он работает, абсолютна, так что ассемблер рулит, он круче С++, просто потому что ПОНЯТНЕЙ!!!!!!!!!

Изменено 26 Апреля 2016 пользователем НаноБот

[НаноБот 705]

@Malandrinus, чем дальше, тем больше мне С++ не нравится, именно студия как среда разработки. Я сейчас конвертер OMF2SMD переписываю на делфи (потом SMD2OMF, надо для одной разработки), мне так проще, чем заставить от компилировать эту простую программу этой сложной студии. Хотя я трачу на это время. Может среду попроще найти, борланд или ещё какую.  Не знаю, может старый стал, что так С++ ака студия не даётся.

 

 

 

Вертолёт вообще-то и должен быть инерционным. Даже ствол пулемёта мгновенно не развернуть, а уж многотонную машину и подавно. Ты в авиасимуляторы играл?

Не, там надо переделывать, мне надо что бы верт слушался  как в билде 756.

[НаноБот 705]

А зачем столько классов оружия в сталкере?

Ну наверно, возможно, предполагалось методом smart_cast отличать один ствол от другого. На деле это делается (регистрируется) в методе void CObjectFactory::register_classes(), а в скриптах проверяется методом clsid. В общем, можно спокойно удалить часть классов, и к тому же, классы потребляют часть ресурсов, и если в классе нет особой нужды, то его лучше не создавать.

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

Изменено 12 Июля 2016 пользователем НаноБот

[НаноБот 705]

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

Я ещё тут подумал, и пришёл к выводу что взрывные объекты не совсем правильно сделаны, хорошо объект взрыва поместить в пространство level как и пули, это надо для взрывных пуль, то есть снарядов. Создание CGameObject весьма ресурсоёмко, и  для взрывного предмета который взорвётся сразу после создания это не целесообразно.

И совмещать класс CWeaponMagazinedWGrenade   с основным, не к чему, его просто надо доработать, имеем спаренное оружие, то есть кнопкой перейти на ПГ мы перегружаем почти все параметры оружия, и теперь можем легко сделать тройник, два ствола гладкоствольные, а нижний нарезной. И хорошо сделать двухстволку наследником этого класса.

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

 

Наверно стоит перечислить.

CWeaponMagazined Обычное оружие: стреляет пулями, одиночными и очередями. В этом классе стоит реализовать пару типов заряжания, нормальное и заряжание по одному патрону (револьвер НАГАН, подствольный магазин у дробовика). 

CWeaponMagazinedDual  Бинарное оружие: это оружие имеющие два разнотипных ствола (автомат с ПГ, автомат с подст. дробовиком, тройники).

CWeaponMagazinedRL Гранатомёты: оружие стреляющие ракетами, многозарядные, может стрелять очередями или залпом.

Дружественные классы - ракеты (хорошо бы сделать специальный класс объектов с ускоренным спавном, класс по определению не имеет серверного объекта, а не просто флажок):

Не управляемые ракеты, можно отключить способность взрываться (осветительной ракеты).

Управляемые ракеты: алгоритм наведение помещён в скрипт, в движке только есть алгоритм лететь в определённую точку.

Для ПЗРК так же целесообразно сделать отдельный класс, хотя можно и скриптом полностью реализовать, но если этот аппарат поместить в МП, то лучше будет алгоритм работы полностью в движке зашит, иначе читер может отключить или переделать механизм работы.

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

Изменено 19 Июля 2016 пользователем НаноБот

[НаноБот 705]

@Дизель, у гусеницы порядка 98 траков, и того порядка 230 костей надо, а ограничение 64 кости, и легкими методами это число не поднять. Я думаю проще объединить траки в группы  костей, и таких групп порядка 6-8, и всё, анимация только одна, делаем методы задающие скорость анимации, в том числе отрицательную скорость, что бы задом на перед можно было отыгрывать.

Хотя не, не получится, придётся делать по другому. Делаем эти группы не подвижными, а анимацию имитируем, задавая видимость и не видимость группы костей, согласно движению нашей гусеничной техники.

Давно мечтаю как было в диздоках, вернуть БМП-2, как раз идея для проекта Oblivion Lost Remake 3.0.

Изменено 29 Августа 2016 пользователем НаноБот

[НаноБот 705]

@HellRatz, в принципе можно и увеличить количество костей, например до 256. Но моя идей может быть реализована уже сейчас для проекта XRay-Extensions для ТЧ и ЗП. Надо только сделать соответствующий модель. Я так понимаю эти методы должны работать для костей не имеющих наследников. 

ЗЫ

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

Изменено 29 Августа 2016 пользователем НаноБот

[НаноБот 705]

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

Просто у модели делается несколько гусениц, траки каждой смещены не много вперёд, таких гусениц порядка 6-8 для каждой стороны и косточка каждая отдельно (например l_track_0, l_track_1, l_track_2 и так далее), и мы методам set_bone_invisible(bone) задаём видимость только одной гусеницы, а остальные невидимы. Как то так. Вроде понятно объяснил.

Хотя конечно можно сделать гусеницы отдельным объектом, который приатачен к нашему танку, но вся равно мешает ограничения количество костей. Но такой метод позволит реализовать полный физический эффект, включая разрыв гусеницы и разматывания её. Можно захватив гравиганом разорванную и слетевшую с танка гусеницу махать её и убивая врагов. Короче физика абсолютна реальная. 

Изменено 29 Августа 2016 пользователем НаноБот

[НаноБот 705]

Конечно от скриптов нельзя отказываться, но и решать многие проблемы чисто скриптами тоже нельзя, вот например Судьба Зоны, мод довольно сильно заскриптован, в ОГСЕ при бое с солдатами с блокпоста загрузка скриптами ЦПУ доходила до 75%. В общем, надо часть ресурсоёмких функций переносить в движок. Я например решил сделать колбек на вход объекта в зону для любого объекта, быстродействие повысилось, это я делал для детектора, можно для чего угодно, не надо перебирать ID'шник. На счёт отладки, а вот и нет, я лучше буду отлаживать в скритах какой либо алгоритм, код, чем в С++, я например уже биндеры называю так: CWeaponPZRK, т.е. я отлаживаю свой ПЗРК с начало в скриптах, уже потом буду переносить в С++ и то если потребуются. А почему не в С++, к чёрту С++, мне проще и быстрей в луа это отладить.

[НаноБот 705]

Наконец-то скачал Сервис Пак 1 для VS2010 и смог собрать проект с https://xp-dev.com/scs/210311

Как оказалось, там была ошибка, проект то и раньше у меня собирался(без сервис пака 1), но при старте НИ, игра валилась, я по началу не изучил лог как следует и не заметил проблему.

[26.09.16 13:41:21.953] FATAL ERROR

[26.09.16 13:41:21.953]
[26.09.16 13:41:21.953] [error]exp​ression : fatal error
[26.09.16 13:41:21.953] [error]Function : CInifile::r_string
[26.09.16 13:41:21.953] [error]File : Xr_ini.cpp
[26.09.16 13:41:21.953] [error]Line : 352
[26.09.16 13:41:21.953] [error]Description :
[26.09.16 13:41:21.953] [error]Arguments : Can't find variable anim_draw_empty_both in [wpn_bm16_hud], file f:\windows.old.000\program files\gsc world publishing\s.t.a.l.k.e.r\gamedata\config\system.ltx

 

Добавил в конфиг БМ16 нужную анимацию, игра ЗАРАБОТАЛА. Далее исправил код, что бы не вылетало. Вот:

// Real Wolf. 03.08.2014.   (с) НаноБот фикс вылета: если не нашли нужной анимацией для класса БМ16. 26.09.2016
#if defined(BM16_ANIMS_FIX)
	LPCSTR anim;
	anim = READ_IF_EXISTS(pSettings, r_string, *hud_sect, "anim_draw_empty_both", "draw");
	animGet	(mhud_draw_empty_both, anim);
	anim = READ_IF_EXISTS(pSettings, r_string, *hud_sect, "anim_draw_empty_right", "draw");
	animGet	(mhud_draw_empty_right, anim);
#endif 

 

 

Игра работает если забыть указать новые анимации в конфиге. Виновник проблем @Real Wolf, ну да ладно, странно что такую ошибку не заметили и не пофиксили, у меня ушло пару минут и 00:28:16.25 компиляции.

Изменено 26 Сентября 2016 пользователем НаноБот

[НаноБот 705]

Ну да, так и получается Луа-программистов гораздо больше чем С++, быстро что менять хорошо на Лау, а не на С++. В общем, имеет смысл перенести часть схем для НПС в движок, а Луа надо развивать, добавлять дополнительные методы, колбеки, что бы не городить огород.

[НаноБот 705]

Хотел спросить. Почему при нажатии Ctrl+F7(скомпилировать) у меня не создаётся исполняемый файл(xrGame.dll), то есть компиляция запускается, а этот файл не обновляется. Просто нажать F5(построить решение) слишком долго собирает, порядка 26 минут, а на Ctrl+F7, быстро, но файл не создаётся.

Изменено 6 Октября 2016 пользователем HellRatz

[НаноБот 705]

Да, долго код создаётся, можно конечно отключить оптимизацию, тогда минут 10 и файл xrGame.dll получается размером 10-12 МБ. Но опять проблемы, получаются не понятные вылеты, пока не разобрался где косяк, возможно скрипты или конфиги накрутил. Ах да, что лучше нажимать, "собрать xrGame.dll", или "собрать только xrGame.dll"?

ЗЫ

У меня русская версия.

Athlon II X4 640 3Ghz, 4-1 GB, WinXP 32 bit.

 

ЗЫЫ

В общем, разобрался, если собирать проект без оптимизации, то выскакивает ошибка в скрипте task_manager.script:222 - defend_object = nil. Я закинул себе в папку scripts этот скрипт и подправил код, но закинул не тот, т.е. из патча 1.0004 или 1.0005, в общем, мучился  целую ночь. Сейчас всё работает, но этот баг выскакивает если проект собран без оптимизации, т.е. алгоритмически код разный получается. Вот так то.

Изменено 7 Октября 2016 пользователем НаноБот