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

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

В коде случился такой паттерн: у объекта есть два указателя на разные куски в памяти, в зависимости от флажка надо выбирать либо по 1му, либо по 2му. (Для справки, это некая статическая часть данных, которая расшарена между несколькими копиями объектов, и динамическая часть, которая очень личная и которой объект владеет).

Написал return bDynamic ? m_pDynamic[iOffset] : m_pStatic[iOffset], слегка задумался. Поля m_pStatic и m_pDynamic в объекте лежат подряд. bool bDynamic хоть и занимает целый байт, принимает все равно значения 0 и 1. Догадается компилятор заменить это дело на (*(&m_pStatic+bDynamic))[iOffset], и выгоднее ли это?

Результаты MSVC 2005: да, выгоднее на 30%. Нет, не догадывается.

Результаты gcc 4.2.3: не уверен, что правильно понимаю ассемблерную нотацию, но похоже, догадывается сразу. Поэтому разницу померить не удается, результаты одинаковые.

Код бенчмарка под катом.

На моем десктопе собранный MSVC 2005 вариант выдает

Новость первая - в “Нивал Онлайн” ( или компания уже называется “Аструм Нивал”, я не в курсе ) открывается вакансия gfx программера. Работа не особо пыльная, если с надрочкой. Проект забавный, коллектив внятный ( Яся и Вова, куку ). Зарплату могут платить хорошую, как линейную функцию от скилла, с хорошим коэффициентом. Это я все без иронии, если что.

Менеджмент в компании разный - есть два менеджера, один добрый, второй соответственно не очень. Работают на контрастах.

Новость вторая. Мной подписано заявление об увольнении с 1 августа сего года, в связи с чем я ищу работу в стольном граде Москва. Можно в индустрии, можно за пределами. Умею писать под разное странное железо на низком уровне, вот успешно драйверцы для RSX зафигачил http://psp.jim.sh/svn/listing.php?repname=ps3ware&path=%2Ftrunk%2Flibps3rsx%2Fsrc%2Finit%2Fps3rsx%2F. Умею писать высокий уровень. Умею разное. По укурке защитил диссертацию по алгебраической топологии, уже работая в Нивале. Пожелание одно - работа без овертаймов. Я и с ними могу, если специально и заранее со мной согласовать, но у меня имеется стойкая аллергия на сей счет.

Не стесняйтесь c предложениями, пишите на IronSPeter ‘at’ gmail.com. Только имейте в виду, что с 1 августа по 21 августа буду в безынтернетных далях и отвечать на заманчивые предложения не смогу. На новое место работы выйду с сентября, если найду внятную контору.

Под катом - неофициальная часть, отчасти грустная.

Есть такая отвратительная болезнь. Глаукома, необратимая атрофия зрительного нерва. Поле зрения сужается и превращается в замочную скважину, через которую человек смотрит на мир. А потом и вовсе… У меня этой дрянью болеет отец. Был май, Нивал распределял отпуска, мне вышел август. Отец попросил с ним поехать в родной город, я не отказался, сам он не сможет поехать.

Потом был июнь и менеджмент стал срочно искать, что урезать. Пытливый взор свеженазначенного менеджера Д.Д. наткнулся на отпуска. О! Предлагалось отложить личные дела, забыть привязанности и всей командой дружно поработать. Я запомнил фразу, формулировка меня привела в ступор. “Другое лето, другая первая любовь - все это еще у вас будет. А вот такого шанса зажечь - уже нет”.  Вроде я это действительно слышал, сам придумать такое не мог.

В связи с чем интересно.

С одной стороны имеем рассказы, что overtime оборачивается всегда undertime. Что многократно сорванные сроки - это всегда ошибка планирования, но никак не рядовых сотрудников. Что талантливые люди сгорают под нагрузками. И прочие другие азбучные истины менеджмента из книжек, которые читает Семен.

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

Петр.

Вот, например, я несколько месяцев назад таки осилил классику софтверного project management - Peopleware ДеМарко и Листера.

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

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

Первая часть - про сравнение софтвера с традиционным производством.

Говорят очевидные вещи - что development очень отличается от production (у нас, слава богу, стоимость production нулевая), процессам вредит излишняя стандартизация - главная задача исполнителя думать, нельзя процессами компенсировать работу мозга.
Уточняют отличия - спокойнее относиться к ошибкам, так как все новое и многое не узнать, пока не попробуешь; не помогает людей пинать, потому что от пинков быстрее думать не начинаешь; заменять людей очень тяжело, медленно и дорого.

Что тут сказать… well, duh (но надо помнить, это книжка 1987 года).

Следующий набор мыслей про последствия давления на людей:
- овертайм _всегда_ приводит к такому же или большему undertime - т.е. люди как минимум такое же количество времени работают менее продуктивно. Это легко не заметить.
- у овертайма есть долговременные последствия - жизнь проходит мимо
- с трудоголиками нужно очень осторожно - если додавливать до предела, то рано или поздно сгорят с концами
- самое дорогое последствие овертайма - как влияет на текучку кадров. Пишут, никто не даже не пытается оценить этот фактор.
- People under time pressure don’t work better, they just work faster.

В Windows (да и вообще в MS) в этом смысле все очень хорошо. У меня за два года кранчи случались всего пару раз и длились не больше недели, менеджеры не наседают и почти никогда не предлагают поработать по выходным. У меня был тиммейт, который именно поэтому пришел в MS из геймдева и даже не думал обратно.
С другой стороны, если ты сам хочешь въебывать - сколько угодно, и если у тебя получается продуктивно - это конечно окупается. То есть, прецеденты, когда отсутствие жизни очень помогает в карьере, я видел. Видел хорошие карьеры и без этого, впрочем. Что логично - если получается больше делать, это приемущество, но надо еще знать что.

Еще у них неожиданные наблюдения про “качество против времени”.
Во-первых, что делать некачественный продукт люди не любят (с последствиями). Это понятно.
Во-вторых, что внутренний стандарт качества исполнителей типично выше необходимого менеджменту (даже сильнее, маркету). Это допустим.
И в-третьих, неожиданное - от повышения качества вне необходимого растет продуктивность, потому что мол больше мотивации и люди начинают работать над процессами и тулами, которые окупаются.

Я прям не знаю. Я очень хорошо вижу, что в Windows (и, по рассказам, в Office) от размера проекта и очень высокого качества кода (да-да, очень высокого) все очень медленно. Багфиксинга - более 50% времени разработки, чинить один баг в день - хорошо, а два - подвиг. Тест-команда такого же размера и квалификации, что дев - ибо полностью покрывать Windows автоматическими тестами.
С другой стороны, быстрый билд, очень мощный отладчик, тулзы для code review и прочее-прочее. Может, если изначально туда бы не целились, и вообще бы не взлетело. Возможно, они хотят сказать, что нужно инвестировать в инфраструктуру дальше, чем на сейчас.
А у вас есть мнение?

Последний их тезис на сегодня - Parkinson’s Law revisited.
Все знают, что такое закон Паркинсона - работа занимает все выделенное на нее время, вне зависимости от его количества.
Они считают, что к нам с вами он не применим, потому что мы в основном получаем удовлетворение от сделанной работы и понимаем, что жизнь коротка, и хочется многое успеть. Считают, что если в хорошей команде кто-то никак не может что-то закончить - это чаще не из-за лени. И даже когда из-за лени - то лучше если пинают товарищи по команде, чем менеджер.
(я уже говорил, что это светлая и добрая книжка?)
Приводят некие исследования, в которых измеряется продуктивность в зависимости от установления срока. Хуже всего, когда срок оценивает менеджер (и он получается самым маленьким), лучше - когда сам, еще лучше - когда без оценки.

Про слабую корреляцию агрессивного дедлайна/пинания жопы с производительностью - я согласный (что через вопросы “как там?”, что через менеджерское дилдо). С возрастом я скорее более прямо говорю “нет, это займет вот столько” и “я тут проебал, надо больше времени” и на пинки реагирую все спокойнее. (Джоэль, кажется, об этом же пишет)
Важный момент, мне кажется - дело скорее не в распиздяйстве, а в размазывании фокуса, т.е. когда начинаешь много тратить времени на необязательные возникшие проблемы. Но опять же, это не вылечить наличием дедлайна - это опыт, это “узнавать о проблеме рано и поправлять расписание”.
Одним словом, не верю я в мотивацию сроками, но верю, что помогает фокусу.

В Крейтовском коде еще с прошлого века существовал блок функций SetIdle()/ClearIdle()/IsIdle(). Эти функции предназначены для работы с режимом паузы. SetIdle() увеличивает счетчик паузы, ClearIdle() - уменьшает. Если счетсик равен 0, игра находится в рабочем состоянии. Если > 0, игра находится в режиме паузы. Внутриигровое меню, например, на конструкторе ставит режим паузы, на деструкторе ее снимает. Железобетонно? Вроде как да.

Тем не менее, одновременно с этими функциями был сделан следующий код в момент начала загрузки каждого нового уровня:

Так вот. Играю я вчера в American Chopper, врезаюсь в очередную машину, меня в воздухе ловит камера, ставит паузу, показывает со всех сторон, я прерываю этот скрипт Enter’ом, и происходит чудо. Впервые за все время разработки в Крейте, за все время локализации в 1С (я заканчивал проект, уже работая тут), игровой скрипт не снимает режим паузы при прерывании показа. То есть скрипт отработал, а я лежу себе на дороге такой красивый загораю, а посадить себя в мотоцикл и поехать дальше не могу.

Впрочем, работает внутриигровое меню, я перезагружаю уровень, и несмотря на то, что в протокол ушло “Resetting pause mode”, следующий уровень начал играть нормально. Больше мне ни разу не удалось вызватьтакое поведение скрипта, я даже предположить не могу, с чем было связано такое поведение. Возможно, с быстрым 4-х ядерным процессором. Возможно, я попал Enter’ом в какую-то наносекунду, куда не мог попасть раньше. А возможно, скрипт также фатально прервал свою работу, потому что что-то случилось где-то еще в программе. Но самое главное, что программа восстановилась после такого сбоя и позволила пользователю продолжать работать дальше.

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

Я в следующей статье покажу, каким образом выражение вида

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

Мораль: если у вас есть переменная int alwaysZeroValue = 0; то иногда она будет ненулевой.

Начнём, впрочем, с конца. Внятная новая абстракция кроме собственно инноваций очевидно успешно решает уже имеющиеся проблемы.

Сперва абстракция. Итак float4 TexBlah(float4 coordinates). Будем резать. Очевидных линий отреза две: прямо на уровне TexBlah, либо на уровень ниже фильтрации. Нужен-ли шейдер фильтрации я буду думать потом, а пока что отрежем на уровне текстурного сэмпла. float4 SampleTexBlah(int4 coordinates). Уровень TexBlah имеет свои приимущества, но идёт вопреки идее грубой силы – и потому лесом.

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

Кеширование, кстати, ставит интересный вопрос. Float4 SampleTexBlah(int4 coordinates) очевидно проигрывает byte4 SampleTexBlah(int4 coordinates) – формат результата зависит от формата текстуры, а для случая DXT1 (которое на современном железе хранится в кеше в нераспакованом виде) придумать внятный формат результата у меня почти не получается. Т-е вопрос исключительно эффективности кеша, и здесь однозначного мнения у меня нет (интруция говорит ограничимся byte4 снизу и float4 сверху). Собственно здесь снова встаёт вопрос шейдера фильтрации, но это, пожалуй, единственный имеющийся у меня use-case.

В итоге очередной кусок специализированного железа (а есть ли он там?) получает равноправное унифициорванное применение. Пусть будет 2x нитей, а не ещё несколько текстурных блоков. Такая система будет значительно лучше масштабироваться.

Как всё это может выглядеть? Ну, например, вот так

Теперь, когда как-то понятно, где оно работает, вернёмся снова к предмету обсуждения. А, собственно, зачем?

Пример выше иллюстрирует мой самый первый use-case. А именно поддержка текстур с палитрой на современном железе. Я ничего не буду говорить про компрессию, мегатекстуры, фрагментацию текстурной памяти и прочие самоочевидные вещи. Замечу, только, что работать такое будет значительно лучше, чем сколь угодно продуманный фиксированный API. Меньше всего я хочу удвидеть очередную видеокарту с аппаратной поддержкой мегатекстур. Надеюсь имеющиеся “фенечки” про стенсильный буфер тоже когда-нибудь кто-нибудь выкинет на свалку истории, хотя-бы какими-нибудь бленд-шейдерами. Но это уже тема совсем другой истории.

P.S. ужасно уродливый шейдер про текстуру с палитрой и билинейной фильтрацией могу отдать в хорошие руки.

Ленивый код: любая фича добавляется по нужде. У класса Image есть метод CropRight, для прогресс-баров. CropLeft, CropTop, CropBottom пока не понадобились.

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

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

Я озвучу свою собственную точку зрения на вопрос “требуется ли такая диагностика в игре и если да, то каким образом ее делать”. Кстати судя по ответам, по состоянию на 11:47 24 апреля я должен растаться с 29 литрами пива (именно столько людей проголосовало за пункт 1). Впрочем, пиво почти наверняка останется при мне, потому что я готов привести конфигурации компьютеров и настроек, на которых ваша версия GetTotalVideomem() даст неправильный ответ.

А раз вы не можете быть уверены в результате, то что же делать?

Разумеется, очевидно, что для PC-игр конфигурация компьютера может быть сильно различной. И для борьбы с этим явлением многие разработчики вынуждены вводить видео-опции. Кто-то вводит технологические опции, такие так “Lightmaps”, “Texture filtering”, “HDR” и т.п., кто-то - более игровые “Render quality” и т.п. Ну и иногда делаются кнопки типа “максимальное качество” / “сбалансированные настройки” / “минимальные настройки”. Хотя настройки типа Lightmaps/Shadows позволяют (наверное) сбалансировать качество vs производительность лучше, чем один ползунок “Render quality”, не совсем понятно, какое количество игроков будет готово заниматься таким тщательным тюнингом.

Но речь даже не об этом. Стремление помочь игроку в познании игры в ее максимальном качестве иногда приводит к совершенно невообразимым результатам. Из них вполне получился бы такой же “Топ 10″, какой я делал про самые нелепые падения игр. Установка игре high process priority и автоматическая блокировка процесса icq.exe - это еще не самое страшное, что может быть. Требование на определенный размер своп файла - это уже веселее. Требование на /3Gb пока еще не встречал, и слава богу. Но это все меркнет перед тем, на какие реальные шаги разработчики готовы пойти, ради того, чтобы оградить пользователя от плохого впечатления от игры, вызванного низкой производительностью…

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

Я хотел бы развеять несколько мифов.

Миф номер 1. Вы можете определить конфигурацию компьютера. На сам деле ни хера вы не можете. Даже тактовую частоту процессора вы не определите. А даже если и определите (и даже если еще про количество ядер не забудете), что вам это даст? И вы уверены, что тактовая частота больше 4294967296 Гц не вызовет в вашей программе переполнения int? Про видеопамять уже писал выше, даже повторяться не буду. Вы конечно можете потратить несколько человеко-месяцев на борьбу с текущим детектированием конфигурации компьютера и несколько человеко-месяцев на борьбу с будущими конфигурациями (примеры ниже). Но это все равно бесперспективно.

Миф номер 2. Пользователю требуется регулярная проверка конфигурации компьютера и установка параметров в автоматическом режиме. Ни хрена. Он будет благодарен вам, если вы настроите игру в момент инсталляции. Если он купит другую железку или покрутит настройки в биосе, то он достаточно опытен, чтобы найти окно “Video options”. Если хотите совсем казуального решения - сделайте отдельную утилиту “Автоматическое детектирование конфигурации компьютера”, чтобы она переустановила настройки игры (альтернативный вариант - ключ запуска игры типа -reset - приведен ниже).

Миф номер 3. Игра должна блокировать свой запуск, если конфигурация компьютера не соответствует системным требованиям. Поскольку миф номер 1 - это действительно миф, то блокировка запуска игры - это самый худший вариант, который вы можете предложить игроку. Вы можете сообщить, что его компьютер плохой, и что он может не потянуть с нужной производительностью (Continue/Cancel). Вы можете сообщить, что из-за капсов у него что-то не будет рисоваться или рисоваться с глюками или даже вообще программа может упасть. Но физически запрещать запуск игры - я надеюсь, что среди издаваемых нами продуктов я такого больше не увижу. Потому что когда появился Core 2 Duo некоторые наши игры начали выдавать следующий перл: “Ваш компьютер имеет тактовую частоту 2.1 ГГц. Для игры требуется 3 ГГц. Нажмите Ok,. чтобы выйти из программы” (это еще к мифу номер 1).

На самом деле, какие вопросы надо решить разработчику:
1. Надо, чтобы игра установилась на компьютер;
2. Надо, чтобы она “по умолчанию” работала достаточно адекватно;
3. Надо, чтобы ни при каком развитии событий у пользователя не возникло дедлока, что он не может запустить игру (разумеется, про критические рантайм ошибки речь не идет);
4. Надо, чтобы ее запуск не отжирал продолжительное время;
5. Надо, чтобы у продвинутого пользователя была возможность настроить / отбалансить игру под свой компьютер и под себя;
6. Надо, чтобы у обычного “казуального” пользователя при помощи службы техподдержки была возможность дистанционно решить какие-то проблемы или настроить игру под свой компьютер.

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

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

И наконец, пункты 5 и 6 могут быть реализованы в игре при помощи каких-то дополнительных переключателей и настроек. Не обязательно даже в графическом режиме. Можно в текстовом файле при помощи команд set. Можно так, как это сделано в firefox (about:config). Можно как угодно. Желательно, чтобы эта возможность была, но при этом абсолютно не мешала 99% пользователей, которым это никогда не понадобится.

А освободившееся время лучше потратьте на профилирование и улучшение производительности. Пользователи вам будут намного более благодарны, чем если вы будете на каждом старте игры детектировать конфигурацию и “не пущать”.