Перейти к контенту

Malandrinus

Жители
  • Число публикаций

    1 930
  • Регистрация

  • Последнее посещение

  • Дней в топе

    13
  • AMKoin

    48 [Подарить AMKoin]

Весь контент пользователя Malandrinus

  1. gam, Вроде как с частотой кадров, т.е. точной частоты нет.
  2. Неплохо было бы услышать больше конкретики. Не для поспорить, а просто интересно. Что не так в рендере?
  3. Думаю, это просто косяк, кривой дизайн классов. Люди же разные делали: AI, рендер, погоду, интерфейс, оружие, скрипты те-же - всё разные люди и с разным уровнем. AI и рендер сделаны на очень приличном уровне, а вот оружию с разрабами не повезло до такой степени, что не соблюдены даже простейшие принципы ООП. Конечно классов столько было не надо. Класс - это принципиально другое поведение, а большинство стволов отличаются только параметрами. Пары-тройки классов хватило бы за глаза: огнестрельное оружие, холодное оружие, ещё какая экзотика, да и всё наверное. Остальное - урезанием полного функци
  4. С чем бы это сравнить. Вот представь себе компанию, массово производящую автомобили, Mercedes или там GM. Сотни инженеров, месяцами работающие над каждой деталью, сложнейшая логистика, высочайший уровень автоматизации и прочее в этом роде. Теперь приходит такой механик из сельской автомастерской и говорит: "Гавно эти ваши инженеры и роботы. Напильник, молоток и гаечный ключ форева."
  5. Malandrinus

    X-Ray extensions

    На мой взгляд, слишком хлопотно. С другой стороны, что мешает подменять локацию просто подменяя переход на неё? Технология скриптовых переходов давно существует, так что просто надо по условию переходить на другую локацию.
  6. Размер ячейки сетки в 0.7 метра (если правильно помню) очевидно выбран с учётом габаритов человека в плане. Если неписи ходят по сетке, то пересекаться не должны. А если они упираются друг в друга, то это никакого отношения к габаритам не имеет, а является дефектом алгоритма навигации, когда не учитывается занятость ячейки сетки. К сожалению, иногда размера ячейки не хватает для габаритов существа в плане, например для псины в плане, отчего зад псины и может залезть в стену. Но тут уж ничего не поделать. Хотя может и можно что-то поделать, если при навигации занимать не одну, а две ячейки
  7. @DoK74rus, Есть ограничения на размеры AI сетки. Я это подробно объяснял в этом посте. За исключением этого, размер уровня ограничен только возможностями компьютера. Проблемы на Кордоне - это ты скорее всего что-то не так сделал.
  8. Ну не знаю. По мне так баги в минорных версиях (т.е. уже пофиксенные) на конечный результат не влияют. А конечный результат, что включает поддержку стандартов, качество оптимизации, скорость компиляции, улучшается с каждой версией. Скорее всего это не написанный код столько весит, а вся программа со всяким балластом типа стандартного пролога/эпилога, стандартных секций, недооптимизированных стандартных библиотек и т.п. Если же залезть внутрь и сравнить собственно размер скомпилированного кода, то разница не будет так уж велика. А по поводу балласта. Во-первых, часть балласта мож
  9. НаноБот, "Вы просто не умеете их готовить" (C) Препроцессор (а ты говоришь о макросе препроцессора) - это средство времени ДО компиляции. Он берёт твой текст и преобразует его в другой текст, который затем уже и компилируется. Препроцессор по определению не делает ничего другого. Поэтому твоё пожелание, чтобы g_alive работал во время исполнения - заведомо некорректное. Этот макрос развернётся в что-то другое до того, как код вообще будет скомпилирован и уж всяко до исполнения. Инлайн-функции же работают совсем иначе. Инлайн функции - это конструкции времени компиляции, они учит
  10. Вот здесь я не понял. А как ты хотел, чтобы макрос препроцессора выполнялся на этапе выполнения программы? В целом то, что ты делаешь, - это путь в никуда. Ассемблер существует с единственной целью - чтобы компилировалось ровно то, что написано. Это важно, это изначальная суть ассемблера - последовательность инструкций процессора. Ты смотришь на код и точно знаешь, что получишь в итоге. У тебя же идёт уход в прямо противоположную сторону - нагромождение макросов препроцессора и даже кодогенерирующих директив (типа того же .IF). Какой в этом смысл? Такими вещами гораздо
  11. Не замечал за MASM особенных багов. Максимум, что мне от него было надо - компилировать код, генерируемый IDA. С этим MASM вполне справлялся. Единственная проблема была с версией 6 из состава Masm32. Но там был не баг, а просто старая версия, которая не поддерживала новые инструкции процессора. С трудом себе могу представить, что такое надо написать, чтобы ассемблер начал глючить. Если же речь идёт о глюках в препроцессоре, то это в ассемблере вообще от лукавого. Можно подумать, у тебя проект с компиляцией в пару часов. Не напомнишь, какая вообще мотивация про
  12. Можно. Используются же в XE повсеместно. Это как? Может у тебя версия старая? Такого эффекта добиваются с использованием макропроцессора. Но в целом это путь в никуда. Ассемблер нужен для выполнения узких задач, в целом же лучше положиться на оптимизацию С/С++. Кроме того, у Микрософт-а ассемблер можно встраивать прямо в С/С++ код. Но из 64-х разрядного компилятора это убрали. Подозреваю, что именно потому, что это в широкой перспективе неправильно и неэффективно. Лучше скомпилировать отдельно модуль с нужными функциями чисто на ассемблере.
  13. Если вылет вызван скриптом, то при вылете будет показан стек Lua и соответственно сбойный скрипт. Если этого нет, то напрашивается вывод, что сбой вызван не скриптом.
  14. Строго говоря, эти условия не равнозначны. Однако, второе является избыточным, так как либо равно true (и таким образом не влияет на результат вне зависимости от значения p[2]), либо совпадает с первым, когда p[2] равно nil (поскольку в этом случае p[2] эквивалентно false), и соответственно тоже не влияет на результат. Зачем это сделано трудно предположить. Версия, что автор этого кода не знал об особенностях Lua и перестраховывался отпадает, поскольку избыточное условие стоит вторым и значит проверяется после первого и значит никак не страхует от проверки в первом условии потенциального значе
  15. Ну это вообще классика. Конструкции вида: if (<условие>) return true; else return false; Вместо простого return <условие> всегда вызывали у меня ступор. Начинаешь гадать, а не имел ли в виду автор что-то премудрое, например последующее расширение кода типа такого: if (<условие>) { // сделать что-то перед возвратом значения return true; } else return false; Но потом всегда оказывается, что это стиль такой. Немного позанудствую, но это не оператор. Это два последовательных оператора логического отрицания. И поскольку в С/С++ значения и так ав
  16. Desertir, возможно кого-то это покоробит, но лично мне глубоко безразлично, что будут думать о моём коде другие люди. Я исхожу из того, что первым человеком, который будет сопровождать мой код, буду я сам. Поэтому я себе упрощаю жизнь. Если есть смысл использовать goto, и код от этого станет лаконичнее и понятнее, то я буду использовать goto. Нет смысла - не буду. Чаще всего он и не нужен. Но если таки нужен, то все теоретики идут лесом. Я признаться не понял, ты споришь со мной или соглашаешься. Судя по этой фразе, обсуждать вообще нечего. Если проблема не в инструме
  17. =) Злостное трюкачество. Да и вообще-то речь о другом. Я только хотел сказать, что сам по себе оператор switch - это в сущности не что иное, как goto на метку case xxx: У case даже синтаксис почти как у метки - заканчивается двоеточием - и логика работы в точности как у метки для перехода, т.е. туда тупо передаётся управление и продолжается выполнение далее по ходу (если нет break конечно). Сам break - это не что иное, как goto на метку, расположенную сразу за оператором for или switch. Оператор continue - просто замаскированный goto на метку, расположенную в конце тела цикла. Оператор return
  18. Не надо преувеличивать проблему. В точно такой же ад может превратить дебаг, исправление, понимание и т.д. не использование этого оператора там, где это уместно. Как, к примеру, в вышеприведённом совете паковать вложенный цикл в функцию. В С++, кстати, полно замаскированных операторов goto: switch, break, continue, множественные return - это всё по сути операторы goto.
  19. Ты же сам и ответил на вопрос. Потому что реальное быстродействие зависит от приложения и от компилятора. К числу факторов могу ещё добавить скорость работы оперативной памяти. Память - это вообще узкое место современного компьютера, поскольку работает в несколько раз медленнее процессора. Как-то это компенсируется кешами, но есть куча приложений, где кеш не помогает, и скорость вычислений сводится к скорости чтения/записи. Собственно, это как раз и делает, среди прочего, реальную скорость вычислений так сильно зависимой от приложения, поскольку в разных задачах сильно разнится соотношение и п
  20. Malandrinus

    X-Ray extensions

    @7.9 К сожалению, это вряд ли осуществимо в виде ассемблерной правки (не считая того, что проект уже по-сути заморожен). В исходниках наверное можно сделать, но это уже другая история. Вообще же, не очень понятно, зачем вообще эта фича нужна. При текущем подходе для каждой пропорции надо всё равно делать набор конфигов руками. От этой работы никто не избавит (в рамках именно такого подхода). Получается, что движок должен только переключать наборы конфигов в зависимости от пропорций. Но это как раз совершенно спокойно можно сделать и вне движка: например в специальном ланчере.
  21. Предложенные тобой варианты избыточны в плохом смысле. Дело в том, что размер элемента массива вообще хранить не нужно, поскольку в С/С++ эта информация связана с типом и меняться не может. Размер элемента "вкомпилирован" в код, а ты предлагаешь хранить его в ячейке памяти, что существенно медленнее работает. А в стандартном векторе С++, если мне не изменяет память, хранится не указатель на конец массива, а указатель на конец зарезервированной под массив памяти. Есть там даже специальный метод reserve() для резервирования этой памяти, а сам язык при наращивании размера массива добавляет резерв
  22. Malandrinus

    X-Ray extensions

    @НаноБот, вношу поправку в предыдущий пост. bsdiff использовался не столько для удобства публики, а скорее потому, что не хотелось вносить в состав публичного проекта правленый файл dll. Ну т.е. в сущности всё равно для удобства публики, поскольку иначе пришлось бы заставлять всех учиться добавлять секцию с помощью PE Tools =) Если вышеозначенное соображение насчёт присутствия правленного коммерческого бинарника не важно, то можно просто создать этот файл с пустой секцией один раз и затем его и использовать. Просто создавать батником копию перед переносом правок, а оригинал не трогат
  23. Malandrinus

    X-Ray extensions

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

    X-Ray extensions

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

AMK-Team.ru

×
×
  • Создать...