FB palette array datatypes

[counting_pine]

Pages like KeyPgBload and KeyPgPalette touch briefly on palette arrays, but don't seem to specify the exact data type needed.

My presumption is that palette arrays need to be of a 32-bit data type (e.g. ulong), but examples on both pages use an Integer array.
I would guess that the wiki is outdated and that it's safe to change them to 32-bit datatypes, but I can't confirm that at present, and I don't know whether or not 64-bit Integer arrays are supported in either function.

I can't really test at the moment without delving into the code, or trying it out in a 64-bit OS (I'm stuck in a 32-bit one at the moment.) So I guess I'm just raising it here to see if anyone else has anything to say on it.

[fxm]

I thought (maybe stupidly) that the declared type of palette array should always be an Integer (32-bit or 64-bit, depending on the platform).

[MrSwiss]

... the declared type of palette array should always be an U/Integer (32-bit or 64-bit, depending on the platform)

This is clearly (from a memory allocation point of view), the wrong approach, since any 32 bit's
color should only ever be represented by ULong! (fixed unsigned 32 bit type, uint in "C")

FBC 64 (specific):
With Integer (unspecified size) you're allocating DOUBLE the amount of memory "really used"!

Conclusion:
A lot of people here, seem to be still living in a 32 bit World. FBC's going 64 bits, has impact
(should at least) on coding. Integer can and should, in most cases simply be replaced with Long
(to retain the original intention, of the coder/programmer).
FBC 64 then, requires a certain amount of adaptation on the coders side, who are writing new
code/project e.t.c. this seems to not to have taken place, at this point in time, unfortunately!
(may also be related to the ton's of examples in DOC, which should be 're-done' to reflect the
change, that has impacted the "Integer" type ...)

Remember:
In FBC Long = int in C (not Integer!).

[fxm]

Perhaps, but currently, ULong pallette arrays do not work with FBC-64.

[MrSwiss]

Perhaps, but currently, ULong pallette arrays do not work with FBC-64.

This is due to: legacy language mode = QB! The Ball & Chain, on FB's legs ...

Even if QB afaik, had type Long = 32 bit int type (Integer, in QB = Short in FB).
This is the reason, that GFXLib2 requires "Integer" as a type (hard coded, currently).

Btw: they do, in the more modern FB.Image type (which is coded "on top"), but still
requires "integers" for querying: see ImageInfo(), for compatibility reasons ...
(Header and data are 4 bytes alligned, at least, in 32 bit color mode.)

[counting_pine]

Maybe we could support both..
Use overloads on bload/bsave, and add some more logic to the Palette quirk statement handler.

With the overloads, it's not clear what should happen with Any Ptrs. But probably it is foolish to accept Any Ptrs anyway.
(If it needs a default, ulong would be better from a memory safety perspective.)

[coderJeff]

Perhaps, but currently, ULong pallette arrays do not work with FBC-64.

This is due to: legacy language mode = QB! The Ball & Chain, on FB's legs ...

@MrSwiss, I think you have a talent for finding inconsistencies and bugs. I mean that sincerely. I also think you arbitrarily assign the cause, I'm sorry, I find that very annoying, because it points people (including me) in the wrong direction.

The transition from 32-bit to supporting 64-bit has a long process, and obviously not done yet. It's unfortunate that we have to break compatibility, but also unavoidable. On my mind was to start a community discussion about breaking compatibility to progress development. To be honest, not really looking for opinions, just to let users know it's coming and what to expect.

I didn't look in to the details of this issue; I think should just decide what needs to be done and break compatibility as needed.

[MrSwiss]

I also think you arbitrarily assign the cause, ...

Could you please, be a bit more specific, on that "arbitrarily" statement?
I think that I've explained later on sufficiently, what is meant in the first statement.

To be honest, not really looking for opinions, just to let users know it's coming and what to expect.

Then, I'd advice against starting a discussion, simply post in "News" (locked), whats what ...
I'm probably the last one to oppose, breaking compatibility, for a "good reason".
(I've proposed already, before FBC 64 came out, to break with all "legacy" dialects!)

[coderJeff]

Maybe we could support both..

I looked at PALETTE [GET] USING. gfxlib has functions for 32/64 bit data sizes. fbc is supposed to check data size to map the function, but long don't work on 64-bit and longint don't work on 32-bit.

BUG in rtl-gfx.bas:rtlGfxPaletteUsing() - check is made on size of pointer rather than the size of the data it points to, so wrong function gets mapped. Change the one IF statement to if( typeGetSize( typeDeref( astGetDataType( arrayexpr ) ) ) = 8 ) then and integer, long, longint data types will work on both fbc 32 & 64 bit.

For example:

Code: Select all

#macro do_test( T, expr )
	scope
		cls
		Dim p(0 To 255) As T
		Palette Get Using expr
		For i As Integer = 0 To 15
			locate i+1,1
			Print Using "Color ## = &"; i; Hex(p(i), 6)
		Next i
		'' sleep
	end scope
#endmacro

Screen 13

do_test( integer, p )
do_test( uinteger, p )
do_test( long, p )
do_test( ulong, p )
do_test( longint, p )
do_test( ulongint, p )

do_test( integer, @p(0) )
do_test( uinteger, @p(0) )
do_test( long, @p(0) )
do_test( ulong, @p(0) )
do_test( longint, @p(0) )
do_test( ulongint, @p(0) )

do_test( integer, p(0) )
do_test( uinteger, p(0) )
do_test( long, p(0) )
do_test( ulong, p(0) )
do_test( longint, p(0) )
do_test( ulongint, p(0) )

I didn't test for other failures. Although I did notice this pattern in fbc for checking if the "large" versions of functions from the rtlib should be called, like for images, and file functions. So, this may be a common bug.

[fxm]

I did not know we could provide to "Palette [Get] Using" not only the array name 'pal', but also the address of its first element '@pal(0)' and therefore the address of array data buffer 'p' with 'p=@pal(0)'.

But I am surprised that this also works if we provide the first element itself of the array 'pal(0)', whereas this does not work with the first element of array data buffer 'p[0]' or '*p' with 'p=@pal(0)' !
Not very logical for an ordinary user.
Would not it be better to forbid the syntax 'pal (0)', or at least not to quote it in the future update of the documentation ?

[coderJeff]

I think I found all the forms for the palette using expression. GET/PUT image buffers also have similar rules (not tested).

This example shows similar kinds of calls using overloaded SUBS.

Code: Select all

/'
	1) array name, no index (QB)
	2) array element access, non-pointer type (QB)
	3) [u]long[int] or [u]integer ptr
	4) any ptr
	5) UDT that can cast to any ptr
'/

dim shared x(5 to 55) as long

type T as any ptr

type R
	__ as long ptr
	declare operator cast() as any ptr
end type

operator R.cast() as any ptr
	operator = __
end operator

sub A  overload( x() as long )
	print "1 &" & hex(@x(lbound(x)))
end sub

sub A overload( byref x as long )
	print "2 &" & hex(@x)
end sub

sub A overload( byval x as long ptr )
	print "3 &" & hex(x)
end sub

sub A overload( byval x as any ptr )
	print "4 &" & hex(x)
end sub

sub A overload( byref x as R )
	print "5 &" & hex(cast( any ptr, x ))
end sub

dim y as any ptr = @x(5)
dim z as R = ( @x(5) )

A x()
A x(5)
A @x(5)
A y
A z

palette get using x
palette get using x(5)
palette get using @x(5)

palette get using y
palette get using z

[fxm]

Code: Select all

Dim As Long Ptr p = @x(5)
A p[0]

works, the case #2 ('p[0]' being a Long reference)
but not:

Code: Select all

palette get using p[0]

[coderJeff]

@fxm, I understand. But, if it's documented and fbc works as per documentation, how important is this to allow or disallow? It's a quirk statement. Yeah, it doesn't follow the rules of normal subroutines.

#1 array & #2 array(index) are the QB specific forms
otherwise it's expecting a pointer type where @p[n], p+index, etc would be accepted also.

@MrSwiss, to address earlier comment, I think I am just looking for a "why" or evidence to back up a claim or conclusion. It's a lot of work for someone to prove or disprove. Without an investigation or information, the claim is meaningless ... but most people don't care about that.

[fxm]

@coderJeff,
Regarding the "references", did you see my other post: viewtopic.php?p=248410#p248410 ?

[coderJeff]

I saw the post. I think the connection is that the "palette [get] using array(index)" form inherited from QB is a form of byref variable even if it is implicit. array(index) is used to specify a (pointer-less) reference to a memory location.

Code: Select all

Dim pal(0 To 255) As integer
dim byref r as long = pal(0)

Palette Get Using pal(0)  '' implicit reference to pal(0) - OK
Palette Get Using @pal(0) '' pointer to pal(0) - OK

Palette Get Using r       '' reference to pal(0) - currently not valid
Palette Get Using @r      '' pointer to pal(0) - OK