基于盒式游戏的编程方式如何?[关闭]


44

我想我想像的是SNES,N64,Atari ...甚至是今天的DS。

SNES游戏通常不会占用超过4 MB的空间,而N64游戏通常需要32至64 MB的数据。

这些天,您几乎不能编译一个“ hello world!” 程序,而没有产生1.21 GB的编译结果!数据的。(开个玩笑,与当时的某些技术相比,今天的文件确实占用了无数的空间。)

那么...他们是怎么做到的?

  • 他们用什么编程了这些游戏?ASM?ASM中的全部内容?!
  • 图形是如何创建的?他们必须使用什么技术来创建Sprite表,并且在某些情况下(例如N64)创建3D模型?
  • 它们如何适合这些墨盒上的如此多的关卡,角色,任务和物品?我的意思是,SNES上的超级马里奥世界时钟大约1 MB,它有96个出口!《时光之笛》,Banjo-Kazooie,DK64和其他一些游戏占用的内存不到64 MB,并且拥有巨大的世界,大量的内容和3D模型!

抱歉,如果我的问题看起来有点太过头了,我只是惊讶于那里有很多很棒的标题都可以容纳这么小的存储空间。

这让我着迷,因为即使是最微小的文件和游戏,也至少要占用几MB的内存,因此,想象像GoldenEye 007中的那些巨大的水平几乎根本无法吸收任何数据。


1
此外,关于重复项,我知道人们会指出:我最感兴趣的是如何将实际数据放入游戏中,以及如何在保留较小文件大小的情况下创建巨大级别-而不是开发过程和使用的工具。
Corey


1
NES(见银河战士源在MDB)和SNES(的一些随机第三方游戏的源代码就在那里在网络上)使用ASM,N64(塞尔达传说:MM的调试屏幕显示在崩溃信息文件名)使用C.
伊沃Wetzel

在8位时代,游戏编程非常广泛。例如,制作Pacman花费了一笔巨款,而今天却可以廉价地制造出来。原因是硬件的限制比今天限制了千倍(或更多)。这意味着这些8位游戏必须依靠汇编代码。今天的游戏如此之大的原因并不是他们必须如此。主要是它们可以。您可以阅读有关维尔斯定律的信息。
wolfdawn

是的,8位游戏通常是用汇编编写的。短信游戏的初衷是Z80,这是众所周知的。在Assembly中编写时,仍然可以创建有用的库。我不认为保持代码紧凑与当今的游戏开发有何关系。听起来好像有人在现代汽车论坛上问如何养马和养马。如果您编写本机二进制指令,则在一台目的明确的机器上,当然可以并且很可能会使代码紧凑。当您需要将代码运行在几兆赫兹的频率时,会感到多么肿。:)
wolfdawn

Answers:


25

占用空间的是美术和音频资源,编程语言的选择更多的是要充分利用硬件。

以N64为例,大多数第三方游戏为8、12或16Mb。32Mb和64Mb游戏主要来自Nintendo,因为运往其他所有人都可以使用的大型手推车价格昂贵。这听起来很小,但是艺术资产和最终的视觉输出也是如此。您必须记住,大多数N64游戏以320x240渲染,而不是今天的1280x760或更高。在如此小的输出分辨率下,纹理和精灵比今天小得多。

由于N64上的纹理缓存很小,因此大多数纹理都是32x64像素,带有4/8位调色板(也称为16/256色)。通常通过混合纹理和顶点颜色来完成额外的颜色细节。班卓琴游戏就是一个很好的例子。

今天,虚幻引擎游戏中的一块石头将具有多个512x512x24bpp甚至32bpp。另外,您现在不仅具有单个漫反射纹理,而且还具有法线贴图,镜面反射蒙版,反射蒙版,反射立方体贴图等。因此,以前具有4Kb纹理的对象现在被数MB的数据覆盖。

旧游戏也大量使用艺术。超级马里奥兄弟(Super Mario Bros.)的灌木丛与云是相同的小精灵,山丘与蘑菇是相同的。不同的字符只是相同艺术资源的变色版本。所有这些都可以从购物车上的每个纹理或精灵中获得更多使用。

音频是现代游戏的另一大不同之处。过去,几乎所有东西都是由顺序音轨完成的。现在,音乐曲目,语音和声音效果都以各种压缩的音频格式存储。尽管肯定比未压缩的数据要小,但它们仍然比已排序的等效数据大得多。


8
啊,马里奥灌木丛/树木乱伦有一个合理的解释!优秀的。
卡扎伊2010年

10
这是值得指出的是,车是在大型尺寸往往比特,而不是兆字节。那些64Mb的购物车只有8MB。
dash-tom-bang 2010年

3
在N64中,输出不是320 x 240。详细信息不正确。大多数游戏可能正在使用256 × 224看到这里
wolfdawn

13

至于NES(大多数情况下也是SNES),这是一个基本概述。我没有写任何NES游戏,但是写了NES模拟器(Graybox),并对旧车进行了大量的改造工程。

至于编程语言:是的,都是汇编语言。对NES进行编程意味着直接使用硬件中断,DMA端口,存储区切换等。幸运的是,对6502(或者说2A03)进行编程非常容易[1]:

  • 寄存器很少:主要是A,X和Y,后两个仅用于索引和迭代
  • 指令集很小,通常很简单
  • 内存不多:主RAM为2KB,可选电池支持8KB扩展。在这2KB中,为堆栈保留256个字节,由于某些特殊的寻址方式,第0页(前256个字节)是您要存储最常用的指针和值的位置

这三件事共同构成了一个易于记忆的环境。是的,您可以自行管理所有内存,但实际上这意味着您要创建一张完整的地图,说明一切进展顺利,而且该地图并不是很大,因为您只需要担心2K,因此可以将其绘制在一张方格纸。您必须多计划一些事情,并将变量和常量静态分配给RAM和ROM(盒式磁带)位置。

一旦您的卡式盒数据超出了CPU的可寻址限制,它就会变得有些棘手。那是64KB,其中较低的32KB是固定的,并映射到各种硬件端口和RAM。这是存储区切换起作用的地方,这意味着将ROM的一部分映射到较高的32KB地址空间中(的一部分)。

可以根据程序员的需要使用此功能,但示例使用的游戏可能是具有3个级别的游戏,每个级别的所有级别数据,元数据和代码都塞在盒带上单独的8KB内存区域中。该级别可能具有例如初始化,每帧更新等的回调。“加载”该级别意味着将8KB的内存块映射到例如0xC000。然后,您可以指定初始化例程始终为0xC000,帧更新例程为0xC200,级别数据从0xC800开始。然后,将游戏的主要代码存储在另一个内存块中,只需在合适的时间交换正确的块并跳转到绝对地址0xC000和0xC200即可控制级别更改。

Wrt图形数据:NES的图块数据是2位8x8像素图。对于背景,它们与1/4分辨率2位图层结合在一起。然后将这些4位值索引到16项调色板中,我相信可以使用53种有效的独特颜色。Sprites还使用2位像素数据,每个Sprite都指定了自己的2位组索引,从而再次形成了4位pal索引。屏幕上的BG图像是32x30的瓦片索引号数组。

本质上,通过进行大量重复和索引索引,可以使数据保持很小。物位数据通常存储为图块索引的垂直条,并且由于这些垂直条也被重复使用,因此这些索引也被索引,并且仅在盒式磁带上存储一次。简单数据压缩技术的工作原理与此类似。这使Mario 1可以存储32KB的数据(有剩余空间)和8KB的位图数据。

至于开发环境,我看过一些照片,人们在这些古老的计算机上工作,这些计算机连接到EEPROM刻录机进行工作。直到SNES时代[2]之后,工具辅助调试才真正成为可能。这是许多旧游戏中存在“明显”错误的主要原因,以及为什么像Gameshark这样的事情可以做他们所做的事情。播放器的健康状况始终位于内存位置X,因此您可以始终将其设置为100。

如果您觉得这些事情有趣,我鼓励您查看例如http://wiki.nesdev.com/w/index.php/Nesdev_Wiki。 还有许多关于NES的编程课程也可以在网上找到。

我希望这个简化的概述可以让您对80年代的游戏开发有所了解。

[1]相对而言。当我在大约85%的PowerPC程序集中编写Graybox本身时,我也有偏见。[2]参见FF6文章的制作:http://www.edge-online.com/features/the-making-of-final-fantasy-vi/


3

在您提出的几乎所有问题中,都有很多子主题。优化本身就是一个巨大的领域,有很多事情需要探索。

如果您对这种优化感兴趣,那么可能要探索的事情之一就是demoscene。蠕虫及其一些相关的艺术文化长期以来一直对尝试创建占用空间尽可能少的计算机的复杂艺术充满好奇。他们中的许多人将获得有关他们如何完成部分或全部“技巧”的信息。

尽管存在特定于游戏或类型的“技巧”和“ hacks”,但通常会巧妙地结合常识。通常会有一点“运气”,一个团队知道他们正在努力的极限(也许在整个过程中不断地与这些极限相抵触),知道他们可以进行的取舍,并愿意进行一些必要的交易牺牲和牺牲以达到自己的极限。

我可以想到的一些事情可以帮助团队缩小比赛规模:

  • 重复使用您可以使用的内容:重复使用相同的精灵,以及可以轻松地从单个精灵图像进行的变化(例如反射,旋转,调色板移动)将节省您的空间。代码,音乐以及游戏中几乎所有其他内容也是如此。
  • 压缩您能做到的:有很多压缩方案,知道使用哪种压缩方案可以节省大量空间。甚至有时候,诸如行程编码之类的简单压缩方案也会产生令人惊讶的变化。不仅如此,还有针对单个文件类型的压缩方案(以及并非完全压缩的替代格式),通常需要进行质量折衷。例如,可以将wave / CD音频文件压缩到MP3文件中,同时会造成一些信息丢失。此外,诸如MIDI和基于采样器的MOD之类的文件格式是替代格式,占用的空间要少得多,但是对音乐的编码却完全不同,并且需要不同的技巧来使它们听起来不错。
  • 失去您不需要的东西:您能便宜点吗?例如,您是否还能用更少的像素(或多边形)来获得角色的“个性”?设计人员是否需要精确定义图块的位置,或者可以在程序代码中随机生成它们?
  • 代码通常更便宜:尽管您开玩笑说代码编译现在通常需要花费多少空间(并且有理由说明多年来这种“平台”有所增加,以及在绝对需要时缩小它的方式),但通常来说,如果您可以轻松地通过算法/过程/代码进行某些操作,则该方法也将更易于调整和重用于其他类似但外观不同的资产。分形是一个特别容易看到的示例:与生成它的数学公式相比,您可能拥有一张复杂的分形图像,该图像占据了很多空间。另外,该数学公式可以具有可以生成相似但有时令人惊讶地看起来不同的图像的参数。

无论如何,对于如此众多的大量问题,希望上面的一些主题可以成为您学习更多的好起点。


另外,请使用占用较少空间的技术。
speeder 2010年

3
(对不起,请再次输入问题...有一种方法可以禁用它?我讨厌每次按Enter时都会提交评论)。
speeder 2010年

另一个输入:/不管怎样,使用程序地图等占用更少空间的技术(Noctis拥有一个拥有数百万个太阳系的整个星系,您可以在不到3MB的空间内看到行星,生命,树木,废墟,建筑物……) ),模块音乐(格式为.mod,.xm,.it ...等的音乐),程序纹理(请参阅werkkzeug,mapzone和其他一些软件),程序音效(几乎所有音效都可以通过数学方法制作)方程或基本声波的操纵),等等。
加速

@speeder可以很容易地在意外评论上单击“编辑”或“删除” ...
dash-tom-bang 2010年

回复:“压缩您能做的”,在旧硬件上,您通常会压缩到硬件可以处理的一切。您永远都不会将音频压缩到MP3,因为音频硬件无法原生处理音频,并且当您直接将其从媒体流传输到音频硬件时,您也不想浪费时间在CPU上对其进行解压缩。MIDI之所以出色,是因为每个人都拥有(并且拥有)一个波表合成器。只需加载样品,然后就可以开始了。
dash-tom-bang 2010年

0

一件事是我不确定它是否仍会保留在N64后时代,但是SNES和N64经常在其他3D对象上重用纹理,这通常可以节省大量空间,并且可以渲染出背景经常是假的艺术品。另一个技巧是使用边框创建背景雾。

尽管设置可能会更改San Francisco Rush拱廊没有的密度,但San Francisco Rush N64总是有雾,与N64版本相比,您可以看到Track 1上的金门大桥。

另外,游戏经常重用音乐,例如《时代》的《塞尔达传说》,大量重用音乐,我觉得很烦,因为本来可以做得更好的工作,例如Banjo Kazooie / DK64如何经常在主题中包含主题!

塞尔达·奥卡里纳(Zelda Ocarina)曾经有过Hyrule Overworld,然后是主题的水下版本,如果您去水下或使Shop Theme中的乐器反映出笛子和小提琴将被用作Kokiri森林商店和牛角的外部区域。小号为Hyrule城堡镇商店和Goron村庄的鼓等。

在PC中,3D模块被编译成库,以便使用解压缩程序快速访问它们,但是我不确定基于ROM的Nintendo是否会遇到这种情况。PC就像进入一个杂乱的房间那样的RAM,在这里杂乱的事物并不总是停留在它们应有的位置,并且信息可能被覆盖到计算机甚至无法启动的地步!

游戏机是ROM,所有内容都存储在分配的空间中,因此,每次打开游戏时,它都会在该分配的空间中查找文件,并确保将其保留在该空间中。

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.