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

Malandrinus

 Глобальные модераторы
  • Число публикаций

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

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

10 подписчиков

О Malandrinus

Недавние посетители профиля

2 889 просмотров профиля
  1. Курилка программистов

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

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

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

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

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

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

    @Kondr48, Там есть ссылка на хорошее разъяснение сути. Там правда на английском. Полностью согласен с @abramcumner. Всякие тонкости, которые там обсуждаются, совершенно не важны для проектов на основе x-ray по той простой причине, что они по сути своей нелегальны. Так что беспокоиться не о чем - удалить могут так и так в любой момент.
  8. Курилка программистов

    Ну вот, можно было бы развести сочный пафосный холивар на тему "как единственно верно инициализировать глобальные таблицы". Но это, выходит, только "для посвящённых". Скучно.
  9. Курилка программистов

    @Dennis_Chikin, прошу прощения, но я либо что-то пропустил, либо совсем в танке. Ничего не понял, о каких именно файлах с таблицами речь?
  10. Курилка программистов

    @Дизель, так а какая мораль? Выходит, x-ray не так уж плох, если тянул это без проблем да ещё и на весьма древнем железе.
  11. Курилка программистов

    Эта функция сама аттач не выполняет, а только вызывает метод attach_Actor у холдера. Это именно то, о чём я и говорил. Без наличия основного функционала ничего бы вернуть не удалось. Опять же с точки зрения исходников (а бинарные правки я вообще не вижу смысла обсуждать) и вовсе ничего не вырезано, поскольку разрабы даже не потрудились удалить фрагмент кода. Вернуть обратно - стереть четыре символа.
  12. X-Ray extensions

    @dsh, разные авторы правок. Колбек 153 был добавлен позднее. Возможно, его автор не вполне был в курсе всех возможностях колбека 152. С документацией в этом проекте всегда было туго. На мой взгляд колбек 152 покрывает большую часть возможных нужд, поскольку даёт доступ к полной структуре хита, включая адресата, типы пули и пр. Достаточно подробный пример использования можно найти в огсе.
  13. X-Ray extensions

    @dsh, цитирую из лога Там есть ещё колбек 152 на событие "прехит", с помощью которого можно сделать всё тоже самое. В частности, в огсе через 152 сделаны иммунитеты актору и игнор дружественного огня неписями.
  14. Курилка программистов

    @Дизель, твои слова фактически подтверждают то, что я сказал. Бинарными правками нельзя вернуть в движок функциональность такой сложности. Если Колмогору это удалось, значит код посадки в машинки там был. И вообще мы же обсуждаем не бинарные сборки, а движок в исходниках. В исходниках всё осталось, и в этом нетрудно убедиться самому. Просто сравни файлы машин в ТЧ и ЗП.
  15. Курилка программистов

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