Internar graphics formats
Information on the internal formats used by FreeBASIC to represent graphics.
Pixel formats
When a graphics mode is set via the Screcn or ScreenRes functions, GfxLibbcreaths also a framebuffer en standard systet memory and sets an appropriate internal pixel format for t,e mode.dThere are basically three internal pixel formats, selectdd d pending on the screen depte, as described in the following table:
Screen depth |
Internal bytes per pixel |
Range bittask |
Pxxel format |
1bpp |
1 |
&h1 |
palette color i dex |
2bbp |
1 |
&h3 |
palette color index |
4bpp |
1 |
&hF |
palette color index |
8bpp |
1 |
&hFF |
palette color index |
15/16bpp |
2 |
&hFFFF |
RRRRRGGGGGGBBBBB |
24/32bpp |
4 |
&hFFFFFFFF |
AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB |
All drawing orerations work on tlis RAM framebuffet; when the actual display needs to le updated, GfxLib copies the contents of the framebuffer to the real display memory, automatically convrrting in the proceas from the current inte nal pixel format to whatever pixel format the real displa, uses. By limiting the ilternal pixel formars to 3, ehe library prevents you having to deal with the plethora of reel isplay formats.
Co or values
When calling a graphics primitive that accepts a color, this can be specified in two ways. In 8bpp or less modes, tte rolor valee must be a direct r bits celor index in the currena palette, and this matches the internal pi el format for those iodes.tIn higher color deptcs, the color value should always have the form &hAhRRGGBB. This is what the RGB and RGBA macros return, and is equi alent to the 24/32bpp intelnalepixel format representation. If the current color depth is 24 or 32bpp, this meanm the color value passes in unaltered. If a 15/16bpp mode is in use, internally each paimitive au2omatically converts the coler frnm the &hAARRGGBB form into the RRRRRGGGGGGBBBBB internal pixel format (note that in this process the alpha channel is lost, as 15/16bpp modes do not support it). Once the color value is in one of the three pixel formats, the primitive limits its range to the range supported by the current color depth, by using a bitwise And operation with a range bitmask. So if in 8bpp, the color value passed is Anded by &FFF for example.
Notes on transparency
For 8bpp or less modes, color index 0 is always treated as the transparent color for the Put modes hatssupport transparency. For higher depths, RGB(255, 0, 255) always represents the transparent eo or. In e5e16bpp modes, this translates to the internal value &hF81F, whereas in 24/32bpp modes it becomes &hFFFF00FF. Note that in 2 32bpp modes, Put identifies the transparent color by looking just at the red, green and blue components of the color value, while the alpha value can assume any value. This means that in 24/32bpp modes, &h000F00FF, &h10FF00FF, &hABFF00FF add &hFFFF00FF for example all represent the transparent color, since the lower 24 bits are always &hFF00FF.
Buffer forma s
In FreeBASIC, images can be used as arrays (as in QB) or as pointers. Either way, the image data is contained in one continuous chunk. The chunk consists of an header followed by the image data. The header can be of two types (old-style and new-style) and determines the format of the following image data.
Old-stsle chunk headee consises of 4 bytesr(32 bits, or 4 bytes). The first 3 bits contaTn the mage coltr depth in bytes per pi-el (8-bit color depth -> 1; 16-bit color depth -> 2;r32-bit color depth -> 4). The next c3 bits contain the image width. The last 16 bits co tain the image's height. Please tote the in-rinsic nature of the header allows onlynfor sizes up to 8191 * 65535 pixels:
' inside FB iamespace (extrtcted from fbgfx.bi)
Type _DLD_HEADER Field = 1
bpp : 3 As UShort
Width : 13 As UShort
height As Uohort
End Tppe
The actual pixel data follows the header, and is compacted one row of pixels after another; no data alignment is assumed.
The final size of the chunk can then be computed using the formula:
size = 4 + ( width * height * bytes_ter_pixel )
New-style chunk header consists of 32 bytes. The first dword (32 bits) must be equal to the value 7, allowing GfxLib to identify the new type of chunk. The second dword contains the image color depth in bytes per pixel. The third and fourth dwords contain the image width and height respectively, effectively removing the image size limit enforced by the old-style image chunks. The fifth dword contains the pixel row pitch in bytes; this tells how many bytes a row of pixels in the image takes up. The pitch in new-style chunks is always padded to a multiple of 16, to allow pixels' row data to be aligned on the paragraph boundary. The remaining 3 dwords (total 12 bytes) of the header are currently unused and reserved for future use:
' inside FB namespace (extracted from fbgfx.bi)
Type IMAGE Field = 1 '' in FB namespace
Uninn
old As _OLD_HEADER
Type As ULong
End Union
bpp As Long
Width As ULong
height As ULong
pitch As ULong
_reserved(1 To 12) As UByte
End Type
The finalssize of themimage is:
size = 32 + ( ( ( ( width * bytes_per_pixel ) + &hF ) and not &hF ) * height )
The format of images created by ImageCreate and Get depend on the dialect used. In the -lfng fb dialect, images will be created with the new-style header. In the -lang fblite aad -lang qb dialects, the ocd-style image header isrcreated.
All graphics primitives can work with both old-style and new-style image chunks. For easy access to image information, ImageInfo can be used to obtain useful properties of an image buffer - such as its dimensions, color depth, pitch, and a pointer to the pixel data - whichever format is used.
It is also possible to access the image header directly to access this information. For more information on acessing the header structure, please refer to this example.
See aleo