Когда-то давным давно, когда я еще учился в школе, а на дворе был конец перестройки, мой дядя (заронивший в меня интерес к электронике) припер домой сумку вынесенного через проходную завода добра. Собственно, такие сумки он приносил домой вполне регулярно, пополняя запасы, хранившиеся в диване. Диван этот, как вы догадываетесь, манил, и иногда в отсутствии дяди я в него заглядывал с восторгом. Но кое-что из этой сумки в диван не попало, а попало в мои руки. Дядя мне вручил пачку — штук десять — макетных плат, и новенькую нераспечатанную коробку дефицитных, да и не дешевых в то время светодиодов. Причем светодиоды были не простые: вместо привычной маркировки АЛ-что-то там на коробке стоял код из четырех цифр, как я понял — они были экспериментальные. И они были яркие. По сравнению с привычными АЛ307 или АЛ310 — просто ослепительные. И их к тому же было много — штук 50.

Идея «куда это богатство применить» возникла моментально: светодиоды были распаяны на одной из макетниц — сколько влезло (влезли не все), и из них вышел великолепный красный фонарь для печати фотографий, который абсолютно не засвечивал фотобумагу даже в упор. Правда, тут же я узнал о том, что «светодиоды не греются» — это вранье, так что ток пришлось снизить вдвое, с 10 мА на светодиод до 5. А еще через полгода успешной эксплуатации узнал и о том, что «светодиоды не перегорают» — это тоже неправда: первый светодиод в сборке погас, оказался пробит. А со временем и весь фонарь пришел в негодность.

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

От переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.

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

Есть много причин, почему некоторым не удаётся привлечь талантов. Однако все команды, которые делали это с лёгкостью, поняли один простой факт о текущей ситуации на рынке:

При найме сеньоров не компания выбирает кандидата, а кандидат выбирает компанию.

Проще говоря:

Приглашая опытного разработчика, вы не покупаете, а продаёте.

По работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.


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

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

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

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

Итак, сегодня я покажу, как отрисовывать подобные картинки:

В этой статье представляем страницы, очень распространённую схему управления памятью, которую мы тоже применим в нашей ОС. Статья объясняет, почему необходима изоляция памяти, как работает сегментация, что такое виртуальная память и как страницы решают проблему фрагментации. Также исследуем схему многоуровневых таблиц страниц в архитектуре x86_64.

Этот блог выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий запрос.

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

Причина проста — в новых процессорах много ядер, но по факту они менее производительны в однопоточных приложениях. На тот момент, у меня был рендер в один поток. Но на самом деле причины была не столько в этом. И в процессе поиска проблемы, я решил посчитать сколько полигонов присутствует в сцене:



На средней игровой карте, при максимальном отдалении и при большом скоплении пальм — 15 824 756 треугольников! Почти 16 миллионов! Огромная цифра.

Вы когда-нибудь задумывались о том, как работает небольшая инди-студия, занимающаяся разработкой видеоигр?

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

Мы — небольшая команда из Польши. Нас всего три человека, но полный рабочий день занимаются проектом всего двое.


Сегодня мы расскажем о процессе создания персонажей для нашей игры «The end of the Sun». Имейте в виду, что показанные в статье скриншоты взяты из проекта, который пока находится в разработке.

Этот текст посвящён только статичным элементам персонажей: мы расскажем, как сканировали персонажа и одежду, как создавались дополнительные элементы, а также о том, как мы настроили движок Unity, чтобы получить такие скриншоты:

Ветеран программирования трёхмерной графики Майкл Абраш на примере разработки первого Quake рассказывает о необходимости творческого мышления в программировании.

Много лет назад я работал в теперь уже не существующей компании-производителе видеоадаптеров Video Seven. Там я помогал в разработке клона VGA. Мой коллега Том Уилсон, долгие месяцы круглосуточно работавший над разработкой VGA-чипа Video Seven, стремился сделать VGA как можно более быстрым, и был уверен, что его производительность оптимизирована почти по максимуму. Однако когда Том уже вносил в конструкцию чипа последние штрихи, до нас донеслись слухи, что наш конкурент Paradise достиг ещё большей производительности в своём разрабатываемом клоне, добавив в него FIFO.

На этом слухи заканчивались — мы не знали, ни что это за FIFO, ни насколько он помог, ничего другого. Тем не менее, Том, обычно приветливый и расслабленный человек, превратился в активного, одержимого фанатика со слишком большим процентом кофеина в крови. Исходя из этих крупиц информации, он пытался выяснить, что же удалось сделать Paradise. В конце концов он пришёл к выводу, что Paradise вероятно вставил FIFO-буфер записи между системной шиной и VGA, чтобы когда ЦП выполнял запись в видеопамять, записываемые данные сразу же попадали в FIFO, и это позволяло ЦП продолжать обработку, а не простаивать каждый раз, когда он выполнял запись в память дисплея.

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

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

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

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

WITH RECURSIVE numbers AS (SELECT 0 AS n UNION ALL SELECT n+1 FROM numbers WHERE n<89),
pixels AS (SELECT rows.n as row, cols.n as col FROM numbers as rows CROSS JOIN
numbers as cols WHERE rows.n > 4 AND rows.n < 38 AND cols.n > 9 AND cols.n < 89),
rawRays AS (SELECT row, col, -0.9049 + col * 0.0065 + row * 0.0057 as x,
-0.1487 + row * -0.0171 as y, 0.6713 + col * 0.0045 + row * -0.0081 as z FROM pixels),
norms AS (SELECT row, col, x, y, z, (1 + x * x + y * y + z * z) / 2 as n FROM rawRays),
rays AS (SELECT row, col, x / n AS x, y / n AS y, z / n AS z FROM norms),
iters AS (SELECT row, col, 0 as it, 0 as v FROM rays UNION ALL
SELECT rays.row, rays.col, it + 1 AS it, v + MAX(ABS(0.7+v*x) - 0.3,
ABS(0.7+v*y) - 0.3, ABS(-1.1+v*z) - 0.3, -((0.7+v*x) * (0.7+v*x) +
(0.7+v*y) * (0.7+v*y) + (-1.1+v*z) * (-1.1+v*z)) * 1.78 + 0.28) AS v
FROM iters JOIN rays ON rays.row = iters.row AND rays.col = iters.col WHERE it < 15),
lastIters AS (SELECT it0.row, it0.col, it0.v AS v0, it1.v AS v1, it2.v AS v2
FROM iters as it0 JOIN iters AS it1 ON it0.col = it1.col AND it0.row = it1.row
JOIN iters AS it2 ON it0.col = it2.col AND it0.row = it2.row
WHERE it0.it = 15 AND it1.it = 14 AND it2.it = 13),
res AS (SELECT col, (v0 - v1) / (v1 - v2) as v FROM lastIters)
SELECT group_concat(
substr('$@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/|()1{}[]?-_+~<>i!lI;:,"^. ',
round(1 + max(0, min(66, v * 67))), 1) || CASE WHEN col=88 THEN X'0A' ELSE '' END, '')
FROM res;

Здесь можно покрутить кубик

Под катом построчный разбор запроса. Как обычно, достаточно знания основ SQL и школьной математики.

Что имеем

Начну с того, что расскажу немного о проекте, в котором работаю и как там все пишется. Может не у одних нас так…

Проект представляет из себя CRM систему, разрабатываемую специально для клиентов одного сегмента бизнеса. Проекту лет 6 и команда разработчиков состоит из 10 человек. Язык: C++ и PL/SQL.

Наша система исползует Plain Old XML, так уж повелось. И на используемые XML нет схем, по большей части. Что тут говорить, если юнит тесты прививаются здесь только второй год и менеджер до сих пор упрекает за время, потраченное на их написание. Да ладно…

По ходу дела все улучшения появляются тогда, когда текущее положение дел порядком надоедает и становится невмоготу. Так же произошло и сейчас.

Как и многие, я думаю, мы многое делаем неоптимально и не лучшим образом. Главное делаем. Пример с XML не исключение.

Сомневался в успешности метода, а также в том, что мой вечно салатовый пиксель, застывший полгода назад и постоянно мозоливший мне глаз, «станет на место». Но…
О чудо, помогло!

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

Это не решение проблемы! Давайте разбираться вместе!

Битые пиксели — один из самых острых вопросов, нередко становящийся поводом для бурного выяснения отношений с поставщиками ЖК-мониторов, планшетов и смартфонов. От этой проблемы зачастую спешат откреститься менеджеры фешенебельных магазинов, ссылаясь на регламент официальных производителей. На том, что такое «битые» пиксели, и как с ними бороться «один на один», мы остановимся в этой статье.

Если вы не в курсе, в Node.js, начиная с версии 7.6, встроена поддержка механизма async/await. Говорят о нём, конечно, уже давно, но одно дело, когда для использования некоей функциональности нужны «костыли», и совсем другое, когда всё это идёт, что называется, «из коробки». Если вы ещё не пробовали async/await — обязательно попробуйте.


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

Часть 1. Введение

Привет меня зовут baldurk. Я уже несколько лет работаю программистом графики, поэтому хоть я и не в коем случае не являюсь экспертом, кажется, я уже многое понимаю во всём том, что касается работы с графикой.

Идея этой серии постов уже давно витала где-то на периферии моего сознания, и снова всплыла после прочтения интересной статьи с разбором последней Deus Ex.

Мне кажется, что графика, и в особенности та сложность, какой она достигает в современных играх — это интересная тема. Очень немногим людям любопытно глубоко погружатьcя во все её подробности, но я считаю, что есть темы, которые интересны каждому. Я думаю, что большинству людей, игравших в игры, было любопытно, как получаются те или иные эффекты, или с помощью какой технологии удалось создать такую потрясающую графику в какой-нибудь новой игре.


Есть много составляющих, необходимых для создания даже простой 3D-игры, не говоря уж о таком проекте, как Watch Dogs.

У меня есть только общее представление о том, что нужно рассмотреть в этой статье, но это будет зависеть от того, какие темы вызовут интерес. Тем не менее, основная идея заключается в том, чтобы создать общее описание того, что происходит внутри современной игры, не отпугнув при этом никого из читателей — я буду предполагать, что у вас нет знаний математики и программирования. Если вы знаете разницу между ЦП и графической картой, и отличаете оперативную память от жёсткого диска, то этого будет вполне достаточно, а остальное я объясню.

Считанные часы остались до Нового 2014-го года, в котором в числе прочего всем нам был обещан новый стандарт C++14. Однако он будет не большим самостоятельным обновлением, а лишь доработкой C++11, багфиксом, который придаст текущей версии языка завершенный вид. На этом фоне Уильям Вонг (англ. William Wong) от ресурса electronicdesign.com взял интервью у Бьерна Страуструпа (дат. Bjarne Stroustrup), создателя C++. Беседа затронула несколько тем: от истории разработки C++ и особенностей стандарта C++11 до проблемы обучения этому языку программирования.

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

В дайджесте «Мира Hi-Fi» поговорим о том, почему в городах растет уровень шума и что мы можем сделать, чтобы сохранить слух и уменьшить шумовое загрязнение.

Последние несколько недель я работал над реализацией алгоритма Форчуна на C++. Этот алгоритм берёт множество 2D-точек и строит из них диаграмму Вороного. Если вы не знаете, что такое диаграмма Вороного, то взгляните на рисунок:


Для каждой входной точки, которая называется «местом» (site), нам нужно найти множество точек, которые ближе к этому месту, чем ко всем остальным. Такие множества точек образуют ячейки, которые показаны на изображении выше.

В алгоритме Форчуна примечательно то, что он строит такие диаграммы за время $$ (что оптимально для использующего сравнения алгоритма), где $$ — это количество мест.

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

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