Курилка программистов

[Malandrinus 624]

 

 

Как делается грязь в Спин Тирес?

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

[Malandrinus 624]

 

 

такие фичи

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

[Malandrinus 624]

 

 

а ты обратил внимание на скос травы и по моему там еще будет смена грунта при вспашке.

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

 

 

заточка под многопоточность

Нет в сталкире никакой многопоточности для физики.

 

 

 

Большие проекты на виджитах тяжело делать

Почему? Да и является ли это большим проектом с точки зрения окошек? И на виджетах есть несколько примеров весьма массивных с точки зрения окошек систем.

 

 

 

https://github.com/SonyWWS/SLED+еще BabeLua(Visual studio[editor+debugger]),Notepad++(Editor only)

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

 

 

 

необходимо создавать отдельный lua_state в каждом потоке.

Тогда возникает проблема коммуникации между потоками. Отдельные стейты будут полностью изолированы друг от друга, соответственно нельзя будет обмениваться данными между скриптами. О динамическом планировании мнопоточности можно сразу забыть, что резко снижает потенциал распараллеливания.

[Malandrinus 624]

 

 

тот же транспорт, хотя и в ТЧ он весьма почикан, но в сиквеле прямо евнух

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

 

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

[Malandrinus 624]

@Дизель,

твои слова фактически подтверждают то, что я сказал. Бинарными правками нельзя вернуть в движок функциональность такой сложности. Если Колмогору это удалось, значит код посадки в машинки там был.

 

И вообще мы же обсуждаем не бинарные сборки, а движок в исходниках. В исходниках всё осталось, и в этом нетрудно убедиться самому. Просто сравни файлы машин в ТЧ и ЗП. 

[Malandrinus 624]

 

 

аттача ГГ не было

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

[Malandrinus 624]

@Дизель,

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

[Malandrinus 624]

@Dennis_Chikin,

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

[Malandrinus 624]

 

 

Это для понимающих

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

[Malandrinus 624]

@Kondr48,

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

[Malandrinus 624]

Указатель на массив. Указатель на последний элемент массива. Указатель на конец массива.

...

Указатель на массив. Размер объекта. Количество объектов.

...

Указатель на массив. Указатель на последний элемент массива. Количество объектов.

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

Изменено 12 Мая 2017 пользователем BFG

[Malandrinus 624]

On 9/25/2017 at 5:49 AM, НаноБот said:

Почему производители процессоров существенно завышают реальное быстродействия.

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

[Malandrinus 624]

18 hours ago, Desertir said:

даже один этот оператор может превратить поддержку (дебаг, исправление или просто понимание логики работы кода) в кромешный ад

 

Не надо преувеличивать проблему. В точно такой же ад может превратить дебаг, исправление, понимание и т.д. не использование этого оператора там, где это уместно. Как, к примеру, в вышеприведённом совете паковать вложенный цикл в функцию.

 

В С++, кстати, полно замаскированных операторов goto: switch, break, continue, множественные return - это всё по сути операторы goto.

[Malandrinus 624]

7 hours ago, abramcumner said:

И ни одного гото. 

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

[Malandrinus 624]

Desertir,

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

 

5 hours ago, Desertir said:

Проблемы же не в компьютере, а в субъекте по ту сторону клавиатуры

 

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

[Malandrinus 624]

On 11/22/2017 at 3:54 PM, НаноБот said:

if bit_and(m_flags, cfExploding)~=0 then return true else return false

 

Ну это вообще классика. Конструкции вида:

if (<условие>)
	return true;
else
	return false;

Вместо простого return <условие> всегда вызывали у меня ступор. Начинаешь гадать, а не имел ли в виду автор что-то премудрое, например последующее расширение кода типа такого:

if (<условие>) {
  	// сделать что-то перед возвратом значения
	return true;
}
else
	return false;

Но потом всегда оказывается, что это стиль такой.

 

On 11/22/2017 at 3:54 PM, НаноБот said:

в С++ есть оператор !! преобразовать в булеву

Немного позанудствую, но это не оператор. Это два последовательных оператора логического отрицания. И поскольку в С/С++ значения и так автоматом интерпретируются как логические, то в использовании этой конструкции чаще всего нет нужды.

 

19 hours ago, НаноБот said:

памятник быдлокоду

О, да! Особенно использование неинициализированной переменной x1. Понятно, что это Паскаль, и там есть значения по умолчанию, но всё же это подрастрельная статья.

 

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

Это помимо уже упоминавшегося выхода из вложенных циклов.

Ещё весьма важный случай - для нужд отладки и эксперимента. Хоть это и не должно попасть в готовую программу, но наличие такого инструмента может сильно упростить процесс разработки.

Ещё вспомнил случай из своей практики. Был у меня код вида такого:

lab1:
// фрагмент сложного цикла 1
lab2:
// фрагмент сложного цикла 2
if () goto lab1;
// фрагмент сложного цикла 3
if () goto lab2;

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

[Malandrinus 624]

On 3/27/2018 at 6:39 PM, НаноБот said:

нельзя использовать xmm регистры

Можно. Используются же в XE повсеместно.

 

On 3/27/2018 at 6:39 PM, НаноБот said:

не правильно работают макрофункции

Это как? Может у тебя версия старая?

 

On 3/27/2018 at 6:39 PM, НаноБот said:

МАСМ на С/С++ больше был похож

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

[Malandrinus 624]

On 5/21/2018 at 7:43 PM, НаноБот said:

МАСМ глючный, забагованный

 

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

 

On 5/21/2018 at 7:43 PM, НаноБот said:

UASM быстрей компилирует, гораздо быстрей, проект XRayExt для ТЧ всего за 0.6 сек,

 

Можно подумать, у тебя проект с компиляцией в пару часов.

 

Не напомнишь, какая вообще мотивация продолжать использовать ассемблер?

[Malandrinus 624]

10 hours ago, НаноБот said:

сначала идёт макрос g_alive. а затем проверка esi.

Вот здесь я не понял. А как ты хотел, чтобы макрос препроцессора выполнялся на этапе выполнения программы?

 

В целом то, что ты делаешь, - это путь в никуда. Ассемблер существует с единственной целью - чтобы компилировалось ровно то, что написано. Это важно, это изначальная суть ассемблера - последовательность инструкций процессора. Ты смотришь на код и точно знаешь, что получишь в итоге.

 

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

 

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

 

10 hours ago, НаноБот said:

Чем нам это грозит?

В ближайшей перспективе ничем. Вроде пока ничего не собираются менять. А даже если и закроют - полно других свободных хостингов.

[Malandrinus 624]

НаноБот,

Quote

Мне не нравится С++, особенно С++11 и более новые редакции, =)

"Вы просто не умеете их готовить" (C)

Quote

g_alive это имитация инлайн метода С+

Препроцессор (а ты говоришь о макросе препроцессора) - это средство времени ДО компиляции. Он берёт твой текст и преобразует его в другой текст, который затем уже и компилируется. Препроцессор по определению не делает ничего другого. Поэтому твоё пожелание, чтобы g_alive работал во время исполнения - заведомо некорректное. Этот макрос развернётся в что-то другое до того, как код вообще будет скомпилирован и уж всяко до исполнения. Инлайн-функции же работают совсем иначе. Инлайн функции - это конструкции времени компиляции, они учитывают контекст (своё окружение) а также все правила вызова функций.

 

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

 

Quote

всякий хлам вроде std

 

Quote

на асме такой же код, весил бы 2-3 кб максимум. И создать его бы не было проблемы. Почти столько же по времени.

Я бы посмотрел, как ты написал бы на ассемблере парсер формул в 40 строк за пару часов (хотя наверняка этот код занял даже меньше).

 

Dennis_Chikin,

Quote

Ну, это явно кто-то извращался. Именно с целью добиться максимальной нечитаемости

 

Да нормальный код же! Ничего нечитаемого. И насчёт С++11 там ничего такого запредельного нет. Вполне можно было бы обойтись обычными указателями на функции, но и всё. К собственно читаемости алгоритма это никакого отношения не имеет.
 

Quote

А вот оптимизация -  чтобы ее сделать для современного процессора, нам просто ни кто не скажет, как

 

Есть полная официальная документация на каждый процессор, в том числе и насчёт оптимизации. Другое дело, что это весьма пухлый документ для профильных специалистов, собственно создателей компиляторов и библиотек низкого уровня. Их же для того и пишут, чтобы каждому прикладнику не нужно было вникать во все эти детали. Для вас стараются, а вы нос воротите =)

 

Ну и не надо забывать про разные платформы. Код на ассемблере будет работать на конкретной платформе. Код на языке высокого уровня будет работать везде, где есть соответствующий компилятор/интерпретатор.

 

Quote

синтаксис обычного, не приплющенного c студия уже не позволяет ?

Всё позволяет. Вообще, Мелкософт много в чём можно упрекнуть, но их С/С++ компиляторы - одни из лучших и с каждой версией становятся только лучше.