Sanity Check / debugging table for INK/PAPER values.

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Sanity Check / debugging table for INK/PAPER values.

Post by Nomad »

Fellow potato's, if like me you often sit scratching your head wondering "Why is my screen blank? What did this... KAHN!!!!!!"

[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 :lol: ) 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

Ok so this table is here for the ones that ask how I got the numbers, You see that you have to watch for not only the standard colours but situations where you have bright. This gives us a total of 16 'bad' values to look out for.

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 thing to remember when looking at the tables, this is only a suggestion on how these values might have occurred. I can't sure your code is not doing something freaky to mess with your data.. remember its just a number. There are many ways to get the same result. This is where your debugging starts, was it just you being a potato and screwing up the initial value or was it something that was a result of a side effect? time to crack open the debugger and get to work.

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.
AndyC
Dynamite Dan
Posts: 1388
Joined: Mon Nov 13, 2017 5:12 am

Re: Sanity Check / debugging table for INK/PAPER values.

Post by AndyC »

It's worth noting there are another 16 "bad" values, obtained by adding 128 to each of your current ones, because FLASHing between identical colours causes the same problem too. It's also worth noting that, as your get more advanced, such values can become incredibly useful. A lot of scrolling shooters, such as R-Type, for example use a column of black ink and black paper at the edge of the screen so that partially drawn graphics are automatically clipped in a nicer fashion.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Sanity Check / debugging table for INK/PAPER values.

Post by Nomad »

Thanks Andy I had forgotten about FLASH. :lol: . You are right about the advanced techniques that use ink+paper of the same colour. But you would know you want to use them and have a clear idea when to. This was more just for silly errors in setting colour values.
Post Reply