Мне все равно. Я стараюсь как можно меньше иметь дело с деньгами и материальными благами вообще. (Без истерического фанатизма.) Так что это на меня не влияет.
Меня гораздо больше интересуют математика и программирование.
Если складировать биткоины — не заработаешь ничего(потому что выгоды от склада биткоинов нет). Ровно так же не заработаешь ничего и на интернет-магазине, если не будешь забирать прибыль, а просто хранить где-то в банке.
Что значит «замкнутый круг»? Единицы валюты созданы, чтобы их реплицировать нужны реальные деньги. Раз так, можно быть уверенным, что валюта не появится из ниоткуда.
Бумажки, что лежат в кошельке, тоже обеспечены только в малой доле, от этого доверие к ним критически не снижается.
ctr+f -> doSOmeething ( -> enter/ctrl+g намного(серьезно, намного) быстрее, чем дотянуться до мыши, и уж тем более искать глазами, а то и с раскрытием списка эту функцию.
Вообще, он сделан не для такого выранивания. Идея таба же в том, чтобы из двух колонок текста можно было выровнять вторую вне зависимости от содержимого первой(до момента переполнения). С пробелами при каждом изменении первой призодится редактировать и отступ, с табами — нет.
Но сейчас даже это уже малоактуально, потому как во-первых, строки стандартизированнной длины используются реже, все часто перескакивает на следуюзий табпоз, во--вторых, везде ГУИ, в-третьих, в консоли есть `column`.
А в коде колонки — сравнительно редкое дело, и там, где они есть — они как правило пишутся раз и надолго. (Вообще, может я что-то позабыл, но реальные колонки вроде используют только в наборах констант, либо инициализациях крупными пачками, для этих случаев — верно.)
Ан нет, все гораздо проще, похоже.
На текстуре есть градиент. На анимации в плоскости G — тоже очевидный градиент по ссылкам. Штука в том, что текстура — не классическая текстура, она так-же содержит версии для разной освещенности. А анимация напрямую ссылается на них. Но, учитывая то, что например лицо на текстуре явно только в одной версии, освещение таким методом сделано не для всего конечного спрайта, а только для некоторых областей.
Ну ведь оригинал фильма — поезда всякие — трехмерные, значит и сам фильм трехмерный, так?
(Хинт, если конечные данные+алгоритм не содержат прямых данных о трехмерных свойствах, и не используют трехмерных преобразований над этими данными — такая технология будет «без какого-либо 3д», а то, как мы генерируем исходные данные — вопрос третий.)
Говорить как вы — это все равно, что говорить, что перемножение матриц и поиск подстроки — одно и то-же: берем бинарные данные, производим над ними операцию, кладем результат.
На каком-то уровне абстракции, конечно все так, но в реальности мы имеем очевидную ситуацию: есть разные технологии, которые достигают разных целей.
В наши времена, когда файл, выложенный одним, может быть скачан миллионами других, начинают иметь смысл даже очень медленные технологии сжатия.
Главный вопрос тут скорее время декодирования.
Единственное, что могу предположить:
При правильном методе текстурирования расстояние между точками, на которые сссылаются соседние точки анимации, связано с нормалью(правда, криво-косо).
Меня гораздо больше интересуют математика и программирование.
tcc -run - << EOF
#include <tcclib.h>
int main(int ac, char**av){ printf("Hello habrahabr\n"); return 0; }
EOF
Золото не стоит ничего, когда нечего есть.
Бумажки, что лежат в кошельке, тоже обеспечены только в малой доле, от этого доверие к ним критически не снижается.
Но сейчас даже это уже малоактуально, потому как во-первых, строки стандартизированнной длины используются реже, все часто перескакивает на следуюзий табпоз, во--вторых, везде ГУИ, в-третьих, в консоли есть `column`.
А в коде колонки — сравнительно редкое дело, и там, где они есть — они как правило пишутся раз и надолго. (Вообще, может я что-то позабыл, но реальные колонки вроде используют только в наборах констант, либо инициализациях крупными пачками, для этих случаев — верно.)
На текстуре есть градиент. На анимации в плоскости G — тоже очевидный градиент по ссылкам. Штука в том, что текстура — не классическая текстура, она так-же содержит версии для разной освещенности. А анимация напрямую ссылается на них. Но, учитывая то, что например лицо на текстуре явно только в одной версии, освещение таким методом сделано не для всего конечного спрайта, а только для некоторых областей.
(Хинт, если конечные данные+алгоритм не содержат прямых данных о трехмерных свойствах, и не используют трехмерных преобразований над этими данными — такая технология будет «без какого-либо 3д», а то, как мы генерируем исходные данные — вопрос третий.)
На каком-то уровне абстракции, конечно все так, но в реальности мы имеем очевидную ситуацию: есть разные технологии, которые достигают разных целей.
Главный вопрос тут скорее время декодирования.
При правильном методе текстурирования расстояние между точками, на которые сссылаются соседние точки анимации, связано с нормалью(правда, криво-косо).