The first place to start is to ask if you are already using double buffering or not. You really can't get smooth motion across the screen of any kind if you aren't. The basic idea is to have two copies of the video display memory, one which is in use by the monitor, the other of which is 'shadowed', preferably both inside the video buffer but on different memory 'pages'. You would draw to the shadowed copy, then 'flip' them by changing which of the video memory pages is being used.
You might actually want to have a third copy in main memory as well; this allows you to perform the editing there, then copy it to the shadowed page before flipping. On modern systems, unless the system is using an integrated GPU that is 'sharing' main memory with the CPU, main memory is usually faster to access than video memory even when the video memory has a faster clock rate (since the main memory is connected more immediately to the CPU through what is called the 'memory local bus', and doesn't have to pass through the PCI bridge), and for non-integrated video, it also leaves the bus connection free more of the time.
(This doesn't mean that integrated video is better; quite the opposite, usually, as the CPU and GPU can end up fighting for contention over the shared memory local bus, and with most local bus arrangements the GPU usually accesses it slower than the CPU even if the CPU is idle. Integrated video with a separate video memory might be slightly faster than an expansion bus card, but the CPU generally still won't get local bus speeds accessing that, so it's pretty much the same as with the separate video card.)
Similarly, you probably will need to sync or latch the vertical refresh, to ensure that you are only writing to the video memory between refresh cycles. This goes hand in hand with double buffering, as the former allows you to create a new image off-screen, but you still need to make sure that you don't flip the pages during a vrefresh, as that could lead to screen tearing (which isn't as serious for 2D games as it is for 3D games, unless it is happening so often that it makes it hard to make out what is going on, but it still looks sloppy).
Most video display systems today have hardware support for this, and much more besides, but for a retro VGA program, you probably won't want (or be able) to use those, especially if it is actually running it under MS-DOS or a workalike such as FreeDOS (since pretty much no one has been providing MS-DOS drivers for their new video cards in the past twenty years, and even if you were willing to write one yourself, you'd have trouble getting the necessary information even for an 'open' one). Just what you'll be able to use in terms of card-specific hardware will depend on which card you are using, the availability of a driver, and just how 'authentic' you mean to make it (i.e., if you stick to just the VBE routines, then you will be limited to the common set of operations supported by VBE).
_________________ Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF Ordo OS Project Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
|