QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: bplus on March 03, 2022, 11:49:47 am

Title: &H colors dont work as CONST
Post by: bplus on March 03, 2022, 11:49:47 am
Use to work with POINT, what happened?

Doesn't appear to work way back before 1.4 even.

Title: Re: &H colors dont work as CONST
Post by: FellippeHeitor on March 03, 2022, 11:54:23 am
No clue what you mean. Still waiting for reply at Discord.
Title: Re: &H colors dont work as CONST
Post by: bplus on March 03, 2022, 11:57:12 am
This code from 4 years ago use to work with CONST SkyC = &Hffwhatever

Now it has to be DIM Shared as_Unsigned Long and then assigned for POINT to match correctly.
Code: QB64: [Select]
  1. _Title "Tanks Battle! by bplus 2018-02-03"
  2. 'from: Tanks Battle.sdlbas (B+=MGA) 2016-10-29
  3. ' let the projectiles fly!
  4.  
  5.  
  6. 'screen stuff
  7. Const SW = 1200
  8. Const SH = 720
  9.  
  10.  
  11. 'tank stuff
  12. Const tN = 15 'number of tanks
  13. Const tNm1 = tN - 1 ' for loops and arrays
  14. Const tW = 20 'width of tank
  15. Const tH = 8 'height of tank
  16. Type tank
  17.     x As Single
  18.     y As Single
  19.     da As Single
  20.     v As Single 'velocity
  21.     c As _Integer64 'color
  22.     bx As Single 'barrel
  23.     by As Single
  24.     f As _Byte 'finished
  25.  
  26. 'hole stuff
  27. Const hR = tW + 3
  28. Const topHole = 1000
  29. Type hole
  30.     x As Integer
  31.     y As Integer
  32.  
  33. 'projectile stuff
  34. Const rightA = -10
  35. Const leftA = -170
  36. Const lVel = 7
  37. Const hVel = 22
  38. Const pC = &HFFFFFF00
  39. Const gravity = .35
  40.  
  41. Screen _NewImage(SW, SH, 32)
  42.  
  43.  
  44. Const skyC = &HFF848888 ' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< this  used to work !
  45. 'Dim Shared As _Unsigned Long skyC ' >>>>>>>>>>>>>>>>>>>>> fix for 2.0
  46. 'skyC = &HFF848888
  47.  
  48. Common Shared rad, deg ' yeah don't need these with _D2R and _R2D but this was 4 years ago
  49. deg = 180 / _Pi
  50. rad = _Pi / 180
  51.  
  52. ff$ = "arial" ' I have loaded and tested many fonts from Windows Folder and disappointed how few work with QB64
  53. 'load and check Big size font
  54. bArial& = _LoadFont("C:\windows\fonts\" + ff$ + ".ttf", 48, "BOLD")
  55. If bArial& <= 0 Then Print "Trouble with " + ff$ + ".ttf size 48 file, goodbye.": Sleep: End
  56. 'bFW = _FONTWIDTH(bArial&): bFH = _FONTHEIGHT(bArial&)
  57. '_FONT bArial&
  58. 'LOCATE 1, 1: PRINT "This is BIG font."
  59. 'SLEEP
  60.  
  61.  
  62. Dim Shared tanks(tNm1) As tank, holes(topHole) As hole
  63.  
  64. 'get holes set up
  65. holeIndex = -1
  66.  
  67. land& = _NewImage(SW, SH, 32)
  68. _Dest land&
  69. drawLandscape
  70.  
  71. initializeTanks
  72. hotTank = tNm1
  73.  
  74. change = 1
  75. While change 'get tanks landed before start shooting
  76.     change = 0
  77.     Cls
  78.     _PutImage , land&, 0 'land the tanks and reland the tanks if the dirt is shot out under them
  79.     For i = 0 To tNm1
  80.         If Point(tanks(i).x + tW / 2, tanks(i).y + tH + 1) = skyC Then
  81.             tanks(i).y = tanks(i).y + 2
  82.             change = 1
  83.         End If
  84.         drawTank i
  85.     Next
  86.     _Display
  87.  
  88. While 1 '< main loop start
  89.     Cls
  90.     _PutImage , land&, 0
  91.  
  92.     'the land with holes
  93.     If holeIndex > -1 Then
  94.         For ii = 0 To holeIndex
  95.             drawHole holes(ii).x, holes(ii).y
  96.         Next
  97.     End If
  98.  
  99.     'reland the tanks if the dirt is shot out under them
  100.     For i = 0 To tNm1
  101.         If tanks(i).f = 0 Then
  102.             While Point(tanks(i).x + tW / 2, tanks(i).y + tH + 1) = skyC
  103.                 tanks(i).y = tanks(i).y + 2
  104.             Wend
  105.  
  106.             'repoint barrels and reset velocitys
  107.             If Rnd < .5 Then 'avoid straight up and down  suicide shots
  108.                 tanks(i).da = rand(leftA, -92)
  109.             Else
  110.                 tanks(i).da = rand(rightA, -88)
  111.             End If
  112.             tanks(i).v = rand(lVel, hVel) 'velocity
  113.             drawTank i
  114.         End If
  115.     Next
  116.     _Display
  117.     _Delay .1
  118.  
  119.  
  120.     ''whose turn to shoot
  121.     lastMan = hotTank
  122.     hotTank = hotTank + 1
  123.     hotTank = hotTank Mod tN
  124.     While tanks(hotTank).f = 1 'look for a tank still alive
  125.         hotTank = hotTank + 1 'whose turn to shoot
  126.         hotTank = hotTank Mod tN
  127.         'did we cycle through all the dead tanks?
  128.         If hotTank = lastMan Then 'game over, last man standing
  129.             Color _RGB32(220, 255, 0), skyC
  130.             _Font bArial&
  131.             _PrintString (SW / 2 - 120, SH / 2 - 80), "Game Over!"
  132.             _Display
  133.             _Delay 5
  134.             _Font 16
  135.             Sleep
  136.             End
  137.         End If
  138.     Wend
  139.  
  140.     'setup hotTank's shot
  141.     rAngle = tanks(hotTank).da * rad 'convert here to radians for SIN and COS
  142.     pX = tanks(hotTank).bx
  143.     pY = tanks(hotTank).by
  144.     pX_change = tanks(hotTank).v * Cos(rAngle) 'this is the cuurent  X vector of the projectile
  145.     pY_change = tanks(hotTank).v * Sin(rAngle) ' this is the current Y vector of the projectile
  146.     pActive = 0 ' do not Activate until projectile sees the skyC
  147.  
  148.     While 1
  149.         pY_change = pY_change + gravity ' pY starts in upward direction but will eventually fall due to gravity
  150.         pX = pX + pX_change
  151.         pY = pY + pY_change
  152.  
  153.         'show projectile progress, hit or air
  154.         If pX >= 0 And pX <= SW And pY <= SH Then ' still active
  155.             'check for tank hit
  156.             For iTank = 0 To tNm1
  157.                 If tanks(iTank).f <> 1 And pActive Then 'tanks can blow up themselves
  158.                     If dist(pX, pY, tanks(iTank).x + tW / 2, tanks(iTank).y + tH / 2) < hR Then
  159.                         tanks(iTank).f = 1
  160.                         Color _RGB32(255, 0, 0)
  161.                         For rr = 1 To hR
  162.                             fcirc pX, pY, rr
  163.                             _Display
  164.                             _Delay .01
  165.                             If rr Mod 2 Then
  166.                                 Color _RGB32(128, 255, 0)
  167.                             Else
  168.                                 Color _RGB32(255, 0, 0)
  169.                             End If
  170.                         Next
  171.                         If holeIndex < topHole Then
  172.                             holeIndex = holeIndex + 1
  173.                             holes(holeIndex).x = pX
  174.                             holes(holeIndex).y = pY
  175.                             drawHole pX, pY
  176.                             _Display
  177.                         End If
  178.                         pX = SW + 10
  179.                         pY = SH + 10
  180.                         Exit While
  181.                     End If
  182.                 End If
  183.             Next
  184.  
  185.             If Point(pX, pY) = skyC Then
  186.                 pActive = 1
  187.                 Color pC
  188.                 fcirc pX, pY, 2 ' <<<<<<<<<<<<<<<< to see round projectiles that could be replaced by image
  189.             ElseIf pY < 0 Then
  190.                 'still hot but cant see
  191.             ElseIf Point(pX, pY) <> skyC And Point(pX, pY) <> pC And pActive Then 'hit ground?
  192.                 Color _RGB(255, 0, 0)
  193.                 For rr = 1 To hR
  194.                     fcirc pX, pY, rr
  195.                     _Display
  196.                     _Delay .01
  197.                     If rr Mod 2 Then
  198.                         Color _RGB32(128, 255, 0)
  199.                     Else
  200.                         Color _RGB32(255, 0, 0)
  201.                     End If
  202.                 Next
  203.                 If holeIndex < topHole Then
  204.                     holeIndex = holeIndex + 1
  205.                     holes(holeIndex).x = pX
  206.                     holes(holeIndex).y = pY
  207.                     drawHole pX, pY
  208.                     _Display
  209.                 End If
  210.                 pX = SW + 10
  211.                 pY = SH + 10
  212.                 Exit While
  213.             End If
  214.         Else 'not active
  215.             Exit While
  216.         End If
  217.         _Display
  218.         _Delay .03
  219.     Wend
  220.  
  221. Sub drawHole (xx, yy)
  222.     Color skyC
  223.     For i = yy To 300 Step -1
  224.         fcirc xx, i, hR
  225.     Next
  226.  
  227. Sub drawLandscape
  228.     'the sky
  229.     Line (0, 0)-(SW, SH), skyC, BF
  230.  
  231.     'the land
  232.     startH = SH - 100
  233.     rr = 70: gg = 70: bb = 90
  234.     For mountain = 1 To 6
  235.         Xright = 0
  236.         y = startH
  237.         While Xright < SW
  238.             ' upDown = local up / down over range, change along Y
  239.             ' range = how far up / down, along X
  240.             upDown = (Rnd * (.8) - .35) * (mountain * .5)
  241.             range = Xright + rand%(15, 25) * 2.5 / mountain
  242.             For x = Xright - 1 To range
  243.                 y = y + upDown
  244.                 Line (x, y)-(x + 1, SH), _RGB32(rr, gg, bb), BF
  245.             Next
  246.             Xright = range
  247.         Wend
  248.         rr = rand(rr - 15, rr): gg = rand(gg - 15, gg): bb = rand(bb - 25, bb)
  249.         If rr < 0 Then rr = 0
  250.         If gg < 0 Then gg = 0
  251.         If bb < 0 Then bb = 0
  252.         startH = startH + rand(5, 20)
  253.     Next
  254.  
  255. Sub initializeTanks ' x, y, barrel angle,  velocity, color
  256.     tl = (SW - tW) / tN: tl2 = tl / 2: tl4 = .8 * tl2
  257.     For i = 0 To tNm1
  258.         tanks(i).x = rand%(tl2 + tl * i - tl4 - tW, tl2 + tl * i + tl4 - tW)
  259.         tanks(i).y = 300 '<<<<<<<<<<<<<<<<<<<<<<<<<< for testing
  260.         tanks(i).da = rand%(-180, 0) 'degree Angle
  261.         tanks(i).v = rand%(10, 20) 'velocity
  262.         If tanks(i).da < -90 Then 'barrel  is pointed left
  263.             tanks(i).v = -1 * tanks(i).v
  264.         End If
  265.         tc = i * Int(200 / (3 * tN)) 'maximize color difference between tanks
  266.         tanks(i).c = _RGB32(55 + 2 * tc, 13 + tc, 23 + tc) ' first tank is darkest
  267.     Next
  268.     'shuffle color order
  269.     For i = tNm1 To 1 Step -1
  270.         r = rand%(0, i)
  271.         Swap tanks(i).x, tanks(r).x
  272.     Next
  273.  
  274. Sub drawTank (i)
  275.     'ink(tanks(i, "c"))
  276.     Color tanks(i).c
  277.     'turret
  278.     fEllipse tanks(i).x + tW / 2, tanks(i).y + tH / 3, tW / 4 + 1, tH / 4 + 1
  279.     bX = tW / 2 * Cos(rad * tanks(i).da)
  280.     bY = tW / 2 * Sin(rad * tanks(i).da)
  281.     Line (tanks(i).x + tW / 2, tanks(i).y + tH / 3)-(tanks(i).x + tW / 2 + bX, tanks(i).y + tH / 4 + bY)
  282.     Line (tanks(i).x + tW / 2 + 1, tanks(i).y + tH / 3 + 1)-(tanks(i).x + tW / 2 + bX + 1, tanks(i).y + tH / 4 + bY + 1)
  283.     tanks(i).bx = tanks(i).x + tW / 2 + bX
  284.     tanks(i).by = tanks(i).y + tH / 4 + bY
  285.     fEllipse tanks(i).x + tW / 2, tanks(i).y + .75 * tH, tW / 2, tH / 4
  286.     Color _RGB32(0, 0, 0)
  287.     ellipse tanks(i).x + tW / 2, tanks(i).y + .75 * tH, tW / 2 + 1, tH / 4 + 1
  288.     ellipse tanks(i).x + tW / 2 + 1, tanks(i).y + .75 * tH, tW / 2 + 1, tH / 4 + 1
  289.  
  290. Function rand% (lo%, hi%)
  291.     rand% = (Rnd * (hi% - lo% + 1)) \ 1 + lo%
  292.  
  293. Function rdir% ()
  294.     If Rnd < .5 Then rdir% = -1 Else rdir% = 1
  295.  
  296. Function dist# (x1%, y1%, x2%, y2%)
  297.     dist# = ((x1% - x2%) ^ 2 + (y1% - y2%) ^ 2) ^ .5
  298.  
  299. 'Steve McNeil's  copied from his forum   note: Radius is too common a name
  300. Sub fcirc (CX As Long, CY As Long, R As Long)
  301.     Dim subRadius As Long, RadiusError As Long
  302.     Dim X As Long, Y As Long
  303.  
  304.     subRadius = Abs(R)
  305.     RadiusError = -subRadius
  306.     X = subRadius
  307.     Y = 0
  308.  
  309.     If subRadius = 0 Then PSet (CX, CY): Exit Sub
  310.  
  311.     ' Draw the middle span here so we don't draw it twice in the main loop,
  312.     ' which would be a problem with blending turned on.
  313.     Line (CX - X, CY)-(CX + X, CY), , BF
  314.  
  315.     While X > Y
  316.         RadiusError = RadiusError + Y * 2 + 1
  317.         If RadiusError >= 0 Then
  318.             If X <> Y + 1 Then
  319.                 Line (CX - Y, CY - X)-(CX + Y, CY - X), , BF
  320.                 Line (CX - Y, CY + X)-(CX + Y, CY + X), , BF
  321.             End If
  322.             X = X - 1
  323.             RadiusError = RadiusError - X * 2
  324.         End If
  325.         Y = Y + 1
  326.         Line (CX - X, CY - Y)-(CX + X, CY - Y), , BF
  327.         Line (CX - X, CY + Y)-(CX + X, CY + Y), , BF
  328.     Wend
  329.  
  330. Sub fEllipse (CX As Long, CY As Long, xRadius As Long, yRadius As Long)
  331.     Dim scale As Single, x As Long, y As Long
  332.     scale = yRadius / xRadius
  333.     Line (CX, CY - yRadius)-(CX, CY + yRadius), , BF
  334.     For x = 1 To xRadius
  335.         y = scale * Sqr(xRadius * xRadius - x * x)
  336.         Line (CX + x, CY - y)-(CX + x, CY + y), , BF
  337.         Line (CX - x, CY - y)-(CX - x, CY + y), , BF
  338.     Next
  339.  
  340. Sub ellipse (CX As Long, CY As Long, xRadius As Long, yRadius As Long)
  341.     Dim scale As Single, xs As Long, x As Long, y As Long
  342.     Dim lastx As Long, lasty As Long
  343.     scale = yRadius / xRadius: xs = xRadius * xRadius
  344.     PSet (CX, CY - yRadius): PSet (CX, CY + yRadius)
  345.     lastx = 0: lasty = yRadius
  346.     For x = 1 To xRadius
  347.         y = scale * Sqr(xs - x * x)
  348.         Line (CX + lastx, CY - lasty)-(CX + x, CY - y)
  349.         Line (CX + lastx, CY + lasty)-(CX + x, CY + y)
  350.         Line (CX - lastx, CY - lasty)-(CX - x, CY - y)
  351.         Line (CX - lastx, CY + lasty)-(CX - x, CY + y)
  352.         lastx = x: lasty = y
  353.     Next
  354.  
  355.  

This part:
Code: QB64: [Select]
  1. Const skyC = &HFF848888 ' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< this  used to work !
  2. 'Dim Shared As _Unsigned Long skyC ' >>>>>>>>>>>>>>>>>>>>> fix for 2.0
  3. 'skyC = &HFF848888
  4.  
Title: Re: &H colors dont work as CONST
Post by: FellippeHeitor on March 03, 2022, 11:59:43 am
Might wanna force type, or else it'll be unsigned:

Code: QB64: [Select]
  1. Const skyC˜& = &HFF848888
Title: Re: &H colors dont work as CONST
Post by: FellippeHeitor on March 03, 2022, 12:00:40 pm
a& = _rgb32(255) results in -1 <-- that'll fail when compared with POINT()
aËœ& = _rgb32(255) results in  4294967295 <-- that'll work when compared with POINT()
Title: Re: &H colors dont work as CONST
Post by: bplus on March 03, 2022, 12:06:08 pm
Just saying this use to work and Const's didn't have to be typed.
Title: Re: &H colors dont work as CONST
Post by: bplus on March 03, 2022, 12:07:35 pm
Nope
Code: QB64: [Select]
  1. Const skyC~& = &HFF848888 ' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< this  used to work !          
  2.  

Doesn't do it either.
Title: Re: &H colors dont work as CONST
Post by: FellippeHeitor on March 03, 2022, 12:08:01 pm
It's an old discussion that pops up eventually (Steve has many posts explaining the issue). One must be aware that POINT() returns unsigned values. CONST will store the required value in whatever it sees fit, which is usually unsigned by default.

Store your POINT() returns in a signed variable first and it'll match.
Title: Re: &H colors dont work as CONST
Post by: FellippeHeitor on March 03, 2022, 12:09:06 pm
Nope
Code: QB64: [Select]
  1. Const skyC~& = &HFF848888 ' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< this  used to work !          
  2.  

Doesn't do it either.

What does this return?

Code: QB64: [Select]
  1.  PRINT skyCËœ&, &HFF848888
Title: Re: &H colors dont work as CONST
Post by: RhoSigma on March 03, 2022, 12:11:51 pm
I'd give it a try to make the value a specific type, not the const name, as CONSTs typically get its type from the given value, so does it work this way?
Code: QB64: [Select]
  1.     Const skyC = &HFF848888~& ' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< this  used to work !          
  2.      
Title: Re: &H colors dont work as CONST
Post by: bplus on March 03, 2022, 12:16:15 pm
Here's what I get when I also compare to POINT

  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: &H colors dont work as CONST
Post by: FellippeHeitor on March 03, 2022, 12:17:48 pm
Here's what I get when I also compare to POINT

  [ This attachment cannot be displayed inline in 'Print Page' view ]  

In that scenario skyC˜& has to be equal to Point(10, 10) - does the comparison fail?
Title: Re: &H colors dont work as CONST
Post by: bplus on March 03, 2022, 12:22:32 pm
Yes Const SkyC is failing to match to POINT(x,y) either as SkyC or SkyC~&

Wait Rho's works! This
Const skyC = &HFF848888~&

But not this:
Const skyC~& = &HFF848888

So I will have to add ~& to &H color numbers in future and fix past.
Title: Re: &H colors dont work as CONST
Post by: bplus on March 03, 2022, 12:46:57 pm
It is odd that Rho's Const assignment and test prints that same exact numbers but works in program!
  [ This attachment cannot be displayed inline in 'Print Page' view ]  


The print line matches Fellippes but Fellippes Const SkyC~& does not work in program and Rho's Const SkyC = &Hnumber~&

Wait do I have to compare to SkyC~& at the crucial POINT check! Ah that might be it! (And all other, 10 places!)

Well I changed all 10 places where SkyC was used to SkyC~& and still errors but error is different now.
Rho's solution better, only have to change the &H color number once and works.
Title: Re: &H colors dont work as CONST
Post by: RhoSigma on March 03, 2022, 01:12:36 pm
That is because the explicit type suffix is ignored on the const name:

CONST skyC~& = whatever can be recalled using PRINT skyC~& as well as PRINT skyC, both will print the same.

Only the contents/value designates the type here, think of it like for functions behavior, you define eg. FUNC UglyFunc&(whatever%) to declare a LONG result, but in the program you can call it either as UglyFunc& or without suffix UglyFunc, both will work, because the function internally "knows" how it was defined. Same is true for CONSTs.
Title: Re: &H colors dont work as CONST
Post by: bplus on March 03, 2022, 01:46:04 pm
Thanks somewhen I learned that suffixes don't mean much for Const and thanks for your fix @RhoSigma.
Title: Re: &H colors dont work as CONST
Post by: Cobalt on March 03, 2022, 04:55:29 pm
Well Bplus is right, Back in Ver 1.1Build82 you can just do this:
CONST WHITE = &HFFFFFFFF
and you get the correct value, sometime between 1.1 and 1.4 that was changed
Can not find my copies of 1.2 and 1.3 to see what happens there.

As you can see in the attachment, Ver 2.1 prints -1 while Ver 1.1B82 prints the correct value for an _UNSIGNED constant

  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: &H colors dont work as CONST
Post by: FellippeHeitor on March 03, 2022, 06:22:59 pm
The whole CONST system was replaced by Steve at some point. We're in internal talks to replace the pre-compiler const evaluator with a runtime evaluator - technically that'd make CONSTs regular variables that have a "can't change" flag. That's in the works, but we don't have a public road map for this specific update yet, so please keep Rho's indications in mind for now.
Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 03, 2022, 06:49:02 pm
CONST has always tried to guess as to what type of variable to assign a value to.  Back before I first overhauled CONST to allow us to use more functions with it with the internal math evaluator, it used to shoot for unsigned values by default. 

Try a copy of QB64 around v0.90 or so, and you'll see that &HFFFFFFFF evaluated to -1.

When I overhauled the CONST system to add in our math functions and all, I made a point of trying to switch out to unsigned values, if possible.  &HFFFFFFFF would now become +4286...(whatever).

Under the hood, both these values are the exact same.  One is FFFFFFFF as a signed long, the other is FFFFFFFF as an unsigned long.  The main reason why I chose to swap from signed to unsigned by default, when I overhauled the CONST system the first time, was for numeric matches with POINT.



Now, sometime after the 1.2 and before the 2.1 version which is the most current, I went in and tweaked the CONST system once again.  Before, it ran into issues with explicitly defined types and sometimes ignored them, so I expanded and corrected that issue (along with a few more little things like multiple assignments from the same line).  Since users could now manually define what types they wanted associated with CONST, there wasn't any reason for me to hijack the process and force CONST to choose unsigned values over signed values.  I took that hijack hack out for us as it was no longer necessary.

If one wants to work with unsigned values, simply make certain to assign unsigned values to your const, or else specify the const as being unsigned.

Code: QB64: [Select]
  1. Const C = &HFF848888
  2. Const C1~& = &HFF848888
  3. Const C2 = &HFF848888~&
  4. Print C, C1, C2
  5.  

-8091512            4286875784          4286875784

C is an signed long.
C1~& is an unsigned long.
C2 is an unsigned long.

Either specify the CONST with an explicit type, or assign the value with the explicit type, and it makes certain that the value is that specific type.  It's only when you leave off an explicit type completely that CONST chooses for itself as to what type of variable works best to store the value for you -- which in the above case happens to be a signed long.   
Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 03, 2022, 06:59:20 pm
The issue here doesn't seem to be in CONST.  There actually appears to be some sort of issue with IF which is causing a glitch with this:

Code: QB64: [Select]
  1. Const skyC~& = &HFF848888
  2. Const skyCompare = &HFF848888~&
  3.  
  4. Print skyC
  5. Print skyCompare
  6. If skyC = skyCompare Then Print "They match" Else Print "No match"

From the two print statements, we can see that the two values are exactly the same -- yet the IF statement is showing that they're "No match".  This doesn't appear to be a CONST issue, but an IF issue somewhere.
Title: Re: &H colors dont work as CONST
Post by: FellippeHeitor on March 03, 2022, 07:09:26 pm
Inspected the C++ output and CONST eval is storing skyC~& as 18446744073701460104 and skyCompare as 4286875784 -- so IF is working as intended.
Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 03, 2022, 07:22:49 pm
Inspected the C++ output and CONST eval is storing skyC~& as 18446744073701460104 and skyCompare as 4286875784 -- so IF is working as intended.

I was just looking at that as well.  Things here are complicated as heck.

Code: QB64: [Select]
  1. Const skyC~& = &HFF848888
  2. Const skyCompare = &HFF848888~&
  3. Const skyC2~&& = &HFF848888
  4.  
  5. Print Hex$(skyC), skyC
  6. Print Hex$(skyCompare), skyCompare
  7. Print Hex$(skyC2), skyC2
  8. If skyC = skyCompare Then Print "They match" Else Print "No match: "

The value we're generating seems to be an unsigned integer 64, rather than an unsigned long.  The odd thing is if you look at the c-c-output for the above.

The first print statement makes certain that we print an unsigned long:

qbs_set(tqbs,qbs_add(qbs_str((uint32)( 18446744073701460104 )),qbs_new_txt(" ")));

The third one, doesn't do that; it makes certain that we print an unsigned integer64:

qbs_set(tqbs,qbs_add(qbs_str((uint64)( 18446744073701460104ull )),qbs_new_txt(" ")));

So the internal value is stored as the same in both cases, and there's some flag which knows to toggle with (unit32) and (uint64) to make certain we have the right value associated with the number.

Except the IF statement doesn't have this explicit assignment associated to it: if ((-( 18446744073701460104 == 4286875784 ))

(There's no uint32 or uint64 in there anywhere, but notice that the ull is missing as well, and that should be what specifies us as an unsigned integer64 -- we should default to an unsigned long here.)



So where's the glitch in this mess?  Apparently the CONST is flagging some sort of internal switch so that PRINT knows to toggle between uint32 and uint64, but exactly what's wrong with the above?  Does IF need this same switch?  Does CONST need something to change?  Why is it sometimes accepting that it's an uint32 and other times ignoring that?

The overall thing has me baffled at the moment.  It doesn't appear that CONST itself is wrong, as the PRINT knows to use uint32 values...  So where exactly is the root of the problem coming from??



Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 03, 2022, 07:39:56 pm
Note: Tweaking the IF statement to add the uint32 cast to the values makes things work as expected:

Code: [Select]
if ((-( (uint32)(18446744073701460104) == 4286875784 ))||new_error){
The only issue with this comes from the question:  Is IF the only statement which is missing the (uint32) code, or are there other places where it could be an issue with CONST?  WHY does PRINT have one and make certain to use one, while IF doesn't? 



DO statements are just like IF -- they don't have an explicit (uint32) associated with them either with CONST values.

}while((!(-(*__ULONG_I>= 18446744073701460104 )))&&(!new_error));

That's a little snippet from:
Do
    i = i + 1
    If _KeyHit Then Exit Do
    Print i, skyC
Loop Until i >= skyC

As you can see; there's no (uint32) in there either. 

Print seems to realize that our variable is an unsigned long, but nothing else does...  And I don't have a clue why the heck that is!
Title: Re: &H colors dont work as CONST
Post by: Cobalt on March 03, 2022, 07:44:46 pm
I don't really care one way or the other, works fine for me now. I just thought I see if Bplus was right about it being different in an earlier version or not. And he was.
AND it turns out Steve is right too! Ver .954(SDL) displays a -1.
Guessing, perhaps, when it switched over to GL it assigned the CONST differently and then an update sometime after 1.1\1.2 changed the way they are allocated.

I say leave them alone. CONSTs are fine just how they are.
Title: Re: &H colors dont work as CONST
Post by: bplus on March 04, 2022, 01:54:40 pm
I hate to disagree with fellow Ohioan but Const is valuable part of coding in my book. You don't have to use them in your book but to me it is important they work as well as any other coding tool.

It is so much easier to remember and write SkyC than to do &HFFRRGGBB all the time. And what if you want to change that value, you'd have to change it everywhere in your program instead of once in Constants Declares Section.
Title: Re: &H colors dont work as CONST
Post by: _vince on March 04, 2022, 11:15:56 pm
The whole CONST system was replaced by Steve at some point.

Glad to know the fundamental CONST is in good hands!

May I recommend Steve's useful colour storage tutorial
https://qb64forum.alephc.xyz/index.php?topic=4480.0 (https://qb64forum.alephc.xyz/index.php?topic=4480.0)

though, personally, I prefer to leave it to the pros and just quickly include one of these in my programs ;)
https://qb64.freeforums.net/thread/5/32-bit-color-const-names (https://qb64.freeforums.net/thread/5/32-bit-color-const-names)

Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 05, 2022, 02:16:36 am
though, personally, I prefer to leave it to the pros and just quickly include one of these in my programs ;)
https://qb64.freeforums.net/thread/5/32-bit-color-const-names (https://qb64.freeforums.net/thread/5/32-bit-color-const-names)

@vince With the latest versions of QB64, you can save the includes and just use $COLOR:32 or $COLOR:0.  (Unless you're working with a 256 color screen, in which case you'd probably want the include to set the palette to match the names for any temp/secondary screens you might create.)
Title: Re: &H colors dont work as CONST
Post by: _vince on March 05, 2022, 02:44:12 am
oh wow, you built in your colour constants into QB64, handy!

btw, did you hand-pick these constants yourself? I trust that WildWatermelon, BananaMania, VividViolet and such others are tastefully fine tuned to their literal connotation
Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 05, 2022, 03:01:25 am
oh wow, you built in your colour constants into QB64, handy!

btw, did you hand-pick these constants yourself? I trust that WildWatermelon, BananaMania, VividViolet and such others are tastefully fine tuned to their literal connotation

The list came from basically two places:  The first is html standard values used in web browsers everywhere, while the second is from the crayola website and from wiki: https://en.wikipedia.org/wiki/List_of_Crayola_crayon_colors
http://www.jennyscrayoncollection.com/2017/10/complete-list-of-current-crayola-crayon.html
https://www.w3schools.com/colors/colors_names.asp
Title: Re: &H colors dont work as CONST
Post by: Cobalt on March 05, 2022, 05:58:22 am
I hate to disagree with fellow Ohioan but Const is valuable part of coding in my book. You don't have to use them in your book but to me it is important they work as well as any other coding tool.

Not sure how to take that.

I didn't mean to suggest that const be mothballed or such. Just that it did not need further disruption, inpart to one of Fellippe's comments earlier.

The whole CONST system was replaced by Steve at some point. We're in internal talks to replace the pre-compiler const evaluator with a runtime evaluator - technically that'd make CONSTs regular variables that have a "can't change" flag. That's in the works, but we don't have a public road map for this specific update yet, so please keep Rho's indications in mind for now.

I would consider myself quite the hypocrite if I said "const's are not important so shove em'" Not sure what I would do without them!
If perhaps you don't like using the affix ~&, it seems to work fine using _RGB32(R,G,B) to assign a color value to a  constant.
Title: Re: &H colors dont work as CONST
Post by: bplus on March 05, 2022, 11:43:51 am
sOK @Cobalt

I was probably over reacting to:
Quote
I don't really care one way or the other, works fine for me now.

I dislike when I go to use an old program that worked and find out it doesn't... with 2.0+ I do expect old functions have to be checked, never expected to have to recheck Const's too, since 1.4 I think. But now it's on my bug checklist. I remember Qwerkey had a time of it with Consts in his Pi in the Sky program, after that Const were fixed better but still a few things get by. Anyway, live and learn...
Title: Re: &H colors dont work as CONST
Post by: _vince on March 05, 2022, 09:10:28 pm
(Unless you're working with a 256 color screen, in which case you'd probably want the include to set the palette to match the names for any temp/secondary screens you might create.)

oh yeah I spent hours wondering why my screen wasn't BananaMania then I realized I was in 256 mode!

anyways, since 256 mode is effectively emulated, why would anyone use that mode?  Why not stick to 32 bit color mode and just create DIM a(256): a(0)=BananaMania: a(1)=_rgb(255,0,0): etc, or have it match the original VGA palette, or map it to 'Hue', or whatever and use that with any graphics command for an effective 256 mode emulation, ie CIRCLE (100,100),3,a(155) instead of CIRCLE (100,100),3,155
Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 05, 2022, 10:21:43 pm
Only real reason for 256 color mode that I can think of is for smaller image file sizes.  A 256 color image has to store the palette (3 or 4 bytes if alpha is included, for 256 colors), and then a single byte for each color pixel.   32-bit colors are 4 bytes per pixel, so quite a bit larger sizes.

Of course, since QB64 currently doesn't support 256 color images with _LOADIMAGE, (it auto coverts them to 32-bit images instead,) and since modern OSes have so much memory available anyway, I don't really see the point for 256 color screens anymore.  Apparently nobody else does either, as we never see posts complaining about not being able to load 256 color images.

I truly think everyone has moved on to 32-bit screens nowadays.  ;)
Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 06, 2022, 02:05:53 am
Back to the glitch at hand here:

It appears to me that CONST only deals with 3 values when it comes to explicitly defining a type -- float, string, and integer64.  Down in QB64.bas, around line 2250, we find the following for storing values in a const:

Code: QB64: [Select]
  1.                                 If t And ISFLOAT Then
  2.                                     constval## = _CV(_Float, e$)
  3.                                     constval&& = constval##
  4.                                     constval~&& = constval&&
  5.                                 Else
  6.                                     If (t And ISUNSIGNED) And (t And 511) = 64 Then
  7.                                         constval~&& = _CV(_Unsigned _Integer64, e$)
  8.                                         constval&& = constval~&&
  9.                                         constval## = constval&&
  10.                                     Else
  11.                                         constval&& = _CV(_Integer64, e$)
  12.                                         constval## = constval&&
  13.                                         constval~&& = constval&&
  14.                                     End If
  15.                                 End If

Right after that, we find the following little snippet of code:
Code: QB64: [Select]
  1.                                 'override type?
  2.                                 If typeoverride Then
  3.                                     'range check required here (noted in todo)
  4.                                     t = typeoverride
  5.                                 End If

Which, as the comment above, seems as if it's just a stub for code that was intended to be added later.  There's supposed to be a range check in that IF block, but it's not there.  It's just a note in some forgotten todo list somewhere.  :P

The math evaluator works with the formula foo = &HFF848888~& to make that &H the proper unsigned long value, but the CONST evaluator doesn't have a range check to make CONST foo~& an unsigned long.  It's trying to store the value as an _CV(_integer64) value.

Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 06, 2022, 02:49:03 am
I'm thinking the simplest fix for this is to go in around line 2350 (do a search for the label "constAddDone:"), where you'll find this:

Code: QB64: [Select]
  1.                             constdefined(i2) = 1
  2.                             constcname(i2) = n$
  3.                             constnamesymbol(i2) = typevalue2symbol$(t)
  4.                             If Error_Happened Then GoTo errmes
  5.                             consttype(i2) = t
  6.                             If t And ISSTRING Then
  7.                                 conststring(i2) = e$
  8.                             Else
  9.                                 If t And ISFLOAT Then
  10.                                     constfloat(i2) = constval##
  11.                                 Else
  12.                                     If t And ISUNSIGNED Then
  13.                                         constuinteger(i2) = constval~&&
  14.                                     Else
  15.                                         constinteger(i2) = constval&&
  16.                                     End If
  17.                                 End If
  18.                             End If
  19.  
  20.                             constAddDone:

Add in a few simple lines to check scope and we make certain that our value is what we intend for it to be, like so:
Code: QB64: [Select]
  1.                             constdefined(i2) = 1
  2.                             constcname(i2) = n$
  3.                             constnamesymbol(i2) = typevalue2symbol$(t)
  4.                             If Error_Happened Then GoTo errmes
  5.                             consttype(i2) = t
  6.                             If t And ISSTRING Then
  7.                                 conststring(i2) = e$
  8.                             Else
  9.                                 If t And ISFLOAT Then
  10.                                     constfloat(i2) = constval##
  11.                                 Else
  12.                                     If t And ISUNSIGNED Then
  13.                                         If t And 8 Then constval~&& = constval~&& Mod (2 ^ 8) 'unsigned byte
  14.                                         If t And 16 Then constval~&& = constval~&& Mod (2 ^ 16) 'unsigned integer
  15.                                         If t And 32 Then constval~&& = constval~&& Mod (2 ^ 32) 'unsigned long
  16.                                         constuinteger(i2) = constval~&&
  17.                                     Else
  18.                                         If t And 8 Then constval&& = constval&& Mod (2 ^ 8) 'signed byte
  19.                                         If t And 16 Then constval&& = constval&& Mod (2 ^ 16) 'signed integer
  20.                                         If t And 32 Then constval&& = constval&& Mod (2 ^ 32) 'signed long
  21.                                         constinteger(i2) = constval&&
  22.                                     End If
  23.                                 End If
  24.                             End If
  25.  
  26.                             constAddDone:

CONST only holds floats, strings, and int64 values.  We have to make certain that we store what we want properly, rather than just let it toss the value into the largest container that it can fit.

-1 as a byte is: &HFF
-1 as an integer is: &HFFFF
-1 as a long is:&HFFFFFFFF
-1 as an integer64 is: &HFFFFFFFFFFFFFFFF

Same number, but much different results when we store it in different variable types.



There's probably other ways and other places to fix this issue along the way of generating our value/type, but this seems like it'd be about the simplest and easiest to do for us, to me. 

Feel free to grab the file below, compile it, and test it out, if you want.  I'm thinking it should fix this issue for good, without breaking anything else.  Give it a few days for folks to try it and and make certain that it works as advertised, and then I'll try and sort out what's required to push it into the repo for everyone, as it's been ages since I last actually pushed a change into the source for us.  I wonder if I can still dig up my Git/Github account  info, or if I'm going to have to go through all that "last credential" hassle to get back into it.  LOL!
Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 06, 2022, 11:19:25 am
@bplus I've finally wrapped my head around what exactly is going on to cause the issue you posted on.

First, let's take a look at the core of the problem:
Code: QB64: [Select]
  1. Const foo~& = -1
  2. Print foo, "foo"
  3. Print 4294967295, "literal"
  4. If foo = 4294967295 Then Print "It matches" Else Print "No match"

Now here, we specify that foo should be an unsigned long, and it's value should be the equivalent of a -1.  We'd expect to see a value of &HFFFFFFFF, overflowed to become 4294967295 for us, and the PRINT statement confirms this value for us.

Unfortunately, the IF statement doesn't think the two numbers match at all!

WHY??

Because QB64 only stores CONST values as one of 4 actual types:  String, Float, Signed Integer64, Unsigned Integer64. 

Sure, we specified that we wanted to store the value as an unsigned value, but CONST only has unsigned integer64's which it stores the numbers as, so that -1 ends up becoming &HFFFFFFFFFFFFFFFF rather than &HFFFFFFFF -- as illustrated below:

Code: QB64: [Select]
  1. Const foo~& = -1
  2. Print foo, "foo"
  3. Print 4294967295, "literal"
  4. If foo = 4294967295 Then Print "It matches" Else Print "No match"
  5.  
  6. UInt64_Max = -1
  7. If foo = UInt64_Max Then Print "It matches" Else Print "No match"

There's no point in specifying CONSTs as byte, integer, or longs.  They'll all simply be integer64s.

The only really interesting and odd thing about these CONST values -- we set a flag to try and keep track of what type they're supposed to be, and PRINT and HEX$ and a few other places make use of that flag to give us the results we expect to see...  It's just that IF and DO and WHILE and such don't bother with that flag, so they don't convert that value.

PRINT foo will print the desired unsigned long value, as it uses that (uint32) flag.
IF foo doesn't use that flag, so it uses the internal unsigned integer64 value...

And that's the basic crux of the issue at hand here.

CONST skyC~& = &HFF8B8888   <-- &H math gives us a negative value for this.
skyC~& is an unsigned integer64 internally, with a flag which is supposed to track its type.
PRINT will use that flag and print the expected type value.
IF doesn't use that flag and thus the 64-bit number doesn't match the expected 32-bit equivalent. 

The code I posted above should fix the issue as far as CONST is concerned, but with &H changing from integer to long to integer64 as it wishes, it's a situation where you could run into just about anywhere.

My suggestion from now on:  If you use &H, specify the return type manually yourself.  Instead of &HFF8B8888, make it &HFF8B8888~&.  This will force that return value to be an unsigned long, rather than a signed long, and that'd stop the issue before it ever started.  ;)
Title: Re: &H colors dont work as CONST
Post by: bplus on March 06, 2022, 11:40:17 am
Wow @SMcNeill  what an investigation, I think you love a good coding mystery and from what I can gather from what you described, this one's a beauty of a mess-tery.

When you get into bit stuff you lose me, I am of the humble and probably singular opinion that only -&H.... (minus &H... ) should be negative to be consistent with numbers of any base and not with computer science geeks for the obvious and plain reason: it's obvious and plainly < 0!

Fellippe's proposed upcoming change to Const's still might not help us with &H numbers or will it?
Title: Re: &H colors dont work as CONST
Post by: SMcNeill on March 06, 2022, 12:02:16 pm
Fellippe's proposed upcoming change to Const's still might not help us with &H numbers or will it?

It won't as the issue is we're changing counting systems based on the length of the hex after the &H.

&H with up to 4 letters after is counted as an integer
&H with up to 8 letters after is counted as an long.
&H with more than 8 letters is counted as an integer64.

This means that it's literally impossible to represent the numbers from 32768 to 65535 with &H.  (Without specifying a manual data type extension.)

&H7FFE is 32766.
&H7FFF is 32767.
&H8000 is -32768.
&H8001 is -32767.
&H8002 is -32766.

our four digit numbers are signed integers, up until we get up to &HFFFF. which represents -1.  Then, when we add 1 to the value, we get:
&H10000 is 65536.

You can't represent the numbers from 32768 to 65535 with &H.  4 digit &H values are signed integers.  5-8 digit values are signed longs that pick up past the integer cutoff.  (And you have the same issue with values between signed long and where 9 digit integer64 values come from as well.)

Overhauling CONST to make it static variables isn't going to change that one bit.  :P
Title: Re: &H colors dont work as CONST
Post by: mdijkens on March 06, 2022, 12:04:50 pm
I would expect CONST values to match assigned type or condition?
So
Const MYCONST = &HFFFF
a% = MYCONST ' -1
a~% = MYCONST ' 65536
a&= MYCONST '65536

Same with comparing in conditions
Title: Re: &H colors dont work as CONST
Post by: bplus on March 06, 2022, 12:27:17 pm
Ah yes the Chameleon variable type.

Now I wonder if difference between Val and Print along with If.