Одним из нововведений Visual Studio 2012 сопутствовало явление народу нового кастомизируемого отладчика под названием «Concord». Его компонентная система позволяет VSIX-плагинам подстраивать под себя поведение отладчика и писать новые, контекстно-зависимые, инструменты, которые могут эксплуатировать отладчик для своих нужд. Его API предоставляет множество QOL фич, таких как маршалинг между управляемым/неуправляемым кодом, бесшовная интеграция с удалённо/локально отлаживаемым процессом, и не только. По сути, практически всё, что можно сделать в IDE, можно сделать программно, используя Concord API! Менять на лету значения конкретных переменных, вызывать по заказу функции (или специально заставлять программу пропускать вызовы оных!), плагинам доступен поиск по PDB (!), пошаговый обход и даже модификация кода! Открой кат, и ты узнаешь об этих малоизвестных инновациях в области велосипедостроения.

Алгоритм воронки — это простой алгоритм поиска наипростейшего пути, проходящего через «порталы». Наиболее подробное описание можно найти по ссылке Efficient Triangulation-Based Pathfinding (2)
Здесь же этот алгоритм будет реализован до одури просто. Вместо использования очередей и прочих очешуительных вещей, наша простейшая реализация перезапускает цикл каждый раз, когда обнаруживает очередной угол. Это значит, что некоторые порталы будут опрашиваться таки чаще, чем должны были бы, тем не менее, делая реализацию всяко проще.

Логичным дополнением к прошлой статье был-бы наглядный пример, хотя-бы для того, чтобы показать что не так страшен чёрт, как его рисуют, и на самом деле даже если вам необходимо собрать инициализатор массива через Reflection.Emit, то большинство лишних телодвижений возьмёт на себя API, а от вас остаётся, по большей части, только слизать придуманный компилятором код из прошлой статьи. В этом примере я ограничусь простым статическим массивом на 3 System.Int32 элемента.

Наверняка почти каждому, кто имел дело с C#, известна подобная конструкция:

int[] ints = new int[3] { 1,2,3 };//А если уж вдруг и не была известна, то отныне и впредь уж точно

Вполне логично было-бы ожидать превращение этой конструкции в нечто подобное:

int[] ints = new int[3]; 
ints[0] = 1; 
ints[1] = 2; 
ints[2] = 3;

Увы и ах, на деле орех гораздо более морщинист, чем кажется с первого взгляда, и имеются некоторые тонкости, на которые будет указано позже. А до тех пор, наденем ношеную «IL freak» майку (у кого имеется) и погрузимся в недра реализации.

Что такое «Инверсная кинематика»?

Задачей инверсной кинематики является поиск такого набора конфигураций сочленений, который обеспечил бы максимально мягкое, быстрое и точное движение к заданным точкам. Однако, множество существующих ныне методов страдают от таких недостатков как высокая вычислительная сложность и неестественность результирующих поз. В этой статье описан новый (вероятно, на момент написания статьи — 2010 г.) эвристический метод под названием «Метод прямого и обратного следования» ( Forward and Backward Reaching Inverse Kinematics, далее просто FABRIK),
FABRIK избегает использования вращений и матриц в пользу непосредственного получения точки на прямой. Благораря этому, дело обходится всего несколькими итерациями, имеет низкую стоимость вычислений и визуально естественную позу в результате. FABRIK так-же без проблем справляется с наложением ограничений а так-же использованием нескольких цепей и/или конечных точек. Именно об этом методе этот пост.

Никогда не приходил в голову вопрос: "а как сохранить/передать в другой поток ссылку на поле?"? Логичным предположением будет «передам ref в метод и сохраню. Стоп, oh shi~». Да, ref не сохраняются (а ещё, нельзя использовать на них замыкания, так что создать функцию внутри такого метода и создать из её поток тоже не получится). Но зато можно превратить ref в TypedReference с помощью недокументированного ключевого слова __makeref. Увы, TypedReference нельзя напрямую сохранить в поле и не наследует от System.Object, так что каст привычными методами тоже невозможен (да и вообще на их использование наложена целая куча ограничений). Казалось бы, тупик. Но это ещё не всё — есть ещё RuntimeArgumentHandle, который обладает свойствами TypedReference, за одним исключением — после хитрого каста в System.Object его ещё можно использовать до тех пор, пока жив кадр стека, в котором он был создан. Об этом этот пост.

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

В последнее время я стал все больше и больше интересоваться функциональным программированием, и при выборе языка предо мною пал выбор среди двух очень понравившихся мне языков — Haskell и F#.
В F# меня соблазнило то, что его можно компилировать в MSIL сборки, что обеспечивает возможность использования библиотек классов F# в других языках Microsoft .Net, а также то, что он и сам может их использовать. Ко всему прочему, я ещё и начинающий разработчик Unity3D, и мне в голову пришла мысль: если компилируется в MSIL, то может можно использовать F# скрипты в Unity? Гугление дало ответ: по-человечески нельзя. Можно создать библиотеку классов, поставить в проекте ссылки на библиотеку UnityEngine.dll, компилировать и импортировать как ассет, после чего добавлять компоненты Mono-behaviour напрямую из библиотеки, но это не слишком удобно, согласитесь. Однако, пройдя гугл, Reflection и справку по Unity, мне все таки удалось приблизить(но не повторить в точности) работу с F# скриптами внутри редактора к тому виду, в котором производится работа со скриптами на встроенных языках. Подробности — под хабракатом.