MonkAlex

Wix

Честные порталы делать очень сложно, нужно хорошо понимать физику и весь пайплайн рендера. Есть очень много граничных случаев, каждый из которых нужно отдельно поддерживать: портал внутри портала, пересечение границ внутреннего и внешнего портала, несколько внутренних порталов, повороты плоскости портала, перемещение предметов, тени и освещение, прозрачные материалы и т. п. Есть две основные техники реализации отрисовки порталов: через рендер текстуры и стенсильный буфер.

Порталы на рендер текстурах делаются проще, но они дороже по производительности, даже на простой геометрии несколько порталов могут оказаться непосильной задачей для компьютера. Основной принцип следующий: когда вы смотрите на портал, на другой стороне портала камера рисует картинку в текстуру, эта текстура натягивается на плоскую геометрию, и со стороны кажется, будто бы через дырку видно другую часть сцены. Примитивную реализацию такой схемы можно собрать руками в редакторе, но дальше начинаются сложности. Если у конечного портала "за спиной" будет геометрия, она попадёт во вьюпорт камеры и будет странно смотреться. Чтобы это предотвратить нужно ближнюю плоскость отсечения у камеры сдвигать в плоскость портала с помощью CalculateObliqueMatrix. Для вычисления положения камеры и пересчёта матрицы есть удобный колбэк OnRenderObject. После корректировки матрицы порталы будут смотреться более-менее корректно, но будут всплывать всевозможные косяки при перемещении через плоскость портала из-за буфера глубины и nearClipPlane основной камеры.

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

Прошу заметить, что всё вышесказанное касается чисто графической части, для простейшего случая, когда мы имеем FPS камеру без анимаций, без дополнительных механик, которая просто ездит по уровню и может заглядывать в порталы. Что уж говорить про миллион потенциальных багов, если вы захотите включить рядом с порталом систему частиц или взять в руки кубик. Посему советую либо купить плагин и довольствоваться тем, что он умеет, либо приготовиться потратить несколько месяцев на разработку своей портальной системы. И в том и другом случае ограничения движка не позволят вам в разумные сроки получить Portal, в лучшем случае это будет Narbacular Drop.

1) алгоритмы сжатия изпользуют доп. память для генерации словарей. Размер словаря будет зависеть как от алгоритма сжатия, так и от данных которые надо сжать.
2) для того чтоб освободить память от кучи хлама - можно сделать GC.Collect для инициализации сборщика мусора. В данном случае прийдеться делать GC.Collect(2), что достаточно дорогая операция.

кроме того, следует помнить про нюансы сборки мусора для LOH. В отличии от SOH, для LOH не будет проводиться дефрагментация данных в памяти, а CLR будет просто пытаться переиспользовать освободившиеся куски. Потому вполне возможна ситуация когда память в куче вроде как есть, но CLR продолжает ее выделять для новых обьектов.

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

switch case ищет соответствие переменной string и ее возможное значение в case. Что вы хотите сопоставить? Что в переменной string хранится какое-то регулярное выражение? Или что string соответствует одному из регулярных выражений? Если второе, то ваш путь if else if.

И там и там можно не задавать, нужно понимать что вы хотите сделать.

using System;

public class Test<T>
{
    // Перед вызовом конструктора выставится в default(int), то есть 0 
    private int i;

    // Для ссылочного типа default(object) будет null
    private object obj;

    // default(T)
    private T t;

    public Test()
    {
        // Не инициализированная переменная
        int foo;

        // error CS0165: Use of unassigned local variable 'foo'
        Console.WriteLine(foo.ToString());

        foo = 0;

        // У foo появилось значение, теперь переменной можно пользоваться
        Console.WriteLine(foo.ToString());

        int bar;

        // error CS0165: Use of unassigned local variable 'bar'
        Ref(ref bar);

        // Для ref нужна инициализированная переменная
        Ref(ref foo);

        // Для out не нужна
        Out(out foo);
        Out(out bar);
    }

    private void Ref(ref int r)
    {
        r = 0;
    }

    private void Out(out int o)
    {
        o = 0;
    }
}

Подробнее читайте в MSDN здесь и здесь.

В общем меня это сводит с ума и я не понимаю, неужели все сводится к тому,чтобы брать и гуглить?

Данная методология программирования называется Stack Overflow Driven Development, и практикуется даже программистами экспертного уровня.

Я бы сделал это при помощи сериализации (класс BinaryFormatter).

Создаём класс, который содержит картинку и текст, пихаем туда твою картинку и текст, сериализуем всё это при помощи BinaryFormatter.Serialize( ) в MemoryStream, получаем из него массив байт.

При получении массива байт, создаём MemoryStream из массива, десериализуем из него при помощи BinaryFormatter.Deserialize( ) - получаем класс с нашей картинкой и текстом

Вопрос в том, в каком потоке вызывается эта функция.
Вместо this.Invoke поставьте Dispatcher.BeginInvoke.

Передавайте id первого процесса как параметр при запуске второго. Тогда второй сможет найти родительский процесс по этому id и ждать, пока он не завершится.