• Раздача слонов или инвайты на Google+
    0
    Получилось зарегистрироваться. Спасибо!
  • Раздача слонов или инвайты на Google+
    0
    Спасибо! Но к сожалению:
    The Google+ project is currently working out all the kinks with a small group of testers. If you're not able to access Google+, please check back again soon.
    :(
  • Раздача слонов или инвайты на Google+
    0
    yuriyo@gmail.com, пожалуйста
  • Ускоряем Visual Studio, часть I. Unity Builds
    0
    К сожалению, anonymous namespace не помогает с коллизиями символов.
  • Ускоряем Visual Studio, часть I. Unity Builds
    +1
    У unity билдов есть еще одно достоинство — у компилятора появляется больше возможностей для оптимизации. Теоретически, компилятор сможет практически всё что делает линкер с link time code generation.
    Еще один прием — вместо дополнительных конфигураций (и головной боли от отключения всех новых *.cpp файлов при добавлении в проект), можно просто создать дополнительный _проект_ с одним единственным cpp файлом. И еще, можно вытащить все общие параметры проектов в отдельные property sheets. Они работают просто «из коробки» для PC и 360 проектов. PS3 VSI представляет собой небольшую головную боль, но и его тоже можно настроить (VSI может использовать user macros, которые заданы в property sheet).
    На мой взгляд, у unity есть всего три недостатка (один из которых описан в статье):
    1. Статические, инлайн и anonymous namespace функции, переменные и типы должны иметь уникальные имена. Автор статьи призывает ими не злоупотреблять, но лично я с этим не согласен. Эти механизмы очень хороши для того чтобы прятать внутренности систем от пользователей публичных интерфейсов. Конечно, есть множество альтернатив для достижения того-же эффекта, но лично мне anonymous namespace-ы кажутся элегантным решением.
    2. Когда один из cpp файлов include-ит какой-то заголовок, он становится доступным для всех последующих cpp файлов. Таким образом unity проект может компилироваться без проблем, но не-unity может выдавать ошибку о том, что некоторые символы не определены, т.к. необходимый заголовок на самом деле не включен. Это довольно серьезная проблема когда не-unity конфиг собирается долго и разработчики коммитят только тестируя в unity. На мой взгляд, самое простое решение этой проблемы — только поддерживать unity! У нас в проекте, например, несколько unity файлов (т.к. они могут компилироваться параллельно с помощью -j, /MP, SN-DBS или IncrediBuild).
    3. При работе с одним отдельным cpp файлом, собирается весь unity файл. Это частично решается созданием нескольких unity файлов (как у нас в проекте) и созданием одного специального пустого unity файла. При необходимости в быстрой итерации, можно убрать отдельные файлы из «главного» файла и включить в специальный. Кроме того, это можно сделать по #ifdef YOUR_NAME для группы файлов и смело коммитить в депо.
  • Sony получила разрешение изучить информацию на жестком диске с ПК хакера GeoHot
    0
    Я думаю что процент людей которые будут это делать достаточно мал и вполне компенсируется тем, что 360 теперь в гораздо более выгодном положении с точки зрения паблишеров. Разработка для PS3 и раньше была гораздо дороже и рискованей чем для 360. А теперь тем более.
  • Sony получила разрешение изучить информацию на жестком диске с ПК хакера GeoHot
    0
    Как Microsoft пострадает?
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • В Starcraft 2 можно играть с AI на нескольких спецкартах и на разных уровнях сложности
    +1
  • Эффективность C++ на современных ПК
    0
    В современных процессорах еще есть такая штука как pipelining и register renaming. Благодаря этому, процессор может одновременно выполнять несколько операций если между ними нет зависимостей. Это, опять-же, помогает спрятать доступ к памяти.
    Сами инструкции выполняются примерно с одинаковой скоростью (обычно 1 инструкция за цикл). Но благодаря глубокому пайплайнингу, хороший код будет выполняться со скоростью ~2-3 инструкции/цикл.
  • Эффективность C++ на современных ПК
    +1
    1. Разница в 4 раза это еще хорошо. Здесь работает автоматический префетчинг. На PC, современные процессоры умеют предсказывать какие кэш линии будут скоро необходимы. Это работает даже при прыжке в несколько кэш линий. Необходимо только чтобы вы шли в одном направлении по памяти, с одинаковым шагом. Можно еще самому поставить hint-ы для префетчинга, но здесь необходимо очень аккуратно проверять результаты, скажем, VTune-ом. Попробуйте создать массив индексов для выших 100мб данных, отсортировать его случайным образом и потом опять сложить данные, используя случайные переходы.

    Про SIMD — современные компиляторы умеют самостоятельно векторизировать ваш скалярный код. С тем или иным успехом. Intel C++ compiler умеет это делать лучше чем MSVC. Никакого ассемблера не ребуется.

    2. В большинстве практических случаев это именно так, как я сказал.

    3. Можно. Разные процессоры умеют по разному предсказывать где произойдет cache miss. Но инструкции они выполняют более-менее одинаково.
    Cache-efficient код будет работать на порядок быстрее на любом современном процессоре.
  • Эффективность C++ на современных ПК
    +1
    1. Основная проблемма в современных процессорах — медленный доступ к основной памяти (L2 cache miss* стоит сотни циклов). Всевозможные приемы, как out-of-order execution, branch prediction и т.п. предназначены в первую очередь именно для того чтобы угадать где в будущем будет этот-самый miss и начать копировать память в cache. Современные компиляторы не способны особо помочь в этой ситуации (кроме как на совсем микро-уровне scheduling-а инструкций). Негативный эффект от L2 промаха может замедлить самый алгоритмически оптимальный, векторизированый (simd) код в 10 раз! Никакой апгрейд компилятора не поможет если вы прыгаете по памяти.
    Так что ответ — ДА, реорганизация данных для оптимального использования L2 будет выиграшем.

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

    3. Нет, не будет. Будет только быстрее. В обозримом будущем память будет всё более дорогим ресурсом, т.к. будет всё больше ядер которые борятся за одновременный доступ.

    Авторы статей — широко известные (в узких кругах геймдева) программисты. Они знают о чем говорят.

    * для справки: кэш процессора организован в несколько уровней (обычно L1, L2 и L3). Каждый уровень разбит на мелкие участки — cache lines (обычно в 64 байта). В каждом участке хранится копия данных из основной памяти. Кроме кэша, у процессора есть регисры. Для маппинга физических адресов основной памяти используется совсем-совсем простая hash-функция (обычно бит-маска и сдвиг). Когда все вычисления происходят с регистрами — мы получаем оптимальную скорость. В этом случае компилятор это наш лучший друг и его качество сильно влияет здесь на производительность. Когда нужно записать новую информацию в регистр, процессор идет в L1. Если там есть данные — cache hit, всё хорошо и быстро (несколько циклов на i7). Если данных нет — cache miss, процессор идет в L2. Если нужные данные там есть (cache hit) — всё не плохо (десяток-другой циклов). А если данных нет — cache line запрашивается из основной памяти (. Это уже стоит сотни циклов.
    Cache line это минимальное количество памяти, которую процессор может запросить. Поэтому если даже вы трогаете всего один байт в вашей структуре, из памяти будет передано 64. Кроме того, если суммарный размер вашей структуры, скажем, 65 байт — будет передано 128. И это еще не всё! Если у вас есть динамический массив из данных в которых каждый элемент 64б — у вас всё равно есть шанс передавать две кэш-линии при доступе к одному элементу. Это происходит изза выравнивания памяти.

    Я мог бы продолжать еще очень долго. Возможно это была бы хорошая тема для отдельного хабратопика?
  • Основы создания игрового движка: таймер
    0
    Qt и glib это довольно высоко-уровневые абстракции, а не стандартные кросс-платформенные решения.
  • Основы создания игрового движка: таймер
    +2
    В OGRE таймер устроен точно так-же как автор описал.
    В юниксах обычно используют gettimeofday().
  • Основы создания игрового движка: таймер
    0
    Точность WaitForSingleObject гораздо хуже QPC.
  • Основы создания игрового движка: таймер
    0
    Ничего страшного не произойдет. Автор гарантирует исполнение QueryPerformanceCounter на одном ядре:
    SetThreadAffinityMask(GetCurrentThread(), 0);
  • Основы создания игрового движка: таймер
    +1
    Надежных и точных (high resolution) кросс-платформенных решений НЕТ.
    В геймдеве обычно используют оптимальное решение для каждой отдельной платформы (PC, PS3, 360, и т.д.), скрытое за общим интерфейсом.
  • Видео докладов iPhoneDevCamp Kyiv v2.0
    +1
    Хорошо запомнилось:
    — Про то, как в directx нет различия между pixel и vertex шейдерами.
    — Про то как шейдеры не снижают производительность.
  • Видео докладов iPhoneDevCamp Kyiv v2.0
    +1
    Посмотрел про OpenGL.

    Хочу сказать что докладчик очень плохо понимает тему и в нескольких местах дает ложную информацию.

    Рекомендую вместо просмотра почитать документацию:
    developer.apple.com/iphone/library/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Introduction/Introduction.html

    И код практического применения:
    code.google.com/p/cocos2d-iphone/
  • Теломераза: накрутка счётчика для хромосом
    0
  • Когда Photoshop отображает совсем не то, что надо
    0
    V^(1/gamma), конечно-же, должно быть V^gamma
    1/gamma должно быть напряжение чтобы получить линейную яркость
  • Когда Photoshop отображает совсем не то, что надо
    +4
    Проблема не только в качестве мониторов, но и в количестве бит на пиксель.

    Сейчас практически везде используется 24-битные форматы (8 бит на канал).
    Хранить яркость без компрессии не эффективно, т.к. мы воспринимаем яркость (как и громкость) логарифмически.
    Чем ярче точки, тем менее заметна между ними разница.
    Соответственно, в идеале наши 8 бит (256 градаций) необходимо распределить неравномерно: темным пикселям — больше разрешения, светлым — меньше.

    Давным-давно на помощь пришли CRT мониторы, которые по дикой случайности тоже воспроизводят яркость нелинейно.
    Если нормализировать напряжение подаваемое на точку в диапазон 0-1 (V), то её яркость получается пропорциональна V^(1/gamma).
    У типичного CRT монитора, gamma=2.2 (оппа! вот откуда ростут ноги у sRGB).
    Возможно, у CRT мониторов apple нативная гамма была 1.8. А может 1.8 просто потому что think different :-\

    Поэтому если вывести на экран #808080 мы получим яркость не 0.5(mid-grey), а примерно 0.217 (0.287 на apple).

    Художники работают с изображениями и корректируют их «на глаз». Сами того не зная, они оптимизируют изображение одновременно для представления в памяти и для отображения на _их конкретном мониторе_!

    Но сегодня у LCD мониторов соотношение напряжение/яркость — линейно. Поэтому коррекция происходит искусственно при декодировании пикселя монитором. Обычно используется именно гамма 2.2 для совместимости с CRT.

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

    Я подозреваю, это всё чтобы окончательно заморочить голову большинству пользователей: вместо одного места для fuck-up-а (настройки монитора), у нас появилось хрен знает сколько.

    Возможно, в будущем мы все будем кодировать наши цвета в HDR форматы (как минимум 16 бит на канал). И у всех будут линейные мониторы.
    Тогда мы забудем всё это как страшный сон.

    А сейчас, на мой взгляд rule of thumb такой:
    — выбрать sRGB во всех приложениях (т.е. чтобы приложения ничего сами не конвертировали);
    — Не сохранять никаких профилей в изображениях (sRGB по умолчанию);
    — Корректировать яркость/гамму настройками монитора (т.е. в ОДНОМ месте);
    — Смотреть на разультат на разных компьютерах. Корректировать гамму изображения _в соответствии с результатами_. В самом-самом конце. Один раз.

    PS:
    И это всё еще даже без упоминания всевозможных графических алгоритмов. Обычно они работают в гамме 1.
    Например, что получится если взять изображение 2x1, один пиксель белый, другой черный и resize его в 1x1?
  • OnLive — революция подкралась незаметно
    0
    Думаю, современные latency & bandwidth погубят как идею, так и компанию. Этой технологии время через лет 8-10, когда в большинстве европейских стран и в штатах проапгрейдят броадбэнд инфраструктуру.
  • Производительность C#
    0
    Ааа, внимательно прочитал комментарий. Мне почему-то показалось что имелось в виду поддержку int-ов приходится эмулировать, а не double-ов.
  • Производительность C#
    0
    Ну как причём? Нативная поддержка операций над целыми числами (в т.ч. bitwise операций) пришла в мейнстрим только с выходом DX10, а точнее Shader Model 4.
  • Производительность C#
    –1
    Все Directx10 карты (nvidia 8-й серии и выше, например) поддерживают работу с целыми числами.
  • Spore — самая пиратская игра в истории (из-за DRM)
    0
    Вероятно, особенности ваших локализаторов. Моя европейская версия диск не требует.
  • Spore — самая пиратская игра в истории (из-за DRM)
    0
    Причина — невероятное количество хайпа вокруг игры. Интерес к игре не пропорционален количеству людей, готовых платить за неё деньги.
  • Spore — самая пиратская игра в истории (из-за DRM)
    +1
    В случае со Spore — так оно и будет, ведь Maxis это часть EA.
  • Spore — самая пиратская игра в истории (из-за DRM)
    0
    Аккаунт привязывается к серийному номеру твоей копии. Разрешается только одно подключение с аккаунта.
    А все дополнительные методы защиты только портят игру.

    Очень правильно с этим поступает Epic Games (unreal tournament series). Сначала игра привязана к диску, но с первым-вторым патчем эта привязка снимается. Делается это с целью остановить первую волну пиратов, которые бы просто установили игру с дисков товарищей для сингла или LAN игры.

    Если человек в любом случае не желает покупать игру, никакой DRM не поможет (по крайней мере пока он существует на програмном, а не аппаратном уровне).
  • Spore — самая пиратская игра в истории (из-за DRM)
    0
    В батлфилде есть динамическая реклама (на разнообразных билбордах внутри игры).
  • Флешмоб против Spore
    0
    Я купил в день релиза за £35 (~60$), посмотрев как сотрудник играл на первой стадии.
  • Флешмоб против Spore
    0
    А что это, если не флешмоб?
  • Флешмоб против Spore
    +1
    Это сложный вопрос. Сейв как таковой там один (одна галактика). В ней можно создать несколько цивилизаций в разных spiral arm-ах и они не будут мешать друг другу (если, конечно, целенаправленно не лететь «в гости»).
    Но нельзя разграничить то, что ты создаешь в редакторах. Все видят (и могут редактировать, удалять и т.д.) всё что есть на локальном компьютере. И публиковаться создания будут тоже все от одного имени.

    Но это, в принципе, не такая уж и важная проблема на фоне зверского DRM-а и вялого геймплея.
  • Флешмоб против Spore
    +1
    На одном только хайпе, думаю, миллион у них продастся.
  • Использование выражений в PHP
    +1
    Coding standard-ы на самом деле есть. В любой серьезной софтверной компании как минимум один (могут быть для разных языков, платформ и даже отдельных проектов).

    Стандарт описывает индентацию, case-конвенцию, комментарии, namespace-ы, названия классов, допустимые сторонние библиотеки (stl, boost, etc.), глобальные и статические переменные, и многое другое.

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

    От программиста который «хотя бы работает» или постоянно не высыпается и кодит с температурой гораздо больше вреда чем пользы.

    А если программист большую часть дня страдает непонятно чем, то нужен ли такой программист вобще в компании?
  • Красив ли код???
    0
    Кстати, этот код отлично оптимизируется для констант. Компилятор сам подставит результат вместо вызова get_ones_count(SOME_PREDEFINED_CONSTANT).