Re: [ql-users] C structures
Wolfgang Lenerz wrote: BTW: I'm back. Will probably start answering mails tomorrow. Did you win? Nah, but we didn't really expect to win. Other teams are years of development ahead and have a much higher motivation (e.g. being freed from the military service like IIRC the Persian team). We did it more or less for fun ;-) Marcel
Re: [ql-users] C structures
Phoebus Dokos wrote: You could also get BMP2SCR from Malcolm and use it in reverse (trivial to do so and from the quick look I gave to your code you're on the right track). Just had a quick look (it's on disk GE104 in my PD library) . However, it doesn't explain the file structure except how to check it's 24 bit and picture size. But it does show how to do the approximation of 24 bit colour to 16 bit QL colour (i.e. how to convert 8 bit RGB component to 5 or 6 bit GD2 colour components - simply lop off the extra info, you then simply get coarser steps of colour, so instead of values 0-31 for a bit GD2 colour you get 0-255 step 8 in 24-bit colour). A bit mind bending for a simpleton like me, but I'll get there ;-) And (I don't know if you mentioned it in your message as I really didn't read it through, just a quick look) always remember that the lines on the bmp are stored upside down :-) Err, yes, that did throw me a bit when I had a first crack at the program. You realise your code works then it slowly sinks in that the picture's upside down! I do have a full program ready that does that, however you're killing yourself with no reason. Just press Print Screen while you're running QPC and then paste it in your favourite graphics editor :-) Presto you're screen capture is complete :-) Point taken about using PrintScreen etc, but I wanted to write a simple piece of code to insert in one of the Launchpad utilities, hence the reason for killing myself. With some help from Geoff Wicks, I got the Windows character translations (as opposed to DOS ones). With (as yet) no GD2 screen dumps, the best interim option seemed to be to allow for export of QL GD2 graphics to PC formats and BMP seemed the easiest to get going as I didn't have to wrestle with compression. I want to try to look at the possibility of getting a PC program to do the printing, to see if the QPC_EXEC command could be persuaded to fire up a Windows or DOS program, load a file and make it print since Marcel has kindly put the abilty to fire up a PC program in QPC2. After all, I'm not asking the PC to do anything File Info II can't do for a QL program :o) I do already use PrintScreen but in addition to the file exporting I mentioned, I can also write a batch converter for Launchpad which can be left to get on with it in its own time (overnight perhaps) rather than have to do all that cutting and pasting manually. Marcel Kilgus wrote: blue=8*(PEEK(addr)31) red =PEEK(addr+1)248 Those are 5 bit, i.e. from 0 to 31. green=(PEEK(addr)224)||((PEEK(addr+1)7)*4) *8 This is 6 bit, i.e. from 0 to 63. Conversion to 8 bit is needed, of course. 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 IIRC BMP data is 24 bit, i.e. without the 0. There seems to be two formats, RGB Quad 3.0 using 4 bytes (the fourth of which seems to have to be reset, presumably so software can manipulate the 32 bits without having stray bits floating around to corrupt the values) and RGB 2.x which uses 3 bytes per pixel, which seems hard to manipulate. Although the 24 bits-of-32 seems wasteful. it's easier to manipulate. QL_bytes = pixel_width*pixel_height : REMark width should be even? Every BMP single screen line must be padded to a 4 byte boundary. Ah yes, it does say that in my notes, I just missed it. But if I use the 32 bit format this would just happen anyway. Thanks Marcel, Phoebus and others who helped me with this. Although there are programs for the QL which do the conversion I want to some degree, I wanted to write my own fairly simple code (speed not too important) to insert in my own programs. I downloaded some free docs from the web on various PC file formats - BMP, GIF, JPG, PNG, TIF etc - if anyone wants them they're on disks GE145 and GE146 in the library. If there's enough interest I could put them onto my websites for download (might help stimulate development of GD2 graphics-ware). If I do come upwith a reasonable SBASIC program to do the BMP conversion I might print it in QL Today as a follow up to my recent GD2 article, if it wouldn't be hypocrisy having an article about a Windoze file format! -- Dilwyn Jones
Re: [ql-users] C structures
On Sat, 12 Jul 2003 08:49:49 +0100, Dilwyn Jones [EMAIL PROTECTED]
wrote:
Phoebus Dokos wrote:
You could also get BMP2SCR from Malcolm and use it in reverse
(trivial to
do so and from the quick look I gave to your code you're on the
right
track).
Just had a quick look (it's on disk GE104 in my PD library) . However,
it doesn't explain the file structure except how to check it's 24 bit
and picture size. But it does show how to do the approximation of 24
bit colour to 16 bit QL colour (i.e. how to convert 8 bit RGB
component to 5 or 6 bit GD2 colour components - simply lop off the
extra info, you then simply get coarser steps of colour, so instead of
values 0-31 for a bit GD2 colour you get 0-255 step 8 in 24-bit
colour). A bit mind bending for a simpleton like me, but I'll get
there ;-)
snip
The complete file format ('new' format which is the most common) (more like
the complete header of the BMP format is as follows):
Offset Field Size Contents
000h Id 2 bytes (Insert here 'BM' for BMP image file. Other options are
possible as well)
002h FSIZE 4 bytes Full file size in bytes
006h RESVD 4 bytes Reserved (Pad with 0s)
00Ah BMPD_OFF 4 bytes Offset of the beginning of bmp data from the
beginning of file
00Eh BMPH_SZ 4 bytes Length of the BMP Info Header (what describes bmp
colours, compression... possible sizes are:28h - Windows, 0Ch OS2 1.x, F0h
OS 2.x
012h WD 4 bytes Width of image in pixels
016h HT 4 bytes Height of image in pixels
01Ah PL 2 bytes # planes in the picture (not the flying kind ;-)
01Ch BPP 2 bytes BPP used for palette info. (Possible colours of sorts).
Possible values
1 - Mono, 4 - 16 colours, 8 - 256 colours, 16 - High colour, 24 - 24 bit
colour, 32 - 32 bit colour
01Eh CMP_SPEC 4 bytes Compression Specs. Possible values: 0 - none (Also
BI_RGB), 1 - RLE 4bit/pixel (Also BI_RLE4), 2 - RLE 8bit/pixel (Also
BI_RLE8), 3 - Bitfields (Also BI_BITFIELDS)
022h BMP_DSZ 4 bytes Size of the bitmap DATA in bytes. Must be rounded to
the next 4 byte boundary.
026h HRES 4 bytes Horizontal res in pixels/meter
02Ah VRES 4 bytes Vertical res in pixels/meter
02Eh COL 4 bytes Number of colours used by this bitmap (ie for an 8bit
colour image: 256)
032h IMPCOL 4 bytes Number of important colours (equal to COL above if
every colour is important)
036h PAL n*4 bytes Palette Specs. For every entry in the palette, 4 bytes
describe the RGB values as follows: 1 byte:blue, 1 byte: green, 1 byte red,
1 byte filler (filled with 0)
436h BMP_DATA n bytes Depending on CMP_SPEC, all bitmap data bytes that
represent indices in colour palette
Now since a Type structure is impossible in SBasic, you should use an Array
to conveniently manipulate all this blah-blah.
However to save space you should remember that there is a MAXIMUM size of
the header (and that occurs when a palette exists).
Also to try to go through the hoops and produce every possible combination
would be irrational (IMVHO) and I would recommend you use only the 24bit
option, as it simplifies calculations. Not to mention that you can have the
rest of the info hard coded for all screen sizes mode 32 and 33 support.
Moreover, in Mode 33 (and you should include Mode 33), remember the
importance of the Intensity (Extra Green bit) and cater for that in the
translation.
Hope this helped a bit,
Phoebus
--
Phoebus Dokos - Undergrad in MIS
Eberly College of Business - Indiana U. of PA
RE: [ql-users] C structures
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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dilwyn Jones Sent: 11 July 2003 20:33 To: QL Users List Subject: [ql-users] C structures In attempting to write routines to convert graphics, I've used some Windows documentation which refers to C structures. It refers to UINT, DWORD and LONG. Can someone explain these to a C ignoramus (i.e. me): UINT - Unsigned integer presumably, how many bytes? DWORD - Double word? Signed? How many bytes? LONG - Like a QL 32 bit integer? -- Dilwyn Jones
Re: [ql-users] C structures
Dilwyn Jones wrote: In attempting to write routines to convert graphics, I've used some Windows documentation which refers to C structures. It refers to UINT, DWORD and LONG. They're defined as follows: DWORD = unsigned long UINT = unsigned int Generally you can never say for sure what an int or a long stands for. In the special case of Windows on Intel platforms however they are all 32bit or 4 bytes wide. I.e. UINT = DWORD = 32bit unsigned LONG = int = 32bit signed BTW: I'm back. Will probably start answering mails tomorrow. Marcel
Re: [ql-users] C structures
Dilwyn Jones wrote: In attempting to write routines to convert graphics, I've used some Windows documentation which refers to C structures. It refers to UINT, DWORD and LONG. Can someone explain these to a C ignoramus (i.e. me): UINT - Unsigned integer presumably, how many bytes? DWORD - Double word? Signed? How many bytes? LONG - Like a QL 32 bit integer? It is all very arbitrary. You really need to track back somehow to find out which variation of the standard(sic) include file happens to have been used. You probably need to find a types.h that comes with the compiler that you think the code was defined for. Loosely, you have the right idea. The must probable definitions are: typedef unsigned int UINT typedef unsigned long DWORD typedef signed long LONG However, that really doesn't help a lot. An int doesn't neccesarily mean 16 or 32 bit. Older compilers default to 16, newer to 32, and neither is guaranteed. It was supposed to be the natural (i.e. most efficient) size for an integer on whatever architecture you were compiling for. I.e. if you had a 20 bit machine, that could be what int came out as. However, on 8-bit machines, ints are typically 16 bit! A short is only guaranteed to be no bigger than a long with an int somewhere between. Also, the WORD in DWORD is not always defined as unsigned. - However - all is not so bleak - I've just done the obvious(?) and searched Google for types.h DWORD UINT LONG and come up with http://ssobjects.sourceforge.net/docs/html/msdefs_8h.html and http://www.minigui.com/api_ref/group__win32__types.html which seem exactly what you're after (and match what I said above). - Finally, a search on the MS site got me to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/windows_data_types.asp which ties it all up. DWORD - 32 bit unsigned integer LONG - 32 bit signed integer UINT - unsigned INT INT - signed 32 bit integer Hence, according to Microsnot, we have UINT as an unsigned signed 32 bit integer - I'm not at all sure what that means. (Actually, I am - unsigned takes precedence over signed). - Out of amusement, on looking at Micro$oft's table, they have the following: Single bit (in effect) - BOOL or BOOLEAN (they don't actually say what storage size it really is). 8 bit, but no idea whether it's signed or unsigned - BYTE or CHAR. 8 bit unsigned - UCHAR. 16 bit signed - SHORT. 16 bit unsigned - USHORT or WORD. 32 bit signed - INT, INT32, LONG or LONG32. 32 bit unsigned - UINT, UINT32, ULONG, ULONG32, DWORD or DWORD32. (No less than six synonyms!) 64 bit signed - INT64, LONG64 or LONGLONG. 64 bit unsigned - ULONG64, UINT64, DWORD64 or ULONGLONG. - I give up. - (I'm being a little cruel about the BYTE/CHAR type - K R left it open as to whether a char was signed or not. On early compilers, before the signed attribute was invented, you couldn't actually get a signed 8 bit value at all.) -- Lau http://www.bergbland.info Get a domain from http://oneandone.co.uk/xml/init?k_id=5165217 and I'll get the commission!
Re: [ql-users] C structures
On Fri, 11 Jul 2003 22:48:29 +0100, Dilwyn Jones [EMAIL PROTECTED] wrote: Dilwyn, I do have a full program ready that does that, however you're killing yourself with no reason. Just press Print Screen while you're running QPC and then paste it in your favourite graphics editor :-) Presto you're screen capture is complete :-) Phoebus -- Phoebus Dokos - Undergrad in MIS Eberly College of Business - Indiana U. of PA
Re: [ql-users] C structures
Dilwyn Jones wrote: 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. The BMP format originates from Win16 platforms, so my earlier explanations regarding sizes don't apply. An int is 16 bit there. Long however is still 32bit. 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. For the sake of completeness, when running QPC in windows mode you can just copy the contents of the current window to the clipboard by pressing ALT+Print. Here's the information I have: 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 Those are 5 bit, i.e. from 0 to 31. green=(PEEK(addr)224)||((PEEK(addr+1)7)*4) *8 This is 6 bit, i.e. from 0 to 63. Conversion to 8 bit is needed, of course. 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 IIRC BMP data is 24 bit, i.e. without the 0. QL_bytes = pixel_width*pixel_height : REMark width should be even? Every BMP single screen line must be padded to a 4 byte boundary. Marcel
Re: [ql-users] C structures
In message [EMAIL PROTECTED], Phoebus Dokos [EMAIL PROTECTED] writes On Fri, 11 Jul 2003 22:48:29 +0100, Dilwyn Jones [EMAIL PROTECTED] wrote: Dilwyn, I do have a full program ready that does that, however you're killing yourself with no reason. Just press Print Screen while you're running QPC and then paste it in your favourite graphics editor :-) Presto you're screen capture is complete :-) Phoebus I'd like a copy of that ! -- Roy Wood Q Branch. 20 Locks Hill, Portslade, Sussex. Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501 web : www.qbranch.demon.co.uk
Re: [ql-users] C structures
On Fri, 11 Jul 2003 23:31:43 +0100, Roy wood [EMAIL PROTECTED] wrote: snip Phoebus I'd like a copy of that ! Do you have the .NET framework installed? Phoebus -- Phoebus Dokos - Undergrad in MIS Eberly College of Business - Indiana U. of PA
