Попал в геймдев, хотя думал быть веб-прогером. Поэтому есть вопрос по алгоритмам.
Часто приходится иметь дело с вещами типа триггеров - каждый апдейт спрашивать, а есть ли кто рядом, или наступил ли определённый момент времени (и если наступил, то не обрабатывал ли я наступление этого момента времени раньше), т.е. конструкции типа:

очень распространены в проекте.
И все эти балалайки крутятся и апдейтятся каждый кадр с самого старта игры в количестве сотен (некоторые я прибиваю, после того как стали не нужны, но с большинством не очевидно, что может произойти, поэтому нет)
(да, пишу на C# под Юнити)
При том, что игры специфические - под очень мощное железо (7D-стереоаттракционы), то позволить быдло-кодинг я технически могу, а душа болит и хочет красоты и оптимальности и оптимизаций.

Забавно, столько просмотров и даже ни намёка на более оптимальный вариант проверки произвольного условия, чем ежекадровый if. Оверы, ау !

Забавно то, что в теме нет ни одного вопроса. Автор, чего вы хотите то?

Гы! Тут прям ща столько специалистов в 3д, что 'ни продыхнуть'.
Место ты выбрал неудачное. Пошто не пошел, хотя-бы, на gamedev.ru ?

По subj - не хочешь использовать условные события, значит делай 'живыми' сами события. Т.е. выполняй их всегда, а не по условиям (что выродится в 'оглядывание и "wait" ').
Недостаток - затраты процессорного времени гораздо больше. Достоинство - динамичнее система.
(на правах бреда)

Хм. Странное решение обрабатывать триггеры каждый кадр. Ну лучше ли для них иметь отдельный таймер?
Я не знаю как у вас это реализовано. У меня лично (хотя это препреальфа вариант) есть "список" неактивных триггеров. Они через каждый промежуток времени проверяются. Как только триггер стартовал, он из этого "списка" переходит в список активных триггеров
К тому же я не думаю, что у вас именно это большой % ресурсов съедает (хотя вам виднее, тем более вы легко можете это проверить).
И вообще C# - странный выбор для таких задач.
Действительно на Gamedev больше вероятность что просветят

AzaZeo, вам там кадры случаем не нужны?

кстати, да, а почему бы не проверять триггеры с прореживанием по кадрам или даже по времени с учетом приоритета (например, одни - каждый кадр, другие - раз в 50-100 мс, третьи - раз в 200 мс)?

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


Это вопрос действительно по алгоритмам. По конкретным алгоритмам. Каждый случай надо рассматривать отдельно. В некоторых случаях сделать ничего нельзя, в других - можно очень сильно оптимизировать. Здесь, на мой взгляд, нужно начинать рассматривать проект на очень высокой стадии абстракции и искать - нет ли там чего то, что можно сделать по другому, более оптимально. Вполне возможно, что изменения для оптимизации здесь надо будет вносить на уровнях более высоких, чем те, которые находятся в компетенции программистов.

Единственное что хочу заметить - эти кусочки напоминают процедурный код с использованием объектов/методов как переменных/функций (наверно ошибаюсь, но все же). Если таких кусков в одном месте текста слишком много - наверняка процедурный стиль. Лечится просто - твой код должен посмотреть опытный ООП-программер и сказать, что он думает, относительно соответствия ООП-стилю. Нет опытного - сойдет и малоопытный.

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

Если у проекта есть программирующий архитектор/ведущий программист - нужно писать в его стиле, насколько плох или хорош бы он ни был, игнорируя все остальные методики, повторяя любые мелочи. В таком случае время на проверку будет минимальным - проект быстрей попадет в продакшн.
У меня есть такая вот личная особенность, например. Я не могу читать код, если открывающая фигурная скобка не стоит на отдельной строке. Если я беру чужой код, то мне приходится сначала его форматировать по своему стилю и только потом разбираться с содержимым. Иначе начинаю тупить.


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

Это главный принцип разработки коммерческого ПО ещё с 80-ых годов.

Если ты потратишь пол года на оптимизацию, то программа будет работать быстрее. Если же ты потратишь пол года на отдых, то программа тоже будет работать быстрее, потому что к тому времени компы уже уйдут вперёд, упадут в цене, куча народу уже сделает апгрейд, и твоё требование "60 фпс в 1920х1080 на 6600GT" к тому времени уже можно будет менять на "60 фпс в 1920х1080 на 6800"

Вспомни как MS винду делала... Сначала сделали тормознутый GUI а потом просто ждали когда появятся более быстрые компьютеры...

Vladson, ну коммерческий смысл можно найти, конечно. С другой стороны абсолютное большинство проектов имеют чёткие требования к производительности: допустим, программа должна позволять с комфортом работать с ней будучи запущенной на Pentium IV с 256 МБ оперативы. Что значит комфортно? Понятно, что всё должно работать как можно быстрее - чем быстрее, тем лучше. Тут уже приходится тратить очень много времени на оптимизацию - кстати к слову, оптимизация - это отнюдь не рутинная задача, а творческая; обычно это гораздо интереснее, чем добавлять в программу функционал. И вообще среди программистов не зря существуют стереотипы, что сильный программист пишет куда как более быстрый и экономичный код, чем джуниор

Если вспомнить тот же DOOM 3, то для его оптимизации приглашали именитых специалистов в области оптимизации для х86

Оптимизация нужна всегда, просто по ходу оптимизации встаёт вопрос о разумности дальнейшей оптимизации. Например, я увеличил скорость в 900 раз - изображение 640х480 в среднем обрабатывается 50 миллесекунд, хорошо. Но фотография с 8-мп камеры обрабатывается более 3-х секунд, плохо. Что делать, дальше оптимизировать? Для этого у меня есть 3 варианта: 1) Работать напрямую с памятью. Чёрт, я не знаю как в C# работать с памятью не переключаясь в unsafe 2) Писать библиотеку на С++, которая бы обрабатывала изображение 3) Писать библиотеку на ассемблере, которая бы ←... А с другой стороны, может и ну его? Мне это делать неинтересно, да и кому придёт в голову обрабатывать такие гигантские картинки

С 3д-движком всё же дело иначе обстоит, особенно что касается тех частей программы, что выполняются циклически на протяжении очень долгого времени - а там в 3д-движках очень много такого кода. Вот тут уже не должен стоять вопрос "а может ну его?"

и да, 6600 GT временно - пока не найду на барахолке за смешные деньги затычку с потоковой архитектурой типа 2400Pro/8400GS

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

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

Ну это если выбор между именно ворд и байт - такое редко бывает, а в подавляющем-то большинстве случаев стоит использовать дворд, даже если переменная не принимает значение больше, скажем, 10.

Что касается цитаты - мнение одного программиста всё же не может отражать реального положения дел. Тем более что у Excel и Word (не говоря уже о Internet Explorer), репутация тормозного и глючного **вна. Тормозная Виста (хотя 7 недалеко ушёл), вообще получилась феилом, несмотря даже на то, какими отвратительными способами M$ завлекли на неё юзеров

Что касается игр - да, на ПК ситуация в целом печальна - выходят всякие ГТА 4, которые не только ужасно оптимизированы, но ещё и имеют серьёзные утечки памяти. Зато на консолях разработчики ещё как убиваются чтобы заставить игры быстро работать на консольном хламе.

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

Добавлено спустя 29 минут 52 секунды:
P.S. Вот вам обратный словам мелко$офтовского быдло-кодера пример:

Это не его мнение, это революция рынка в те времена.


Этот "быдлокодер" признанный во всём мире гуру. Причём как в области кодинга, так и позднее (когда ушёл из MS и открыл свою компанию) в области управления проектами. Много споров идёт о нём, кто-то считает его быдлокодером, кто-то гением, но факт остаётся фактом, о нём говорят, а он рассказывает вещи под которыми подписался бы сам капитан очевидность. Он говорит о простых и очевидных вещах, но о которых почему-то другие молчат.


Правильной реализации не значит оптимизации. У них был план они его выполняли. Они встретились с трудностью и её преодолели. Ни какой оптимизации в этом нет.

Добавлено спустя 2 минуты 37 секунд:

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

Почему нету оптимизации? Если одно из условий - скорость, это уже подразумевает что требуется оптимизация. А условия такого могло и не быть - как у создателей Internet Explorer "Ну, если ничего не трогать, вроде даже работает. Вроде даже быстрее, чем если бы всё зависло"

Добавлено спустя 4 минуты 26 секунд:

Ну это и неудивительно, если посмотреть сколько всяких технологий в современных игр. Их же все невозможно глубоко знать - сликшом всего много. Те же шейдеры, это такое ватафак мазафака - по сути отдельный язык программирования на основе С (если речь о HLSL, без него это вообще по сути ассемблер), а компилятора нормального для этого дела не существует. Это объективная причина почему код становится менее эффективным. Необъективная - вот такой быдло-подход, как в цитате выше

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

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

Может че не так скажу, но в "С" не так рублю, я просто делал, когда писал на Вижеле делал просто основной код и типа скрипта в подставу на все остальное где похожее выполняется чтоль, я там как то измудрялся не помню точно, было лет 5 назад, все супер летало, даж 1,5 рублей получил за эту хрень...

Наверное обычно так, а вообще это от круга задач программы зависит. Я вам мог бы привести из моего движка примеры, когда я переделывал совершенно правильные части кода, когда видел что в будущем эта часть будет всё сильнее и сильнее рубить производительность. И мне придётся экономить на чём-то другом. Если бы я не требовал от себя скорость - я мог бы сказать что тут всё правильно - даже придраться не к чему. Всё по науке
И если речь о графике вообще( 2д, 3д ), в подавляющем большинстве случаев правильный алгоритм, но неоптимизированный, будет работать с неприемлимой скоростью

Наука не канает, все на собственных мышцах!!!
Скорость зависит от чтения и обработки кодов которые ты задаешь, правильно???
Идем дальше, если у тебя есть несколько блоков которые повторяются пишешь один ставишь переменнную чтоб их использовать, я правильно веду логику???
Если еще дальше, пишешь блок который может изменяться в зависимости от переменной и все, и не зачем его каждый раз прописывать, ну я имею ввиду правтически одну и ту же процедуру,но с разными поддтипами и т.д. её не зачем писать когда переменная быстрее вставиться и блок обрабатываемой информации меньше, я правильно думаю???
Точнее мыслю, или я совсем ЛОХ стал в написании...

Для продвинутых есть третье правило оптимизации. "Не оптимизируй. Пока...". Но оно не для этой темы. А первые два лучше распечатать и принимать как аксиому.

А вот эти строки - как закон:


Также не забывать о таком правиле - "Не пессимизируйте преждевременно".



Это не обратный пример.
Во-первых:

И в главных - там нарушались технические требования к реализации.

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