Malandrinus

gam, Вроде как с частотой кадров, т.е. точной частоты нет.

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

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

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

На мой взгляд, слишком хлопотно. С другой стороны, что мешает подменять локацию просто подменяя переход на неё? Технология скриптовых переходов давно существует, так что просто надо по условию переходить на другую локацию.

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

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

Ну не знаю. По мне так баги в минорных версиях (т.е. уже пофиксенные) на конечный результат не влияют. А конечный результат, что включает поддержку стандартов, качество оптимизации, скорость компиляции, улучшается с каждой версией. Скорее всего это не написанный код столько весит, а вся программа со всяким балластом типа стандартного пролога/эпилога, стандартных секций, недооптимизированных стандартных библиотек и т.п. Если же залезть внутрь и сравнить собственно размер скомпилированного кода, то разница не будет так уж велика. А по поводу балласта. Во-первых, часть балласта можно урезать при некотором старании. Во-вторых, этот балласт останется ровно таким же при размере программы в пару кб и пару десятков Мб. Ну и наконец. 60 кб - серьёзно?! ЭТО повод для переживаний?! Ну и что? А вот дизассемблер для Zilog Z80 занимает примерно 1 кб. Какое это отношение имеет к современным реалиям? Нынче вообще важнее время написания программы, а не размер кода. Просто потому, что при нынешней сложности программ стародавние подходы к их написанию приведут к бесконечным срокам разработки. Т.е. просто не закончить проект, ну скажем сталкира, ни в какие разумные сроки, пытаясь писать его так, как это делали вы с этим редактором. Научись пользоваться компилятором и не перекладывай с больной головы на здоровую.. Жесть! Ты серьёзно думаешь, что сможешь запустить современную программу, скажем, на 286? Я попробую ещё раз, последний. Макрос - это элемент препроцессора. Препроцессор - это средство обработки исходного текста. Препроцессор берёт один текст и превращает его в другой. Это происходит ДО компиляции. Таким образом макрос препроцессора ПРИНЦИПИАЛЬНО НЕ МОЖЕТ работать во время выполнения.

НаноБот, "Вы просто не умеете их готовить" (C) Препроцессор (а ты говоришь о макросе препроцессора) - это средство времени ДО компиляции. Он берёт твой текст и преобразует его в другой текст, который затем уже и компилируется. Препроцессор по определению не делает ничего другого. Поэтому твоё пожелание, чтобы g_alive работал во время исполнения - заведомо некорректное. Этот макрос развернётся в что-то другое до того, как код вообще будет скомпилирован и уж всяко до исполнения. Инлайн-функции же работают совсем иначе. Инлайн функции - это конструкции времени компиляции, они учитывают контекст (своё окружение) а также все правила вызова функций. Когда ты имеешь дело с препроцессором, первый вопрос - хорошо ли ты понимаешь, что конкретно он делает. Без этого его использование чревато последствиями, поскольку ты видишь у себя один код, а реально компилируется что-то другое. Судя по всему, ты не до конца его понимаешь. Это нормально, препроцессор штука мутная, в случае с ассемблерами вообще не сильно стандартизированная и весьма специфичная для каждой конкретной версии и производителя, и именно поэтому его принято избегать. Я бы посмотрел, как ты написал бы на ассемблере парсер формул в 40 строк за пару часов (хотя наверняка этот код занял даже меньше). Dennis_Chikin, Да нормальный код же! Ничего нечитаемого. И насчёт С++11 там ничего такого запредельного нет. Вполне можно было бы обойтись обычными указателями на функции, но и всё. К собственно читаемости алгоритма это никакого отношения не имеет. Есть полная официальная документация на каждый процессор, в том числе и насчёт оптимизации. Другое дело, что это весьма пухлый документ для профильных специалистов, собственно создателей компиляторов и библиотек низкого уровня. Их же для того и пишут, чтобы каждому прикладнику не нужно было вникать во все эти детали. Для вас стараются, а вы нос воротите =) Ну и не надо забывать про разные платформы. Код на ассемблере будет работать на конкретной платформе. Код на языке высокого уровня будет работать везде, где есть соответствующий компилятор/интерпретатор. Всё позволяет. Вообще, Мелкософт много в чём можно упрекнуть, но их С/С++ компиляторы - одни из лучших и с каждой версией становятся только лучше.

Вот здесь я не понял. А как ты хотел, чтобы макрос препроцессора выполнялся на этапе выполнения программы? В целом то, что ты делаешь, - это путь в никуда. Ассемблер существует с единственной целью - чтобы компилировалось ровно то, что написано. Это важно, это изначальная суть ассемблера - последовательность инструкций процессора. Ты смотришь на код и точно знаешь, что получишь в итоге. У тебя же идёт уход в прямо противоположную сторону - нагромождение макросов препроцессора и даже кодогенерирующих директив (типа того же .IF). Какой в этом смысл? Такими вещами гораздо удобнее заниматься в языках высокого уровня, а ассемблер оставить для сугубо ограниченных целей: критические по производительности моменты и непосредственный доступ к железу в драйверах. Были бы у меня исходники изначально - не потратил бы ни секунды на всю эту возню с ассемблером. Более непроизводительного, неудобного и глючного способа писать код я в жизни не видал. Впрочем, у меня тогда не было другого выхода. Я отчётливо помню тот момент, когда решил влезть во всю эту историю с ассемблером. Я тогда для гравипушки придумал крайне извращённый способ отловить нажатие клавиши огня - по отлову быстрого расхода патронов. После этого я и понял, что это - предел и дальше чистыми скриптами ничего не развить. И тут как раз связался с Колмогор-ом насчёт этого его способа делать правки. Оттуда и завертелось. Но вот мотивации заниматься этим сейчас я не понимаю. Впрочем, каждому своё. В ближайшей перспективе ничем. Вроде пока ничего не собираются менять. А даже если и закроют - полно других свободных хостингов.

Не замечал за MASM особенных багов. Максимум, что мне от него было надо - компилировать код, генерируемый IDA. С этим MASM вполне справлялся. Единственная проблема была с версией 6 из состава Masm32. Но там был не баг, а просто старая версия, которая не поддерживала новые инструкции процессора. С трудом себе могу представить, что такое надо написать, чтобы ассемблер начал глючить. Если же речь идёт о глюках в препроцессоре, то это в ассемблере вообще от лукавого. Можно подумать, у тебя проект с компиляцией в пару часов. Не напомнишь, какая вообще мотивация продолжать использовать ассемблер?

Можно. Используются же в XE повсеместно. Это как? Может у тебя версия старая? Такого эффекта добиваются с использованием макропроцессора. Но в целом это путь в никуда. Ассемблер нужен для выполнения узких задач, в целом же лучше положиться на оптимизацию С/С++. Кроме того, у Микрософт-а ассемблер можно встраивать прямо в С/С++ код. Но из 64-х разрядного компилятора это убрали. Подозреваю, что именно потому, что это в широкой перспективе неправильно и неэффективно. Лучше скомпилировать отдельно модуль с нужными функциями чисто на ассемблере.

Если вылет вызван скриптом, то при вылете будет показан стек Lua и соответственно сбойный скрипт. Если этого нет, то напрашивается вывод, что сбой вызван не скриптом.

Строго говоря, эти условия не равнозначны. Однако, второе является избыточным, так как либо равно true (и таким образом не влияет на результат вне зависимости от значения p[2]), либо совпадает с первым, когда p[2] равно nil (поскольку в этом случае p[2] эквивалентно false), и соответственно тоже не влияет на результат. Зачем это сделано трудно предположить. Версия, что автор этого кода не знал об особенностях Lua и перестраховывался отпадает, поскольку избыточное условие стоит вторым и значит проверяется после первого и значит никак не страхует от проверки в первом условии потенциального значения nil.