From: broeker AT acp3bf DOT knirsch DOT de (Hans-Bernhard Broeker) Newsgroups: comp.os.msdos.djgpp Subject: Re: Plague of the slow 'blit' routine :) Date: 22 Oct 1999 14:55:28 +0200 Organization: RWTH Aachen, III. physikalisches Institut B Lines: 24 Message-ID: <7upms0$3c1@acp3bf.knirsch.de> References: <380F58BD DOT 9FDDC7CF AT connect DOT ab DOT ca> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 940596931 14303 137.226.32.75 (22 Oct 1999 12:55:31 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 22 Oct 1999 12:55:31 GMT X-Newsreader: TIN [version 1.2 PL2] To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Tom Fjellstrom (tomcf AT connect DOT ab DOT ca) wrote: [...] > Because I want to call the same routine on any bitmap whether or not > it's a regular bitmap, the screen, or a sub bitmap of the screen. Excuse me repeating myself, but I think this point really needs some stressing: you have a serious design problem, here, and there's no way your choice of nearptr() vs. far*() methods will get you out of it. Reading off screen memory, like you are planning to do, here, is *extremely* inefficient. Shawn Hargreaves once gave more precise numbers, IIRC, but in the essence, reading from screen memory is usually about a factor of 10 or so slower than writing to it. Compared to main memory access speed, the slowdown is even worse. So, if you want it fast: Avoid reading from screen memory --- it's awfully SLOW The usual solution is to do all the drawing, copying and whatnot in main memory, alone, and only after that's complete, blast the whole image to the screen, in one blit(). -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.