ft2-clone

commit fd2588ae60a77cc858256ef18378ef17459b5388
parent 6c06e97860e82dbc8a4bd3a90ed36057046e52ec
Author: Olav Sørensen <olav.sorensen@live.no>
Date:   Wed, 11 Mar 2020 13:02:15 +0100

Added some comments

Added some comments about interpolation tap look-up, to prevent people from thinking that the mixer is buggy.

Diffstat:
M
src/ft2_mix_macros.h
 | 
15
+++++++++++++++

1 file changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/ft2_mix_macros.h b/src/ft2_mix_macros.h
@@ -117,6 +117,16 @@
 	s0 = ((s0 * t[0]) + (s1 * t[1]) + (s2 * t[2]) + (s3 * t[3])) >> CUBIC_QUANTSHIFT; \
 } \
 
+/* 8bitbubsy: It may look like we are potentially going out of bounds by looking up sample point
+** -1, 1 and 2, but the sample data is actually padded on both the left (negative) and right side,
+** where correct samples are stored according to loop mode (or no loop).
+**
+** The only issue is that the -1 look-up gets wrong information if loopStart>0 on looped-samples,
+** and the sample-position is at loopStart. The spline will get ever so slighty wrong because of this,
+** but it's barely audible anyway. Doing it elsewise would require a refactoring of how the audio mixer
+** works!
+*/
+
 #define RENDER_8BIT_SMP_INTRP \
 	assert(smpPtr >= CDA_LinearAdr && smpPtr < CDA_LinearAdr+v->SLen); \
 	sample = smpPtr[-1]; \
@@ -180,6 +190,11 @@
 	s2 = (s2 * (int32_t)f) >> (16 - 1); \
 	s1 += s2; \
 
+/* 8bitbubsy: It may look like we are potentially going out of bounds by looking up sample point
+** 1, but the sample data is actually padded on the right side, where a correct sample is stored
+** according to loop mode (or no loop). This is how original FT2 (MS-DOS) does it as well.
+*/
+
 #define RENDER_8BIT_SMP_INTRP \
 	assert(smpPtr >= CDA_LinearAdr && smpPtr < CDA_LinearAdr+v->SLen); \
 	sample = smpPtr[0]; \