The two functions scale inputs to table dimensions as outputs. So an 8x8 table is a fair call.BOOSTEDEVERYTHING wrote: ↑2024 May 31, 10:20 No I have not, but I would assume by the functions it calls it would be 8, but It is 16, So I am very confused about how it all works exactly.
Clearly the data space fits 16 rows, so is it two 8 row tables??
Search for 15CDC does not find any hits in the code, maybe it's an encoded address that has not been identified yet.
I've seen tables where two different subroutines access the same table but use different row counts, though that is not evident in this case, yet.
Note swTb23EPPH @ 15c9c is similar.
The column scaler is unusual in that output increases above 0 for the last four rows after the input drops to 0.
The function lookup won't look in those lower 4 function rows as the input has hit the minimum input in the row above.
Code: Select all
uuyFn.0x15d1c:
15d1c: ff,70 func 255, 112
15d1e: 50,60 func 80, 96
15d20: 28,40 func 40, 64
15d22: 00,00 func 0, 0
15d24: 00,10 func 0, 16
15d26: 00,10 func 0, 16
15d28: 00,10 func 0, 16
15d2a: 00,10 func 0, 16
Code: Select all
uuyFn.0x15d2c:
15d2c: ff,70 func 255, 112
15d2e: c8,70 func 200, 112
15d30: ac,60 func 172, 96
15d32: 64,00 func 100, 0
15d34: 00,10 func 0, 16
15d36: 00,10 func 0, 16
15d38: 00,10 func 0, 16
15d3a: 00,10 func 0, 16
Defining the table as 8x16 in the XDF (the 8x16 DIR data source), is not an issue. If you ever see access to the lower eight rows while tuning you will know to look closer at the code.
Interpolation. Rather than take the value at the intersection of the row and column, the four nearest cells are interpolated.Looks like it Checks the table 3 times before outputting a value.
Looks ok.Here is the complete Table lookup....I think?