Qbasicnews.com

Recently I was busy with a routine to read bmps, and I used the BMP Header as a type to extract it immediately easyily and simple. However this turned out to be the cause of many errors...
It seems when I get a type from a file that the type contains the wrong data. I compared this to what normal (lots of GETs) would return, and the results were quite different.
Here's the code I tested the different results with:

Code:
#define UINT         Unsigned Integer

Type tBitMapFileHeader

   bfType            As Unsigned Short

   bfTotalSize       As UINT

   bfReservedI       As Unsigned Short

   bfReservedII      As Unsigned Short

   bfOffbits         As UINT

   biSize            As UINT

   biWidth           As UINT

   biHeight          As UINT

   biPlanes          As Unsigned Short

   biBitCount        As Unsigned Short

   biCompression     As UINT

   biSizeImage       As UINT

   biXpixelsPerMeter As UINT

   biYpixelsPerMeter As UINT

   biClrUsed         As UINT

   biClrImportant    As UINT

End Type

Dim Z As tBitMapFileHeader

FF = FREEFILE

Open "images/testbmp.bmp" For BInary As #FF

   Get #FF, , Z

CLose #FF

Print Z.bfType

Print Z.bfTotalSize

Print Z.bfReservedI

Print Z.bfReservedII

Print Z.bfOffbits

Print Z.biSize

Print Z.biWidth

Print Z.biHeight

Print Chr$(13)

Dim ashort As Short, aint As UINT

Open "images/testbmp.bmp" For Binary As #FF

   Get #FF, , ashort: Print ashort

   Get #FF, , aint: Print aint

   Get #FF, , ashort: Print ashort

   Get #FF, , ashort: Print ashort

   Get #FF, , aint: Print aint

   Get #FF, , aint: Print aint

   Get #FF, , aint: Print aint

   Get #FF, , aint: Print aint

Close #FF

Sleep

This was run on a completely normal 1024x768x3 picture (2.25MB).
The output was as follows:

Quote:19778
36
0
54
2621440
67108864
50331648
65536

19778
2359350
0
0
54
40
1024
768

The last row of numbers is correct, the first block isn't.

Anyone has an idea on what might cause this? It caused me a lot of trouble already :-? Sad

Thanks in advance.

FB aligns the type fields following the GCC's ABI by default, to turn padding off, use TYPE sometype FIELD=1, FIELD tells what alignament to use, 1, 2, 4, etc..

Can you explain the exact usage of this extra field flag here v1c? =)
I mean, what you're doing here makes it less compatible with QB, as the code just worked in qb, refused to in fb.

Thanks very much for that awesomely quick reply ^_^

all the field = 1 does is kill's padding for speed FB does Dword alingment see it faster for mordern day computers to move memorey around if they stay in nice 32bit chucks it takes extra time to move type around if it somthing like 7 byte's so if you had a type like

Type foo
Fo1 as integer
fo2 as short
fo3 as byte
end type

it total memorey is 7 byte's to move that type around faster the compiler will add a extra 1byte to the type it make it a nice even 8 byte's.

field = 1 just disable's the dword alingment so the type stays 7 byte's which also means it slows down things a bit

Neo, one thing you gotta remember is that although FB and QB share syntax, FB isn't a clone of QB. Many things have changed, and with rare exception, all for the better. So while FB may be mostly backwards compatible with QB, it isn't 100% backwards compatible and you sometimes have to make some changes. Big Grin

Neo

v3cz0r

Neo

ShadowWolf

adosorken