From: Elliott Oti Newsgroups: comp.os.msdos.djgpp Subject: Re: graphics Date: Mon, 30 Dec 1996 23:46:02 -0800 Organization: Academic Computer Centre Utrecht, (ACCU) Lines: 23 Message-ID: <32C8C4BA.6FBC@stud.warande.ruu.nl> References: <1 DOT 5 DOT 4 DOT 16 DOT 19961218230509 DOT 19f7ab66 AT mail DOT algonet DOT se> <5a4pjc$5b2 AT nr1 DOT vancouver DOT istar DOT net> <01bbf68d$e5e607e0$cc2549c2 AT default> NNTP-Posting-Host: warande1078.warande.ruu.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Thomas Harte wrote: > I wrote it somewhere else, but for anyone who only reads this message, I > just wanted to add that you can use a shortcut based on the fact that > 256+64 = 320, that 2 to the power of 8 is 256 and 2 to the power of 6 is > 64, and that binary is based around two options. Therefore, using the > correct bit-shifts, you can change the line to :- > > _farpokeb(_dos_ds, 0xA0000 + (y << 8) + (y << 6) + x, colour); > > . . . .which is faster. Quibble, quibble: Since djgpp does strength reduction effortlessly, you get the shifts anyway. I'm sure somebody's pointed this out already, but putting in explicit shifts can slow your code ( I've timed some examples !). Anyway the big slowdown is that you keep setting the selector _dos_ds every time you draw a pixel; set it once with farnsetsel() and use farnspokeb() to poke your pixels instead: that's a bigger speed increase. Or how about using near pointers: everybody speaks woe of them, but they're fast, and I like 'em. Elliott