高位字节 低位字节

by Colt McAnlis

通过Colt McAnlis

所有字节从何而来？ (Where do all the bytes come from?)

Great question Dion! I will answer it, and not justbecauseyou’re my new boss, but because it’s a good question. (but also because you’re my new boss.)

狄翁大问题！ 我会回答的，不仅仅是因为你是我的新老板，而且因为这是一个很好的问题。 (也是因为你是我的新老板 。)

I want to set something clear here though : we’re not really comparing Apples-to-Apples, so let’s define some technologies first.

不过，我想在这里说清楚一点：我们并没有真正将Apple与Apple进行比较，所以让我们先定义一些技术。

马里奥如何运作 (How Mario Works)

So let’s talk about how the original Super Mario game worked, from an asset perspective.

因此，让我们从资产角度谈谈原始的《超级马里奥》游戏是如何工作的。

The original NES console was only designed to output images that were 256 wide by 240 high; meaning that the final image that needed to be displayed to the screen was 180kb in size.

最初的NES控制台仅设计为输出256宽x 240高的图像； 表示需要在屏幕上显示的最终图像大小为180kb。

Besides that, the NES only had 2kb of RAM. A cartridge itself could could hold 8k to 1mb of game data. So, there was no way to fit the entire game’s contents into main memory. Basically, a subset of the 1MB cartridge data must be loaded into the 2kb RAM and used to render the 180kb screen. How does one achieve that?

除此之外，NES仅具有2kb的RAM。 盒带本身可以容纳8k到1mb的游戏数据。 因此，没有办法将整个游戏的内容放入主存储器中。 基本上，必须将1MB盒带数据的子集加载到2kb RAM中，并用于渲染180kb屏幕。 如何做到这一点？

SpriteSheets.

SpriteSheets 。

Sprite sheets contain small tiles of graphics, that are re-used over and over again. For example, below is a remake of the original super mario sprite sheet:

Sprite工作表包含小块图形，这些图形块可重复使用。 例如，以下是原始超级马里奥精灵表的翻版：

Each small 16x16 pixel square represents a “tile” and artists would string these together to create the actual levels. The levels themselves, just became a giant 2D array of indexes into the sprite sheet. (I talk about this in a lot more detail in Lesson 3 of my HTML5 Game Development course @ Udacity, or in my book HTML5 Game Development Insights.) Tack on some Run-Length-Encoding, or some basic LZ77, and you get a fairly compact format for levels.

每个16x16像素小方块代表一个“平铺”，艺术家会将它们串在一起以创建实际的水平。 这些关卡本身就变成了一个包含在Sprite表中的巨大2D索引数组。 (在我的HTML5游戏开发课程@ Udacity的第3课中，或在我的书HTML5 Game Development Insights中，我对此进行了更详细的讨论。)了解一些Run-Length-Encoding或一些基本的LZ77 ，您将获得一个相当紧凑的关卡格式。

So with concepts like tile-sheets and sprite-sheets, we can use a small set of images to create large scenes & worlds. This is generally how most games work. Even 3D games will have a set of common textures that are applied multiple times and places throughout the game itself.

因此，使用图块图和子画面图等概念，我们可以使用少量图像来创建大型场景和世界。 通常，这就是大多数游戏的工作方式。 甚至3D游戏也将具有一组通用纹理，这些纹理在游戏本身中会被多次应用和放置。

Now let’s talk about generic image compression.

现在让我们讨论通用图像压缩。

图像如何压缩 (How Images are compressed)

Here’s the “not fair” part of this comparison. Generic image compression algorithms have no domain knowledge about the pixels inside of them. JPG, PNG, WebP have all been designed forphotosand not so muchgame screens. The result is that for a given 16x16 pixel block, these algorithms assume it’s unique among the image; Besides some color quantization, there’s no real logic added to determine if another 16x16 block could be anexact duplicateof the current one. This generally means there’s a lower-bound on how a given block of data is compressed.

这是此比较的“不公平”部分。 通用图像压缩算法不了解其中的像素。 JPG，PNG，WebP都是为照片而设计的，而没有太多游戏屏幕。 结果是，对于给定的16x16像素块，这些算法假定它在图像中是唯一的。 除了一些颜色量化之外，没有添加任何确定其他16x16块是否可以与当前块完全相同的真实逻辑。 通常，这意味着如何压缩给定的数据块。

For example, JPG breaks a given image into 8x8 pixel blocks, converts the RGB color space into the YCbCr version, and then applies Discrete cosine transform on them. It’s onlyafterthis step, does a lossless encoder come along, and see if it can match up common duplicate groups using DPCM, or RLE.

例如， JPG将给定的图像分成8x8像素块，将RGB颜色空间转换为YCbCr版本，然后对它们应用离散余弦变换 。 仅在此步骤之后，才会出现无损编码器，并查看它是否可以使用DPCM或RLE匹配常见的重复组。

So, the only place where two blocks might get compacted into 1 block, is if their post-DCTd version is identical, and RLE can make stride recommendations. This doesn’t happen that often.

因此，将两个块压缩为1个块的唯一地方是它们的后DCTd版本是否相同，并且RLE可以提出重大建议。 这种情况不会经常发生。

Despite its other flaws, PNG is much better in this regard. PNG compression is entirely lossless, (so your image quality is high, but your compression savings are low), and based on the DEFLATE codec, which pairs LZSS along with Arithmetic Compression. The result is that long runs of similar pixels can end up being cut down to a much smaller size. This is why an image with a very uniform background will always be smaller as a PNG instead of a JPG.

尽管存在其他缺陷 ，但PNG在这方面要好得多。 PNG压缩是完全无损的(因此，图像质量很高，但是压缩节省量很低)，并且基于DEFLATE编解码器，该编解码器将LZSS和算术压缩配对。 结果是，长距离运行的类似像素最终可能会被缩小到更小的尺寸。 这就是为什么背景非常均匀的图像将始终以PNG(而不是JPG)较小的原因。

下图是5.9kb PNG文件，而JPG图是106kb (The below image is a 5.9kb PNG file, while the JPG image is 106kb)

苹果与火龙果 (Apples vs. Dragonfruit)

My point here is that it’s kinda unfair to compare game content to a single image on the internet.

我的意思是，将游戏内容与互联网上的单个图像进行比较有点不公平。

From the game side, you start with a small set of re-usable tiles, and index them to build up your larger image, we can do this, because we know how the game is going to be made. On the other side, JPG/PNG/WebP just tries to compress the data it can find in local blocks, without any real desire to match repeated content. Image compression is clearly at a disadvantage here, since they don’t have prior knowledge of their data space, they can’t really make any expectations about it.

从游戏的角度出发，您从一小套可重复使用的图块开始，并对它们进行索引以建立更大的图像，我们可以这样做，因为我们知道游戏的制作方式。 另一方面，JPG / PNG / WebP只是尝试压缩它可以在本地块中找到的数据，而不需要任何真正的愿望来匹配重复的内容。 图像压缩显然在这里处于不利地位，因为他们没有数据空间的先验知识，因此他们无法对此真正抱有任何期望。

I mean, consider The Demo Scene which is super big on this sort of thing. They can cram 30minutes of an entire 3d shooter into 64kb because they understand and know so much more about their data.

我的意思是，考虑演示场景是在这个超级大之类的事情 。 他们可以将整个3d射击游戏的30分钟填充为64kb，因为他们了解并了解有关数据的更多信息。

It just goes to show, with the right amount of foreknowledge about your data, you can do great things with compression.

它只是说明了，有了对数据的适当了解，您就可以通过压缩完成许多事情。

期待。 (Looking forward.)

Obviously, we’ve grown up since the 256x240 displays of the NES days. The phone in my pocket has 1,920 x 1,080 display pixels @ it’s 5.2” size, giving it ~423 pixels per inch density. To compare that in the same number of pixels that’s ~33 super-mario screens, or rather, 8MB of pixel data. I don’t think anyone’s surprised that screen resolutions are increasing, but it also comes with the need formore data.

显然，自NES时代的256x240显示器以来，我们已经成长。 我口袋里的手机显示像素为1,920 x 1,080(@ 5.2英寸)，每英寸密度约为423像素。 要以相同数量的像素(约33个超级马里奥屏幕)或8MB像素数据进行比较。 我不认为有人会为屏幕分辨率提高而感到惊讶，但这还伴随着更多数据的需求。

This is something I’ve been harping on for a while now. While we get bigger displays, the content channels need to up their resolution outputs in order to still look good on our higher-density setups (otherwise, we get scaling blurryness..). This of course, causes our video game packages to grow in size, our web-pages to grow in size, and even our youtube streaming videos to grow in size. Basically, we’re sending more data to smaller devices simply due to screen resolution. Which, for the next 2 billion folks in emerging markets, on 2G connections, is like the worst idea ever.

这是我现在一直在努力的事情了 。 当我们获得更大的显示器时，内容通道需要提高其分辨率输出，以便在更高密度的设置上仍然看起来不错(否则， 我们会得到缩放模糊。 )。 当然，这会导致我们的视频游戏程序包增大，我们的网页大小增大 ，甚至YouTube流媒体视频的大小增大。 基本上，仅由于屏幕分辨率，我们就将更多数据发送到较小的设备。 对于新兴市场中的未来20亿人口，在2G连接上，这就像有史以来最糟糕的想法。

But I digress. That’s a different post.

但是我离题了。 那是不同的帖子。

翻译自: /news/where-do-all-the-bytes-come-from-f51586690fd0/

高位字节 低位字节