В предыдущем уроке был дан обзор основам реализации физически правдоподобной модели рендеринга. В этот раз мы перейдем от теоретических выкладок к конкретной реализации рендера с участием непосредственных (аналитических) источников света: точечных, направленных или прожекторного типа.
В C++/CLI достаточно часто используются так называемые классы-дескрипторы — управляемые классы, имеющие указатель на родной класс в качестве члена. В статье рассматривается удобная и компактная схема управления временем жизни соответствующего родного объекта, основанная на использовании управляемых шаблонов. Рассмотрены сложные случаи финализации.
PBR, или физически-корректный рендеринг (physically-based rendering) это набор техник визуализации, в основе которых лежит теория, довольно хорошо согласующаяся с реальной теорией распространения света. Поскольку целью PBR является физически достоверная имитация света, он выглядит гораздо более реалистичным по сравнению с использованными нами ранее моделями освещения Фонга и Блинна-Фонга. Он не только лучше выглядит, но и дает неплохое приближение к реальной физике, что позволяет нам (и в частности художникам) создавать материалы, основанные на физических свойствах поверхностей, не прибегая к дешевым трюкам дабы заставить освещение выглядеть реалистично. Главным преимуществом такого подхода является то, что создаваемые нами материалы будут выглядеть как задумано независимо от условий освещения, чего нельзя сказать о других, не PBR подходах.
В своём выступлении на CppCon 2018 Herb Sutter представил общественности свои наработки по двум направлениям. Во-первых, это контроль времени жизни переменных (Lifetime), который позволит обнаруживать целые классы багов на этапе компиляции. Во-вторых, это обновлённый proposal по метаклассам, которые позволят избежать дублирования кода, один раз описывая поведение категории классов и потом подключая его к конкретным классам одной строчкой.
В C++ программист должен сам принимать решения о том, как будут освобождаться используемые ресурсы, автоматических средств типа сборщика мусора нет. В статье рассмотрены возможные варианты решения этой задачи, детально рассмотрены потенциальные проблемы, а также ряд сопутствующих вопросов.
Виртуальные машины языков программирования в последние десятилетия получили весьма широкое распространение. С презентации Java Virtual Machine во второй половине 90-х прошло уже достаточно много времени, и можно с уверенностью сказать, что интерпретаторы байт-кодов — не будущее, а настоящее.
Но данная техника, на мой взгляд, практически универсальна, и понимание основных принципов разработки интерпретаторов пригодится не только создателю очередного претендента на звание "Язык года" по версии TIOBE, но вообще любому программисту.
Словом, если вам интересно узнать, как складывают числа наши любимые языки программирования, о чём до сих пор спорят разработчики виртуальных машин и как безболезненно сопоставлять строки и регулярные выражения, прошу под кат.
В предыдущей статье имел наглость использовать CLion в качестве IDE. И тут же прибежал человек с вопросом: ой, проприетарная платная поделка, продался, зажрался, итп. Справедливости ради, на Хабре такой комментарий был всего один, но в реальности их тысячи. Например, крайний действующий аккаунт на ЛОРе, у меня зарегистрирован с 2010 года, и в почти каждой дискуссии с участием какого-то несвободного софта начинается этот ад. Понятно что никому я ничего не докажу, но редким бредущим мимо может помочь.
Статья условно делится на две части: социально-мотивационная и техническая (как собирать CMake в Windows под различными IDE).
Только что пришла в голову мысль — нужно найти какое-то хобби. Иначе с катушек можно съехать. А поскольку я весьма бесполезный человек, ничего кроме как тыкать кнопки не умеющий, хобби будет такое: не реже раза в неделю устраивать стрим с написанием игрушки. После стрима запись публикуется на Хабре. (Можно попробовать постить на Хабр прям лайв, но это сильно сложней).
Написание очень feedback driven — если кому-то нужны пояснения, то я могу пояснить как смогу. Если есть предложения — постараюсь учитывать. На хабре читаются все комментарии до последнего, в других местах — как получится.
Первый блин комом вот здесь:
Под катом — тезисное описание для тех, кому справедливо влом тратить на просмотр полтора часа.
После того как с помощью Arm Mbed OS удалось помигать светодиодом, настало время протестировать и настроить другие важные сервисы. Далее рассказывается:
#include <windows.h>
int x = 0, y = 1;
int* ptr;
DWORD CALLBACK ThreadProc(void*)
{
Sleep(1000);
ptr = &y;
return 0;
}
int main(int, char**)
{
ptr = &x; // starts out pointing to x
DWORD id;
HANDLE hThread = CreateThread(nullptr, 0, ThreadProc, 0, &id);
// Ждём, пока другой поток изменит значение по указателю ptr
// на некоторое ненулевое число
while (*ptr == 0) { }
return 0;
}
Цель моего поста — рассказать о C++ API распределенной базы данных Apache Ignite, который называется Ignite C++, а также о его особенностях.
О самом Apache Ignite на хабре писали уже не раз, так что наверняка некоторые из вас уже примерно представляют, что это такое и зачем нужно.
Не буду вдаваться в подробности о том, как появился Apache Ignite и чем отличается от классических баз данных. Все эти вопросы уже поднимались тут, тут или тут.
Итак, Apache Ignite — это по сути быстрая распределённая база данных, оптимизированная для работы с оперативной памятью. Сам Ignite вырос из дата грида (In-memory Data Grid) и до недавнего времени позиционировался как очень быстрый, находящийся полностью в оперативной памяти распределённый кэш на основе распределенной хэш-таблицы. Вот почему, кроме хранения данных, в нем есть множество удобных фич для их быстрой распределенной обработки: Map-Reduce, атомарные операции с данными, полноценные ACID транзакции, SQL запросы по данным, так называемые Continues Queries, дающие возможность следить за изменением определённых данных и другие.
Однако недавно в платформе появилась поддержка постоянного хранилища данных на диске. После чего Apache Ignite получил все преимущества полноценной объектно ориентированной базы данных, сохранив при этом удобство, богатство инструментария, гибкость и быстроту дата грида.
void FuncToDealWith() {
InCurrentThread();
writerQueue.PushTask([=]() {
InWriterThread1();
const auto finally = [=]() {
InWriterThread2();
ShutdownAll();
};
if (NeedNetwork()) {
networkQueue.PushTask([=](){
auto v = InNetworkThread();
if (v) {
UIQueue.PushTask([=](){
InUIThread();
writerQueue.PushTask(finally);
});
} else {
writerQueue.PushTask(finally);
}
});
} else {
finally();
}
});
}