What's the format that QB uses in graphics GET/PUT? (I know the first four bytes give width and height, but that's it).
Is it possble for a QB program to create shortcuts?
Thanks.
Quote:What's the format that QB uses in graphics GET/PUT? (I know the first four bytes give width and height, but that's it).
The rest width * height bytes are just raw image data, supposing the 8bit mode in QB. Something like this in pseudo:
Code:
Byte 1 & 2 -> Width
Byte 3 & 4 -> Height
For Each y To Height - 1
For Each x To Width - 1
Byte Width*y+x+4 -> Pixel Data for pixel(x, y)
Next x
Next y
Quote:Is it possble for a QB program to create shortcuts?
Windows shortcuts? Learn the shortcut format and just create a file in the appropriate Desktop\ directory of windows, in case you want one on the desktop.
Correction: Bytes 1 & 2 = width * 8.
Also nothe that the endian of the Intel architecture stores the numbers backwards, so 1st number would be Byte 2 | Byte 1, i.e. Byte 2 * 256 + Byte 1.
Code:
width = (Byte2 * 256 + Byte1) \ 8
Quote:Correction: Bytes 1 & 2 = width * 8.
Nath, I said the width was stored in bytes 1 & 2, I didn't say in what form it was stored
Just indicated that so simple because he already appeared to know the first two bytes contained the width multiplied by 8.
Your last post is just ego, man
My correction was to him:
Quote:(I know the first four bytes give width and height, but that's it)
Sorry, I was looking for Screen 12 4-bit mode. I should have specified that earlier. It seems to each bit of each pixel in a different byte, and while I can see some sort of pattern I haven't been able to find an algorithm that works all the time.
Thanks.
SCREEN 12 turns on a planar mode. The sprite format is slightly different. Note that I'm not sure of this, i.e., the screen is organized this way, but I'm not sure if the GET/PUT arrays are stored using the same organization. Chances are, they are:
You have four different bit-planes: red, green, blue and intensity. If a bit is set in the red plane, for example, that means that the red component of the pixel corresponding to that bit is on. For example, if a pixel is coloured in bright yellow, that means that the red plane will have the correspondent bit set, the green plane will have it set as well, the blue plane will have it unset, and the intensity plane will have it set. Dark blue will have all the bits to 0 and the blue one to 1... etcetera.
That means that the image is built using four monochrome images which are combined to obtain it.
Checking for the colour of 1 pixel using this organization is somewhat slow 'cause you have to do tons of things. First of all you have to create a bit mask, 'cause in every byte you can store 8 bits, i.e. 8 pixels per plane. You apply this bit mask to each plane, then get the four resulting bits and combine them together to get the colour.
Looks how this makes sense, for example, bright red is colour #12. Bright red will have red and intensity set, green and blue unset. If we order this Intensity, Red, Green, Blue and put the bits together, i.e. 1 1 0 0 we get 1100 which is 12.
White is colour #15: all bits set, we get 1111 which is 15.
Dark purple is colour #5: intensity unset, red set, green unset, blue set, which is 0101 = 5.
You see, this is really costly to calculate, so I'd rather use another screen mode.
I'm not sure I completely understand what you're saying: it seems that that type of format would restrict the possible colors to the default ones, because the color numbers (eg, White = 15) refer crude, single-bit RGB/I values rather than point to palette values (eg, 15 = FFFFFF).
For example, if I used PALETTE to create a 16-color greyscale scheme, only four of those 16 colors (black, white, light and dark grey) could be described in terms of 1-bit R/G/B/I planes.
....Or did I completely miss the point of what you wrote?
No, that's 'cause the initial assignations to the DAC registers (which control which colours are showed on screen) are set to the standard EGA colours which were formed in that way using just 4 bits for colour information.
So no matter which attributes you assign to each colour, they will be acting the same in planes. In fact, the planes have no "colour meaning"; the are called "Intensity, red, green and blue" just for legacy.
The thing to understand is that instead of having the pixel information in a linear way (like in SCREEN 13 where you have all the pixels stored one right after the previous), i.e. storing two pixels per byte, it is stored in parallel. Each pixel can be a number from 0 to 15, you need 4 bits to store those numbers, so you have four planes with one bit in each plane per pixel.
A little tip for those of you that haven't realized in SCREEN 13,
a GET/PUT image doesn't use the 4th byte, so you can use it for anything else you may desire! (ummm.... good to use as a pointer for the address to the next frame, if you use multi-framed tiles or sprites
Cya,
Nemesis