delorie.com/archives/browse.cgi | search |
Newsgroups: | comp.os.msdos.djgpp |
From: | tob AT world DOT std DOT com |
Subject: | Re: Allegro loads graphics funny... |
Message-ID: | <EK6tBr.7Ju@world.std.com> |
Sender: | tob AT world DOT std DOT com (Tom Breton) |
Reply-To: | tob AT world DOT std DOT com |
Organization: | BREnterprises |
References: | <m3pvnrccoo DOT fsf AT H-Bukin DOT inp DOT nsk DOT su> |
Date: | Tue, 25 Nov 1997 05:45:27 GMT |
Lines: | 40 |
To: | djgpp AT delorie DOT com |
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp |
Michael Bukin <bukinm AT inp DOT nsk DOT su> writes: > This scheme is not symmetrical. It will be more symmetrical > if you take central pixel from each box as a value for target pixel. Right. The heart of the Allegro routine for big->little goes like so: else { /* little -> big scaling */ x2 = sx >> 16; COMPILER_LODSB(); for (x=0; x<dest_width; x++) { if (masked) { COMPILER_MASKED_STOSB(); } else { COMPILER_STOSB(); } sx += sxd; if ((sx >> 16) > x2) { COMPILER_LODSB(); x2++; } } } ...but to be symmetrical it should start off with an half-increment... sx += sxd/2; ...which requires turning the loop around a bit so that the test for compensation... if ((sx >> 16) > x2) { COMPILER_LODSB(); x2++; } ...comes first. The 15, 16, 24, and 32 are parallel to this AFAICS. Tom
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |