Let's Code MS DOS 0x04: Make It Move!

In this third part of the series "Let's Code: MS-DOS" we will add player objects that you can move and animate via the cursor keys. You will learn how to blit sections of the VGA framebuffer to and from program memory. And most important of all: how to avoid screen flicker during redrawing of the scene.

[ian_b]

There's something very relaxing about listening to you talk. Thanks for the videos!

[JamesBowling]

Having so much fun working through these :) Thanks for putting these up!

[teslastellar]

Great tutorial 👍 Thanks again. I appreciate the time and effort you put into these very much.
And just wanted to say that I'm also interested in a more in-depth tutorial about sprites, bit-blitting, transparency, etc if you have time. Will join the forum you suggested as well 😃

[zhulikkulik]

6:01 Shouldn't the second memset save backup to p2.backup instead of p1.backup?

[jukkajylanki]

Nice video! Used to program DOS back in the day, but my memory is really hazy from those days. The video raises some higher level questions on an engine design for more complex games, would love to see the videos discuss a little bit around scalability and general engine design!

1. The 1.25ms vertical refresh period. Maybe a Pong game will be able to repaint within that time, but it is likely not a design that can scale to more complex games? Because of that, one would naturally double buffer the game, and only blit a full frame within a vertical refresh. However, how feasible/costly would that kind of a full VGA frame blit be? I presume it should be well doable within a 1.25ms retrace period? (or otherwise DOS game development would be pretty constrained?) Now I'm curious about the fill performance of e.g. a 386 16MHz: how many pixels/second would it be able to move? (and was mem->vga memcpy the same cost as general mem->mem memcpy, or did a write to VGA memory have additional perf penalty?)

2. The backup-restore paint stack algorithm: Would have been good to have the code diligently do the restores in a reverse order from the paint to highlight the correctness of the algorithm. I recall programming up a paint stack implementation back in the day, but now I am wondering whether more complex games actually used that algorithm at all? E.g. say Raptor, where each pixel practically changes on the screen each frame? Although several of those background pixels scroll, so I wonder if Raptor would use the backup-restore paint stack algorithm: first restore the moved sprites, then scroll the background, then paint the moved sprites; or would it just redraw everything every frame like modern games do?

3. Wait for vblank: is there a way to get the actual vsync line counter, as opposed to a single bit telling if the display is in a vblank? If so, then it would be possible to start blitting immediately after the vsync line count has passed the sprite positions, as those scanlines would effectively already be in vblank. Of course that would only work if one knows they will be able to finish painting all sprites within the vblank period to get a complete frame, but that could improve performance overall. Was such "racing the beam" kind of code possible in DOS?

[psionski]

5:48 “make sure to get everything”... <leaves memset to p1.backup>

[nihonam]

why do you use prefix increment in for()? doesn't it make count from 1 instead of 0 ?

[jeppy]

Can you make a video on writing text in graphics mode....like the score and stuff

[nihonam]

can you provide me with some contact where we can discuss VGA bitblt topic in extended way with code examples?

[luisdardis]

hi to all, somebody knows where can i find a dos real mode programming tutorial about cga(rgbi-composite) ? ty in advance.