Несуществующий, твои мысли на счет рендеринга оч-чень интересны.
Попробую частично ответить на эти вопросы. Прошу прощения, если скажу нудно, просто иначе это сложно сделать.

1. Код повторяет геометрию матрицы только в визуальной модели, которую видит человек, в данном случае - Нео. Тут - размещение потоков геометрически демонстрирует принадлежность того или иного потока к тому или иному моделируемому обьекту в Матрице.

2. Детализация конечно изменяется. Попробуйте представить, что если в некоем обьекте - миллиарды атомов. Чтобы "запрограммировать" все свойства, связи и методы каждого атома, вплоть до кварков, необходимы фантастические массивы информации. А сколько обьектов в Матрице? Миллиарды! поэтому детализация определеннно изменяется.
Напишу на некоем алгоритмическом языке, немного схоже на плюсы:

Просчитывается детализация скорее всего так: мы имеем некий шаблон обьекта N, который задается потоком:

N_basic_thread(descriptor, sub: Matrix_Of_Sub_Threads; register: int: BOOL; inherited; //булевская функция, которая возвращает лог.1 если поток подключен, и 0 если отключен. descriptor - набор child-потоков, которые кодируют светлый символ, sub - ядро потока N; register - приоритет.

{
register_thread(<Name_Of_Parent>, descriptor, register); // регистрируем поток как связь с родительским потоком

on scanview(<Name_Of_Parent>, View) execute: // отслеживаем, "виден" ли поток функцией от родителя
{
if view==true //если виден, то...
{
scanstep(<Name_Of_Parent>, Step); // ...узнаем у родителя "шаг", т.е. что конкретно нужно показывать, в зависимости от ситуации...
execute_thread(sub, step); // ...выполняем шаг...
}
else // если же не виден...
{
set_thread_idle(sub, step); // ...то тормозим его...
}
//так делаем, пока не выполнили поток...

buffer = unregister_thread(<Name_Of_Parent>, descriptor, register): : Matrix_Of_Sub_Threads; //получаем идентификаторы тех child-потоков, какие могут понадобиться.

move_to_storage(buffer); // разбираем его дочерние потоки и кидаем их в буфер, из которого будем собирать другие потоки...
free_thread; // прощаемся...
} // и уходим...

В случае необходимости(т.е. видимости) этого обьекта мы заполняем его свойства при помощи обьектов, которые задаются его родителем. Т.е. регистрируем поток, и отслеживая видимомть, выполняем.

3. Скорость течения кода скорее всего определяется приоритетом потоков при интерпретациии.

4. Нео видит геометрическую интерпретацию потому, что он - Избранный.

5. Возможно, желтый код Серафа - это самостоятельные потоки, которые не могут быть "убиты" своими родителями. Т.е. это что-то типа хаков, что-то дописанное или взломанное. Может, потому он такой таинственный.



Ещё раз извините за то, что лезу в дебри и пытаюсь всё обьяснить. Просто интересно попробовать понять код с точки зрения математики.

Адрес поста | Один пост | Сообщить модератору | IP: Logged