Shader - A Colour Tint Selector

[GWS]

Here's a port from Creative of a program to help select that particular shade you want for colouring a window, text box, button etc.

It uses the Hue, Saturation, Lightness model of colour.   Hue values range from 0 to 360 degrees, with Red at 0 degrees.
Saturation is the amount of colour in the shade, ranging from 1.0 (full colour) to 0.0 (No colour .. ie.Grey).
Lightness as the name implies ranges from 1.0 (White) to 0.0 (Black) - normal colour is when L = 0.5.

Once you select the basic colour you fancy from screen 1, you then get screen2, which shows a wide range of shades for that colour.
These are based on a Saturation value of 0.7.  There is a Saturation scroll that allows you to vary the saturation to increase or reduce the amount of colour in the shade boxes.

Select the shade you want and you get screen 3.   This allows you to fine tune the shade, and then save either the RGB or Hex colour value to the clipboard for pasting into your CBasic code.

You will need the background graphic shaded.jpg in the same directory as the program for it to look nice .. 

This port from Creative was much trickier than I expected.

Although it was working fine in Creative, I got a long list of compile errors in Emergence.
I had 'invalid assignments' and 'incorrect parameters' all over the place.

Some of the errors were due to the different CONTROL parameters, which need ,"", for a blank text field, rather than just ,, which I expected. (I'm not used to Emergence yet ..  )

Others arose from the different parameter lists for subroutines, where you need to assign types to the variables in the list as opposed to using a DECLARE statement in Creative.   One particular omission caused a whole slew of errors, and the compiler messages gave no clue what was upsetting it.  I had missed the variable type of a return value off the end of the SUB parameter list.  Once I added that, lots of strange errors such as for instance, loud complaints about:   H = H / 360  being absolutely incorrect  - went away.

The most tricky errors arose from the stricter processing of integer constants and calculations in Emergence compared to the free-and-easy style you can get away with in Creative.

I had to go through the code 'floatifying' calculations by scattering decimal points all over, and carefully using FLOOR to truncate integer calculations.   Without that, the program was not displaying some colours, and not selecting the right ones when you clicked on them.
Quite a bit of debugging time was needed to sort that problem out.

Clearly you need to take a lot more care with integer division in Emergence, and watch variable typing carefully.

Anyway, I think it's working OK now - but I bet I've left the odd decimal constant in there that maybe wasn't actually necessary.
Still, better safe than sorry.

Hope you find it useful ..

all the best,

Graham

[Ionic Wind Support Team]

Graham,
That's because Creative uses a primitive calculation engine.  It doesn't actually do integer divisions but converts everything to DOUBLE before performing calculations, besides being a tad slower it also doesn't preserve the significance of the operands. 

The rules of emergence and type promotion are listed in the end of the "operators" section of the users guide

For all mathematical operations the resultant type will be the same as the operand with the highest precision. Operands can be given a different type for use in the calculation with the INT or FLT functions.

For example a common user programming error is dividing two integers and assuming the result will be a floating point value:


DEF b,c as INT
b = 1:c = 2
A = b / c

Will result in a value of 0 because both operands are integer. However if one of the operands is a floating point type the result will be 0.5. This can be accomplished by using either a type modifier or the FLT function.


A = b / FLT(c)

In this case c is temporarily promoted to a floating point value and the result will then be a floating point value.

The key to that section, and applies to the majority of programming languages is:

For all mathematical operations the resultant type will be the same as the operand with the highest precision

Which is done for efficiency of assembler code and accuracy of the result.  Simple when you think about it for a second:

INT/INT = INT
FLOAT/INT = FLOAT
INT/FLOAT = FLOAT
FLOAT/FLOAT = FLOAT
DOUBLE/FLOAT = DOUBLE

and so on.

For all graphics programming using a double is overkill, emergence supports the 'f' modifier so you can convert your results to FLOAT.

float num = 1/2f

No need to add .0 to anything.  You can also use the INT and FLT keywords when working with variables.   

Paul.

[GWS]

Thanks for the comments Paul .. 

I thought I knew those things, but I still fell into the traps .. 

I shall have to read the EBasic guide a bit more carefully ..

all the best,

Graham

[MarineDon]

Dear Graham:

I enjoyed using your Shader program. Up 'till now, for other
programs, especially HTML web pages, I've been using
Franke's Color Picker program, CPick.Exe. Your Shader
program will make it extremely easy to determine
RGB values. Thanks a lot!

Sam Franke's home page:
http://home.hccnet.nl/s.j.francke/software/software.htm

Regards, Don Smith (MarineDon)

[RG]

yes, well doen and useful 

[GWS]

You're welcome folks .. 

Hey Don - ex Marine (salutes respectfully) .. programming is a much gentler way of life .. 

I hope you're enjoying it.

best wishes,

Graham