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.

Ну это вообще классика. Конструкции вида: if (<условие>) return true; else return false; Вместо простого return <условие> всегда вызывали у меня ступор. Начинаешь гадать, а не имел ли в виду автор что-то премудрое, например последующее расширение кода типа такого: if (<условие>) { // сделать что-то перед возвратом значения return true; } else return false; Но потом всегда оказывается, что это стиль такой. Немного позанудствую, но это не оператор. Это два последовательных оператора логического отрицания. И поскольку в С/С++ значения и так автоматом интерпретируются как логические, то в использовании этой конструкции чаще всего нет нужды. О, да! Особенно использование неинициализированной переменной x1. Понятно, что это Паскаль, и там есть значения по умолчанию, но всё же это подрастрельная статья. Однако, этот код напомнил мне ещё об одном вполне легитимном использовании goto. Если надо организовать цикл из кода, который не влезает в один экран, то использование goto может оказаться предпочтительным перед встроенным циклом. Дело в том, что к структурным операторам прилагается соответствующее форматирование, в частности отступ. А если отступ идёт на огромный блок кода, то он не улучшает читаемость, а только ухудшает (структуру всё равно не показывает, поскольку не видно обеих границ, а только увеличивает пустое пространство слева). goto же отступа не требует. Типичный случай - главный цикл программы. Это обычно бесконечный цикл, и внутри него может быть до чёрта напихано. Это помимо уже упоминавшегося выхода из вложенных циклов. Ещё весьма важный случай - для нужд отладки и эксперимента. Хоть это и не должно попасть в готовую программу, но наличие такого инструмента может сильно упростить процесс разработки. Ещё вспомнил случай из своей практики. Был у меня код вида такого: lab1: // фрагмент сложного цикла 1 lab2: // фрагмент сложного цикла 2 if () goto lab1; // фрагмент сложного цикла 3 if () goto lab2; Т.е. цикл состоит из трёх фрагментов, где постоянной частью является фрагмент 2, а зависимости от условий перед ним или после него выполняется ещё какой-то код. Я пытался заменить это на использование структурных операторов, но всё выходило существенно хуже: более громоздко и намного менее очевидно.

Desertir, возможно кого-то это покоробит, но лично мне глубоко безразлично, что будут думать о моём коде другие люди. Я исхожу из того, что первым человеком, который будет сопровождать мой код, буду я сам. Поэтому я себе упрощаю жизнь. Если есть смысл использовать goto, и код от этого станет лаконичнее и понятнее, то я буду использовать goto. Нет смысла - не буду. Чаще всего он и не нужен. Но если таки нужен, то все теоретики идут лесом. Я признаться не понял, ты споришь со мной или соглашаешься. Судя по этой фразе, обсуждать вообще нечего. Если проблема не в инструменте, а в том, кто его использует, то и с goto нет проблем. Это ведь всего лишь инструмент. Как и любой инструмент, его надо использовать с умом, и будет тогда щастье. Поскольку без головы можно любую программу превратить в нечитаемое, непостижимое и неотлаживаемое УГ. И причём безо всяких там goto.

=) Злостное трюкачество. Да и вообще-то речь о другом. Я только хотел сказать, что сам по себе оператор switch - это в сущности не что иное, как goto на метку case xxx: У case даже синтаксис почти как у метки - заканчивается двоеточием - и логика работы в точности как у метки для перехода, т.е. туда тупо передаётся управление и продолжается выполнение далее по ходу (если нет break конечно). Сам break - это не что иное, как goto на метку, расположенную сразу за оператором for или switch. Оператор continue - просто замаскированный goto на метку, расположенную в конце тела цикла. Оператор return для внутренней реализации часто требует или дублирования кода завершения функции либо опять же представляет собой просто аналог перехода на метку в конце тела функции. Т.е. сам язык по-сути набит фиговыми листиками, едва-едва прикрывающими этот самый goto. Посему не вижу большого смысла быть святее Папы Римского и разводить большие разговоры насчёт неприемлемости использования этого оператора.

Не надо преувеличивать проблему. В точно такой же ад может превратить дебаг, исправление, понимание и т.д. не использование этого оператора там, где это уместно. Как, к примеру, в вышеприведённом совете паковать вложенный цикл в функцию. В С++, кстати, полно замаскированных операторов goto: switch, break, continue, множественные return - это всё по сути операторы goto.

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

@7.9 К сожалению, это вряд ли осуществимо в виде ассемблерной правки (не считая того, что проект уже по-сути заморожен). В исходниках наверное можно сделать, но это уже другая история. Вообще же, не очень понятно, зачем вообще эта фича нужна. При текущем подходе для каждой пропорции надо всё равно делать набор конфигов руками. От этой работы никто не избавит (в рамках именно такого подхода). Получается, что движок должен только переключать наборы конфигов в зависимости от пропорций. Но это как раз совершенно спокойно можно сделать и вне движка: например в специальном ланчере. Я бы так и делал, а из движка это переключение вообще бы убрал (всё равно оно там сделано до невозможности криво и попросту убого).

Предложенные тобой варианты избыточны в плохом смысле. Дело в том, что размер элемента массива вообще хранить не нужно, поскольку в С/С++ эта информация связана с типом и меняться не может. Размер элемента "вкомпилирован" в код, а ты предлагаешь хранить его в ячейке памяти, что существенно медленнее работает. А в стандартном векторе С++, если мне не изменяет память, хранится не указатель на конец массива, а указатель на конец зарезервированной под массив памяти. Есть там даже специальный метод reserve() для резервирования этой памяти, а сам язык при наращивании размера массива добавляет резерв с запасом, который рассчитывает по определённому алгоритму. Т.е. там ничего избыточного нет.

@НаноБот, вношу поправку в предыдущий пост. bsdiff использовался не столько для удобства публики, а скорее потому, что не хотелось вносить в состав публичного проекта правленый файл dll. Ну т.е. в сущности всё равно для удобства публики, поскольку иначе пришлось бы заставлять всех учиться добавлять секцию с помощью PE Tools =) Если вышеозначенное соображение насчёт присутствия правленного коммерческого бинарника не важно, то можно просто создать этот файл с пустой секцией один раз и затем его и использовать. Просто создавать батником копию перед переносом правок, а оригинал не трогать. В любом случае мучения с PE Tools - это ровно один раз на один проект. ЗЫ: Только не подумай, что я тебя отговариваю от написания своих утилит. Я просто уточняю как было. А так чем больше утилит, тем лучше. Если бы меня не стукнуло переписать вариант Колмогора, то мучились бы сейчас с его утилитой (там было больше ручной настройки).

@НаноБот, Ну в целом bspatch использовался только для удобства публики. Исходно новая секция добавлялась с помощью PE Tools, а bsdiff/bspatch только создавал файл разницы и позволял его позже применять уже без PE Tools. Если знаете, как пользоваться PE Tools или чем-то подобным, то ничего другого не нужно.

@НаноБот, автором bspatch.exe/bsdiff.exe является Colin Percival.Там есть исходники, но под Unix/Linux. Порт утилиты под винду сделал Andreas John. Его сайта уже нет, как и ссылки на скачивание. Однако, у себя нашёл. Авторами patcher.exe являются [member=Колмогор] и ваш покорный слуга. Колмогор изначально разработал методику бинарных патчей с дополнительной секцией и создал утилиту для этого дела. Я утилиту переработал для более удобного и автоматизированного использования. Вот исходники. Утилита ужасна внутри и наверняка имеет косяки, но доводить её до ума времени, да и желания, так и не появилось.