如何在汇编x86语言中移动例如正方形的形状 [英] how to move shapes for eg square in assembly x86 language

问题描述

按照标题，我知道如何在13h模式下绘制形状，但不知道如何在屏幕上移动它，接下来的事情是强制形状从屏幕边缘弹起，我想在循环中重新绘制形状...但是不确定，因为我刚开始组装，所以我在Tasm工作.感谢您的任何建议.

as per title, I know how to draw shape in 13h mode but have not idea how to move it on screen, next thing would be forcing the shape to bounce from edges of the screen, I think to redraw the shape in loop... but not to sure as I just started with assembly, I work on Tasm. Thanks for any suggestions.

推荐答案

与程序集完全无关.如果您知道如何在13h模式下绘制形状，请进行脑力锻炼.想象一下在第一个位置绘制正方形时视频存储器(a000:0000区域)内容的外观，然后想象在第二个位置正方形时vram的内容.

Not related to assembly at all. If you know how to draw shapes in 13h mode, just do the mental exercise. Imagine how the video memory (a000:0000 region) content looks when you draw the square at first position, then imagine the content of vram when the square is at second position.

这两者之间的差异是达到形状移动效果的各个步骤之间必须要做的最小值.清除整个屏幕并重绘形状将实现此目的，但是您可以想象，对vram的写入要多于所需的最小值.

The difference between those two is the required minimum to do between the steps to achieve that effect of shape movement. Clearing whole screen and redrawing the shape will achieve that, but as you can imagine, with lot more writes to vram than the required minimum.

早期，很多游戏开发人员的研究都花在了尽可能小的变化上，以尽可能在慢速CPU上进行大量图形更改.在某些早期的计算机上，甚至比清除屏幕"之类的简单事情所花费的时间还多于显示单个帧所花费的时间，即，没有撕裂"效果就不可能清除屏幕.在这种情况下，过分幼稚的方法来清除屏幕+在新位置绘制形状会导致形状的大量闪烁(因为某些显示框架将显示清除屏幕而不是形状).

Lot of games dev research in early years was spend to get as near minimal changes, as practically possible, to allow for lot of graphical changes on slow CPUs. At some early computers even something as simple as "clearing screen" may have took more time than single frame on display, i.e. it was impossible to clear the screen without "tearing" effect. In such case that naive approach to clear screen + draw shape in new position would lead to lot of blinking of the shape (as some display frames would show the clear screen instead of shape).

稍后通过双(三重)屏幕缓冲避免了闪烁/撕裂-首先在屏幕外的内存缓冲中准备最终图像，在此期间保持旧图像可见，然后尽可能快地切换整个缓冲区(在某些情况下gfx卡可以切换vram的地址，因此在某些计算机上设置gfx寄存器的操作很便宜，因为您必须逐个字节地将缓冲区复制到目的地.VGA DOS 13h模式允许vram地址设置为IIRC，但可以记不清您是否可以进入另一个64k RAM区域，或者被固定到a000段，从而无法加倍缓冲区).

The blinking/tearing was later avoided by double (triple) screen buffering - preparing the final image in off-screen memory buffer first, keeping the old image visible during that, then switching the whole buffer as fast as possible (on some gfx cards it's possible to switch the address of vram, so it's cheap operation of setting up gfx register, on some computers you had to copy the buffer byte by byte into destination. The VGA DOS 13h mode allows for vram address set IIRC, but can't recall if you can go into another 64k RAM region, or you are pinned down to a000 segment, thus unable to double buffer).

另一种常见的方法是脏矩形"更新技术，该技术首先评估所有移动/更改的图形元素的边界框，计算需要更新的vram区域，然后仅重新绘制这些区域，保持其余vram完整.

Another common approach was "dirty rectangles" updating technique, where you firstly evaluated boundary boxes of all moving/changing graphic elements, calculating regions of vram which needs updates, then you fully redraw only those regions, keeping rest of vram intact.

所有这些只是对视频ram中值的操纵，您可以在汇编，C，pascal等任何情况下以相同的方式执行此操作(实际上javascript + canvas以相同的方式工作，因此所有原理都适用) .现代的gfx API通常提供不错的方法来轻松更新大范围的vram，例如填充形状，绘制精灵(将来自屏幕精灵缓冲区的值复制到vram中)，混合(值不只是写入到vram中，而且还会与旧值混合在一起)混合算法)，等等...

All of this is just manipulation of values in video ram, you can do this in the same way in assembly, C, pascal, whatever... (actually javascript + canvas works in the same way, so all principles apply). Modern gfx API usually offer nice methods to update large areas of vram easily, like fill shape, draw sprite (copying values from off screen sprite buffer into vram), blending (value is not just written into vram, but mixed with old value by some blending algorithm), etc...

实际上，有一种技巧是不要触摸vram本身中的值(这是CPU昂贵的操作)，而是通过更改调色板值(每帧只有几顶帐篷/几百个CPU指令)来产生一些运动错觉，请参阅参考资料.例如: http://www.effectgames.com/effect/article.psp .html/joe/Old_School_Color_Cycling_with_HTML5

Actually one family of tricks was to not touch the values in vram itself (which is CPU expensive operation), but create some illusion of movement by changing palette values (only few tents/hundreds of CPU instructions per frame), see for example: http://www.effectgames.com/effect/article.psp.html/joe/Old_School_Color_Cycling_with_HTML5

因此，如果您不得不问这个问题，那么您可能应该多看几张图像，该图像是如何在显示时创建的，它与视频内存的内容如何相关，以及您可以怎么做.

So if you had to ask that question, you should probably take few more looks how the image is created at display, how it relates to content of video memory, and what you can do with it.

对于另一个精神挑战，谷歌针对Atari 2600规格，它根本没有任何视频RAM，游戏必须通过逐行设置视频芯片寄存器来重新创建图像，同时计算其余部分.两者之间的游戏逻辑.这可以使您更深入地了解计算机如何显示事物.

For another mental challenge, google for Atari 2600 specs, it didn't have any video ram at all, the games had to recreate the image by setting up video chip registers on the fly line by line, meanwhile calculating the rest of the game logic in between. This may give you further deeper understanding how computer displays things.

这篇关于如何在汇编x86语言中移动例如正方形的形状的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！