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

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[Malandrinus 611]

@-StalkMen-,

я не понял, о чём ты. Понятие "асинхронный" я знаю применительно к передаче сообщения. Асинхронный в этом контексте означает неодновременный (что понятно из названия, поскольку буквально "не синхронный"). Смысл в том, что обработка сообщения идёт не сразу, как для синхронного вызова, а позже (не важно в этом потоке или другом). А что такое асинхронная физика?

 

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

[-StalkMen- 159]

@Malandrinus,

Я и не говорил, что будет просто

Я к тому, что X-Ray можно распараллелить, но не весь и не за один день
Нельзя асинхрнно юзать луа? Значит надо засинхронизировать доступ к lua стейту.
Сложно реализовать Распараллеленный расчёт физики в старой версии ODE ? Искать замену.- новая версия или там физиксы всякие.

Конечно если "расчёт точки Б связан с координатами точки А", то тут мало что можно сделать. Но ведь так не всегда, Может у нас две пары точек, не связанных межу собой - Можно в два потока посчитать
 

[Expropriator 2 118]

Нашел движок для сетевых и одиночных  игр. Бесплатный - условно (код закрыт - стоит денег (больше штуки баксов)), а так разрешено продавать свою игру. 8 человек онлайн. Все типы техники. Есть СДК. Уроки. Поддержка.

. Изменено 8 Сентября 2016 пользователем Дизель

[ed_rez 16 098]

Prosectors Project

Проект разрабатывают: C.I.U. (Lua, LUA C API), Nazgool (Lua), Malandrinus (Lua, C++)

Что это?

Это рефакторинг-проект, который нацелен на переработку ресурсов игры, в частности и кода. Добавляет множество систем, функций и исправлений. Мы искренне надеемся, что каждый для себя найдет что-то полезное, для этого все и затевалось.
Текущая версия проекта представляет собой практически законченную, по нашему мнению, техническую базу, которую мы разрабатываем для себя, и которой мы не против поделится со всеми . Будем категорически рады увидеть единомышленников.
Какова цель проекта?
Изначальная идея состояла в том, чтобы вычистить мусор, оптимизировать код и написать все популярные модули и системы по новым правилам с использованием новых возможностей (читай исходников). Сейчас же произошла небольшая коррекция, теперь мы хотим продемонстрировать всем людям, которые еще не перешли на исходники или скептически к ним относятся, тот факт, что не стоит боятся чего-то нового, игра никак не меняется, зато существенно расширяются возможности, можно сказать до бесконечности. Мы пытаемся создать удобный и, что главнее, стабильный инструмент, где не нужно дополнительно возится что-то настраивая или адаптируя. Обобщая, на сегодняшний день готова такая лаконичная платформа для любых разработок, в которую уже интегрирован весь необходимый инструментарий. Исходя из этого, скептически настроенные люди могут просто взять и попробовать что-то создать на этой основе без лишнего ущерба для своего времени. В итоге, если хотя бы у нескольких людей с помощью этого проекта чаша весов склонится в сторону использования исходников, то проект был создан не зря.
Каковы промежуточные результаты?
На данный момент нам удалось сократить количество скриптов более чем в три раза по сравнению с оригиналом (140(+6) против 441). Переработано большое количество кода, вычищен мусор, оптимизированы многие участки, исправлена масса ошибок, но несмотря на это работы еще очень много. Новых игровых особенностей мы пока не вносили, так как чтобы их создавать нужно отточить рабочую платформу, созданием которой мы сейчас и заняты, а она включает не только системы вроде таймеров, хранилищ, дебагового функционала, но еще и оригинальный код, который относится к сюжету или игровым особенностям. Он также линкуется и перерабатывается с новым стилем скриптового кода. Также мы стараемся постоянно повышать качество скриптового кода, следовать канонам Lua, а также затруднительные участки оптимизировать с помощью движка, чего мы добились - показывают замеры.
Также не малую часть работы занимает и переработка конфигов, так как там тоже скопилось достаточное количество мусора, а работать с конфигами очень тяжело. Переработка кода и файлов идет постепенно, в отличии от скриптов, процесс достаточно емкий по времени и требует большого опыта.
Почему в файлах две системы событий?
Я объясню почему. Все системы, которые присутствуют в проекте написаны своими руками и сторонние системы не использовались, почему? Потому что мы хотим на 100% владеть пониманием тех систем, с которыми работаем, а это возможно только при личной разработке (или более длительному пониманию кода сторонних авторов). Вернемся к событиям. Они введены только для поддержки работы таймеров, разработка под основную систему событий не была завершена и обкатана в свое время, поэтому было принято решение взять ту систему, которая понятна и стабильна, и, самое главное, о которой можно напрямую спросить автора. Наконец, если разработка под основную систему событий будет доделана, то текущее положение вещей будет переделано. В любом случае волноваться не стоит, здесь абсолютно ничего страшного нет.
Высока-ли модульность в скриптах?
На наш взгляд мы продвинулись до достаточного уровня, чтобы отдельные системы, даже те, которые работают с объектами, можно было безболезненно включать и отключать путем добавления или удаления файлов. С помощью новой системы сохранения появилась абсолютная совместимость сейвов, и все модули (скрипты), в которых предусмотрена опциональность можно удалять в любой момент (а по умолчанию это абсолютно все скрипты), так как их данные хранятся не в net_packet. Более того, система сохранения сама вычистит данные этого модуля, если он был удален безвозвратно(!). Как это? Это значит, что вы этот модуль больше никогда не добавите к скриптам, а если вы хотите удалить какую-то систему лишь на время (но сохранить все ее данные), то и это тоже возможно. Таким образом, например, вам не нравится работа какой-либо опциональной системы (в которой что-либо сохраняется) на определенном этапе игры, у нас вы можете отключить эту систему на время, пройти без ее участия этот этап игры, а затем снова ее активировать, и все ее прежние данные никуда не потеряются. Весь предыдущий опыт комьюнити, вроде изолированного создания какой-то системы под дебагом у нас тоже присутствует.
Почему не присутствует обновленный LuaJIT?
Любой, кто подключал обновленный LuaJIT сталкивался с проблемами измененного алгоритма работы некоторых lua-функий. Поскольку луа – табличный язык, а проблемы встречаются именно там, то очевидно, что оригинальный сталкерский код не рассчитан на измененную работу функций, и отсюда начинались различные баги. Выход есть, это проверка и корректировка всех скриптов, но сразу заметим, что задача это довольно трудоемкая и мы от ее выполнения отказались. Но(!), я готов дать движок с новым LuaJIT именно для тех, кто захочет этим заняться, и если ваша работа увенчается успехом, то по крайней мере мы своим составом объявим вам благодарность, так как обновленный функционал открывает совершенно новые горизонты (см. документацию LuaJIT).
Почему нет документации ко всем системам?
Написание документации дело не быстрое, а без гарантий интереса к проекту не видим смысла расписывать принципы работы. В самих скриптах все достаточно подробно и понятно (на наш взгляд) отражено в комментариях. Если к системам проекта будет проявлен интерес, то руководства будут написаны.
Какие дополнения есть для диалогов?
Начнем, пожалуй, с главного. Мы переделали кеширование диалогов при старте игры, а точнее вырезали его вообще, и теперь любой диалог, любой граф и вся его начинка строится при непосредственном обращении к нему (при юзе персонажа, например), что это дает? Во-первых, с этим исправлением появляется смысл у динамичных диалогов, то есть они становятся действительно динамичными (и если в ветвлениях есть рандом, то он будет отрабатывать постоянно, ранее это было невозможно), а во-вторых появляется возможность строить графы диалогов прямо по ходу игры (даже не перезагружая игру вы можете постоянно перестраивать граф диалога), единственное нужно будет заранее зарегистрировать диалог, регистрация была оставлена для контроля, то есть набор диалогов по-прежнему статичен. Также мы задумались как можно дать функции диалога больше информации, рассматривался парсер и какая-то дополнительная информация. Выбор сделан в пользу второго, так как первое выглядит довольно громоздко, а информацию несет практически туже самую. Итого мы добавили в функции прекондишнов текст фразы, из него можно без труда понять где мы находимся, что сказал персонаж и что нам нужно сделать исходя из этого. В скриптовое получение фразы текст, разумеется, не передается, так как он вам известен заранее.
Почему ГГ так быстро устает? (или подобный вопрос)
Баланс никак не настраивался, сделаны такие грубые зарубки, из которых в дальнейшем возможно будет сделано что-то интересное. Если вы заметите какие-то сильные перегибы в балансе, то указывайте пожалуйста вкупе с вашим вариантом настройки этих параметров баланса. Корень зла зарыт в переработке различных расчетов прямо в движке, и чтобы эти обновленные формулы заставить качественно работать придется переработать довольно большую часть конфигов, поскольку в коллективе нет тех, кто мог бы этим заниматься, то это действо растянется надолго.
Как пользоваться рюкзаком?
Смотрите соответствующие видео на канале (ключевое слово - backpack). Под некоторыми видео существует подробное описание, которое ответит на большинство вопросов, остальные можно задать здесь. Стоит сразу предупредить, что данная система имеет ряд некритичных багов, о которых все-же стоит сообщать и вам, так как не исключено, что мы не увидели все недочеты.
YouTube-каналы разработчиков (не все материалы относятся к данному проекту): https://www.youtube.com/user/MrMalandrinus2010
Для более полного понимания давайте сразу продемонстрирую главный файл документации по движку: http://pastebin.com/FK0Wc3Nd

 

 

Тема проекта здесь: http://www.amk-team.ru/forum/topic/13387-prosectors-project/#entry1036058

Изменено 8 Сентября 2016 пользователем ed_rez

[TIGER_VLAD 361]

Погромисты, с Днем Программиста !!! 

[НаноБот 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 пользователем НаноБот

[Expropriator 2 118]

Здравствуйте. Я изучал движение танка в NeoAxis 3D Engine Free SDK 3.5. Собрал пару танков на ходу.

 

 

 

Так всё гораздо проще, чем нам требуется для реанимации гусениц в Хрее - просто надо реализовать шейдер для текстур с движущейся развёрткой относительно нулевой координаты мирового пространства. То есть: начало движение модели, развёртка смещается векторно.

 

Это что то подобно шейдеру облаков  в Сталкере. Как реализовать?

Изменено 27 Сентября 2016 пользователем Дизель

[Malandrinus 611]

@Дизель,

нужен пиксельный шейдер, куда передаётся некий параметр из движка, что-то вроде фазового смещения текстуры по одной из координат. Соответственно, это смещение надо добавлять к продольной координате. Чтобы это работало, надо правильным образом ориентировать текстурки траков на геометрии (чтобы все смотрели в одну сторону) и также сделать так, чтобы они там не были растянуты (чтобы местами не ездили быстрее, чем все остальные).

 

Смотреться, правда, будет так себе, поскольку картинка трака будет ездить по статичной угловатой геометрии.

[Expropriator 2 118]

@Malandrinus, а что то меня терзают сомнения на счет угловатой геометрии?  Траки привязкой модификатора линкуются с костями, типа axle, для каждого колеса отдельно.

Про текстуры и развертки траков я в курсе. Меня интересует тот самый пиксельный шейдер.

Изменено 27 Сентября 2016 пользователем Дизель

[dPlayer 377]

Предлагаю обсудить такой вопрос, как роль скриптов в движке. ... Что думаете?

Спросил, что об этом думает Дмитрий Ясенев, и вот его ответ:

 

 

Дмитрий 1:05

как было исторически: Олесь Шишковцов добавил поддержку Луа, чтобы дизайнеры не просили программистов что-то менять, если им надо что-то попробовать.

 

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

 

Поэтому получилось то, что получилось.

 

Плюсы - расширяемость без перекомпиляции

Минусы - по факту расширять могут только "скриптовики" - те же программисты, но без нормальных средств отладки. Луа безбожно тормозит даже с ЛуаДжитом, использует непонятное количество памяти, постоянные кэш миссы, на Хбокс 360 - просто ужас ужасный.

 

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

 

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

 

Для геймдизайнеров надо делать что-то другое.

 

Луа - это а-ля анриловские блю принты: для прототипа норм, для продакшина не годится.

 

 

[НаноБот 705]

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

[Murarius 10 094]

 

 

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

Н-да...

[Expropriator 2 118]

@Malandrinus, снял видео о работе движка NeoAxis на этом принципе. Я сам привязывал танки полностью.

С 25 секунды смотри:

 

 

Изменено 28 Сентября 2016 пользователем Дизель

[Malandrinus 611]

 

 

Траки привязкой модификатора линкуются с костями, типа axle, для каждого колеса отдельно

Привязка - это хорошо, а как сами траки перемещаются вверх-вниз? Я смотрю на видео и это не очевидно. То ли физика работает, то ли нечто вроде Inverse Kinematics. По-любому, этого в X-Ray готового нет, поэтому траки будут просто статичной коробочкой вокруг колёс. Сразу, кстати, приходит на ум такая проблема. У автомобиля земли касаются колёса, а у танка земли касаются траки. Поэтому надо ещё и сделать разную физическую геометрию и меш катков. Физическая геометрия должна быть на толщину трака больше.

 

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

 

 

Спросил, что об этом думает Дмитрий Ясенев

С одной стороны конечно интересно, а с другой - почти ничего не сказал. Косвенно подтвердил мою мысль, что попросту не было нужных людей, чтобы развивать собственно движок. Ещё интересна информация о том, что многое делали в потёмках: "если им надо что-то попробовать" и "были непонятны рамки скриптов". Мне то казалось, что на момент введения скриптов уже был ясен план работ, а оно вон как было.

 

Это даже не отвечает на вопрос

 

 

А как дело со скриптами стоит в других движках, аналогичных хрею возможностей?

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

 

Хотя в целом сказанное не противоречит выводам насчёт необходимости снижения роли скриптов.

 

Лично я для себя уже определился - скрипты в таком виде как в сталкире резать. Остались колебания только по поводу GUI. Я здесь вижу две диаметрально противоположные стратегии. Первая согласуется с генеральной линией партии - убрать скрипты из GUI вообще. Вторая - напротив весь GUI делать на скриптах. На движок оставить только самые базовые классы: базовые окна, элементы управления, некоторые крупные блоки типа блока кнопок для главного меню (эта та штуковина с ползунком в виде увеличительного стекла и с интересным названием Shniaga). А всё остальное - скриптами, включая окна типа инвентаря, диалогов, пда и т.д. Разумеется, экспортировать контролы надо более полно и аккуратно, нежели это сделано сейчас. Также нужны все колбеки и ещё до кучи мелочи, но это уже детали. Такая стратегия тоже имеет право на жизнь. Дело в том, что производительность GUI как правило не критична, а это как раз та часть, которая довольно часто меняется модостроителями и при этом действительно в этом случае как-то нет смысла требовать от модостроителя знаний С++. Окошки - это как правило совершенно примитивная алгоритмическая работа, простые структуры данных, простые алгоритмы. В общем, здесь на самом деле можно найти смысл делать их скриптами. Но тогда уж полностью скриптами. Из ровно той же самой идеологии "убрать границы". Просто границу в данном случае можно передвинуть в одну из двух сторон.

[Expropriator 2 118]

У автомобиля земли касаются колёса, а у танка земли касаются траки

Вот ты и спалился . У авто колёса - не являются процессом движения, просто мишура. Там шейпы двигают и радиус в конфигах задает параметр движения.

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

Изменено 28 Сентября 2016 пользователем Дизель

[UnLoaded 313]

 

 

Первая согласуется с генеральной линией партии - убрать скрипты из GUI вообще.

Эмм... Если я правильно понял - при таком раскладе нарисовать свое окно мододел не сможет ?

[Malandrinus 611]

 

 

Вот ты и спалился

Это о чём?

 

 

 

У авто колёса - не являются процессом движения, просто мишура

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

 

Тем не менее колёса же земли касаются. Физической геометрией разумеется, не визуалом. Если обматывать колёса траками, то физическая геометрия (то, что называют шейпом в просторечии), должна быть на толщину трака больше визуальной. Вроде как банальная мысль, разве нет?

 

 

при таком раскладе нарисовать свое окно мододел не сможет ?

 

Ну почему? Я же всё это говорил в контексте наличия исходников. Ну конечно до какой-то степени надо знать С++ и студию, но это далеко не те заморочки, что в игровой логике. В окошках скучный и простой код безо всяких изысков. Если он понятен на Lua, то будет понятен и на С++.

 

Кстати, здесь прямо всплывает один из "тормозов развития" - крайне плохая структура модулей движка. GUI должен быть отдельным модулем и подпроектом, а сейчас является частью самого замороченного модуля - xrGame. Туда залезть и что-то там поменять страшно само по себе. Был бы отдельный модуль - только для окошек - даже чисто психологически было бы легче туда залезть и что надо подкрутить, не говоря уже о том, что это и объективно упрощает дело: меньше  модуль - легче понять, быстрее скомпилить, меньше зависимостей и т.д.

[dPlayer 377]

Malandrinus, а я и спрашивал в общем, без конкретики. А в принципе, Ясенев человек увлеченный и если ты задашь интересный ему вопрос он на него интересно и ответит.

А что, колёса машин в сталкере фейковые? Просто машины так правдоподобно буксуют, трактор встаёт на дыбы, большая разница между полным, передним и правильным приводами, даже работает дифференциал (!)... Не в каждой аркадной гонке такое реализовано. Не, походу все таки колесам передаётся вращение и они уже перемещают автомобиль.

[Malandrinus 611]

 

 

Ясенев человек увлеченный и если ты задашь интересный ему вопрос он на него интересно и ответит.

Я знаю. Сам один раз его спрашивал. Очень давно было, по планировщикам выяснял, когда ещё исходниками и не пахло.

 

 

 

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

Честно скажу, не знаю точно. Не лазил туда. Одно могу сказать точно, с точки зрения мат.моделирования, а здесь имеем именно полноценное моделирование, более устойчивое решение будет не с приводными колёсами, а с ведомыми, т.е. автомобиль - просто тележка, которую тянут/толкают глобальным усилием. Т.е. я бы сам так сделал, а как на самом деле сделано, не разбирался.

[Expropriator 2 118]

Вы своими рассуждениями про колёса авто - зашли не в ту степь. Шейп приатачивается к визуалу колеса и выполняет функцию движителя. Колесо же (визуальное) просто повторяет движение шейпа. Ровно повторяет - потому как приклеено намертво. Авто может перемещаться и без вращения визуального колеса, на не прилинкованом шейпе.

Давайте будем считать так, что авто движется от кости колеса, при помощи шейпа.

 

 

дифференциал

, если бы он там работал правильно. Это порнография, работающая не на мосты, а на все колёса сразу. Это больше напоминает фрикционную систему сцепления.

Изменено 29 Сентября 2016 пользователем Дизель