-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathnotes.txt
86 lines (72 loc) · 3.2 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
TODO:
Nicer scoreboard font using 1-hot encoding?
Consider that crazy optimization for more bits, to do a larger ball with better
shading? How many bits do we need, and how many do we have?
Needed:
2:ball:BUFFER_X/Y_DEPTH_COUNTER,
2:bg+ball:MIN/MAX for BUFFER_X/Y_FLAG,
1:bg+ball:PADDLE_MOVE_DELAY_COUNTER.
1+:ball:shading,
0+:ball+bg+paddle bigger paddle means ideally a larger paddlePixel range,
1:bg:isCenterRespawn/respawnPhase2 will probably need at least one more
bit.
Minimum of 5 for ball, plus shading.
--------------------------------------------------------------------------------
Cleanup:
Consider making DECIMATOR a global bit. Almost everybody uses it, and it would
be nice just to be able to grab it and negate it everywhere. It's not much more
work for the empty background; might even be a wash, with less checking for if
you need it or not. The only other minus would be having it in the scoreboard,
which has no need for it, but that seems fairly trivial, especially if it's not
a very visible bit.
--------------------------------------------------------------------------------
Small ways to shave bits:
1: Use PADDLE_BUFFER_FLAG as a namespace bit for balls. All the paddle buffer
bits go in that namespace, but then we can put BUFFER_Y_FLAG in its complement,
since that information can be derived from the paddle's position and
paddlePixel.
2: FULL_ALPHA is currently 3 bits in the background; we certainly wouldn't miss
the bottom one, and could function without the bottom two if necessary. We've
already trimmed down to 1-2 in the foreground; it's dimmer, but not too bad,
given that it gets the high bit just for being foreground.
3: Can we share bits for MESSAGE_PADDLE_POSITION and PADDLE_DEST in the
background? We can't get a message while we're moving, so PADDLE_DEST should be
0 when MESSAGE_PADDLE_POSITION is set, and then PADDLE_MOVE_DELAY_COUNTER will
keep us from acting on the MESSAGE_PADDLE_POSITION until we're ready. Seems
likely. That only saves us bits in nsBackground, though, not nsBall, which is
generally shorter on bits.
--------------------------------------------------------------------------------
The checkerboard ball state will probably work! We can save a ton of bits that
way. Make a ball out of alternating pixels, where some have all the ball motion
info and the others have all the collected paddle/buffer info. Both need the
isPaddleBuffer and isBall bits. When you need one or the other namespace of
info, there's always a pixel within reach that has it. The only thing to watch
out for is that the leading corner when moving diagonally must have the ball
info, as it may be the only ball pixel that the target pixel can see. That's
probably pretty easy to arrange, though, for most odd ball sizes, and anybody
outside the ball should be able to see the paddle buffer state directly in most
cases, and see at least one paddle buffer pixel inside the ball otherwise.
7:
x.x
x.x.x
x.x.x.x
.x.x.x.
x.x.x.x
x.x.x
x.x
5:
x
x.x
x.x.x
x.x
x
4: does that work? Probably. And the bitflag would make for nice shading here,
too. Start with a 3x3 ball for the switchover, then grow to this once it's
working.
xx
x..x
x..x
xx
3: x
x.x
x