SR64 (тестирование) (2 стр)

Падает при попытке включить SSAA, а так всё работает. Выглядит симпатично.
Скорость с начальной сценой около 130 fps на ноутбуке с i5-4210U, разрешение 1366*768.

Может будет полезно - конкурс софтрендеров:
https://gamedev.ru/projects/forum/?id=215799
(и кстати там сопоставимая скорость на тысяче текстурированных кубов против 128 с освещением)
Ещё в этой ветке обсуждали проблемы софтрендеров:
https://gamedev.ru/code/forum/?id=233033&page=19

invis
> Падает при попытке включить SSAA
Печалька. Даже не знаю что там может глючить.
У меня все нормально в любом разрешении: от 320×200 до 2560×1600.

Спасибо за тест.

>сопоставимая скорость
Смотрел их софтрендеры. Там по другому сделано — текстура без динамического освещения.
У меня динамическое освещение + шейдерная система почти как в GL + барицентрический треугольник + кулинг + перегрузка сканлиний. В общем все очень сложно и универсально.
CPU от таких расчетов просто «подыхает». С тенями вообще тормоза :)
По условиям их конкурса у меня 120 fps в 1600×900 с динамическим освещением.
С текстурами (без динамики) будет в районе 160 fps.

В стартовой сцене у меня 290 fps при таком (1366*768*32) разрешении.
2560×1600 - 90 fps.
И это на одном ядре.

А текстуры у тебя есть? Не вижу где включить. Также Z-сортировка и тени не включаются.

Мне кажется, текстурирование это как минимум не меньшая нагрузка, поскольку считается попиксельно и требует деления, если оно перспективно-корректное. А освещение у тебя повертексное.

Освещение вертексное, а просчет пиксельный - интерполяция. Деление в каждом пикселе.
Если сделать фрагментный шейдер - ЦПУ «умрет». Очень медленно получается.
CPU пока на такие нагрузки не расчитан.

Z-Сортировка активируется с прозрачностью.

У меня векторный расчет цвета - это тяжелее чем расчет текстурных координат.
Текстуры у меня быстрее работают. Пока не активировал. Позже выложу.

Интерполяцию цвета можно делать уже в целых числах, по сути это тот же альфаблендинг в 2D. Никакого деления там точно не нужно. А если уж считать в плавающей точке, то интерполировать нормаль и делать попиксельное освещение по Фонгу. Собственно освещение - это же dot вектора нормали с вектором света, ну ещё умножение на яркость, вроде ничего очень тяжёлого.
А с текстурированием нужно ещё собственно выбирать цвета из текстуры, тоже нагрузка.

Можешь посмотреть пример TexCube отсюда:
https://sourceforge.net/projects/tfastdib/files/Library/FastDIB%2… .zip/download
Там и блендинг, и текстурирование на твоём любимом ассемблере и Дельфи.

invis
Спорить не буду.

TexCube vs SR64:

асм есть асм.

Ну там же текстурирование (с билинейкой по умолчанию) и ещё прозрачность, а ты сравниваешь фактически с заливкой цветом (расчёт освещения в 8 вершинах можно не считать). В TexCube твоего режима нет, хотя можно доделать ради интереса.
Я имел в виду, что интерполяцию цвета по треугольнику можно сделать слегка модифицировав функцию альфа-блендинга (поскольку и то, и то - смешение двух цветов с коэффициентом), например из FastDIB, но можешь и сам написать.

Уточню, что я подразумевал заполнение треугольника методом построчного сканирования по рёбрам, а не через барицентрические координаты.
Здесь это называется Scanline fill:
https://www.rose-hulman.edu/class/csse/csse351/m10/triangle_fill.pdf
Здесь Edge Walking:
https://www.digipen.edu/sites/default/files/public/docs/theses/sa… asterizer.pdf

invis
> Интерполяцию цвета можно делать уже в целых числах
Это давно не актуально. Float уже давно быстрее integer.
Только если через сдвиг. Тогда будет быстрее.

invis
> ты сравниваешь фактически с заливкой цветом
У меня нет заливки. Каждый пиксел так считается:

Я как раз о том, что можно считать проще, с Edge Walking интерполяция между двумя значениями, а не тремя.
А смысл использования целых в том, что их (16-битных) больше влезает в SIMD-вектор, можно по 2-4 пикселя считать.

Видел статью про умножение матриц на Хабре, смотрю, насовали минусов за игнорирование сишных наработок. И справедливо.
В ветке "SIMD оптимизации", на которую я давал ссылку, обсуждали и матрицы. Есть например такой вариант вообще без ассемблера:
https://godbolt.org/z/faAsiz
30 строк против 100 твоих, это avx2 + fma. Но даже если включить -msse2, будет 70 строк, всё равно короче. И кстати, компилятор при этом использует шаффлы, а не инсерты - то есть знает ассемблер лучше тебя.
Если скинешь тестовый пример, я могу собрать сишный код, прицепить его как obj или dll и сравним.

invis
> Видел статью про умножение матриц на Хабре
Просто поделился кодом на чистом асме + Delphi.
В других вариантах там только C++ и интерсинки.

>смотрю, насовали минусов за игнорирование сишных наработок. И справедливо.
Это местные тролли. Они невменяемые. Кроме того я не пишу на C++, о чем сказал сразу.
Но навязывание не прекратилось. Поэтому нет - не справедливо. Не нравится - пройди мимо. Не гадь.

>avx2 + fma
Не в каждом процессоре есть данные технологии.

>И кстати, компилятор при этом использует шаффлы, а не инсерты -
>то есть знает ассемблер лучше тебя.
Вы тоже считаете, что транспонировать нужно используя shufps?

eDmk
> Кроме того я не пишу на C++, о чем сказал сразу.
Ну я бы например постеснялся так огораживаться - "пишу на Дельфи, больше ничего не знаю и знать не хочу". С точки зрения хабраюзеров это тоже вполне себе троллинг. Особенно если статья про что-то претендующее на высокую производительность, которая сейчас однозначно ассоциируется с Си.
eDmk
> Не в каждом процессоре есть данные технологии.
В вашем есть. В моём ноутбучном haswell тоже есть, а хасвеллу 6 лет уже.
Ну и повторю, что даже с sse2 сишный компилятор даёт более короткий код.
eDmk
> Вы тоже считаете, что транспонировать нужно используя shufps?
Шаффлом можно тасовать элементы из 2-х регистров, наверное при определённой ловкости рук можно и транспонировать. Но нужно ли?
Вон по той ссылке, которую вам давали
https://habr.com/ru/post/359272/
первый этап оптимизации - перестановка местами внутренних циклов. В результате получается что-то такое:

procedure MulMatrixC(Const A, B: TMatrix4; Var C: TMatrix4);
Type
  PArray = ^TArray;
  TArray = array[0..15] of Single;
var
  i, j, k: Integer;
  pa, pb, pc : PArray;
  a1 : Single;
begin
  for i := 0 to 3 do begin
    pa := @A[i]; pc := @C[i];
    for j := 0 to 3 do pc[j] := 0;
    for k := 0 to 3 do begin
      a1 := pa[k]; pb := @B[k];
      pc[0] := pc[0] + a1 * pb[0];
      pc[1] := pc[1] + a1 * pb[1];
      pc[2] := pc[2] + a1 * pb[2];
      pc[3] := pc[3] + a1 * pb[3];
    end;
  end;
end;

invis
> Ну я бы например постеснялся так огораживаться
Бред какой то. Я не программист. Просто любитель. Я должен знать десяток языков?
Смотрел передачу про программистов. Не все любят C++. Многие пишут на других языках.
А на хабре либо тролли, либо хамы. В статье четко указал тэги: ассемблер, Delphi, математика.
Набежали - заминусовали и навязали свой стиль мышления, который мне не нужен.
Видимо у них работа такая - «срать в камментах».