www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/12/31/08:42:05

From: Elliott Oti <e DOT oti AT stud DOT warande DOT ruu DOT nl>
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
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019