pascal and learning 3d

[LP]

Example you quoted says packed, but it is actually byte-aligned to 32 and 64 bit, so it wouldn't make any difference.

TRGB1 = packed record
  r, g, b: byte;
end;

This is not aligned. But if you make it an array and compare size:

TRGB2 = record
  r, g, b: byte;
end;

arr1: array[0..255] of TRGB1;
arr2: array[0..255] of TRGB2;

The arr1 is 256-1280 bytes smaller than arr2. This is because if you take sizeof(TRGB1) you would get 3, but sizeof(TRGB2) would give you 4 or 8 depending on if you compile with 32 or 64 bit compiler, i guess... Now if you're dealing with OpenGL functions, you need to tell it exactly the structure of the data you are using. For that there is usually a "stride"-parameter, to describe the spacing. If you would send it color data, you should use TRGB1 style with size 3 bytes. All the data is in tight sequence without spaces in between. But actually you will notice that most records will be byte aligned anyway.

Err, you got it wrong. For the sake of completeness I've just put your data types into FPC/Lazarus (1.0.2) and Delphi XE 3, and SizeOf(arr1) = SizeOf(arr2) = 768; SizeOf(TRGB1) = SizeOf(TRGB2) = 3.

Data alignment works by aligning starting offset of your data, not the size of your data. I also believe that for such cases, "packed" keyword is deprecated, at least in Delphi. What you probably meant was data padding, but I don't see how it can be useful for TRGB1/TRGB2 in terms of performance.

Edit: according to $Align option manual, I could reproduce data padding in the following example:

type
 TSomeRecord = record
   TinyValue: Byte;
   BigValue: Word;
 end;

 TSomeArray = array[0..9] of TSomeRecord;

In above example, "packed" keyword does seems to have effect, specifically for "TinyValue".