Как все это может вписаться в 64 КБ?

Итак, я здесь, на собрании 2011 года, и там было сыграно это демо: http://www.youtube.com/watch?v=69Xjc7eklxE&feature=player_embedded

Это только один файл, это сказано в правилах. Итак, я повторяю, как они сделали это, чтобы вписаться в такой маленький файл?

Это процедурное основание. Содержание не входит в exe, только правила того, как его нарисовать. При запуске программа рисует то, что ей нужно, чтобы во время выполнения она не была предварительно отрисована или предварительно сохранена в любой форме.

Это тот же метод, который используется в Elite для создания огромной вселенной звездных систем и т. Д.

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

Как говорит @Gary Willoughby, это в значительной степени процедурно.

Кроме того, требуется значительное ручное asmкодирование, а также обширные знания о том, сколько окон / платформ выбранных систем работают внутри.

Существует также демонстрационная категория 4K, если вы хотите увидеть еще более экстремальные примеры компактного кода.

Некоторые из групп DemoScene выпускают свои демо-версии онлайн, где вы можете скачать их и поиграть, если хотите.

Заговор
фарб-рауш

Также смотрите Википедию об истории демо-сцены

^{Примечание - много демок приведет к тому , антивирус для наркомана . По сути, кажется, что почти все демо-версии используют упакованные файлы .exe, и большинство демонстрационных групп выпускают свои собственные упаковщики. К сожалению, поскольку многие AV-компании не работают, они, как правило, утверждают, что любой упакованный двоичный исполняемый файл является своего рода вирусом.}

Как все говорят, они широко полагаются на процедурно-сгенерированный код, но в этом демо есть еще кое-что, в частности, если вы остановитесь и посмотрите на некоторые детали, давайте рассмотрим, например, эти стены: посмотрите, какие кирпичи и как на них отражается свет. Они выглядят естественно.

Это потому, что они используют много вершинных шейдеров и фрагментных шейдеров, чтобы оживить сгенерированный контент.

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

Кстати, при выполнении этих демонстраций они также используют инструменты сжатия, чтобы сжать еще больше. проверьте этот процесс компиляции:

all:
nasm -f bin -o intro main.asm
nasm -f bin -o stub stub.asm
gzip -n --best intro
advdef -z -4 intro.gz
cat stub intro.gz > intro
chmod +x intro
rm intro.gz
rm stub

Существует презентация PowerPoint о том, как рендеринг был выполнен в этой конкретной демонстрации. Уже одно это не объясняет, как все вписывается в 64 килобайта, но является ключом к тому, как геометрия была создана в таком небольшом пространстве.

В его блоге также есть много интересного о других его демосценах.

Как уже говорили другие, многое из этого зависит от процедурно генерируемых активов.

В этом есть еще один элемент - сжатие. В демонстрациях 4k и 64k используются узкоспециализированные исполняемые компрессоры. Наиболее известными из них являются kkrunchy by farbrausch (для 64ks) и crinkler от TBC & Loonies (для 4ks). Более того, современные демо-версии активно используют шейдеры, которые представляют собой простой текст и, следовательно, значительно уменьшаются после сжатия.

Теперь, что касается интеграции в видеоигры, главная проблема в том, что все это требует времени. Генерация процедурного контента занимает много времени, а извлечение исполняемого файла занимает огромное количество времени. И люди обычно имеют больше места на своих жестких дисках, чем тратят время на ожидание загрузки игры, поэтому я не думаю, что мы увидим много этого в широко доступных играх в ближайшее время.