FB palette array datatypes
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
FB palette array datatypes
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.
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.
Re: FB palette array datatypes
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).
Re: FB palette array datatypes
This is clearly (from a memory allocation point of view), the wrong approach, since any 32 bit'sfxm wrote:... the declared type of palette array should always be an U/Integer (32-bit or 64-bit, depending on the platform)
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!).
Re: FB palette array datatypes
Perhaps, but currently, ULong pallette arrays do not work with FBC-64.
Re: FB palette array datatypes
This is due to: legacy language mode = QB! The Ball & Chain, on FB's legs ...fxm wrote:Perhaps, but currently, ULong pallette arrays do not work with FBC-64.
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.)
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: FB palette array datatypes
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.)
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.)
Re: FB palette array datatypes
@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.MrSwiss wrote:This is due to: legacy language mode = QB! The Ball & Chain, on FB's legs ...fxm wrote:Perhaps, but currently, ULong pallette arrays do not work with FBC-64.
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.
Re: FB palette array datatypes
Could you please, be a bit more specific, on that "arbitrarily" statement?coderJeff wrote: I also think you arbitrarily assign the cause, ...
I think that I've explained later on sufficiently, what is meant in the first statement.
Then, I'd advice against starting a discussion, simply post in "News" (locked), whats what ...coderJeff wrote:To be honest, not really looking for opinions, just to let users know it's coming and what to expect.
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!)
Re: FB palette array datatypes
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.counting_pine wrote:Maybe we could support both..
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) )
Re: FB palette array datatypes
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 ?
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 ?
Re: FB palette array datatypes
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.
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
Re: FB palette array datatypes
Code: Select all
Dim As Long Ptr p = @x(5)
A p[0]
but not:
Code: Select all
palette get using p[0]
Re: FB palette array datatypes
@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.
#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.
Re: FB palette array datatypes
@coderJeff,
Regarding the "references", did you see my other post: viewtopic.php?p=248410#p248410 ?
Regarding the "references", did you see my other post: viewtopic.php?p=248410#p248410 ?
Re: FB palette array datatypes
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