External Graphics File Formats (page to fill in Programmer's Guide)
External Graphics File Formats (page to fill in Programmer's Guide)
The external graphics file formats supported by rtlib through Bload and Bsave
In order to be able one day (I hope soon) to fill in this last page of the Programmer's Guide, I would like all users who have knowledge on this subject (and only these) to pass it to us via informal drafts posted here-below.
Thank you in advance.
In order to be able one day (I hope soon) to fill in this last page of the Programmer's Guide, I would like all users who have knowledge on this subject (and only these) to pass it to us via informal drafts posted here-below.
Thank you in advance.
Re: External Graphics File Formats (page to fill in Programmer's Guide)
And what's this page supposed to contain? The bload documentation page says:
That's it. Those are the only 'external graphics file formats' supported by the rtlib. What more there is to say?BLoad can load 3 different types of files:
- Old QB-like data files, saved with BSAVE from QB code, containing "raw" data preceded by a 7-byte header, beginning with &HFD, up to 64 KiB in size
- New FB-like data files, saved with BSave from FB code, containing "raw" data preceded by a 5-byte header, beginning with &HFE. There is no 64 KiB limit with this format
- BMP image files, supports a subset of valid ("Windows") .BMP files, beginning with "BM", saved from FB code with BSave, or created / saved in a compatible format using a graphics editor / converter.
Re: External Graphics File Formats (page to fill in Programmer's Guide)
When I asked @coderJeff the question, I only got this answer:
coderJeff wrote:For external graphics file formats topic: what is supported by BLOAD & BSAVE. To be cross platform, the QB/BMP formats that can be loaded/saved are hard coded in the rtlib. So, this is will be a description of what is specifically supported by the rtlib.
Re: External Graphics File Formats (page to fill in Programmer's Guide)
Well then, since both (coderJeff & paul doe) say essentially the "very same thing", there is "no more" to it, than that.
(everything else needs external libraries, dynamic or static like: e.g. FBImage or similar)
(everything else needs external libraries, dynamic or static like: e.g. FBImage or similar)
Re: External Graphics File Formats (page to fill in Programmer's Guide)
Complete documentation is off course best, but 99% of the questions here are like "how do I display JPG or BMP?"
So a programmers's Guide on external graphics should at least include an example to load and save a 32-bit bmp-file, I think.
And a mention that for other file types (JPG, PNG) external libraries or additional code is needed.
So a programmers's Guide on external graphics should at least include an example to load and save a 32-bit bmp-file, I think.
And a mention that for other file types (JPG, PNG) external libraries or additional code is needed.
Re: External Graphics File Formats (page to fill in Programmer's Guide)
Nobody uses BMP. Under Windows, displaying a JPG with GdiPlus is relatively simple, but I can't speak for Linux, of course.badidea wrote:99% of the questions here are like "how do I display JPG?"
Re: External Graphics File Formats (page to fill in Programmer's Guide)
BMP is used a lot in machine vision and as an intermediate format in general, as it is basically just a header + the pixels, and compression (usually to lossless PNG) is only done when storing to disc. JPG is worthless here, since most popular forms are inherently lossy.jj2007 wrote:Nobody uses BMP. Under Windows, displaying a JPG with GdiPlus is relatively simple, but I can't speak for Linux, of course.badidea wrote:99% of the questions here are like "how do I display JPG?"
That said, it might be worth specifying what exactly is the "BMP subset". (no RLE? Not all BPP?)
Re: External Graphics File Formats (page to fill in Programmer's Guide)
You nailed it there. Plus there is some support for reading in gfx files originally saved by QB's BSAVE itself.marcov wrote:That said, it might be worth specifying what exactly is the "BMP subset". (no RLE? Not all BPP?)
Code is run time library implemented and doesn't use any win32 api calls so can be used on linux / dos, etc.
fxm, it's kind of been on my todo list to read the C code implementation and figure it out, but I also secretly hoped if asked enough times, there would be some nice community member that would want to help out too. :)
Re: External Graphics File Formats (page to fill in Programmer's Guide)
I see that there is still no volunteer to fill this page (External Graphics File Formats), or at least provide text for doing it.
However, it seems to me that there is no shortage of talent in this area.
However, it seems to me that there is no shortage of talent in this area.
Re: External Graphics File Formats (page to fill in Programmer's Guide)
Here is a rough starting point, though many bits still to add in...
Files used with BLOAD/BSAVE
First byte of file:
For the QB/FB saved block, &hFD and &hFE identify the file as a QB/FB format and the next bytes determine the SIZE of the data contained in the file, followed by DATA and optionally PALETTE.
For the Windows Bitmap, should be binary compatible with standard Windows BMP files. When loading, &h42 only identifies the file as possibly a windows bitmap and other checks on the header may cause it to fail loading.
QB BSAVED BLOCK
FB BSAVED BLOCK
BSAVE and QB/FB Save Block
BSAVE( filename, source [,[ size ][,{ pal | pal, bitsperpixel }]] )
BSAVE always writes using the FB format (&hFE)
DATA bytes written is the smaller of the SIZE parameter and screen * pitch
PALETTE is written either from pal parameter or from current screen's palette
BLOAD and QB/FB Save Block
BLOAD filename [, dest [, [pal]
If 'dest' is not given, then DATA is loaded directly to screen memory byte for byte. If SIZE exceeds the current screen * pitch, then DATA is truncated to fit the size of the current graphics mode.
if 'dest' is given, then DATA is loaded directly to the memory location pointed to by 'dest'.
BLOAD/BSAVE and Windows bitmap
BLOAD - if first byte is &H42 then file is attempted to be loaded as a bitmap
BSAVE - if filename has '.bmp' extension, then is saved as bitmap
Files used with BLOAD/BSAVE
First byte of file:
Code: Select all
&hFD QB BSAVED BLOCK
&hFE FB BSAVED BLOCK
&h42 Windows Bitmap (&h42 = ASC("B"))
For the Windows Bitmap, should be binary compatible with standard Windows BMP files. When loading, &h42 only identifies the file as possibly a windows bitmap and other checks on the header may cause it to fail loading.
QB BSAVED BLOCK
Code: Select all
OFS LEN DESCRIPTION
0 1 QB BSAVED BLOCK Identifier (&hFD)
1 4 Ignored
5 2 unsigned 16 bit SIZE, little endian order
7 ... DATA (expected to be SIZE bytes long)
? ... PALETTE COLORS
Code: Select all
OFS LEN DESCRIPTION
0 1 FB BSAVED BLOCK Identifier (&hFE)
1 4 unsigned 32 bit SIZE, little endian order
5 ... DATA (expected to be SIZE bytes long)
? ... PALETTE COLORS
BSAVE( filename, source [,[ size ][,{ pal | pal, bitsperpixel }]] )
BSAVE always writes using the FB format (&hFE)
DATA bytes written is the smaller of the SIZE parameter and screen * pitch
PALETTE is written either from pal parameter or from current screen's palette
BLOAD and QB/FB Save Block
BLOAD filename [, dest [, [pal]
If 'dest' is not given, then DATA is loaded directly to screen memory byte for byte. If SIZE exceeds the current screen * pitch, then DATA is truncated to fit the size of the current graphics mode.
if 'dest' is given, then DATA is loaded directly to the memory location pointed to by 'dest'.
BLOAD/BSAVE and Windows bitmap
BLOAD - if first byte is &H42 then file is attempted to be loaded as a bitmap
BSAVE - if filename has '.bmp' extension, then is saved as bitmap
Re: External Graphics File Formats (page to fill in Programmer's Guide)
So top down images (with negative height) ARE supported ?coderJeff wrote: ↑Jun 05, 2021 20:43You nailed it there. Plus there is some support for reading in gfx files originally saved by QB's BSAVE itself.marcov wrote:That said, it might be worth specifying what exactly is the "BMP subset". (no RLE? Not all BPP?)
Code is run time library implemented and doesn't use any win32 api calls so can be used on linux / dos, etc.
Re: External Graphics File Formats (page to fill in Programmer's Guide)
ha, I did not know. Turns out yes, negative height flips the image. (I really was hoping for someone to dig through this. I don't even know what is common or normal with this format)
RLE not supported though. So only uncompressed formats.
Re: External Graphics File Formats (page to fill in Programmer's Guide)
(just for archival purposes in case sb searches for BMP status in the future, there are other weirdnesses like 2-bit WinCE BMPs (very rare). Another rare one, but with PNG, is that Microsoft supports PNG with deflate streams without ZLIB headers)