FB palette array datatypes

Forum for discussion about the documentation project.
counting_pine
Site Admin
Posts: 5941
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

FB palette array datatypes

Postby counting_pine » Jun 14, 2018 21:01

Pages like /wiki/KeyPgBload and /wiki/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
Posts: 8175
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: FB palette array datatypes

Postby fxm » Jun 15, 2018 5:37

I thought (maybe stupidly) that the declared type of palette array should always be an [U]Integer (32-bit or 64-bit, depending on the platform).
MrSwiss
Posts: 2682
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FB palette array datatypes

Postby MrSwiss » Jun 15, 2018 11:25

fxm wrote:... 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
Posts: 8175
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: FB palette array datatypes

Postby fxm » Jun 15, 2018 11:49

Perhaps, but currently, ULong pallette arrays do not work with FBC-64.
MrSwiss
Posts: 2682
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FB palette array datatypes

Postby MrSwiss » Jun 15, 2018 12:03

fxm wrote: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
Site Admin
Posts: 5941
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: FB palette array datatypes

Postby counting_pine » Jun 15, 2018 13:30

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
Site Admin
Posts: 2614
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FB palette array datatypes

Postby coderJeff » Jun 15, 2018 19:59

MrSwiss wrote:
fxm wrote: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
Posts: 2682
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FB palette array datatypes

Postby MrSwiss » Jun 16, 2018 0:26

coderJeff wrote: 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.
coderJeff wrote: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
Site Admin
Posts: 2614
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FB palette array datatypes

Postby coderJeff » Jun 16, 2018 6:10

counting_pine wrote: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 [u]long don't work on 64-bit and [u]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 [u]integer, [u]long, [u]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
Posts: 8175
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: FB palette array datatypes

Postby fxm » Jun 16, 2018 8:45

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
Site Admin
Posts: 2614
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FB palette array datatypes

Postby coderJeff » Jun 16, 2018 11:03

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
Posts: 8175
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: FB palette array datatypes

Postby fxm » Jun 16, 2018 11:41

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
Site Admin
Posts: 2614
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FB palette array datatypes

Postby coderJeff » Jun 16, 2018 12:13

@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
Posts: 8175
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: FB palette array datatypes

Postby fxm » Jun 16, 2018 12:27

@coderJeff,
Regarding the "references", did you see my other post: viewtopic.php?p=248410#p248410 ?
coderJeff
Site Admin
Posts: 2614
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FB palette array datatypes

Postby coderJeff » Jun 16, 2018 16:11

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

Return to “Documentation”

Who is online

Users browsing this forum: No registered users and 1 guest