It's from the file format for a 24-bit .BMP file. There are routines
to port BMP to MODE 32 and 33 but not AFAIK to convert mode 32 screens
to 24-bit PC format.
It's to write a routine to convert the screen dumps from Launchpad
running in MODE 32 so I can use them in an information web page for
that program.
Here's the information I have:
[ word is peek(lower)+(256*peek(higher)) ]
;Bitmap file header section;
---------------------------------------
OFFSET SIZE NAME DESCRIPTION
---------------------------------------
0 UINT type (must be BM)
2 DWORD size (size of file in bytes)
6 UINT reserved 1 (value 0)
8 UINT reserved 2 (value 0)
10 DWORD offbits (specifies the byte offset from the file
header structure
to the actual bitmap data in the file)
;Bitmap info section
14 DWORD size (specifies the number of bytes needed by
the BitmapInfo structure)
18 LONG width (width of bitmap in pixels)
22 LONG height (height of bitmap in pixels)
26 WORD planes (number of planes for target device,
should be 1)
28 WORD bit count (bits per pixel,1=mono,4=16 col,8=256
col,24=24 bit colour)
30 DWORD compression (compression type, 0=uncompressed,=8 bit
RLE,=4 bit RLE)
34 DWORD sizeimage (size in bytes of image, may be 0 if
uncompressed)
38 LONG XPelsPerMetre (pixels per metre horizontal resolution)
42 LONG YPelsPerMetre (pixels per metre vertical resolution)
46 DWORD ClrUsed (number of colour indexes in colour table
used by bitmap
0=use maximum colours defined in bit
count)
50 DWORD ClrImportant (specifies number of colour indexes
considered important for
displaying the bitmap. 0=all colours are
important)
;Bitmap graphics data (RGB 3.0)
4 bytes per pixel:
blue
green
red
reserved (must be 0)
The lines of bitmap data are in reverse order, i.e. the first line
stored in the file is actually the bottom line as seen on screen, but
the pixels themselves run left to right as expected.
I think I've sussed most of this out now. If I'm right, the mode 32
graphics would be converted to 24 bit by "approximation" as follows:
Assuming the QL mode 32 image colour word is at address "addr", I
think it should convert to 24-bit format as follows:
blue=8*(PEEK(addr)&&31)
red =PEEK(addr+1)&&248
green=(PEEK(addr)&&224)||((PEEK(addr+1)&&7)*4)
The .BMP file equivalent long word would then be built as follows:
POKE bmp_addr,blue
POKE bmp_addr+1,green
POKE bmp_addr+2,red
POKE bmp_addr+3,0 : rem unused but must be 0
All I would then need to do is build a loop to all the colour words
and build the 52 byte BMP file header
QL_bytes = pixel_width*pixel_height : REMark width should be even?
FOR word = 0 TO QL_bytes-2 STEP 2
REMark above peeks and pokes
END FOR word
REMark build file header once I've sussed it all out!
Getting too tired after 2 weeks of early shifts, resume tomorrow!!!
Perhaps meantime, if anyone understands the above, can they give me an
indication if I am on the right track to build such a program? (PC
stuff does my head in!)
Dilwyn Jones
> Hi,
> Dont know about UINT
> but DWORD and LONG are the same 4bytes, longword but DWORD is
usually used
> by PC programmers so the bytes are in the reverse order from the
> QL/QDOS/Motorolla long word.
>
> Duncan
