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

Одной из самых интересных функций этого релиза является преобразование клеткой. Оно позволяет изменять форму объектов без внесения искажений в изображение. О нем и пойдет сегодня речь…

Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Update:

Внимание, статья 4в даёт новую, более простую версию растеризатора.

Давайте знакомиться, это я.



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

В прошлый раз мы нарисовали проволочную сетку трёхмерной модели, в этот раз мы зальём полигоны. Точнее, треугольники, так как OpenGL практически любой полигон триангулирует, поэтому ни к чему разбирать сложный случай. Напоминаю, что этот цикл статей создан для самостоятельного программирования. Время, которое я здесь привожу — это не время чтения моего кода. Это время написания вашего кода с нуля. Мой код здесь только для того, чтобы сравнить ваш (рабочий) код с моим. Я совсем не являюсь хорошим программистом, поэтому ваш код может быть существенно лучше моего. Любая критика приветствуется, любым вопросам рад.

Пожалуйста, если вы следуете этому туториалу и пишете свой код, выкладывайте его на github.com/code.google.com и им подобные и давайте ссылки в комментариях! Это может хорошо помочь как и вам (другие люди могут чего посоветовать), так и будущим читателям.

Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Постановка задачи

Цель этого цикла статей — показать, как работает OpenGL, написав его (сильно упрощённый!) клон самостоятельно. На удивление часто сталкиваюсь с людьми, которые не могут преодолеть первоначальный барьер обучения OpenGL/DirectX. Таким образом, я подготовил краткий цикл из шести лекций, после которого мои студенты выдают неплохие рендеры.

Итак, задача ставится следующим образом: не используя никаких сторонних библиотек (особенно графических) получить примерно такие картинки:



Внимание, это обучающий материал, который в целом повторит структуру библиотеки OpenGL. Это будет софтверный рендер, я не ставлю целью показать, как писать приложения под OpenGL. Я ставлю целью показать, как сам OpenGL устроен. По моему глубокому убеждению, без понимания этого написание эффективных приложений с использованием 3D библиотек невозможно.

Здравствуйте, меня зовут Дмитрий Карловский и я… много думал. Думал я о том, что не так с XML и почему его в последнее время променяли, на бестолковый JSON. Результатом этих измышлений стал новый стандарт формат данных, который вобрал в себя гибкость XML, простоту JSON и наглядность YAML.

Tree — двумерный бинарно-безопасный формат представления структурированных данных. Легко читаемый как человеком так и компьютером. Простой, компактный, быстрый, выразительный и расширяемый. Сравнивая его с другими популярными форматами, можно составить следующую сравнительную таблицу:

Больше — лучше	JSON	XML	YAML	INI	Tree
Человекопонятность	3	1	4	5	5
Удобство редактирования	3	1	4	5	5
Произвольная иерархия	3	3	3	1	5
Простота реализации	3	2	1	5	5
Скорость парсинга/сериализации	3	1	1	5	5
Размер в сериализованном виде	3	1	4	5	5
Поддержка поточной обработки	0	0	5	5	5
Бинарная безопасность	3	0	0	0	5
Распространённость	5	5	3	3	0
Поддержка редакторами	5	5	3	5	1
Поддержка языками программирования	5	5	3	5	1

Здравствуйте!

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

И вот на тебе! Пробка… А ехать еще и ехать. Путь не близкий, с учетом пробки — это не менее 3 часов до дома.
Ну, соответственно: подбадриваю себя, что, мол, дома ужин, чай, снег за окном. И вроде настроение возвращаться начинает, как внезапно с правой полосы Toyota Prius (ну, знаете такой — на батарейках весь), включает левый поворот и лезет прямо перед моей машиной… «Хорошо, дружище! Езжай, все равно вместе стоять 3 часа.» Встроился, проехал два метра и встал. Как положено на дороге в пробке, зафиксировался тормозом.

В жизни ардуинщика рано или поздно наступает момент, когда в штатной среде разработки становится тесно. Если скетчам перестает хватать памяти, требуется жесткий реалтайм и работа с прерываниями или просто хочется быть ближе к железу — значит пришло время переходить на C. Бывалые электронщики при упоминании Arduino презрительно поморщатся и отправят новичка в радиомагазин за паяльником. Возможно, это не самый плохой совет, но мы пока не будем ему следовать. Если отбросить Arduino IDE и язык wiring/processing, у нас в руках останется прекрасная отладочная плата, уже оснащенная всем необходимым для работы микроконтроллера. И, что немаловажно, в память контроллера уже зашит бутлоадер, позволяющий загружать прошивку без использования программатора.

SageMathCloud (сокращённо SMC) — это онлайновый сервис, в котором можно написать математический или любой другой расчёт в Sage или IPython Notebook. Расчёт можно комбинировать с HTML, CSS, JavaScript, CoffeeScript, Go, Fortran, Julia, Gap, Axiom, R, Ruby, Perl, Maxima, Maple, Markdown, Wiki (и это неполный список!). При редактировании поддерживается мультикурсорность, можно включить биндинги Vim или Sublime Text. Пользователю также доступна консоль Ubuntu и доступ к проекту по ssh. Можно создавать документы LaTeX и встраивать в них код на Python, который не будет отображаться в итоговом pdf. Широкие возможности позволяют написать не просто расчёт с 2D и 3D графикой, а целое интерактивное приложение или собственный веб-сервер на Flask. Можно расшарить расчёт пользователям на редактирование, и Вы будете видеть, что они меняют и даже где стоит их курсор! При этом великолепии SageMathCloud имеет открытый исходный код, который выложен на Github.

1. Введение

В этой статье я попытаюсь исследовать и развенчать пять популярных мифов про C++:

1. Чтобы понять С++, сначала нужно выучить С
2. С++ — это объектно-ориентированный язык программирования
3. В надёжных программах необходима сборка мусора
4. Для достижения эффективности необходимо писать низкоуровневый код
5. С++ подходит только для больших и сложных программ

Если вы или ваши коллеги верите в эти мифы – эта статья для вас. Некоторые мифы правдивы для кого-то, для какой-то задачи в какой-то момент времени. Тем не менее, сегодняшний C++, использующий компиляторы ISO C++ 2011, делает эти утверждения мифами.

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

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

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

Так уж случилось, что игры я писал лишь для себя, и профессионально этим никогда не занимался.
А вот опыт писать DSL (Domain Specific language) для уменьшения рутины написания совершенно разного кода хоть какой-то есть.
Именно этим и хочется поделится: как упорядочить необъятное.



Наш хороший хабр-юзер GlukKazan пишет много статей о том какие есть замечательные продукты для создания различных досочных игр. Такие как Zillions of Games и Axiom Development Kit.
Однако эти программы не универсальны. И всегда хочется улучшить их. Но данные продукты не свободны, поэтому приходится писать программный продукт заново.
GlukKazan работает над открытым проектом Dagaz, о чём делится отличными статьями (например тут: Dagaz: Новое начало).

Итак, предположим, мы хотим создать универсальный игровой движок для настольных игр, и его основой мы хотим видеть скриптовый язык, который помогает растолковать движку правила игры.
Каким мы хотим его видеть?
1) Язык должен быть универсальным, насколько можно, дабы описать почти любые правила игры.
2) Тем не менее, язык должен быть как можно проще, минимум конструкций.
3) Описание правил должны быть легки для чтения игроделу и для написания своих игр
4) Для большинства случаев игры можно писать, дополняя/изменяя уже написанные
5) Коммуникация (АПИ) со скриптом должна быть насколько простой, насколько это возможно. Так, что бы можно легко писать ботов и ИИ.
На первый взгляд кажется, что потраченные усилия вообще никому не нужны будут, поскольку рутину не уменьшить, проще писать игры сразу готовыми.
Но это не так.
Всё куда проще!

Сигналы и слоты используются для коммуникации между объектами. Механизм сигналов и слотов главная особенность Qt и вероятно та часть, которая отличаетcя от особенностей, предоставляемых другими фреймворками.

Эта статья — последняя из серии моих хабрастатей о фракталах. В хабрастатье «Рисуем картинки с помощью кривой Гильберта» рассказывалось о котёнке по имени Гав, в хабрастатье «Кош на комплексной плоскости» — о перетекании фракталами в горизонт, в хабрастатье «Ночь фракталов» — об алгоритме времени убегания. В этой статье пойдёт речь о ёжике в тумане и, конечно же, о коте.

В какой-то из весенних дней этого года я ехал в троллейбусе и листал комикс о Коше. В одном из выпусков была такая фраза «НО! Её можно понять, она же фракталами в горизонт перетекает, я бы тоже замешкался...». После этого я посмотрел в окно и понял, что если мы возьмём два подходящих дробно-линейных преобразования комплексной плоскости a(z) и b(z), и рассмотрим систему итерированных функций для a(z), b(z), a⁻¹(z), b⁻¹(z), взяв в качестве начального множества картинку с Кошем, то Кош будет перетекать фракталами в горизонт!

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

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

В субботу на прошлой неделе «дело было вечером, делать было нечего», и мы с хабраюзером sourcerer разговаривали не понятно о чём. И почему-то речь зашла речь о задаче обратной к задаче построения графика функции по её выражению. То есть, например, у нас есть выражение y(x) = (cos^0,5x ⋅ cos 200x + |x|^0,5 − 0,7)(4 − x²)^0,01. График такой функции чем-то напоминает сердечко. Но нам был интересен обратный вопрос, как, имея, например, изображение сердечка, получить выражение для функции, графиком которой будет это самое сердечко.

Какие-нибудь ряды Фурье вспоминать не хотелось, а хотелось чего-то простого и красивого. Мы начали вспоминать известные нам результаты, связанные с этим вопросом. В результате получилась программка, которая по изображению генерирует ломаную линию, чем-то напоминающую исходное изображение. На примере котёнка по имени Гав это выглядит примерно так (смотреть лучше издалека):



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

Под термином «системный вызов» в программировании и вычислительной технике понимается обращение прикладной программы к ядру операционной системы (ОС) для выполнения какой-либо операции. Ввиду того что такое взаимодействие является основным, перехват системных вызовов представляется важнейшим этапом встраивания, т.к. позволяет осуществлять контроль ключевого компонента ядра ОС — интерфейса системных вызовов, что, в свою очередь, даёт возможность инспектировать запросы прикладного ПО к сервисам ядра.

Данная статья является продолжением анонсированного ранее цикла, посвящённого частным вопросам реализации наложенных средств защиты, и, в частности, встраиванию в программные системы.

Возник на днях у нас вопрос: «Как спрятать от любителей hex-редаторов строчки текста в скомпилированном приложении?». Но спрятать так, чтобы это не требовало особых усилий, так, между прочим…
Задача состоит в том, что бы использовать в коде строки как обычно, но при этом в исполняемом файле эти строки в явном виде не хранились, возможности сторонних утилит, которые работают с уже скомпилированными бинарными файлами, задействовать так же не хочется, все нужно делать из обычного C++ кода.

Компания, где я работаю, разрабатывает программное обеспечение на C++ под Linux. Долгое время мы использовали Qt Creator, с редкими ребятами работающими из Emacs и Vim. Когда я сам попытался пересесть на Vim, я понял, что ситуация с плагинами для разработки на С++ очень не простая. Поработав немного с CTags, я быстро понял, что без напильника работать в Vim будет очень сложно.
К сожалению, с ростом опыта работы с Vim редактор в Qt Creator в режиме эмуляции устраивал меня все меньше, и в какой-то момент я решил потратить немного времени и разобраться, как же сделать из Vim нормальную среду.
Я очертил для себя четыре вещи, которые я бы хотел от среды разработки, и которых мне бы хватило в Vim, чтобы полностью на него перейти:

1. Автодополнение
2. Навигация по коду
3. Отладка прямо из среды
4. Интеграция с Git (в частности Blame прямо в редакторе, и Git Grep)

Автодополнение в Vim — это решенная проблема, и название у решения YouCompleteMe. Это очень качественный плагин, который реализует автодополнение для большого количества языков программирования, в частности Python и C++. Ходят слухи, что внутри Google YouCompleteMe решает и вторую проблему с навигацией кода, но использует для этого внутренные инструменты гугла для индексирования.

Интеграция с Git в какой-то степени решена с помощью vim-fugitive. Это не такая комплексная интеграция, как бывает у Jet Brains, или в Visual Studio, но сравнимая с тем, что предлагает Qt Creator. Те два сценария, которые нужны были мне: blame и grep — работают хорошо.

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

Вступление

В январе 2015 года исполняется 10 лет приложению Openbravo POS. За эти годы Openbravo POS(включая форки) стало лидером в мире СПО для автоматизации розничной торговли (POS, Point of Sale – торговая точка или более конкретно, рабочее место кассира). Данная статья предварительный итог того, что удалось и не удалось реализовать в проекте Openbravo POS за прошедшие 10 лет.

История имени

Отцом основателем, бессменным руководителем и практически единоличным коммитером проекта был Эдриан Ромеро из Испании. У проекта изначальное название с 2005 по 2007 год было Tina POS, но в августе 2007 года возник конфликт с этой торговой маркой и пришлось переименовать проект в Libre POS. В отличии от первого, второе название не продержалось и пол года, так как Эдриан перешёл работать в Openbravo и первая часть названия была «забрендирована», оставив от старого только «POS» на конце, что подчёркивало с этого момента принадлежность проекта к экосистеме данной ERP-системы в качестве дополнения в сфере розничной торговли. Также в феврале 2008 года вышла и первая версия Openbravo POS сразу за номером 2.00.

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



Тех, кто понимает смысл процедуры EUI-48 -> EUI-64 -> Modified EUI-64, статья вряд ли обогатит новыми знаниями. Остальные – добро пожаловать под кат.

Картинка, которая некоторых привыкших к IPv4 сетевиков может ввести в ступор:

    R6#sh ipv6 interface brief
    FastEthernet0/0            [up/up]
        FE80::218:18FF:FE45:F0E2
        1::1
        1::2
        1::3
        1::10
        1::100:500
        2::1
        2::2

Причём каждый из этих адресов может быть использован наравне с другими. Как так?