В переводе столько косяков, что я даже перечислять их не буду. Каждый абзац просто перекурочен переводчиком, который не разбирается в предмете. Да даже play back — это воспроизведение, а не воспроизведение задом наперед, господи. Уж это-то всем должно быть известно.
И я даже четверти статьи не просмотрел…
Аналогия неверная, потому что разрядность длина команды на сам конвейер не влияет. Проблема переменной длины — не понятно, где начинается следующая команда, пока не будет декодирована предыдущая. А конвейеру жить не быть нужна следующая команда на следующем такте. Т.е. надо успеть понять размер текущей команды за один такт. Ну и это требует дополнительного оборудования, в любом случае.
Я когда-то заказывал LL1105AF065Q. Но они оказались слишком вялыми. По остальным параметрам они подходят.
Если не ошибаюсь, в итоге нашел подходящие в чип-и-дипе, но они не столь долговечные.
Ожидаемая ошибка — ошибка, реакцию на которую предусмотрел программист. Он четко понимает, какие последствия несет эта ошибка и как ее обрабатывать.
Фатальная ошибка, соответственно, — ошибка, которую программист не предвидел, просто забил (- Еб*анет! — Не должно...), не продумал на нее реакцию. Или решил, что ошибка действительно фатальная и продолжать смысла нет.
Вообще, исходя из слов автора, что библиотека не знает, является ли ошибка фатальной, никогда не должна кидать эксепшены. А обработкой должен заниматься потребитель. Вот тут монады и пригодятся.
Ну деление на ноль приводит к ошибке потому что в Си оно приводило к ошибке. А в Си оно приводило к ошибке потому что большинство процессоров валятся с ошибкой при попытке делить на ноль. А делать обвязку, замедляющую выполнение, для обхода этого поведения — совсем не в стиле Си/Си++.
Посмотрите, как бронебойно-подкалиберные снаряды пробивают броню. Никаких «розочек». Розочка образуется только при малой скорости удара. На космических скоростях ничего такого, скорее всего, не будет.
>если рендерить в случайном порядке, а не сверху вниз.
Сейчас железо очень сильно полагается на пространственную когерентность доступа к памяти. Если вы сделаете случайные порядок — начнутся проблемы с текстурными кэшами, которые станут просто бесполезны, и широкой шиной памяти.
>Физику можно не считать, только изменения в положении камеры
Т.е. если вы едете в машине (камера движется) — для вас все гладко. А если машина перед вами (камера неподвижна) — она будет рывками?
А если камера привязана к физике? Ведь персонаж/машина, где едет персонаж движутся по физике.
1080 * 60 строчко-кадров в секунду? Это ж какая нагрузка на ЦП будет, чтобы для 65000 кадров в секунду считать физику и прочие подготовительные вычисления (например, сортировка по глубине)?
Rolling shutter ужасно выглядит. Не надо эту блевотину.
Рисование кадра — это не просто рисование 1080 линий и все. Перед этим считаются карты теней, кубические карты (анахронизм, но все равно) и буферы всякой всячины. Это константная часть, которую вам надо будет считать в 1080 раз чаще.
И я даже четверти статьи не просмотрел…
Проценты в шкале Цельсия считать — это такое. Если бы в Кельвинах посчитали, было бы больше физического смысла.
Вот так правильней: godbolt.org/z/P6c-WP — и ветвление вернулось на место.
Если не ошибаюсь, в итоге нашел подходящие в чип-и-дипе, но они не столь долговечные.
Фатальная ошибка, соответственно, — ошибка, которую программист не предвидел, просто забил (- Еб*анет! — Не должно...), не продумал на нее реакцию. Или решил, что ошибка действительно фатальная и продолжать смысла нет.
Вообще, исходя из слов автора, что библиотека не знает, является ли ошибка фатальной, никогда не должна кидать эксепшены. А обработкой должен заниматься потребитель. Вот тут монады и пригодятся.
Не показали другие методы, типа фотограмметрии.
А вы пробовали?
>если рендерить в случайном порядке, а не сверху вниз.
Сейчас железо очень сильно полагается на пространственную когерентность доступа к памяти. Если вы сделаете случайные порядок — начнутся проблемы с текстурными кэшами, которые станут просто бесполезны, и широкой шиной памяти.
>Физику можно не считать, только изменения в положении камеры
Т.е. если вы едете в машине (камера движется) — для вас все гладко. А если машина перед вами (камера неподвижна) — она будет рывками?
А если камера привязана к физике? Ведь персонаж/машина, где едет персонаж движутся по физике.
В общем — плохая идея.