Mail Archives: djgpp/1996/02/07/03:56:15
In article <DM0wwA DOT HJ2 AT granite DOT mv DOT net>,
William Parsons Newhall, Jr. <NEWHALL AT american DOT edu> wrote:
>In using a main memory (dare I say "virtual") frame buffer, do you have
>a timer driven interrupt requesting a screen copy N times per second, or
>do you only update the screen after something has been drawn(like after a
>polygon fill or line draw)?
This is a good way of accessing the screen and if done properly, it can
help when porting a program to X, Win-G, or OS/2 DIVE as that is how
things are often done in those environments. The DOS timer tick gives
you a reasonable 18.2 fps. The tough part under DOS is making sure your
code is reentrant. A skeleton interrupt routine would look something
like this....
void video_blit()
{
if (cli() && buffer_has_changed() && !buffer_in_use() && set_buffer_in_use())
{
sti();
blit_buffer_to_screen();
unset_buffer_has_changed();
unset_buffer_in_use();
unset_draw_int_pending();
} else {
set_draw_int_pending();
sti();
}
the drawing code would also need to be enclosed in such an if statement.
void draw_to_buffer()
{
if (cli() && !buffer_in_use() && set_buffer_in_use()) {
sti();
draw_some_stuff();
set_buffer_has_changed();
unset_buffer_in_use();
if (draw_int_pending()) video_blit();
} else sti();
}
Real operating systems have semaphores to handle such eventualities.
Another concern is how long the blit will take. For an ISA graphics board
with a 2MB/second transfer rate, transfering 1 frame will take you 32
milliseconds, leaving you 23 milliseconds to handle everything else. If
you're in this boat, your probably better off drawing directly to the
screen buffer to save time.
If you have a VLB or PCI board, this method will probably work fine.
Eric
--
Eric Korpela | An object at rest can never be
korpela AT ssl DOT berkeley DOT edu | stopped.
<a href="http://www.cs.indiana.edu/finger/mofo.ssl.berkeley.edu/korpela/w">
Click here for more info.</a>
- Raw text -