Steve's Quick Lesson on Number TYPEs and Colors

[SMcNeill]

Code: QB64: [Select]

1. Screen _NewImage(640, 640, 32)
2. _Title "Number Types and Colors"
3. Print "Welcome to Steve's Qucik Lesson on Number Types and Colors."
4. Print
5. Print "The most important thing to keep in mind in this lesson is that we're going to be talking exclusively about 32-bit color values here.  For all other screen modes, this lesson holds much less importance."
6. Print
7. Print "Press <ANY KEY> to begin!"
8. Sleep
9. Cls , 0
10. Print "First, let's talk about how SINGLE variable types work (or DON'T work), in regards to 32-bit colors."
11. Print
12. Print "Let's choose a nice color and use it to draw a box on the screen."
13. Print "How about we choose a BLUE box?  _RGB32(0, 0, 255)"
14. Print
15. Line (50, 90)-(250, 250), _RGB32(0, 0, 255), BF
16. Locate 18, 1: Print "Looks like a nice BLUE box.  Right?"
17. Print "Press <ANY KEY> to continue!"
18. Sleep
19. Cls , 0
20. Print "Now, let's store that BLUE value inside a SINGLE tyoe variable."
21. Print "BLUE = _RGB32(0, 0, 255)"
22. Print ""
23. Print "Once we've did that, let's draw the exact same box on the screen again with the variable."
24. BLUE = _RGB32(0, 0, 256)
25. Line (50, 90)-(250, 250), BLUE, BF
26. Locate 18, 1: Print "Looks like a nice BLUE box.  Right?"
27. Print "Press <ANY KEY> to continue!"
28. Sleep
29. Cls , 0
30. Print "What do you guys mean, 'What box?'??"
31. Print "Do you mean to tell me you nice folks DIDN'T see a pretty BLUE box on the last screen??"
32. Print
33. Print
34. Print "Just what the hell happened to it?!!"
35. Print
36. Print
37. Print "For the answer to that, let's print out two values to the screen:"
38. Print "BLUE = "; BLUE
39. Print "_RGB32(0, 0, 255) = "; _RGB32(0, 0, 255)
40. Print
41. Print "At first glance, those APPEAR to be the same numbers, but let's expand the      scientific notation fully:"
42. Blue&& = BLUE
43. Print "BLUE = "; Blue&&
44. Print "_RGB32(0, 0, 255) = "; _RGB32(0, 0, 255)
45. Print
46. Print "Press <ANY KEY> to continue!"
47. Sleep
48. Cls , 0
49. Print "HOLY COW, BATMAN!!  Was those two numbers DIFFERENT?!!"
50. Print "BLUE = "; Blue&&; "vs"; _RGB32(0, 0, 255)
51. Print
52. Print "Well... They're only a LITTLE different...  Right?"
53. Print "I mean, how bad can one little number difference be?  Right??"
54. Print
55. Print "For the answer to that, let's look at the HEX values of those numbers:"
56. Print "BLUE = "; Hex$(Blue&&)
57. Print "_RGB32(0, 0, 255) - "; Hex$(_RGB32(0, 0, 255))
58. Print
59. Print "And to help understand what we're seeing in HEX, break those values down into   groups of 2 in your mind."
60. Print "(I'm too lazy to do it for you..)"
61. Print "The first two values are ALPHA, followed by RED, followed by GREEN, followed by BLUE."
62. Print
63. Print "So  BLUE = FF alpha, 00 red 01 green, 00 blue"
64. Print "_RGB32(0, 0, 0) = FF alpha, 00 red, 00 green, FF blue"
65. Print
66. Print "And keep in mine that FF is HEX for the decimal value of 255."
67. Print
68. Print "Press <ANY KEY> to continue!"
69. Sleep
70. Cls , 0
71. Print "Since SINGLE values lose precision after numbers get so large, our variable BLUE"
72. Print "has to round to the nearest scientific notation point and try for the closest"
73. Print "possible match."
74. Print
75. Print "And even though "; Blue&&; " is only one number off from "; _RGB32(0, 0, 255); ","
76. Print "that number still greatly changes the color value."
77. Print
78. Print "It changes it from FF 00 00 FF (255 alpha, 0 red, 0 green, 255 blue) to"
79. Print "FF 00 01 00 (255 alpha, 0 red, 1 green, 0 blue)."
80. Print
81. Print "Our BLUE has become a GREEN, simply by using a SINGLE variable type!!"
82. Print "(And, it's such a low shade green, my poor eyes can't make it out at all."
83. Print "To me, the damn 'green box' was just as black as my black screen."
84. Print "I didn't see it at all!)"
85. Print "Press <ANY KEY> to continue!"
86. Sleep
87. Cls , 0
88. Print "So, at this point, I think it should be obvious WHY we don't want to store"
89. Print "color values inside SINGLE variables."
90. Print
91. Print "But what about using a normal LONG to hold the values??"
92. Print
93. Print "Let's look and see!"
94. Print
95. Print "For this, let's draw our box again:"
96. Line (50, 150)-(250, 250), _RGB32(0, 0, 255), BF
97. Locate 18, 1: Print "Looks like a nice BLUE box.  Right?"
98. Print
99. Print "But let's get the POINT value from that box, and store it in a LONG variable."
100. BLUE& = Point(100, 200)
101. Print "BLUE& = "; BLUE&
102. p&& = Point(100, 200)
103. Print "POINT(100, 200) = "; Point(100, 200)
104. Print
105. Print
106. Print "Again, we're looking at two numbers that don't match!"
107. Print
108. Print "FOR THE LOVE OF GOD, WHYYYY??!!!!"
109. Print "Press <ANY KEY> to continue!"
110. Sleep
111. Cls , 0
112. Print BLUE&; "<>"; p&&
113. Print
114. Print "Why are those two numbers so different??"
115. Print
116. Print "For that answer, let's look at their HEX values again:"
117. Print "BLUE& = "; Hex$(BLUE&)
118. Print "POINT(100, 200) = "; Hex$(p&&)
119. Print
120. Print "."
121. Print "..."
122. Print "......"
123. Print
124. Print "WHAT THE HEX??  Those two values are EXACTLY the same??"
125. Print
126. Print "They are.  It's just that one of them is stored as a SIGNED LONG, while the     other is an UNSIGNED LONG."
127. Print
128. Print "HEX wise, they're the same value..."
129. Print
130. Print "BUT, can you see where the two numbers might not match if we use them in an IF  statement?"
131. Print
132. Print "IF "; BLUE&; "="; p&&; "THEN...."
133. Print
134. Print "Ummm...  That might not work as intended!"
135. Print
136. Print "Press <ANY KEY> to continue!"
137. Sleep
138. Cls , 0
139. Print "Even thought the HEX values for "; BLUE&; "and"; p&&;
140. Print "are EXACTLY the same, the values themselves are quite different."
141. Print
142. Print "A LONG will, indeed, hold the proper value for a 32-bit color, as it stores"
143. Print "all four HEX values properly for us."
144. Print
145. Print "As long as our program uses NOTHING but LONG values, you'll never have a"
146. Print "problem with using LONG as a variable type..."
147. Print
148. Print "BUT...."
149. Print
150. Print "The moment you start to compare LONG values directly against POINT values,"
151. Print "your program is going to run into serious issues!"
152. Print
153. Print "Because at the end of the day,"; BLUE&; "is not the same as "; p&&
154. Print
155. Print
156. Print "Press <ANY KEY> to continue!"
157. Sleep
158. Cls , 0
159. Print "So, with all those examples, and all that said, let's answer"
160. Print "the most important question:"
161. Print
162. Print "'What TYPE works best for 32-bit colors??"
163. Print
164. Print
165. Print "DOUBLE, _FLOAT, _UNSIGNED LONG, _INTEGER64, _UNSIGNED _INTEGER64"
166. Print
167. Print "Of all the types which QB64 offers, only the above are TRULY viable"
168. Print "to hold a 32-bit color value."
169. Print
170. Print "Any type not listed above is going to be problematic at one time or"
171. Print "another for us!"
172. Print
173. Print "And of those suitable types, I personally prefer to keep integer values"
174. Print "as integers, so I recommend: _UNSIGNED LONG or _INTEGER64."
175. Print
176. Print
177. Print "Press <ANY KEY> to continue!"
178. Sleep
179. Cls , 0
180. Print "And WHY _UNSIGNED LONG??"
181. Print
182. Print "Simply because it's only 4 bytes of memory (the minimal we can possibly use for"
183. Print "32-bit color values), and it's what QB64 uses internally with POINT and such."
184. Print
185. Print
186. Print "So, if _UNSIGNED LONG works so well, WHY would I *ever* use _INTEGER64??"
187. Print
188. Print "Becauses sometimes I like to code command values into my colors."
189. Print "(Such as: NoColor = -1)"
190. Print
191. Print "_UNSIGNED LONG *only* holds the values for the colors themselves."
192. Print "EVERY number from 0 to FFFFFFFF is accounted for as part of our color spectrum."
193. Print
194. Print "If I need *special* or unique values for my program, I usually just use _INTEGER64s"
195. Print "for my variable types and then I can assign negative numbers for those unique values."
196. Print
197. Print
198. Print "Press <ANY KEY> to continue!"
199. Sleep
200. Cls , 0
201. Print "At the end of the day though, when all is said and done, you're still the"
202. Print "one responsible for your own code!"
203. Print
204. Print "Use whichever type works for you, and works best for your needs."
205. Print
206. Print "Just keep in mind:  Various TYPEs come with various limitations on your code."
207. Print
208. Print "_BYTE, INTEGER, (both signed and unsigned) are insane to use..."
209. Print "SINLGE loses precision.  Expect to lose whole shades of blue...."
210. Print "LONG may cause issues with POINT, if compared directly...."
211. Print "_UNSIGNED LONG works fine, any ONLY stores 32-bit color values...."
212. Print "_INTEGER64 works fine, and can store extra values if necessary...."
213. Print "DOUBLE and _FLOAT both work, but are floating point values...."
214. Print
215. Print
216. Print "And with all that said and summed up, it's now up to YOU guys to decide what"
217. Print "works best in your own programs."
218. Print
219. Print
220. Print "As I said, I personally recommend _UNSIGNED LONG or _INTEGER64 in special cases."
221. Print "But the choice, and the debugging, is entirely up to YOU.   :D"
222.  

Copy.  Paste.  Compile.  I'll let the code speak for itself and hopefully it'll help folks learn a bit more about WHY certain variables are more suitable for use with 32-bit color values than others.  ;)

[Cobalt]

You musta got that there Virginian schooling Steve...

"And even though 4278190336 is only one number off from 4278190112"

Is that there the new fangled 'common core' stuff?🤓   One number off huh?



or maybe you had a _RGB32(0,0,32) instead of _RGB32(0,0,255) on line 75?

[SMcNeill]

I have to include small little typos and such like that, just so see if people are actually paying attention to what I'm saying.  ;D

It's all fixed now.  Sometimes my fingers work faster than my brain.  I was thinking "32-bit colors", so my 255 BLUE ended up turning into a 32 there.   

Maybe I should add a chapter on, "AND MAKE CERTAIN TO USE THE RIGHT VALUES FOR YOUR COLORS".   Only problem with that is, I doubt if I'd ever read it.  I'm a stubborn cuss and have to learn things the hard way by goofing up and glitching them myself first!  Tutorials and lessons be danged!  :P

[OldMoses]

I do like when someone helps me to think out of the box. I was aware of _UNSIGNED LONG as the "correct" type for 32 bit color, but storing color values in _INTEGER64 with additional and/or command data never occurred to me as a thing that one could do. Thanks for that.

[SMcNeill]

I do like when someone helps me to think out of the box. I was aware of _UNSIGNED LONG as the "correct" type for 32 bit color, but storing color values in _INTEGER64 with additional and/or command data never occurred to me as a thing that one could do. Thanks for that.

I actually use INT64 quite a bit for a color variable in different routines.  Anything positive is usually a color for the code, whereas negative values have preset command uses.  For example, a color value of -1 might mean (No need to redraw), which allows me to completely skip processing cycles on drawing/coloring something on the screen that hasn't changed.  A color value of -2 might mean (Use Default color scheme), which is a normal black on white, or black on light gray color set.  A color value of -2 might mean (Use High Contrast color scheme), which is what many folks laugh at when they see some of my demos on the forums here.  My daughter isn't 100% color blind, but she has colors which fade and blend in together for her.  For instance, she can't tell the difference between a Sea Green and a Sky Blue -- though she can tell a bright green from a deep blue!  Learning to code for HER eyes has led me to create some *very* distinctive color styles over the years, with a bight red on yellow being one of the most common -- which nobody else seems to enjoy using!  LOL!   Having a quick value to swap over to her high-contrast colors has came in handy more than once for me, so I'll often code it in as negative value colors.  ;)

All little tricks which I use to help me with my programs/colors from time to time.

Another place where I'll use negative colors is when I'll make a grid for a map.  Negative values might mean (Map not uncovered yet), while positive values means (Show this part of the map).  It's a very simple little toggle to keep track of where the player has traveled and uncovered, and allows me to create a very simple "fog of war" which greatly encourages map exploration.

_Unsigned Long is my go to for when I just need plain color values.  BLUE~& = _RGB32(0, 0, 255), for example.  Integer64, however, is what I'll often use when I need my color values PLUS just a little bit more.

As I said in the lesson above, it's all up to what the programmer and their program itself needs, to work as bug-free and as efficiently as possible.  ;D