Константин Савков GCU

А почему это вообще комиссия в процентах, почему это не привязано к количеству транзакций и времени обслуживания, по аналогии с операторами сотовой связи?
По логике один платёж в 100 рублей или в 500 отличается лишь цифрой внутри пакета, накладные расходы на процессинг разве не одинаковые?

Крик души понятен, но почему так неопрятно?

Заголовок: «повляет»
Текст: «вышла такое» «ставки… уже заложена» «заградительными пошлинам»
Тэг: «экайринг»

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

Вспомнился весёлый «вирус» который портил резервную копию таблицы FAT.
Веселье начиналось когда дисковая утилита бралась «починить» основную таблицу.

Поведение макроса было бы куда веселее в таком виде:

for (; isspace (c = getc (InFile)) && ('\n' != c););

Извиняюсь, я отвечал Sabubu выше и имел ввиду что главное — обработать ошибку. А возвращаемый это код/errno или исключение принципиального значения не имеет.
Полностью согласен с тем, что сама программа должна решать что делать с ошибкой. Задача библиотеки ошибку донести, а не убиться об неё.

То, что вы предложили — возвращать код ошибки — тоже плохо и ненадежно, так как нет гарантий, что кто-то будет результат функции проверять.

https://habr.com/ru/post/324642/ — это стандарт же

Аналогично нет никаких гарантий что исключение не проглотят.

Лучи идут к точкам.
Одна и та-же точка может быть использована для нескольких тайлов. Например для одного тайла она верхняя левая, для другого она же нижняя правая. Нет смысла трассировать одну и ту-же по факту точку дважды.
В плотном блоке 2х2 тайла действительно по 4 угла на тайл, но точек по факту 9, а не 16. Внутренняя точка общая для всех 4х тайлов, точки на серединах граней общие для 2х смежных блоков (сколько тайлов используют точку):
1 2 1
2 4 2
1 2 1

Полагаю чтобы игрок чётко понимал — согласно игры он видит содержимое тайла или нет. В DoomRL, например, от этого зависит можно ли выстрелить в противника. Если механика игры это предусматривает, то логично как-то однозначно трактовать видимость в спорных ситуациях. Субъективно для игрока по факту противник виден, а выстрелить по нему по непонятным причинам нельзя. Дополнительная подсветка в таком случае устранила бы неоднозначность видим/не видим можно/нельзя попасть.

Не соглашусь с рассчётом :). В сетке 60х33 будет (60+1)х(33+1) ~ 2к точек.

Точечные источники освещения отбрасывают очень уж жёсткие тени. Для теней многоугольников можно упростить рейкастинг, например, как тут ncase.me/sight-and-light.

Мягкие тени сделать сложнее, т.к. источник света не точка, а, например, отрезок. И вместо видно/не видно точку нужно считать под каким углом виден отрезок освещения из точки (получается как-бы обратный рейкастинг от точки к источнику/ам освещения). Хотя это и вычислительно сложно, можно заранее «запечь» карту освещения для статических источников.

«а падение производительности было внушительным»
Думаю для Roguelike можно скрыть падение производительности, заранее посчитав тени для позиций на смежных клетках (т.к. игрок двигается по целым клеткам), и делать плавный переход между уже готовыми картинками. Большую часть реального времени мир статичен, и если он выглядит хорошо, то этого, пожалуй, достаточно.

Можно не останавливать луч при контакте с поверхностью, а лишь «ослаблять» его ярокость в зависимости от пройденного «внутри» поверхности пути (как в тумане, луч вошёл в тучку :) )
Тогда тени будут мягче. Картинка темновата, вне контакта с препятствиями яркость можно не менять. Думаю что для плотного леса должно хорошо смотреться, т.к. будет видно что все деревья как-то участвуют в построении тени, а не только первый ряд, который всё перекрыл

Это не очень «реалистично» :).
Обычно в основе реалистичности лежит какая-то модель, приближённая к реальности, ну например:
— деревья перекрывают (k) половину освещённости
— соответственно два дерева перекроют k*k, три k*k*k и т.д. (получается не альфа смешивание, а просто умножение на коэффициент «тени»)
— рассчитанный коэффициент пересчитывается для гамма-кодированных значений цвета и уже по нему делается альфа-смешивание.
Ну какой-то такой «реализм» :)

А какая функция используется для наложения теней одна на другую — просто альфа-смешивание с чёрным?

Но она на то и пирамида, что на большой крепкой основе надстраиваются новые уровни, их нельзя просто взять и искусственно убрать / игнорировать. Удовлетворение потребностей более высокого порядка не идёт в ущерб более низким, они всё равно учитываются. Если для небиологического существа этих более низких уровней нет, то они и не будут учитываться. Пока с базовыми потребностями нет проблем — эта особенность будет скрыта при решении общих потребностей высокого порядка, но в долгосрочной перспективе это может привести к серьёзным последствиям.

Вот как раз я и хотел поднять вопрос стимулов. Продуктивное взаимодейсвие требует общих интересов. Если человеческая пищевая цепочка объективно не требуется для небиологических людей, то они не будут непосредственно заинтересованы в её развитии, ведь для них это лишь искусственная проблема. Гораздо интеллектуальнее заниматься объективными и естественными проблемами своего собственного существования, развивая, например, производство электричества.

Если небиологические люди будут иметь другую пищевую цепочку и эта пищевая цепочка не будет пересекаться, то в чём будет их объективная заинтересованность в сохранении человеческой?

По логике когда пользователь доскроллил до изображения, то он ожидает увидеть его уже загруженным, значит загружать его надо раньше, чем область просмотра зацепит край изображения. И тем раньше, чем больше размер изображения. Это можно решить отдельной «увеличенной» областью, по которой будет начинаться загрузка.

GLSL проделал довольно долгий путь к вебу, за это время создано множество инструментов для работы с ним, полностью поддерживающими подмножество языка для WebGL.
Хотя

Можно считать количество каждого встречающегося значения 0-255 в массиве и по этой статистике уже пересчитывать разные варианты «усреднения», не сканируюя всю картинку заново, раз «усреднение» всё равно поканальное. Хотя это скорее оптимизация для больших размеров картинки.
Поскольку это производные от изображения данные, их можно рассчитать заранее (Каким-нибудь ImageMagick, например) и передавать уже готовые рядом с картинкой. Онлайн-рассчёт это хорошо, но пользователи устройств с питанием от аккумулятора, возможно, будут недовольны раходом батареи :(

По логике sqrt алгоритм — это гамма-коррекция 2. Почему бы не использозать страндартную 2.2?

Как-то это сложно и непонятно зачем.
Возможно, когда шейдеры ещё были медленными, хитрое использование сэмплера текстур и давало какие-то ощутимые вычислительные преимущества, однако сейчас какой смысл читать четыре текселя, если коэффициенты можно явно читать с RGBA одного?

Из статьи:

Невидимые части делятся на две категории:
1 Находящиеся сзади модели.

Полагаю что это и есть полигоны для Backface culling, они отбрасываются не потому что чем-то заслонены, а просто по ориентации, т.к. рисуются только с одной стороны.

А как вы учитываете влияние невидимых треугольников на карту освещения?
По логике они являются источником отражений света, но в самой карте не нужны.

По времени непосредственно на отрисовку — один рендер на ракурс всего. В пиксельный шейдер прокидывается индекс треугольника и по нему выставляется цвет фрагмента, меш рисуется целиком.

В моём понимании рендерить видимые части всё равно приходится, чтобы проверить — перекрывают ли они красный треугольник, разве не так?

Приведённый алгоритм выглядит не очень эффективным — для одного треугольника делать рендеринги со всех позиций?
Для каждого треугольника можно писать в буфер цвета его индекс, чтобы потом из картинки найти полный набор отображаемых треугольников. Дополнив этот набор со всех позиций — убрать те треугольники, индексы которых не встречались.