From: Geza Herman Newsgroups: comp.os.msdos.djgpp Subject: Re: Getting the fastest running Date: Tue, 6 Jan 1998 14:58:49 +0100 Organization: Technical University of Budapest Lines: 32 Message-ID: References: <1B174837C8E AT fs2 DOT mt DOT umist DOT ac DOT uk> NNTP-Posting-Host: kempelen.inf.bme.hu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <1B174837C8E@fs2.mt.umist.ac.uk> To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk > Geza Herman replied:- > > Why must you copy? You can write directly to vid.mem. ... > > I must copy because setting up the screen display involves writing and then > overwriting (1) parts of the background which are hidden by objects, (2) parts > of objects which are hidden by other objects. Compare the old and troublesome > `hidden line' problem. If I wrote directly to screen, this hidden matter would > keep flashing in and out of view. How can I tell the PC's graphics card not to > redisplay the screen while I am writing a display to it? > Ah. If you use VESA modes, you are able to write to a backscreen. Use the SetDisplayStart function. Of course, this works if you have enough video memory( for example in 640x480x256c you have to have 1Mb ). But of course, buffering sometimes makes better results( for example, if you read this buffer as well ). I disagree with Eli, because the video memory is very fast in today machines( not 10 times slower ). I experienced the following results( 486Dx2-66, Cirrus 5428 vid.card ): system mem->system mem: 15Mb/sec system mem filling: 55Mb/sec system mem->video mem: 6.5Mb/sec video mem filling: 10.5Mb/sec ( and Cirrus is an average card. S3 is much better ) Of course, with no cacheing. And the dosmemput/get functions is very optimized. But the fastest is memcpy( because memcpy is inlined ) if you copy little buffers.( if you copy large buffers, the speed is the same ) Regards, Geza