Feature Request: Quick Value Selection

[SirCrow]

If it isn't already a part of QB64, here's what I'd like to have:

Maybe I want the prog. to assign a value to a variable based on, say, the counter in a FOR...NEXT loop... 

Example: If the counter, C, runs from 1 to 3, then...

IF C = 1 THEN Main_BG_Clr& = _RGB(255, 0, 0) ELSE IF C = 2 THEN Main_BG_Clr& = _RGB(0, 255, 0) ELSE Main_BG_Clr& = _RGB(55, 55, 255)

could be replaced with...

Main_BG_Clr& = _SELVAL(C, _RGB(255, 0, 0),  _RGB(0, 255, 0)_ RGB(0, 0, 255))

...or...

ON C Main_BG_Clr& = (_RGB(255, 0, 0),  _RGB(0, 255, 0)_ RGB(0, 0, 255))

What do you think?  Maybe not enough of a time/space saver? 

[TerryRitchie]

There's already a number of different ways to do this. A few examples below.

Code: QB64: [Select]

1. ' note: you should be using unsigned long integers for colors
2.  
3.  
4. ' Method 1
5.  
6. FOR c = 1 TO 3
7.     IF c = 1 THEN
8.         Main_BG_Clr~& = _RGB(255, 0, 0)
9.     ELSEIF c = 2 THEN
10.         Main_BG_Clr~& = _RGB(0, 255, 0)
11.     ELSE
12.         Main_BG_Clr~& = _RGB(55, 55, 255)
13.     END IF
14. NEXT c
15.  
16.  
17. ' Method 2
18.  
19. FOR c = 1 TO 3
20.     SELECT CASE c
21.         CASE 1
22.             Main_BG_Clr~& = _RGB(255, 0, 0)
23.         CASE 2
24.             Main_BG_Clr~& = _RGB(0, 255, 0)
25.         CASE 3
26.             Main_BG_Clr~& = _RGB(55, 55, 255)
27.         CASE ELSE
28.             ' anything else here
29.     END SELECT
30. NEXT c
31.  
32.  
33. ' Method 3
34.  
35. DIM clr~&(3)
36.  
37. clr~&(1) = _RGB(255, 0, 0)
38. clr~&(2) = _RGB(0, 255, 0)
39. clr~&(3) = _RGB(55, 55, 255)
40.  
41. FOR c = 1 TO 3
42.     Main_BG_Clr~& = clr~&(c)
43. NEXT c
44.  
45.  

[FellippeHeitor]

The third suggestion seems to fit SirCrow's need like a glove.

[SirCrow]

I could easily have come up with numerous ways to get it done, but I wanted to see what the shortest way would be.  Yes, the third method is the way I'd choose.  Except, of course, that I always prefer not to use arrays if I can easily avoid it;  I'm always running into Duplicate definition and other errors, clumsy as I often am.

As far as unsigned LONG integers for colors, if the regular LONG works well, why is unsigned better?  Uses less memory?  After all these years, I'm still a bit foggy on a lot of things.

Thanks for your input!

[FellippeHeitor]

32bit colors require some pretty high numbers to be stored. Using a LONG or _UNSIGNED LONG will require the exact same amount of memory (4 bytes), but with a LONG you'll eventually get negative values when the color value overflows the limit of LONG data type variables.

In practice, for QB64 drawing functions, it makes no difference.

However, I remember Steve pointing out something to watch for in this regard, I just can't remember what it was.

Code: QB64: [Select]

1. DIM a AS LONG
2. DIM b AS _UNSIGNED LONG
3.  
4. a = _RGB32(255, 255, 255)
5. b = _RGB32(255, 255, 255)
6.  
7. PRINT a
8. PRINT b
9.  

The code above will give you two results: -1 and 4294967295, both of which represent white, full alpha (_RGB32(255, 255, 255)).

[SMcNeill]

POINT returns unsigned values for us, so SIGNED LONGS won't always match.

SCREEN _NEWIMAGE(800,600,32)
DIM White AS LONG
White = _RGB32(255,255,255)
PSET (1,1), White
PRINT White
PRINT POINT(1,1)
IF POINT(1,1) = White THEN PRINT "Match" ELSE PRINT "No Match; we glitched..."


************

Change White to an Unsigned Long and then try the same code.  ;)

[FellippeHeitor]

That was that. Thanks, Steve.

[SirCrow]

I guess I have some tildes to add to my code.  Thanks.