这怎么能容纳64kb?


45

因此,我在2011年大会上就在这里进行了演示:http : //www.youtube.com/watch?v= 69Xjc7eklxE&feature= player_embedded

它只是一个文件,在规则中说明了这一点。所以我重复一遍,他们如何使它适合如此小的文件?


可以下载此演示吗?我想看看它在本地运行时是如何工作的。
大卫


当然,几兆字节的系统库,没有它们,这个东西将无法绘制单个多边形...
hobbs

2
作为积极创建64kB简介的人,我写了这篇文章:ctrl-alt-test.fr/?p=494(演示产生的内容怎么这么小?)。TL; DR:过程生成,压缩和许多额外的工作。
洛朗

1
@TeamUpvote不,全都是C ++。要低于12kB,您需要摆脱标准库。如果您使用Visual C ++,则可以在此处找到示例:github.com/laurentlb/Ctrl-Alt-Test/tree/master/Fiquilezles.org/code/framework64k/framework64k.htm
洛朗

Answers:


39

它是基于过程的。内容不包含在exe中,仅包含如何绘制的规则。启动后,程序会在运行时绘制所需的内容,而不会以任何形式进行预渲染或预保存。

这与Elite用来创建广阔的恒星系统宇宙的方法相同。

使用程序生成,今天可以实现的功能非常令人惊讶,我认为游戏在将来将具有更多功能。


我只是认为纹理非常准确。所以他们只是用代码绘制它,而我猜没有任何纹理文件?
Samuli Lehtonen

1
是的,这是正确的。
加里·威洛比

1
对于此类演示,声音也是从代码生成的(没有样本)。一切都是实时进行的合成...当然,某些点数和淡入淡出的场景也可以进行大量的预计算:)
Karoly Horvath'Aug

2
作为前3d艺术家,我一直希望将程序生成的纹理作为标准工具集包含在主流3d艺术程序中很长一段时间。可能是最接近是使用内置的脚本语言....
Darknight

您可能对诸如Project FrontierProcedural World之类的东西感兴趣,这是通过过程生成来解决同一问题的两种方法。
Kyte

10

就像@Gary Willoughby所说的那样,它具有广泛的程序性。

而且,asm涉及大量的手工编码,以及对内部有多少个选择系统的窗口/平台的广泛了解。

如果您想查看紧凑代码的更多极端示例,则还有一个4K演示类别。

一些DemoScene小组会在线发布他们的演示,您可以在其中下载并播放它们。

阴谋
暴躁

另请参阅Wikipedia上的DemoScene历史

注意-许多演示都将导致您的防病毒软件崩溃。基本上,几乎所有演示都使用打包的.exe文件,并且大多数演示组都使用自己的打包程序。不幸的是,由于许多视音频公司都la脚,他们通常声称任何压缩的二进制可执行文件都是某种病毒。


1
我只是想知道您想到的是哪家视音频公司,甚至可能是非盲文...
Jerry Coffin

+1很棒的东西。他们使用Nvidea API还是直接绘制到图形卡上?

1
他们通常会建立一个最小的OpenGL框架并启动一些着色器来完成其余工作
Jasper Bekkers 2011年

3
这是令人印象深刻的东西。我想如果我年轻15岁,那将是我的业余时间。

以下是一些Assembly 2011演示:archive.assembly.org/2011
Samuli Lehtonen

4

就像每个人都在说,它们广泛依赖于过程生成的代码,但是,这个演示特别有更多的内容,如果您停下来看看一些细节,让我们看看那些墙:看看砖块以及光如何反射在它们上面。他们看起来很自然。

那是因为他们使用了大量的顶点着色器和片段着色器来使生成的内容栩栩如生。

我花了一些时间试图了解它们是如何产生这些东西的,并对我从这些演示中获取的每段代码感到惊讶。

顺便说一句,在进行这些演示时,他们还使用压缩工具进行压缩。检查以下编译过程:

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

3

有一个PowerPoint演示文稿的呈现是如何在这个特定的演示完成。仅此一项并不能解释所有内容如何适应64 KB,而是如何在如此小的空间中创建几何的关键。

在他的博客中,也有许多关于他的其他场景制作的有趣读物。


1

正如其他人已经指出的那样,其中很多依赖于程序生成的资产。

还有另一个要素,那就是压缩。4k和64k演示使用高度专业的可执行压缩器。其中最著名的是Farbrausch的kkrunchy(64ks)和TBC和Loonies的crinkler(4ks)。此外,现代演示程序大量使用了明暗器(shader),明暗器是纯文本,因此压缩后会大大缩小。

现在,就视频游戏中的集成而言,主要问题是所有这些都需要时间。生成过程内容需要时间,而提取可执行文件则需要大量时间。而且人们通常在硬盘驱动器上有更多的空间,而不是花时间等待游戏加载,所以我认为我们不会很快在广泛可用的游戏中看到很多这样的东西。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.