Сегодня синглтон, а завтра уже фабрика объектов.
Я может, просто не хочу путаться, и всегда завожу классы, и если уж так вышло, что объект мне нужен только один — я его создам через new один раз. Зато буду спокоен, что в случае чего смогу создать их еще 10, если потребуется.
if(x === 0)
return;
— плохо, лучше ведь заранее написать
if(x === 0)
{
return;
}
и жить спокойно.
Я к чему все это… ужасы случаются, но завести заранее класс вместо прямого определения объекта — не страшно.
Барьер быть может, отчего ему не быть то?
Вот вам тройка теоретически возможных барьеров:
1) Там где пространство заканчивается, частицы полностью теряют импульс, в 0. Они скользят по краю. Нарушает закон сохранения энергии, но честно говоря этот закон пока аксиома, и неизвестно соблюдается ли он во всех всех всех уголках нашей Вселенной.
2) Там где пространство заканчивается, импульс частицы отражается. Закон сохранения энергии соблюден.
3) Жуткий вариант — там где пространство заканчивается, вылетающие туда частицы… исчезают. Совсем. Нарушает закон сохранения энергии, но как я сказал выше, неизвестно, соблюдается ли он во всех уголках Вселенной.
Изобретайте, на здоровье. На поприще академических языков. Пусть пройдут ваши 10 веков, и ваша технология начнет применяться, когда ваши наработки будут серьезным продуктом. Речь о том, что индустрия хватает все с печки, когда там еще сырая мука.
Я же могу импортировать legacy модуль в legacy режиме. Это наверняка есть и в Rust, но могли бы сделать полный автомат, на уровне, подключил h файл, и в Rust появились все legacy C++ функции из модуля. Я просто не знаю, возможно там это и так есть. Существующие компиляторы, чтобы собиралось под ios и android. Как в Rust с этим, все хорошо? Синтаксис C++, который мне так любим, с этим в Rust все хорошо?
Если бы брали что есть в C++, и просто прикручивали сверху опционально новые возможности, сохраняя возможность использовать старое через директивы, было бы гораздо лучше. Не надо выкидывать старые компиляторы, они мне нужны, чтобы собираться на целевые платформы. Я не хочу ждать, пока новый язык расчехлится на способность собираться везде, где собирается C++ без stdlib. Давайте сначала ехать, а потом шашечки.
Она могла быть бесконечной и в момент большого взрыва. Под большим взрывом подразумевают не сколько физический размер вселенной — бесконечно малую точку, сколько относительные расстояния между частицами в этот момент (плотность). То есть, представьте, что сейчас вся бесконечная вселенная начнет сжиматься, да так, что мы окажемся в 1 мм от солнца. Вселенная все еще бесконечна, но атомы существовать не могут, слишком большая плотность.
И правильно скажет. Сначала должно пройти 10 веков, должны появиться соответствующие технологии обработки металлов, соответствующие инструменты по проверки безопасности судна. Статья прямо пишет — не нужно переходить на новые языки, в которых уровень сопровождения еще в каменном веке. Некуда торопиться.
Это очень сильно отличается. Останется компилятор. Останется ide. Останется синтаксис языка. Останется стандартная библиотека языка. Останутся все предыдущие разработки на этом языке.
Как выше сказали, этого не будет. Еще есть фактор, что сообщество разработчиков не будет рыть себе такую яму — когда кто-то один раз напишет супер изоморфный конвеер, и весь мир разработчиков останется без работы.
50\50. Если разработка идет под ключ, команда сама решает, какие инструменты использовать. Если компания сама владеет разработкой продукта, она сама решает, какие инструменты использовать. Если команда\компания делает заказ на аутсорсе, она сама навязывает, (или выбирает из исполнителей), какие инструменты они будут использовать. А вот если вы сами аутсорс, и присоединяетесь к чужой разработке, тогда да :).
Очевидно, это вечная борьба, в которой защитники могут удерживать процент успешных нападений на каком-то уровне, но не могут опустить до нуля. Так что по идее, хакеры выигрывают на столько, на сколько они создают убытков.
Точно, комментарием ниже beeruser написал вариант и для стоковых видеокарт, даже проще.
Весь кадр рисуется с разрешением x0.5-x0.25. Эт на порядки повышает производительность. И лишь в области фокуса мы рисуем четкую картинку, которая втрое-вчетверо меньше по размеру чем весь дисплей. В итоге минимум двукратный прирост производительности. Если подумать, тоже самое можно использовать и для _самых_ обычных мониторов, получая выигрыш в производительности для обычных ПК в играх. Естественно предполагается, что пользователь сидит достаточно близко к full hd монитору, что конечно не очень приятно и полезно для зрения.
Разбиваем площадь экрана на массив квадратов. Участки в фокусе рендерим 1 к 1. Участки вне фокуса зрения рендерим с разрешением 1:2, 1:4 и так далее. Самый максимум можно выжать, если эти сектора будут виртуальными дисплеями для видеокарты, которые на ходу смогут менять разрешение. Соответственно, сильно заточить железо и драйвер под мультидисплейный рендер. Увы, с стоковыми видеокартами такой вариант не прокатит, однако можно выпустить видеокарты special for vr, и это действительно будет профит и большой выигрыш по производительности.
1 картинка сферической панорамы, или 6 картинок по сторонам куба, разницы нет. Так или иначе энтропия с 6 картинок куба должна как-то уложиться в одну сферическую побольше.
Для передвигающихся, да. Можно оптимизировать, уменьшая шаг поворота съемки. Но в итоге, если все сделать таким способом, влезет ли в видеопамять все это добро? Можно ли реально сделать игру по такой технике?
Скатерть растягивается во все стороны, увеличивая все в размерах, но энергия и количество вещества не меняется, это аналогично падению плотности. Сила гравитации уменьшается, объекты разлетаются.
Для статики, окружения — да, достаточно 6 текстур вокруг. Одна из подобных игр — Шорох, мы можем перемещаться только по ключевым точкам и вращать камерой. Для движущихся объектов, вокруг которых мы можем ходить, задача так не решается, нужны кадры всех сторон по всем доступным для вида осям. Чем ближе можем подходить к объекту, тем крупнее нужны кадры.
Я может, просто не хочу путаться, и всегда завожу классы, и если уж так вышло, что объект мне нужен только один — я его создам через new один раз. Зато буду спокоен, что в случае чего смогу создать их еще 10, если потребуется.
if(x === 0)
return;
— плохо, лучше ведь заранее написать
if(x === 0)
{
return;
}
и жить спокойно.
Я к чему все это… ужасы случаются, но завести заранее класс вместо прямого определения объекта — не страшно.
Вот вам тройка теоретически возможных барьеров:
1) Там где пространство заканчивается, частицы полностью теряют импульс, в 0. Они скользят по краю. Нарушает закон сохранения энергии, но честно говоря этот закон пока аксиома, и неизвестно соблюдается ли он во всех всех всех уголках нашей Вселенной.
2) Там где пространство заканчивается, импульс частицы отражается. Закон сохранения энергии соблюден.
3) Жуткий вариант — там где пространство заканчивается, вылетающие туда частицы… исчезают. Совсем. Нарушает закон сохранения энергии, но как я сказал выше, неизвестно, соблюдается ли он во всех уголках Вселенной.
Если бы брали что есть в C++, и просто прикручивали сверху опционально новые возможности, сохраняя возможность использовать старое через директивы, было бы гораздо лучше. Не надо выкидывать старые компиляторы, они мне нужны, чтобы собираться на целевые платформы. Я не хочу ждать, пока новый язык расчехлится на способность собираться везде, где собирается C++ без stdlib. Давайте сначала ехать, а потом шашечки.
Весь кадр рисуется с разрешением x0.5-x0.25. Эт на порядки повышает производительность. И лишь в области фокуса мы рисуем четкую картинку, которая втрое-вчетверо меньше по размеру чем весь дисплей. В итоге минимум двукратный прирост производительности. Если подумать, тоже самое можно использовать и для _самых_ обычных мониторов, получая выигрыш в производительности для обычных ПК в играх. Естественно предполагается, что пользователь сидит достаточно близко к full hd монитору, что конечно не очень приятно и полезно для зрения.
Для передвигающихся, да. Можно оптимизировать, уменьшая шаг поворота съемки. Но в итоге, если все сделать таким способом, влезет ли в видеопамять все это добро? Можно ли реально сделать игру по такой технике?