А почему это вообще комиссия в процентах, почему это не привязано к количеству транзакций и времени обслуживания, по аналогии с операторами сотовой связи?
По логике один платёж в 100 рублей или в 500 отличается лишь цифрой внутри пакета, накладные расходы на процессинг разве не одинаковые?
Почему же это собственные производители внезапно не являются конкретными предпринимателями?
Таможенные пошлины по логике и стимулирут развитие внутреннего производства, разве нет?
Внутренние производители разве не используют ритейл?
Извиняюсь, я отвечал Sabubu выше и имел ввиду что главное — обработать ошибку. А возвращаемый это код/errno или исключение принципиального значения не имеет.
Полностью согласен с тем, что сама программа должна решать что делать с ошибкой. Задача библиотеки ошибку донести, а не убиться об неё.
Лучи идут к точкам.
Одна и та-же точка может быть использована для нескольких тайлов. Например для одного тайла она верхняя левая, для другого она же нижняя правая. Нет смысла трассировать одну и ту-же по факту точку дважды.
В плотном блоке 2х2 тайла действительно по 4 угла на тайл, но точек по факту 9, а не 16. Внутренняя точка общая для всех 4х тайлов, точки на серединах граней общие для 2х смежных блоков (сколько тайлов используют точку):
1 2 1
2 4 2
1 2 1
Полагаю чтобы игрок чётко понимал — согласно игры он видит содержимое тайла или нет. В DoomRL, например, от этого зависит можно ли выстрелить в противника. Если механика игры это предусматривает, то логично как-то однозначно трактовать видимость в спорных ситуациях. Субъективно для игрока по факту противник виден, а выстрелить по нему по непонятным причинам нельзя. Дополнительная подсветка в таком случае устранила бы неоднозначность видим/не видим можно/нельзя попасть.
Точечные источники освещения отбрасывают очень уж жёсткие тени. Для теней многоугольников можно упростить рейкастинг, например, как тут ncase.me/sight-and-light.
Мягкие тени сделать сложнее, т.к. источник света не точка, а, например, отрезок. И вместо видно/не видно точку нужно считать под каким углом виден отрезок освещения из точки (получается как-бы обратный рейкастинг от точки к источнику/ам освещения). Хотя это и вычислительно сложно, можно заранее «запечь» карту освещения для статических источников.
«а падение производительности было внушительным»
Думаю для Roguelike можно скрыть падение производительности, заранее посчитав тени для позиций на смежных клетках (т.к. игрок двигается по целым клеткам), и делать плавный переход между уже готовыми картинками. Большую часть реального времени мир статичен, и если он выглядит хорошо, то этого, пожалуй, достаточно.
Можно не останавливать луч при контакте с поверхностью, а лишь «ослаблять» его ярокость в зависимости от пройденного «внутри» поверхности пути (как в тумане, луч вошёл в тучку :) )
Тогда тени будут мягче. Картинка темновата, вне контакта с препятствиями яркость можно не менять. Думаю что для плотного леса должно хорошо смотреться, т.к. будет видно что все деревья как-то участвуют в построении тени, а не только первый ряд, который всё перекрыл
Это не очень «реалистично» :).
Обычно в основе реалистичности лежит какая-то модель, приближённая к реальности, ну например:
— деревья перекрывают (k) половину освещённости
— соответственно два дерева перекроют k*k, три k*k*k и т.д. (получается не альфа смешивание, а просто умножение на коэффициент «тени»)
— рассчитанный коэффициент пересчитывается для гамма-кодированных значений цвета и уже по нему делается альфа-смешивание.
Ну какой-то такой «реализм» :)
Но она на то и пирамида, что на большой крепкой основе надстраиваются новые уровни, их нельзя просто взять и искусственно убрать / игнорировать. Удовлетворение потребностей более высокого порядка не идёт в ущерб более низким, они всё равно учитываются. Если для небиологического существа этих более низких уровней нет, то они и не будут учитываться. Пока с базовыми потребностями нет проблем — эта особенность будет скрыта при решении общих потребностей высокого порядка, но в долгосрочной перспективе это может привести к серьёзным последствиям.
Вот как раз я и хотел поднять вопрос стимулов. Продуктивное взаимодейсвие требует общих интересов. Если человеческая пищевая цепочка объективно не требуется для небиологических людей, то они не будут непосредственно заинтересованы в её развитии, ведь для них это лишь искусственная проблема. Гораздо интеллектуальнее заниматься объективными и естественными проблемами своего собственного существования, развивая, например, производство электричества.
Если небиологические люди будут иметь другую пищевую цепочку и эта пищевая цепочка не будет пересекаться, то в чём будет их объективная заинтересованность в сохранении человеческой?
По логике когда пользователь доскроллил до изображения, то он ожидает увидеть его уже загруженным, значит загружать его надо раньше, чем область просмотра зацепит край изображения. И тем раньше, чем больше размер изображения. Это можно решить отдельной «увеличенной» областью, по которой будет начинаться загрузка.
GLSL проделал довольно долгий путь к вебу, за это время создано множество инструментов для работы с ним, полностью поддерживающими подмножество языка для WebGL.
Хотя
Можно считать количество каждого встречающегося значения 0-255 в массиве и по этой статистике уже пересчитывать разные варианты «усреднения», не сканируюя всю картинку заново, раз «усреднение» всё равно поканальное. Хотя это скорее оптимизация для больших размеров картинки.
Поскольку это производные от изображения данные, их можно рассчитать заранее (Каким-нибудь ImageMagick, например) и передавать уже готовые рядом с картинкой. Онлайн-рассчёт это хорошо, но пользователи устройств с питанием от аккумулятора, возможно, будут недовольны раходом батареи :(
Как-то это сложно и непонятно зачем.
Возможно, когда шейдеры ещё были медленными, хитрое использование сэмплера текстур и давало какие-то ощутимые вычислительные преимущества, однако сейчас какой смысл читать четыре текселя, если коэффициенты можно явно читать с RGBA одного?
Невидимые части делятся на две категории:
1 Находящиеся сзади модели.
Полагаю что это и есть полигоны для Backface culling, они отбрасываются не потому что чем-то заслонены, а просто по ориентации, т.к. рисуются только с одной стороны.
По времени непосредственно на отрисовку — один рендер на ракурс всего. В пиксельный шейдер прокидывается индекс треугольника и по нему выставляется цвет фрагмента, меш рисуется целиком.
Приведённый алгоритм выглядит не очень эффективным — для одного треугольника делать рендеринги со всех позиций?
Для каждого треугольника можно писать в буфер цвета его индекс, чтобы потом из картинки найти полный набор отображаемых треугольников. Дополнив этот набор со всех позиций — убрать те треугольники, индексы которых не встречались.