www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/07/05/21:13:57

Message-Id: <199807060112.CAA10613@sable.ox.ac.uk>
Comments: Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: rylan AT inbtekom DOT co DOT za
Date: Mon, 6 Jul 1998 02:06:55 +0000
MIME-Version: 1.0
Subject: Re: Allegro Bitmap Sizes
Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk
CC: djgpp AT delorie DOT com

On  5 Jul 98 at 16:49, Rylan wrote:

> I've run accros a little strange thingy:
> 
> This code
[snipped]
> draws only HALF the width of the Allegro bitmap on the screen. Yet, if I
> look at this particular bitmap in the grabber, the width is given as 276
> pixels, which is the same value in datafile[Rylan_BMP].dat->w. However,
> using 2 x 276 with the above code (the two nested loops) draws the whole
> bitmap. Why? Why does this not apply to the height
> (datafile[Rylan_BMP].dat->h?) Is this some kind of optimization?
> 
> BTW: GFX mode for this is 640x480x16bit.

16 bits need two bytes.  The `w' field is in pixels, but the `line' 
field is an array of pointers to sequences of chars.  In each 
sequence there are enough chars for `w' pixels -- that is w*2 chars 
in 16 bpp modes.

Perhaps it's better to cast to `short *' before accessing the pixels, 
since you're in 16bpp mode:

|   ((short *)(pbmp->line[loop2]))[loop] =
|     ((short *)(((BITMAP *)datafile[Rylan_BMP].dat)->line[loop2]))[loop];

Hopefully all those brackets make it clear what's going on.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk

- Raw text -


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