因此,我在2011年大会上就在这里进行了演示:http : //www.youtube.com/watch?v= 69Xjc7eklxE&feature= player_embedded
它只是一个文件,在规则中说明了这一点。所以我重复一遍,他们如何使它适合如此小的文件?
因此,我在2011年大会上就在这里进行了演示:http : //www.youtube.com/watch?v= 69Xjc7eklxE&feature= player_embedded
它只是一个文件,在规则中说明了这一点。所以我重复一遍,他们如何使它适合如此小的文件?
Answers:
它是基于过程的。内容不包含在exe中,仅包含如何绘制的规则。启动后,程序会在运行时绘制所需的内容,而不会以任何形式进行预渲染或预保存。
这与Elite用来创建广阔的恒星系统宇宙的方法相同。
使用程序生成,今天可以实现的功能非常令人惊讶,我认为游戏在将来将具有更多功能。
就像@Gary Willoughby所说的那样,它具有广泛的程序性。
而且,asm
涉及大量的手工编码,以及对内部有多少个选择系统的窗口/平台的广泛了解。
如果您想查看紧凑代码的更多极端示例,则还有一个4K演示类别。
一些DemoScene小组会在线发布他们的演示,您可以在其中下载并播放它们。
注意-许多演示都将导致您的防病毒软件崩溃。基本上,几乎所有演示都使用打包的.exe文件,并且大多数演示组都使用自己的打包程序。不幸的是,由于许多视音频公司都la脚,他们通常声称任何压缩的二进制可执行文件都是某种病毒。
就像每个人都在说,它们广泛依赖于过程生成的代码,但是,这个演示特别有更多的内容,如果您停下来看看一些细节,让我们看看那些墙:看看砖块以及光如何反射在它们上面。他们看起来很自然。
那是因为他们使用了大量的顶点着色器和片段着色器来使生成的内容栩栩如生。
我花了一些时间试图了解它们是如何产生这些东西的,并对我从这些演示中获取的每段代码感到惊讶。
顺便说一句,在进行这些演示时,他们还使用压缩工具进行压缩。检查以下编译过程:
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 KB,而是如何在如此小的空间中创建几何的关键。
在他的博客中,也有许多关于他的其他场景制作的有趣读物。
正如其他人已经指出的那样,其中很多依赖于程序生成的资产。
还有另一个要素,那就是压缩。4k和64k演示使用高度专业的可执行压缩器。其中最著名的是Farbrausch的kkrunchy(64ks)和TBC和Loonies的crinkler(4ks)。此外,现代演示程序大量使用了明暗器(shader),明暗器是纯文本,因此压缩后会大大缩小。
现在,就视频游戏中的集成而言,主要问题是所有这些都需要时间。生成过程内容需要时间,而提取可执行文件则需要大量时间。而且人们通常在硬盘驱动器上有更多的空间,而不是花时间等待游戏加载,所以我认为我们不会很快在广泛可用的游戏中看到很多这样的东西。