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

[Malandrinus 623]

On 6/9/2018 at 1:56 PM, abramcumner said:

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

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

 

On 6/9/2018 at 4:16 PM, buffy said:

неприятно, что программа, которая выводит какую-то надпись, весит 60кб.

Скорее всего это не написанный код столько весит, а вся программа со всяким балластом типа стандартного пролога/эпилога, стандартных секций, недооптимизированных стандартных библиотек и т.п. Если же залезть внутрь и сравнить собственно размер скомпилированного кода, то разница не будет так уж велика. А по поводу балласта. Во-первых, часть балласта можно урезать при некотором старании. Во-вторых, этот балласт останется ровно таким же при размере программы в пару кб и пару десятков Мб. Ну и наконец. 60 кб - серьёзно?! ЭТО повод для переживаний?!

 

On 6/9/2018 at 4:43 PM, Dennis_Chikin said:

РЕДАКТОР с поддержкой формул был написан. А также поддержкой сетевой работы, станков с ЧПУ, и со сжатием. В одном флаконе. ...Полтора кило размером,

Ну и что? А вот дизассемблер для Zilog Z80 занимает примерно 1 кб. Какое это отношение имеет к современным реалиям? Нынче вообще важнее время написания программы, а не размер кода. Просто потому, что при нынешней сложности программ стародавние подходы к их написанию приведут к бесконечным срокам разработки. Т.е. просто не закончить проект, ну скажем сталкира, ни в какие разумные сроки, пытаясь писать его так, как это делали вы с этим редактором.

 

7 hours ago, НаноБот said:

Весит 7.5 кб если использовать VS2010, с VS2017 весит 9.5 кб и не работает на ХР.

Так что к чёрту std cout и другую хрень.

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

 

7 hours ago, НаноБот said:

есть только х86 и х64

Жесть! Ты серьёзно думаешь, что сможешь запустить современную программу, скажем, на 286?

 

7 hours ago, НаноБот said:

макрос должен срабатывать по ходу следствия

Я попробую ещё раз, последний. Макрос - это элемент препроцессора. Препроцессор - это средство обработки исходного текста. Препроцессор берёт один текст и превращает его в другой. Это происходит ДО компиляции. Таким образом макрос препроцессора ПРИНЦИПИАЛЬНО НЕ МОЖЕТ работать во время выполнения.

[Malandrinus 623]

@DoK74rus, 

Есть ограничения на размеры AI сетки. Я это подробно объяснял в этом посте. За исключением этого, размер уровня ограничен только возможностями компьютера. Проблемы на Кордоне - это ты скорее всего что-то не так сделал.

[Malandrinus 623]

7 hours ago, НаноБот said:

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

Spoiler

даже невооружённым взглядом видно, что произвольная навигация намного сложнее, нежели навигация по сетке. Сетка - это на самом деле граф, а навигация по графу - задача давно решённая и незатратная. Наверное можно написать алгоритм навигации в произвольном окружении, но как представить себе затраты... Здесь даже навигация в пределах пары метров будет сопряжена с колоссальными вычислительными затратами на анализ бесчисленного количества конфигураций пространства. Хотя бы просто решить куда можно сделать шаг, а куда нельзя. Трассировкой лучей определять? Сканировать всё пространство вокруг да ещё с учётом габаритов персонажа? Теоретически можно, практически же даже одиночный запрос на трассировку лучей - весьма тяжёлая операция, и в движке используется в микроскопических дозах. Представим себе теперь, что этим занимается каждый непись, да на каждом шаге, да при этом по много-много раз. И это просто для того, чтобы решить, можно ли сделать шаг в сторону. Теперь можно помедитировать на тему, как построить путь из таких шагов в произвольном окружении, ну хотя бы на пару десятков метров.
Кроме того, к сетке же привязана информация об укрытиях. В СДК вроде как немалая часть времени просчёта сетки уходит как раз на просчёт укрытий: надо из каждого узла сетки просканировать пространство вокруг на предмет его закрытости. Представим себе теперь, что этим надо заниматься в каждый момент боёвки.

Spoiler

 

было бы разумнее пофиксить ограничения движка на размер AI сетки. Это уж всяко более реалистично, чем пытаться сделать "как в реале". Можно даже попытаться сделать навигацию максимально близкой к имеющейся. Ну например:
Пусть имеется суперлокация, покрытая узлами глобального графа. На этой суперлокации мы располагаем много локальных сеток уровня таким образом, чтобы они накладывались друг на друга частично таким образом, что в месте "перехлёста" сеток их узлы совпадали. Таким образом, мы ходим по одной из этих сеток, а когда попадаем в зону наложения двух сеток, то незаметно переходим с одной на другую, если наша навигация ведёт нас к узлу глобального графа, который находится в другой подсетке. Например: Бар - одна сетка, дорога между Баром и Кордоном, другая сетка с зоной наложения где-то в районе блокпостов. Непись идёт по сетке из Бара на Кордон, проходит через блокпост и попадает в переходную зону. Поскольку отсюда путь ведёт в другую сетку, то он перейдёт на сетку дороги и пойдёт уже по ней, и т.д. Такой подход позволил бы оставить львиную долю имеющегося кода.

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

 

 

[Malandrinus 623]

23 hours ago, НаноБот said:

проверять проходимость габарита НПС надо, хотя бы чтобы непыси не упирались в вдруг друга

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

Хотя может и можно что-то поделать, если при навигации занимать не одну, а две ячейки. В конце концов, есть и крупные монстры, типа псевдогиганта, которые явно крупнее одной ячейки. А может там так и делается, я не разбирался в этой части движка. Алгоритмы для этого давно есть и использовались ещё в доисторических играх, где клетки для перемещения были видны явно (типа пошаговой UFO). Там существовали юниты, занимающие 4 клетки, и это учитывалось при навигации (например, они не пролезали в дверь). 

[Malandrinus 623]

On 12/28/2018 at 5:27 PM, НаноБот said:

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

 

С чем бы это сравнить. Вот представь себе компанию, массово производящую автомобили, Mercedes или там GM. Сотни инженеров, месяцами работающие над каждой деталью, сложнейшая логистика, высочайший уровень автоматизации и прочее в этом роде. Теперь приходит такой механик из сельской автомастерской и говорит: "Гавно эти ваши инженеры и роботы. Напильник, молоток и гаечный ключ форева."

[Malandrinus 623]

On 11/15/2019 at 9:17 AM, Zander_driver said:

зачем и для чего в движке ТЧ разрабами создавалась куча ничегонеделающих классов оружия?

 

Думаю, это просто косяк, кривой дизайн классов. Люди же разные делали: AI, рендер, погоду, интерфейс, оружие, скрипты те-же - всё разные люди и с разным уровнем. AI и рендер сделаны на очень приличном уровне, а вот оружию с разрабами не повезло до такой степени, что не соблюдены даже простейшие принципы ООП. Конечно классов столько было не надо. Класс - это принципиально другое поведение, а большинство стволов отличаются только параметрами. Пары-тройки классов хватило бы за глаза: огнестрельное оружие, холодное оружие, ещё какая экзотика, да и всё наверное. Остальное - урезанием полного функционала и изменением параметров/визуалов/анимаций/звуков/и т.д.

 

Продажу движка, как мне думается, вовсе не планировали. Было просто не до того. Если бы делали движок на продажу, то ту-же систему оружия надо было делать совсем иначе. Например, чтобы ствол можно было собрать в SDK как конструктор лего из блоков: навешиваешь конфигами модули стрельбы сколько надо по количеству стволов, аналогично все прочие обвесы. Т.е. чтобы можно было чисто конфигами сформировать совершенно любой ствол с любым количеством стволов, прицелов, глушителей и прочего. И чтобы у оружия это можно было также модульно всё менять во время игры. В этом случае холодное оружие может быть таким же модулем, как и всё остальное. Можно прикрутить к любому стволу штык, а нож будет просто один фиксированный модуль холодного оружия. Ну я бы в этом направлении думал.

[Malandrinus 623]

15 hours ago, ed_rez said:

Программисты рендера и шейдеров готовы с тобой поспорить.

Неплохо было бы услышать больше конкретики. Не для поспорить, а просто интересно. Что не так в рендере?