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

[Dennis_Chikin 3 658]

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

 

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

 

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

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

[Expropriator 2 118]

@НаноБот, у Варгейминга в ВОТ танках гусеницы работают отдельно от танка, примерно как я нарисовал выше. Только там не видно танка без гусениц, так как ГГ всегда в танке. А как быть тут, когда ГГ выйдет из танка, то гусеницы как нарисовать?

[НаноБот 706]

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

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

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

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

[Expropriator 2 118]

@НаноБот, понятно, это типа видимости костей света фар.

[Malandrinus 611]

 

 

Создай проект "VC++ для платформы CLR", добавь в него форму Windows Forms, открой и увидишь Дизайнер, аналогичный подобному в VC# и VB.

Не работает. Вместо формы появляется страница с сообщением о какой-то ошибке. По сети пишут, что и не должно работать, поскольку мелкософт дескать всех силком переводит под C#. Кто я такой, чтобы спорить с мелкософтом? =) Не хотят - и не надо, есть альтернативы.

[Kirgudu 966]

@Malandrinus, в установленной у меня 2013-й студии всё прекрасно работает:

Я, правда, не плюсовик, а шарпист , поэтому, возможно, натолкнулся бы на какую-нибудь ошибку дальше.

Изменено 30 Августа 2016 пользователем Kirgudu

[Malandrinus 611]

@Kirgudu,

у меня вместо такой формы какая-то текстовая белиберда со словами о каких-то внутренних исключениях. Студия 2015.

 

Да и всё равно, работает или нет. Я понял, что именно было сделано, и также понял, что для меня это не вариант. К чёрту всех этих мелкософтовских мутантов. Меня достало это стремление сжить со свету С++. Поскольку я не связан в данном случае никакими корпоративными ограничениями, то я и не обязан прогибаться под их мерзоту. Есть прекрасные альтернативы под чистые плюсы, хотя бы wxWidgets. Отлично работает со студией 2015, и там есть полный спектр GUI красот, включая docking. Проблему вижу только в том, что там некое время назад убрали сборку под ANSI строки, и сделали чисто под юникод. Это напрягает. Уже столкнулся с этим при работе над редактором диалогов (это в Stalker Plot Editor). Приходится там и здесь конвертировать туда-обратно. Но это пережить можно. А в целом надо просто завести в движке ещё один проект с интерфейсом, основанным на wxWidgets, класс приложения при этом надо создать не в основном потоке, а в отдельно созданном, чтобы была своя виндовая очередь сообщений.

[Malandrinus 611]

Вдогонку к сказанному по поводу интерфейса редактора на wxWidgets. Вот тестовая сборка ЗП с дополнительным внешним окошком на базе wxWidgets, которое запускается в отдельном потоке.

https://yadi.sk/d/RNFiyFwNufMrU

Примечания (просто чтобы было понятно, что это и о чём вообще):

В комплекте несколько файлов скриптов/конфигов, чтобы запускалось.

В архиве всё нужное содержимое папки bin (подразумевается рантайм от 2015 студии).

Все библиотеки вкомпилированы в экзешник, кроме openal32.dll (там какие-то проблемы с инициализацией при сборке в виде статической либы) и eax.dll, которая вообще имеется только в виде dll.

В силу монолитной сборки рендер только один, четвёртый..

Это не рабочий движок "под ключ", а просто демонстрация присоединения внешнего GUI. Если повезёт, то получится запустить игру, но сохранение/загрузка в целом поломаны моими экспериментами.

Внешнее окошко взято от балды. Это просто один из примеров от wxWidgets с какими-то пустыми фреймами с возможностью докинга. Никакого взаимодействия его с игрой нет. Поскольку окно рендера захватывает мышь, то надо переключаться по Alt-Tab, чтобы иметь возможность манипулировать этим окном.

 

В целом потребовалась совершенно минимальная адаптация проекта примера для включения его в общий проект движка. В самом движке в функции

void CRenderDevice::Run()

там где создаётся второй поток, добавил создание ещё одного.

thread_spawn(wx_Thread, "external GUI thread", 0, 0);

 

В проекте wxWidgets убрал дефолтовый метод запуска приложения в виде макроса

wxIMPLEMENT_APP(Docking2App);
чтобы не создавалась функция WinMain, и вместо этого в функции потока wx_Thread вставил следующее:

void wx_Thread(void *ptr)
{
    wxDISABLE_DEBUG_SUPPORT();
    wxApp::SetInstance(new Docking2App());
    wxEntryStart(g_hInstance, g_hPrevInstance, g_lpCmdLine, g_nCmdShow);
    wxTheApp->OnInit();
    wxTheApp->OnRun();
    wxTheApp->OnExit();
    wxEntryCleanup();
}

Т.е. там создаётся экземпляр класса приложения и вручную запускается его цикл выборки сообщений.
 

И всё. Гораздо больше было возни с тем, чтобы найти нужные настройки проекта, чтобы всё собиралось. Особенно пришлось повозиться с исключениями и настройкой библиотек. Но это всё делается один раз.

 

 

[Malandrinus 611]

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

 

Начать можно с того, а с чего собственно вообще скрипты. Исторически никаких скриптов в сталкире не было. Все схемы логики были внутри, квестовая составляющая также прекрасно обходилась без скриптов. Есть даже билды, не помню за какой год и с каким номером, где это хорошо видно - вполне можно обойтись без скриптов. Добавили их позже. Официальная версия - чтобы загнать симуляцию в квестовые рамки. Вот здесь возникает вопрос, а что мешало это сделать без скриптов? Что мешало ограничить миграцию неписей и добавить аналог гулага и скриптовых работ на уровне движка? На мой взгляд, если бы изначально такая задача стояла, то не было бы никаких проблем с её реализацией. У меня есть только одна версия, почему так поступили. Я думаю, что на тот момент попросту уже ничего было не сделать с движком. Его сложность превысила пределы, за которыми можно оперативно внести такие изменения. В итоге со скриптами вышел мутант. Вместо того, чтобы использовать скрипты для склейки движковых компонент, скрипты по сути использовались для написания весомой части игровой логики, которая заменила собой часть внутренней. Большая часть движковых схем поведения осталась неактивной. Даже управление анимациями сделали через внешний планировщик. На мой взгляд, всё это совершенно ненормально. Скрипты попросту не предназначены для такой серьёзной алгоритмической работы, как написание схем поведения. Прекондишены в диалогах и квестах - вот разумный диапазон применения.

 

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

 

Соответственно, вывод простой: роль скриптов при наличии открытой архитектуры и отсутствии коммерческих рамок надо радикально снижать. Логику реализовывать исключительно внутри движка. GUI - может да, может нет. Откровенно говоря, для окошек тоже нет особой нужды в скриптах. Мне до сих пор непонятно, зачем заскриптовано главное меню. Где можно оставить, это в квестовой логике, проверять сложные условия, которые тяжело сформулировать единственной инфопорцией, и выполнять примитивные действия там же (передача предметов, выдача денег и т.п.). Для последней задачи скриптовая модель требуется куда проще, чем она есть сейчас. Нужны только классы и функции для получения информации и простейших инвентарных манипуляций.

 

Что думаете?

[Expropriator 2 118]

@Malandrinus, главное в скрости внесения правок. В скрипт - секунды, в движок - час. И чем больше функций в движке, больше время для билда. Есть такая утилита, как Унити или УДК (не помню точно), так там скрипты все в движке билдятся.

[TIGER_VLAD 361]

@Дизель, Согласен, в этом как бы большой плюс. Сделал какую-то маленькую правку- запустил игру, проверил, а не заново движок собирать.

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

[dsh 3 820]

Это тоже самое, как с ассемблером или C. На них должны писаться только критичные вещи. Так и с движком. Как по мне, так в движке должны быть только низкоуровневые вещи или то, что в скриптовой реализации создаст слишком большую нагрузку. Все остальное - для скриптов. И главное меню яркий тому пример. Зачем цементировать в движке то, что можно написать на скриптовом языке и оно хорошо работает. Смарты, гулаги, респаунеры и многое другое прекрасно реализуется скриптово и нормально работает.

[Malandrinus 611]

 

 

главное в скрости внесения правок

Не соглашусь. Общее потраченное на разработку время включает в себя также и отладку. Причём отладка занимает существенно большее время, нежели собственно внесение правок. А здесь как раз тот момент, который я выше упоминал: "Скрипты не предназначены для серьёзной алгоритмической работы". Отладить без серьёзного геморроя можно только что-то очень простое и самоочевидное. Прекондишены в диалогах - самое то. Схемы - на порядок сложнее.

 

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

 

Если вдаваться в лирику, то отладка скриптов в сталкире живо напомнила мне отладку программ на ассемблере под Спектрум (олдфаги помнят эту машинку). Грузишь с кассетного магнитофона ассемблер, грузишь с магнитофона программу, компилишь, запускаешь, отлаживаешь почти вслепую. От малейшего чиха всё перезагружается и начинаешь всё сначала: грузишь одно, другое... Лепота. Терпение развивало просто железное.

[dsh 3 820]

 

 

Скрипты не предназначены для серьёзной алгоритмической работы

 

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

 

 

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

 

А это всего-лишь говорит об отсутствии инструмента скриптовой отладки. Вместо запихивания в движок всего и вся, полезнее будет сделать такой инструмент.

[Murarius 10 107]

 

 

Только вот убеждение изначально ложное.

Думаю, наблюдающим за дискуссией было бы полезно понимать - почему именно оно ложное. Ты не мог бы обосновать свое мнение?

[Malandrinus 611]

 

 

Ты исходишь из ложного убеждения

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

1. Язык примитивен. Это упрощает изучение (и программирование простых задач), но соответственно ограничивает инструментарий и усложняет решение действительно сложных задач. Здесь можно много чего перечислить, но упомяну хотя бы отсутствие жёсткой типизации. Новичкам это кажется благом. Опытный же программист лишается важного инструмента снижения сложности и контроля ошибок.

2. Ограничения библиотек и скриптовой модели. По-простому, что экспортировано, то и доступно, что из стандартных библиотек, что из API игры. Заведомо невозможно иметь настолько же полный доступ как к системе, так и к игре, как из С++.

3. Производительность. При уместном употреблении скриптов этот вопрос не должен возникать, однако скриптов явно перебор. поэтому не спасает даже LuaJIT. Если бы скрипты использовались только в уместном объёме и в уместных местах, то было бы по большому счёту без разницы, JIT там или голый интерпретируемый Lua.

4. Среда разработки, точнее её отсутствие. Таки нету её, и это реальный недостаток со всеми вытекающими, в первую очередь невозможность полноценной отладки.

 

 

полезнее будет сделать такой инструмент.

Т.е. сперва создали проблему использованием скриптов в неподобающих целях, а теперь превозмогаем? Может всё-таки просто не создавать проблемы? Ведь инструмента под Lua нет, под С++ есть, и Lua явно выглядит менее подходящим в целом для серьёзной работы.

[Expropriator 2 118]

Можно флудить тут? Тема же курительная.

 

 

 

почему именно оно ложное.

Я думаю, что оно тоже ложное. Хотя я не понимаю в этой теме и 99%. Скрипты являются своеобразной выноской управления движком. Это типа пульта ДУ. Много видел примеров в скриптах, которые заменяют движковые функции. 

[dsh 3 820]

почему именно оно ложное

По меньшей мере по одной причине. Что бы оно только попыталось стать не ложным, нужно для начала определить, что есть "серьёзной алгоритмической работы". А так, просто утверждение из серии "C rulez forever" и т.п.

 

Язык примитивен

Все императивные языки одинаково примитивны. Все основаны на присваиваниях, циклах и ветвлениях. В этом плане lua и семейство C - одинаковы.

 

По-простому, что экспортировано, то и доступно

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

 

Производительность

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

 

Среда разработки, точнее её отсутствие.

Батенька, а ты ведь не скриптовый писатель? Угадал? Знаешь, какой у меня профессиональный инструмент разработки? Emacs. Вполне себе отличная среда разработки. В ней и на lua ничуть не хуже разрабатывать, чем на перле.

[abramcumner 1 023]

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

[Malandrinus 611]

 

 

Это типа пульта ДУ. Много видел примеров в скриптах, которые заменяют движковые функции.

Таки отличная аналогия "Пульт" - это как раз хорошая аналогия уместного применения скриптов. Пульт же не заменяет телевизор, а только управляет им. А вот  когда мы скриптами начинаем ваять кусок движка - это как если в пульт перенести приёмник и посылать в телевизор сам видеосигнал. Пульт в итоге будет тяжёлый, будет жрать батарейки и глючить. Вот сейчас в сталкире в точности второй вариант.

 

 

что есть "серьёзной алгоритмической работы".

Схемы логики. Я кажется обозначал это несколько раз. Я считаю Lua неподходящим для подобной работы. GUI тоже.

 

 

 

Все императивные языки одинаково примитивны. Все основаны на присваиваниях, циклах и ветвлениях. В этом плане lua и семейство C - одинаковы.

У детской тележки четыре колеса. У автомобиля четыре колеса. Детская тележка и автомобиль - одинаковы. Ну нельзя же так. Я ведь даже упоминал одно из отличий, неужели нельзя было его прокомментировать? Кроме отсутствия жёсткой типизации я ещё могу перечислить: малое количество типов вообще, убогая работа с целыми типами, отсутствие препроцессора, бедные возможности ООП, нет обобщённого программирования, нет прямого доступа к памяти, таблицы отнюдь не заменяют все не свете коллекции.

 

 

 

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

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

 

 

 

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

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

[НаноБот 706]

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