Malandrinus

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

Конечно, как и любую другую сборку.

@RayTwitty, ок, вот применительно к письму есть понятие чистописания. В Розентале про это ничего нет, но тем не менее двойки за это в школе ставят, а учат вообще раньше, чем даже грамоте. Ну вот а правила набора имеют примерно такой же статус, но применительно к печатному тексту. На мой взгляд, подобные базовые требования что к письму, что к печатному тексту не требуют детального разъяснения, как самоочевидные.

Я не понимаю, чего ты хочешь доказать? Что пробелы можно не ставить? Я тебе пытался показать, что таки надо, поскольку мы здесь не руками пишем, а ты цепляешься за формальности. Не поможет это тебе, всё равно придётся ставить пробелы в нужном месте.

В учебниках по русскому языку ничего нет о пробелах после знаков препинания, поскольку это учебники правописания, т.е. правила для письменной речи (буквально письменной). Здесь же идёт речь о правилах набора текста, т.е. правилах создания печатного документа. То, что текст может и не быть напечатан, значения не имеет. Правила остаются применимы, поскольку текст создаётся шрифтами со всеми вытекающими. Так вот эти правила предписывали иметь пробел после запятой и не иметь его перед ней уже как минимум в 19-м веке. Эти правила можно почитать в любом справочнике корректора, пособии по работе с пишущей машинкой или попросту в правилах набора текста на компьютере. Видел информацию, что эти правила включают в подготовку к ЕГЭ по курсу информатики, так что официоз здесь вполне на уровне грамматики для письма.

Это не имеет смысла. Правки в исполняемых файлах делались под скриптовые нужды и в ряде случаев без скриптовой поддержки просто приводят к вылетам или странным эффектам. Если есть желание использовать наработки ОГСЕ, то надо использовать всё вместе: движок, скрипты, соответствующие конфиги, шейдеры.

Объясни пожалуйста, а что мешает тогда просто взять СИ и его использовать? Я не говорю про С++ с его классами, шаблонами и т.п., а только про старый добрый процедурно-ориентированный СИ. Вот застрели, а я не вижу ни малейшего преимущества в ассемблере перед обычным СИ. Тем более, что ты хочешь использовать там макросы, превращающие его в некое подобие нормального языка. Но все ограничения то останутся: с гулькин нос регистров, ограничения по набору операций, никаких типов и соответственно контроля, даже с этими макросами элементарные действия требуют жуткого геморроя по сравнению хоть с каким угодно языком и т.д. Я более скажу. Твои слова насчёт того, что дескать проще распространять и собирать - это ты на самом деле принимаешь за эффективность элементарную неразвитость средств разработки для ассемблера по сравнению со средами для языков высокого уровня. Формально говоря, этапы сборки программы для ассемблера ровно такие же, как и для СИ: компиляция, линковка. Если ты такой эстет, то ничто не мешает и на СИ разрабатывать в блокноте и пользоваться сборкой из командной строки. Будет тебе точно такая же "эффективность и простота". О боги геймостроя! Да если бы у меня пять лет назад были исходники, я бы и думать не стал ни про какой ассемблер. А сейчас проект ХЕ для меня лично актуален только постольку постольку к нему привязан ОГСЕ. Обратная совместимость - страшная штука. Так бы забыл уже как страшный сон.

@НаноБот, Да понял я тебя, и могу только повторить уже сказанное. Формат, близкий к языкам высокого уровня, но при этом со всеми ограничениями ассеблера - это ненужный уродец. Если я могу записать конструкцию eax = eax + ebx, но не могу записать что-то вроде eax = ebx + ecx, то ничего мне это не даёт, кроме как запутает. Пойми же, ассемблер - не язык высокого уровня. Его мнемоники тесно связаны с тем, как это всё устроено в памяти. Формат <мнемоника> <операнд1>, <операнд2> - это максимально соответствует бинарному формату в памяти. Кроме того, все остальные мнемоники, а их куда как больше, нежели мнемоник копирования и простых арифметических операций, имеют такую же вышеописанную структуру. Представь себе бедлам, который внесёт разнобой синтаксиса. А вот например есть мнемоника не просто копирования из регистра в регистр, а копирование из регистра меньшей разрядности в регистр большей. При этом надо решить, как заполнять старшие разряды: нулями или знаковыми битами. Для этого есть две разные инструкции копирования, а как ты предлагаешь это оформить в виде высокоуровнего кода? И есть ещё море подобных возражений. Прекрасно понимает. Я видел кучу кода, где все эти матричные операции компилировались с использованием SSE. Вообще-то для матричной/векторной алгебры вообще надо пользоваться не самопальными, а специальными библиотеками, где векторизация задействована в полной мере и оптимизирована заранее, возможно и с использованием ассемблера. =) Я думаю, что тебе стоит попытаться для начала написать на ассемблере какую-нибудь простую программу. Извини, но если подытожить сказанное, то ты просто не представляешь о чём говоришь. Одна строка C++ или другого языка высокого уровня - это в среднем десятки инструкция ассемблера. Добавь к этому на порядки большую сложность программирования на ассемблере, т.е. на написание и отладку аналогичного фрагмента на ассемблере уходит в десятки раз больше времени, чем на любом языке. 17-19 мегабайт кода С++ тогда превратятся в порядка 200-300 Мб, а время разработки сталкира в шесть лет превратится во все 60. Я не шучу.

@НаноБот, все эти идеи идут от совершенно неверного понимания сути ассемблера. Ассемблер лучше вообще не воспринимать как язык, а думать о нём как о буквальном интерфейсе к процессору. Когда я пишу mov eax, ebx, я буквально говорю разместить в памяти совершенно определённую инструкцию процессора, которая составлена из некой фиксированной части, говорящей, что это MOV и части, отвечающей за аргументы, в данном случае eax и ebx. Когда же ты начинаешь писать вещи типа eax = eax + ebx, то ты сразу уходишь от вот такого непосредственного указания. Конкретно eax = eax + ebx конечно можно транслировать в одну инструкцию, а вот уже eax = ebx + ecx - уже нельзя, и теряется весь смысл затеи. А потом я захочу написать eax = ebx + ecx + edx и начну возмущаться, что это в таком "высокоуровневом ассемблере" почему-то невозможно. Тогда уже возьми компилятор любого языка высокого уровня и не парься с ассемблером. Вообще говоря, ассемблер сейчас мало актуален для разработки обычных программ. Тривиальные вычисления компиляторы оптимизируют лучше, чем это сделает на ассемблере вручную средний программист, поэтому ассемблер нужен в основном для сугубо системных вещей, доступа к каким-то аппаратным ресурсам и т.п.

@redpython, тогда вообще нет смысла заморачиваться и рисовать разные худы прицелов. Всё равно они все будут выглядеть одинаково - как расплывчатое пятно. Я правильно тебя понимаю? В сущности, у пыс именно так и сделано: совершенно одинаковые рамки, вокруг всё чёрное, а отличаются только сетки. А как насчёт того, что и при просто прицеливании из любого оружия сам ствол в фокусе не увидеть? До посещения тира я это как-то умозрительно представлял, но только постреляв из всамделишнего пистолета понял, насколько неудобно из него целиться. Прицельные приспособления элементарно не видно одновременно с мишенью, и надо целиться, как-то примерно выравнивая в одну линию три расплывчатых холмика, в которые превращаются мушка и целик. Так и что, сделать так же в игре? Нас тогда игроки тапками закидают и будут правы.

Я такой эксперимент проводил давно и не раз. И что? Рука превращается в размазанное нечто. И вот я тебе задаю конкретный вопрос, ты так и предлагаешь рисовать прицелы в игре, в виде размазанного нечто?

Так и как же в итоге предлагаешь рисовать прицелы? Одним размазанным пятном?

Здесь я могу возразить, что смотря в прицел ты смотришь не на прицел, а на мишень, т.е. весьма удалённый объект. Поэтому, следуя такой логике, ни один элемент собственно прицела ты резким не увидишь, и надо его весь рисовать расплывчатым. Но тогда это будет уже странно и невыразительно с точки зрения игрового процесса.

Сдаётся мне, что если и поймёшь, как это исправить, то вряд ли сможешь это перенести в виде патча. Рациональней будет уже забить на XE и мутить дальше из исходников. Я мало про них знаю. Ну вот открываю вики, читаю слова: "разработанная для эффективной работы с очень большими репозиториями кода" "является распределённой (децентрализованной) системой контроля версий" "поддерживает полностью децентрализованную работу, ветвление" Это всё замечательно, но конкретно этот проект - полная противоположность этих требований. XE - проект на самом деле очень маленький (особенно если рассматривать каждый подпроект по отдельности). Количество разработчиков - также очень небольшое. Ветвление - может где-то и полезно, но конкретно в этом проекте, IMHO, фича вредная. Сам проект XE вертится вокруг предельно конкретных DLL, правки обычно сугубо локальные и никак не могут, точнее не должны, вести к созданию изолированных сборок. Более того, форки в контексте нашего проекта вообще противоречат его изначальной задумке аккумулировать все правки. Вот конфигурирование проекта - дело полезное, но ветки для этого не нужны. Поэтому нам больше подходит система контроля версий централизованная и желательно как можно более простая, типа SVN. ЗЫ: Я всё же хочу уточнить на всякий случай, что "git - отстой" я имел в виду только в том смысле, что "для этого проекта - отстой". Так-то наверное замечательная система.

Твоя правда, я и не подумал об этом. Там же метаметод "call", а не просто выбор по ключу. Внутри по списку аргументов можно выбрать и нужную функцию.

Фильтрация и подсветка зависит от положения предметов внутри инвентаря, а оно может измениться и после открытия. Поэтому делается глобальная обработка при открытии трупа/тайника и начале диалога, и также на каждый акт перемещения между частями инвентаря. Всё это в сущности разовые операции, да и сами операции - просто установки флажков, поэтому нет ничего криминального, если это случится два раза. Здесь ситуация такая, что я сам понятия не имею, что реально делает эта правка. Помнится, долго ломал голову, как починить солнце, искал концы, наткнулся на странный фрагмент, который выглядел как некая заплатка. Методом научного тыка этот фрагмент вырезал, и вдруг солнце починилось. Насчёт косяков вполне допускаю. В ОГСЕ они, вроде как, не критичны, поскольку там погода в каждый момент контролируется скриптом. Технически установлена одна погода навсегда с одним единственным кадром, который динамически перемещается во времени, и динамически же устанавливаются его параметры интерполяции. Поэтому, даже если описанные косяки и присутствуют, то они вроде как не влияют, поскольку от движка остаётся только интерполяция погоды на текущем кадре, а остальное побоку. Что он там сохраняет/загружает всё равно будет переписано скриптом. Короче, эту правку как раз надо убирать из "не ОГСЕ" конфигураций. Эта функция идёт как затычка к механизму прокрутки времени, который в ОГСЕ используется для сна. Я обнаружил, что после прокрутки времени происходят косяки с пересчётом состояний актора. Подробностей уже не помню, но лечилось это разовым игнорированием соответствующего обновления сразу после приращения времени. Для установки этого разового игнора и предназначена эта функция. Вполне допускаю, хотя уже и не помню точно, что вместе с актором пропускается обновление чего-то ещё. В любом случае, это не используется нигде больше, кроме как в реализации сна.

А разве в Lua есть перегрузка функций? По моему вызов функции, как и обращение к чему угодно другому по имени, - это просто выбор из таблицы по ключу, а значит и функция будет вызвана одна и та же, просто с разным списком аргументов. Или я не понял мысли?

@RayTwitty, ага, нашёл косяк. Спасибо за наводку. Хоть логика фильтрации и раскраски и отключена, но цвет подсветки по умолчанию всё равно берётся из первого элемента пользовательского массива цветов, а массив инитился из скрипта, т.е. там были нули (и соответственно полностью прозрачный цвет). Поэтому "покрасневшие" предметы были невидимы. Сейчас я там заполнил первый элемент, так что покрасневшие предметы не пропадают. Так и я про скрипт. Заметны какие-то косяки?

Сдаётся мне, что ты это проверял очень давно. Там есть глобальные флажки, которые, если не включены, сводят код к его движковой версии. По умолчанию флажки все отключены, и без скрипта включить их некому. И кстати. А как бы сделал ты? Хм. Да там половину незакомменченных правок можно отнести ко второй категории, да и по части "нужности" - это дело индивидуальное. Мне однако вообще непонятно ранжирование правок. Проект для всего. Что хотим, то и добавляем. Главное - друг другу не мешать.

Да, это кто-то закомментил правки на этот счёт, поэтому скриптовые действия, которые только ставят флажки с помощью хаков общего назначения, не работали. Я правки раскомментил, внёс в конфигурацию OGSE. Сейчас должно работать. У меня по крайней мере работает. Вот кстати зачем вообще было кому-то комментить эти правки? Я спецом сделал так, что без скриптовых манипуляций они никому не мешают, и всё ведёт себя по дефолту. В отличие от врезок, по большей части лишний ассемблерный код в дополнительной секции никому не мешает. Я бы и вовсе не заморачивался на его конфигурирование без крайней нужды. Ещё, создал там же батник для ассемблирования под конфигурацию ogse. Компилировать надо именно им, иначе немало всякого не попадёт в сборку. Я этого не знаю. Сомневаюсь, что что-то изменилось.

Я как-то пропустил тот факт, что в ассемблере уже сделаны определённые попытки конфигурирования. Это хорошо, что сделаны, но есть замечания, которые излагаю ниже. Разный синтаксис дефайнов, так что наверное затруднительно. Да и ни к чему это, как мне кажется. Список отключаемых элементов в списке патчей и в файлах ассемблера совершенно никак не связаны, поэтому лучше сделать выбор глобальной конфигурации путём выбора исполняемого файла для сборки, а там уже по отдельности включать конфигурации ассемблера и патчера. В ассемблере, к слову сказать, я бы сделал примерно по такой же схеме, как и в патчере. Т.е. делать условные блоки конкретных фрагментов не на основе принадлежности к моду, а конкретно для каждой фишки. А уже набор для мода формировать в некоем файле конфигурации по более глобальному условию выбора конфигурации. Поскольку как сейчас выходит, что какая-то фишка включается только в составе общего пакета фишек для мода, а если кому-то нужно включить её по отдельности, то опять надо лезть в основной код, чего хотелось бы избежать. Вот ещё к этому вопросу. В ассемблере ml.exe, как и в препроцессоре gpp, можно в аргументах командной строки определять символы препроцессора. Как-то так /DOGSE_BUILD. Так что выбор конфигурации тоже можно делать, не меняя код. Согласен, уродливо получилось, руки дойдут - поправлю. Вообще-то здесь "длинных_мнемоничных_имён" не напасёшься. Более продуктивно будет комментировать опции в файле конфигурации. Ну, тогда уж надо выносить в отдельную папку все файлы, связанные с билдом: список патчей, заготовку под dll и diff-файл, все батники и прочее. Лично у меня уже батник для сборки не найти, поскольку список исходников сильно длиннее окна TC. Так а что мешает подключить и посмотреть на эффект?

Прошу обратить внимание! Я добавил в проект xrGame для ТЧ (это который в папке master/3312_shoc_10006) систему конфигурирования патча. В двух словах: В папке tools добавлен инструмент GPP.exe и описание к нему. Это текстовых препроцессор общего назначения, в целом напоминающий препроцессор от С/С++. Ежели кому интересно, подробнее здесь. Созданы две конфигурации: general и OGSE. Батник патчера patch.cmd соответственно изменён и добавлен второй patch_ogse.cmd. Также добавлены два файла с опциями каждой из конфигураций: config_general.txt и config_ogse.txt. Файл corrections_list.txt тоже изменён. Ряд патчей в нём обнесены условной конструкцией #ifdef <СИМВОЛ> ... #endif. Соответственно, <СИМВОЛ> должен быть определён как #define <СИМВОЛ> в соответствующем файле конфигурации (config_general.txt или config_ogse.txt). Смысл всего этого в том, чтобы менять конфигурации патча без изменений кода. Предлагается те патчи, что не нужны конкретно вам, оформлять так, как описано выше в виде условной конструкции и включать/выключать его в своём файле конфигурации. К слову сказать. Было бы неплохо, чтобы разработчики и не свои фрагменты ассемблера тоже не комментировали, при необходимости их удалить из своей сборки (и так и коммитили), а оформляли в виде условного блока. В ассемблере для этого уже есть свой препроцессор. Это вообще правильный стиль при совместной разработке. Соответственно, аналогичные конфигурации можно было бы сделать и для стадии компиляции, а не только патча. PS: Надо было это сделать сто лет назад. PS2: git - отстой, сильно переусложнён и избыточен для целей этого проекта. Ещё хочу уточнить несколько моментов по процессу сборки и заодно напомнить тем, кому интересно, как это всё работает: Для сборки я в своей практике использую файлы make_src_dll.cmd, patch*.cmd, clean.cmd которые находятся в папке проекта. clean.cmd - это необязательный файл, который просто чистит временные файлы. Можете его игнорировать. Процесс сборки я обычно делаю в два этапа: сперва make_src_dll.cmd, затем patch*.cmd. make_src_dll.cmd - выполняет сборку dll-заготовки с патчами и секцией нашего кода. Он сперва вызывает ml.exe и компилирует файл mydll.asm, который на самом деле включает в себя инклюдами все остальные файлы. Затем собирает dll линковшиком link.exe. Поскольку все ошибки обычно возникают на этом этапе, то я специально поставил в конце этого батника pause, чтобы видеть ошибки компиляции, если таковые случаются. patch*.cmd выполняет несколько действий: В версии с конфигурацией (на данный момент только xrGame для ТЧ) первым действием является вызов tools\gpp.exe, который на основе нужной конфигурации сгенерирует из corrections_list.txt временный файл corrections_list_tmp.txt, т.е. урезанный список патчей. В остальных проектах файл corrections_list.txt используется без изменений Далее вызывается tools\bspatch.exe, который из файла xrGame_orig.dll и xrGame.diff, собирает файл xrGame.dll, который представляет собой чистую dll из игры с добавленной секцией для нашего кода. Вообще говоря, с технической точки зрения этот шаг не является обязательным. Вы у себя можете собрать эту dll раз и навсегда и вырезать этот фрагмент из батников. Сделано это было для того, чтобы не включать в проект проприетарные файлы (по этой же причине не включены ассемблер и линковщик). Наконец, собственно вызывается патчер tools\patcher.exe, который переносит патчи из dll с патчами в целевую с добавленной секцией в соответствии со списком патчей из файла corrections_list.txt (или временного corrections_list_tmp.txt) Ряд замечаний: 1. Если вы понимаете происходящее, то ничто не мешает настроить процесс сборки по-своему, например за один клик без пауз, пересоздания чистой dll и т.д. 2. Касательно версий исполняемых файлов, не включённых в проект. Чистая DLL, которая должна лежать в проекте xrgame ТЧ под именем xrGame_orig.dll - это файл от американской версии игры. Имеет размер 6246400 байт. Ассемблер (ml.exe) нужен версии не ниже 10-й. Берём его из Visual Studio. Линкер (link.exe), к моему удивлению, оказался нужен именно старый от MASM32 (версия 5). Я как-то не заморачивался на его замену, но недавно поэкспериментировал и с удивлением выяснил, что более новые версии вызывают смещение секций, которые не учитывает наш патчер. В итоге ничего не работает.

Не совсем так. Если поставить jump_speed в 0, то прыгать всё-таки не будет, т.е. позволяет решить проблему обездвиживания. С другой стороны действительно факт, что любое значение, отличное от нуля, в итоге приводит к тому, что скорость прыжка просто остаётся постоянной из конфига. Если глянуть исходники, то там скорость прыжка при загрузке копируется куда-то в менеджер физики актора и видимо там уже используется. Поэтому и эффекта от перезаписи нет. При этом и то первое поле в самом объекте актора тоже в одном месте читается и используется, видимо поэтому нулевое значение всё-таки влияет. Короче, разработчики пыс тут в своём репертуаре, запутали и накосячили. Не будет, я проверил. Эффект покачиваения (боббинг) походу начинается с какого-то порога скорости.

Опять же, я из оружия не стрелял, но взял бинокль и провёл простой эксперимент. Смотрю правым глазом в бинокль (т.е. как в подзорную трубу) и пытаюсь рассмотреть что-то вдалеке и при этом пытаюсь понять, что происходит вокруг слева или справа. Мои выводы: Если зажмуриться, то изображение слева практически не воспринимается, поскольку закрыто переносицей. Изображение справа в лучшем случае воспринимается на предмет детекции "какого-то движения". Ни форма ни даже положение объектов не воспринимаются. Если оставлять правый глаз открытым, то изображение справа воспринимается несколько лучше, но опять же в основном на уровне "что-то вроде движется". Картинка размытая, да и внимание в основном на изображении в окуляре. При этом, практически перестаёшь воспринимать изображение справа, а рассмотреть то, что в окуляре становится намного сложнее из-за визуальных помех (наложение противоречивых картинок из левого и правого глаза). Сдаётся мне, что снайперы не зря парами ходят. По мотивам своих доморощенных экспериментов могу сказать, что изображение на экране монитора с "открытой" прицельной сеткой не соответствуют реальному восприятию человеком. Полностью зачернённая картинка вокруг окуляра, хоть и тоже не на сто процентов реалистична, но тем не менее лучше соответствует реальной ситуации. ЗЫ: я однако не агитирую за "закрытые" прицелы, поскольку удобство и комфорт игрока считаю более важным, чем вопросы реалистичности. Откровенно говоря, по мне так весь вопрос не стоит и выеденного яйца. Как сделаете, так и будет хорошо.

Я не стрелял из винтовок и тем более с оптикой, но бинокль у меня есть. Провёл эксперимент и могу подтвердить сказанное в ролике: когда смотришь в окуляр, то всё, что вокруг, на самом деле не видно. Или точнее не то чтобы совсем не видно, а скорее просто не воспринимается мозгом. Ну понятно, боковое зрение и так сильно ограничено, а если картинка там размыта, да ещё и зрачок искусственно фиксируется на узком поле зрения, то для мозга просто нет информации. Так что таки да, сетка с открытой периферией - это ненатурально, и затемнение вокруг окуляра более реалистично. Хотя в игре, надо признать, удобнее открытый =) Что же касается часиков, которые там вылазят, то это как раз поправимо. Часы под картой - это очень старый мод. Сделаны коряво, с постоянным пересозданием статика, на котором отображаются. Потому и вылазят при том, что остальные элементы вполне успешно скрываются.