how to move shapes for eg square in assembly x86 language

Question

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

Answer 1

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.

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.

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).

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).

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.

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...

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.

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.