Now the whole idea behind an offscreen buffer is to create a seperate, temporary writing area, kind of like scratch paper. Things may get written on, written over and many things may happen before a final image is created. After it has been created, we move the offscreen buffer to the VRAM as quickly as possible. This creates smooth transitions on the screen to the user, and it doesn’t show all the horrible steps leading up to the production of the final picture. This method sounds pretty sound, but we are forgetting one major problem. It is most likely that while we are trying to push our offscreen buffer into VRAM, the monitor will be redrawing the screen. This means if the monitor gets past where we are in filling in VRAM, then it will display the old picture. This creates a dreaded flickering effect that makes anything horrible! The answer to this is to wait for the monitor to give us the signal that its about to start refreshing the screen from the top. Once we get the signal, we can fill in VRAM normally without any worries. Here’s another big plus for us. If we hadn’t used the buffer then every time the screen refreshed itself, who knows what would be displayed on the screen, all the steps would show up, and that would look horrible!?
Another use, along with the previous, is to elliminate sprite clipping. This doesn’t seem to be a really popular practice, but with some games, specifically 2-d paralax scrolling or tile based, it works really well. ID software used this method in Wolfenstein. All they had to do was increase the width of the offscreen buffer by however wide the largest sprite could ever get. This was a great solution because most of the characters were tall, not wide. When it came time to blit the offscreen buffer to VRAM, they would take out the chunk that they needed, leaving the overlapping portion on the buffer.
Hooking up with the Vertical Retrace
When refreshing the video screen, if you are halfway through updating, and the refresh beam passes you up (it refreshes your new area and then starts updating the area which you haven’t reached yet) you will get a screen with only half of it updated, while the other portion remains with the old data. This causes a tremendous amount of screen flicker that can really ruin things.
The answer to this problem is update our screen during a Vertical Retrace. This is when the electron beam is moving from the lower right to the upper left of the screen. Since Vram is not being accessed during this time, we can work with it at a much faster rate. Here’s the code to pull it off:
The Code
-
while(inp(0x3DA) & 0×08);
-
while(!(inp(0x3Da)&0×08));
We are reading the Input Status Register, which is one of the video card’s General Registers. We test bit 3 to see if it is set. If it is, then we know that a vertical retrace is taking place. Its just that simple. Although it looks like this will slow our routine down, it won’t! This is because the video card will not insert wait states into the memory accesses that change the video memory during the retrace. We use two while’s because if we detect that the video card is doing a retrace, we don’t know if it is in the middle, beginning or end, so lets wait for the next one, then we’ll be sure to hit it on time.