search for: render_point

...ould be: 21) vector [floor1_final_Y] element [i] = [predicted] - (([val] + 1) divided by 2 using integer division) <p>- in the function render_line 11) [ady] = [ady] - [base] * [adx] hould be: 11) [ady] = [ady] - absolute value of [base] * [adx] <p>Also, the parameter order of render_point(x0,x1,y0,y1,X) and render_line(x0, y0, x1, y1, v) is not consistent, and the references to the render_line function use different ordering: - Floor 1 / curve computation / step 2: curve synthesis 8) render_line( [lx], [hx], [ly], [hy], [floor] ) 12) render_line( [hx], [hy], [n], [hy], [floor] )...

...orks as follows: At the beginning Y[0] and Y[1] contain the absolute amplitudes (log scale) at the lower resp. upper X boundaries, and the Y[i] for i>=2 are the wrapped difference values, which are then progressively replaced by the predicted absolute amplitudes at X[i]. In the current spec docs render_point always takes its input from [floor1_Y] (which mostly contains differences) and [predicted] then is output into [floor1_final_Y], without any feedback. IMHO this doesn't work out. Either the distinction between [floor1_Y] and [floor1_final_Y] has to go away, otherwise the following may do the tr...

...or 1 / curve computation / step 2: It is confusing that these steps are using a different parameter order for calling the same function: 8) render_line( [lx], [hx], [ly], [hy], [floor] ) 12) render_line( [hx], [hy], [n], [hy], [floor] ) As well as the definitions of the functions render_line and render_point: render_line(x0, y0, x1, y1, v) render_point(x0, x1, y0, y1, X) <p>############### #2002-10-15-001 Setup header decode, mappings: When decoding the mappings in the setup header, the specification says: ----------------------------------------------------------------- ------------ read 1...