动态（算法）图形技术
我正在为 内存有限的 32 位处理器编写应用程序（512k 闪存，32k RAM）。
此设备上的显示为 128x160，具有 16 位颜色，如果我要在处理器上缓冲它，通常会消耗 40k 内存。 我没有那么多 RAM，所以我正在寻找动态生成屏幕数据的技术、技巧、窍门和想法。
可能有帮助的事情：
- 也许您知道解决此类限制的资源
- 也许您已经动态生成了有吸引力的图形
- 是否有一种通用算法，我可以使用它来动态组合程序内存中的元素（包括阿尔法混合）扫描显示器
- 简单的矢量渲染技术（或免费（bsd/mit/apache）源）
- ???
我确实有乘法器，但没有浮点处理器。 显示器本身有一个非常简单的控制器和显示器内存 - 但读取和写入成本很高，因此如果可以避免的话，我不想将其用作我的工作区。
-亚当
I'm programming an application for a 32 bit processor with limited memory (512k flash, 32k RAM).
The display on this device is 128x160 with 16 bit color, which would normally consume 40k ram if I were to buffer it on my processor. I don't have that much RAM, so I'm looking for techniques, tips, tricks, ideas for generating screen data on the fly.
Things that might help:
- Perhaps you know of a resource for this sort of limitation
- Maybe you've generated attractive graphics on the fly
- Is there a generic algorithm I might use to combine elements in program memory (including alpha blending) on the fly while I scan the display
- Simple vector rendering techniques (or free (bsd/mit/apache) source)
- ???
I do have a multiplier, but no floating point processor. The display itself has a very simple controller and memory for the display - but reads and writes are expensive so I don't want to use that as my workspace if I can avoid it.
-Adam
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在某种程度上，游戏开发者的处境与 Tandys、Spectrums 和早期 PC 时代的情况几乎相同。 所以，这是我的建议：
你应该阅读 Michael Abrash 有关计算机图形学的著作。 它们是在浮点协处理器是可选硬件的时代编写的，它们描述了旧的（据说是“糟糕的”）软件渲染时代使用的许多基本技术（布雷森汉姆线等） 。
您可以此处阅读他的大部分“黑皮书”。
此外，您可能还可以找到许多以前大多数人用来学习图形编程的旧 BBS 文件 这里。 只需搜索图形、线条等即可。
希望有帮助！
更新：我还记得在我的中使用这个第一次尝试在屏幕上绘制东西。 无法说出我花了多少时间试图理解其背后的数学原理（好吧，公平地说，我当时大概 15 岁）。 非常好的（而且简单的）3D 介绍，也是关于变换、多边形填充和插值的非常好的入门文章。
In a way, you are in pretty much the same situation game developers where at the time of the Tandys, Spectrums and early PCs. So, here's my recommendation:
You should read Michael Abrash writings on computer graphics. They were written in a time where a floating point co-processor was an optional piece of hardware, and they describe a lot of the basic techniques (Bresenham lines, etc.) used in the old (supposedly 'bad') software-rendered days.
You can read most of his "Black Book" here.
Additionaly, you can probably find a lot of the old BBS files that most people used back in the day to learn graphics programming here. Just search for Graphics, Lines, and what not.
Hope that helps!
Update: I also recall using this in my first attempts at drawing things on the screen. Can't tell how much time I spent trying to understand the maths behind it (well, to be fair I was like 15 at the time). Very good (and simple) introduction to 3D, and a very nice premier on transformations, polygon-fillers and interpolation.
您将在屏幕上显示什么样的数据？
如果不是摄影图像，您可以考虑使用调色板。 例如：使用每像素 8 位的 256 调色板将需要 20kb（加上用于查找表的 256 x 2 字节），这至少比 40kb 好。
What kind of data will you show on the screen?
If it is not photographic images, you could consider using a palette. For instance: A 256 color palette using 8 bits per pixel would require 20kb, (plus 256 x 2bytes for the lookup table) which at least is better than 40kb.
我认为处理这种情况的基本技术是将屏幕划分为狭窄的水平条纹，并且只在 RAM 中缓冲两个这样的条纹。 将显示一个条纹，同时向下渲染下一个条纹。 当扫描“光束”击中下一个条纹时（并发出一个中断供您捕捉），您交换两者并开始向下绘制下一个条纹。
这样做的一个令人讨厌的副作用是，您对渲染每个条带的时间有严格时间限制。 所以我想坚持使用一些无聊但具有可预测性能的东西是很诱人的，比如精灵。
有点离题，但这就是 Nintendo DS 3D 硬件的工作原理。 如果您尝试在同一 y 坐标周围渲染太多多边形，您会看到它 - 当屏幕刷新超过渲染硬件时，多边形会随机闪烁并消失。
另外，我赞同另一张海报的建议，即您使用调色板渲染。 在 16 位像素上进行快速数学运算非常困难，但如果您巧妙地布局调色板，则在 8 位像素上会更快。
I believe the basic technique for dealing with this kind of situation is to divide the screen into narrow horizontal stripes, and only buffer two such stripes in RAM. One stripe will be displayed, while you render the next one down. When the scanning 'beam' hits the next stripe (and fires off an interrupt for you to catch), you swap the two and start drawing the next stripe down.
A nasty side-effect of this is that that you have hard timing limits on how long you can spend on rendering each stripe. So I guess it would be tempting to stick with something boring but with predictable performance, like sprites.
Slightly offtopic but this is how the Nintendo DS 3D hardware works. You can see it if you try to render too many polygons around the same y-coordinate - polys will randomly flicker and drop out as the screen-refresh overtakes the rendering hardware.
Also, I'd second the other poster's suggestion that you use palettised rendering. It's very hard to do fast maths on 16bit pixels, but faster in 8bit if you're clever about how you lay out your palette.
一些将漂亮的图形和低内存结合起来的想法：
Some ideas that would combine nice graphics and low memory: