[youtube]https://youtu.be/8EnsUeR2MyI[/youtube]
then waste time doubting yourself and double checking everything until you find it was a miscalculation / corruption of the data sent to the perm colour set functions.. You need this. A simple table of what I like to call bad values.The first thing I do when the screen inexplicably goes blank after a update is check my values going to the subroutines with colour. (obvious.. but this debugging step took a while to streamline ) I check each value against this table. If any of them match I know I screwed up somehow with the value and this is the source of the problem.
This can save a lot of time needlessly tracing the problem elsewhere when a simple change of value can do. In many cases is where a subroutine trashes a register that the colour setting subroutine was depending on. In my programs I still have not gotten to the stage of using the stack extensively to pop push the values before calling subroutines to promote sanity/safety so the risk is always present.
To the potato's who are at the same stage (or earlier) this table is for you... to help with your coding until you get to the stage where you don't need to care any more about this (being fully proficient/comfortable with the stack manipulation.) There are also other considerations why you might not want to be popping and locking with the stack all the time so it still might come in handy later.
Code: Select all
DECIMAL:
BLA: BLU: RED: MAG: GRE: CYA: YEL: WHI:
INK : 0 1 2 3 4 5 6 7
PAPER : 0 8 16 24 32 40 48 56
TOTAL : 0 9 18 27 36 45 56 63
BRIGHT : 64 64 64 64 64 64 64 64
TOTALC : 64 73 83 91 100 109 120 127
HEXDECIMAL:
BLA: BLU: RED: MAG: GRE: CYA: YEL: WHI:
INK : $00 $01 $02 $03 $04 $05 $06 $07
PAPER : $00 $08 $10 $18 $20 $28 $30 $38
TOTAL : $00 $09 $12 $1B $24 $2D $36 $3F
BRIGHT : $00 $40 $40 $40 $40 $40 $40 $40
TOTALC : $00 $49 $52 $5B $64 $6D $76 $7F
Code: Select all
: BADCOLOURSDEC 0 9 18 27 36 45 56 63 64 73 83 91 100 109 120 127
: BADCOLOURSHEX 00 09 12 1B 24 2D 36 3F 40 49 52 5B 64 6D 76 7F
One extension to this is for fellows building tools and scripts. the 'bad values' are probably ones you are going to want to check for during the input stage of the tool. Remember the user is not even on a potato functioning level. You have to write these things to be as bullet proof as possible. Imagine your user as a typical window licker. Now you have a mental picture of how this individual is probably going to interact with the tool. Test for each of the values for each input and give them a friendly warning that they are not going to see 'nuthin.
But for my money - you always want to give even a window licking user the ability to enter the value. He might be wanting to do a cheesy screen blank for whatever reason. Let him lick the window if he insists.