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

Кашетирование как делали? Или на черном при наложении есть пересветы? :)
Хотя на скетчапе вижу решетки. Тогда вопрос далее, снимаются ли решетки на время рекалибровки и сшивки, обратно опять ручками настраивать?

Хоть и пишу шейдеры и даже достаточно большие и сложные, но то, что в статье — для меня какие-то инопланетные технологии… В целом всё понятно, но… В общем как собака — понимаю, а сказать не могу.
Хотелось бы подобную статью по разбору RTX технологии от майков и как она работает.

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

Для себя предпочел Intel Compute Stick или аналоги. Да, дороже. Да, тоже нет ethernet. Да, wi-fi вообще никакой и usb-ethernet адаптер или нормальный wi-fi stick к нему обязательны. Да необходим air mouse. За то приличный gpu на котором можно даже в minecraft погонять и аппаратная поддержка 4k форматов, «человеческая» операционка и работа с samba шарами без проблем, а не в каком-то только одном приложении. Ставишь 200% масштаб для интерфейса и не промахиваешься. Медиацентров под винду есть, если критично. И все это втыкается в телек сзади через Г-образный переходник hdmi, и нет никаких «соплей», ничего не торчит и не выпирает.

А я просто написал свой плеер с шейдерами и юниформами. :) Но требования у меня были иными, в рамках MPC-HC эти требования не реализовать, например смена соотношения сторон видео с преобразованием Equiangular -> Fisheye и GLSL. Жаль что MPC-HC закрылся, не вижу преимуществ MPC-BE перед первым, оба в последнее время еле-еле развивались.

Она явно не хранится, она создается, когда есть ключевое слово array или string (Delphi). Для плюсов, да, там все прям квадратно и перпендикулярно: sizeof(array)/sizeof(array[0]), хотя вот в векторе скорее всего как в дельфи. Впрочем оставим неизлечимо больного в покое (это я про с++)… Ну а уж в C#-то должно же быть как в дельфи хотя бы… разве нет?
На счет «скрытых» элементов массива не скажу, а вот строки дельфи, например, содержат такие элементы как CodePage, ElemSize, RefCount, ну и наш length. У массивов всё точно так же, за минусом CodePage. Они хранятся по отрицательному смещению от первого элемента строки/массива.
зы Мне кажется я сейчас ещё чуточку больше полюбил Delphi :)

В смысле не в пользу компилятора Delphi?! Тут и компилятор-то не при делах… Это ж как бы логично, что если имеем некий массив, уж без разницы как он реализован, на уровне компилятора (языка), на уровне рукописного класса или класса стандартной библиотеки, то там должна быть (даже обязана быть) переменная 1 штука, которая всегда хранит текущую длину этого массива. При увеличении количества элементов массива на N, увеличиваем переменную длины массива на N. То же самое при уменьшении. Зачем это проходить отладчиком? Строки обязаны быть реализованы точно таким же образом. Я, собственно, именно по этому и был удивлен геттеру получения длины массива, когда вот просто возьми и прочитай эту самую переменную из памяти в регистр. Её адрес или смещение и всё прочее заранее известны компилятору.

Ну так и надо было это отобразить в статье, т.е. показать дизасм дебаг версии. Потому что даже в моём мире Delphi, даже в дебаг версии без оптимизаций, даже при явном указании «якобы функции» len := length(array) нет никаких call в дизасме, регистр напрямую читает длину массива из памяти. Было бы очень странно и как-то даже глупо, если бы в C# было бы по другому. Ну а с геттером — это вообще рукалицо. В смысле прям с геттером, который вызывает целую функцию (уж не спец в C#), а не просто возвращает длину массива.

Геттер у Array.Length? Серьезно? Ну по дизасму же видно, что нет там никакого геттера, это обычная переменная, хранящая длину массива, точно такая же как и у строк и у кучи всего остального и не только в C#…

Ну такое…
Вот тут полноценный тетрис со спец.эффектами целиком на GLSL. (кроме опроса клавиатуры разумеется и инициализации)
www.shadertoy.com/view/4d33Dj

ps. Чтобы поиграть надо закомментировать первый return 0; в Buffer A

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

Это всё прикольно до той поры пока не надо будет запустить VMWare или VBox, т.к. виндовый Hyper-V будет болтаться в памяти как сервис, ну а вышеобозначенное ПО при попытке запуска будет ругаться, что в системе уже запущен некий виртуализатор. По крайней мере при установке родного виндового Hyper-V было именно так.

Всё как обычно… Можно лопатой гвозди забивать, другой вопрос — зачем, если есть молоток. Но у нас отдельным людям виднее. Если точнее, человеку просто очень нравится linux. Но это не подход преподавателя, согласитесь?!..

Ох уж этот извечный спор, что для чего лучше… Могу судить только по себе, ибо вообще начинал с ассемблера z80. Если понимаешь как устроен компьютер изнутри, то с языками высокого уровня вообще проблем не возникает. Помню еще на том же спектруме был и c++ и pascal и балуясь с ними на досуге, написал классическое заполнение экрана #FF, сделал вывод, что по скорости кода pascal опережает местный c++ примерно раз в 5. Ну а тонны скобочек, звездочек и точек с запятыми, идиотски реализованная работа с указателями лишь подогрели мое неприятие плюсов как языка. Сейчас, конечно без проблем могу использовать и его, вопрос лишь в том, что он мне ни разу не пригодился, потому что абсолютно всё можно сделать красиво и сразу с интерфейсом в том же Delphi или Lazarus'е c FPC. Обработка гигабайт эквайринговых выгрузок сбера (текстовые данные) — 20 минут и удобное приложение готово, обработка гигабайт xml выгрузок по организациям, с преобразованием в эксель или бд — полчаса-час максимум (не забываем, что это уже с интерфейсом). Да мне проще работать даже с MS Office из Delphi (обработка таблиц или шаблонов Word), чем из родного VBA. Чем мне заменить для этого Lazarus или Delphi? Ну а учитывая ещё и появившуюся у них кроссплатформенность, вообще считаю бессмысленным заморачиваться на что-то другое… Ну кроме как если отсутствуют биндинги на нужные либы, написанные на плюсах. Ну и скорость компиляции и удобство IDE и отладки, знаете ли, далеко не на последнем месте находятся.

Спасибо за триггер. Удалось сократить этот мрак до вполне осмыслимого:

  v23 := P15.DotProduct(P21) * -2.0 + P15.DotProduct(P15) + P21.DotProduct(P21) - Radius * Radius;

  P18 := P18 - P15;
  v24 := P18.DotProduct(P18);
  P15 := P15 - P21;
  V26 := P15.DotProduct(P18) * 2;
  v27 := v26 * v26 - 4.0 * v24 * v23;

Да и собственно, как вы сказали, название коэффициентов тут не критично.
зы Жаль карма нулевая… Ну и тысяча извинений, человек не был рожден ни математиком, ни программистом, он бы рождён реверсером. *грустный смайлик*

Да, всё как вы сказали. Функция называется RaySphere, просто хотелось бы иметь осмысленные переменные, а не безымянные v23..v27.
Полная функция:

function TWarpData.RaySphere(var a1, a2: Double; Radius: Double; P15, P18, p21: TPoint3D): Boolean;
var
  v23, v24, v25, v26, v27, v29, v30, v31: Double;
begin
  Result := false;

  v23 := P15.DotProduct(p21) * -2.0 + P15.DotProduct(P15) + p21.DotProduct(p21) - Radius * Radius;
  v24 := (P18.Z - P15.Z) * (P18.Z - P15.Z) + (P18.X - P15.X) * (P18.X - P15.X) + (P18.Y - P15.Y) * (P18.Y - P15.Y);
  v25 := (P15.X - p21.X) * (P18.X - P15.X) + (P15.Y - p21.Y) * (P18.Y - P15.Y);
  v26 := (P15.Z - p21.Z) * (P18.Z - P15.Z) + v25 + (P15.Z - p21.Z) * (P18.Z - P15.Z) + v25;
  v27 := v26 * v26 - 4.0 * v24 * v23;

  if (v24 >= 0.0) then
  begin
    if (v24 < 0.00001) then
    begin
      a1 := 0;
      a2 := 0;
      Result := false;
      Exit;
    end;
  end
  else if (v24 > -0.00001) then
  begin
    a1 := 0;
    a2 := 0;
    Result := false;
    Exit;
  end;
  if (v27 >= 0.0) then
  begin
    v30 := sqrt(v27);
    v31 := v24 + v24;
    a1 := (v30 - v26) / v31;
    v29 := (-v26 - v30) / v31;
    Result := true;
  end;
  a2 := v29;
end;

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

  v23 := P15.DotProduct(p21) * -2.0 + P15.DotProduct(P15) + p21.DotProduct(p21) - Radius * Radius;
  v24 := (P18.Z-P15.Z) * (P18.Z-P15.Z) + (P18.X-P15.X) * (P18.X-P15.X) + (P18.Y-P15.Y) * (P18.Y-P15.Y);
  v25 := (P15.X-p21.X) * (P18.X-P15.X) + (P15.Y-p21.Y) * (P18.Y-P15.Y);
  v26 := (P15.Z-p21.Z) * (P18.Z-P15.Z) + v25 +(P15.Z-p21.Z) * (P18.Z-P15.Z) + v25;
  v27 := v26 * v26 - 4.0 * v24 * v23;

15ти ядерный…

Я уже как-то писал тут, что теоретически можно представить экран спектрума и как «прогрессивную развертку» — это 256 байт (2048 пикселей) в ширину и 24 линии в высоту. Просто вот «наломанную» в финале таким образом…
Сколько же неудобств в рисовании графики это в свое время вызывало (при программировании), просто ужас.
Более того был такой компьютер «Profi» и с 512kb и аж с мегабайтом памяти и с процессором на 7 мегагерц. Вобщем — мечта любого мальчугана желавшего именно спектрум. Так вот, работал он и как обычный спектрум, а в режиме CP/M имел разрешение экрана 512x240 точек. Тоесть в 2 раза больше спектрумовского. И мне казалось, ну уж там-то сделали по уму… Ан нет… Оказалось, что там экран рисуется точно так же как и на Спекки и кроме этого там есть еще четные горизонтальные байты и нечетные и сначала заполняются нечетные, потом четные. Вот где настоящий ад!