 
Wertstahl
Registered: Apr 2012 Posts: 34 
Simple bilinear interpolation in assembler
Hello,
for some reason, with increasing age, i am no longer interested in spending much time on reinventing the wheel.
Therefore, i'd like to ask if any of you wizards perhaps know of a close solution to this problem:
Lets say you have a "heatmap" in a matrix of 20x10 cells.
Does anyone perhaps already have a fast and simple routine for interpolating all the values within these cells, so that when you have some cells with very high values and some cells with very low values, that more or less smooth transitions (image blur) can be achieved in very few rasterlines?
Google just spat out hardcore math for me, which i feel unable to wrap my head around, when attempted to translate to a c64 assembler solution. (I code in assembly, directly, no c++ or the like, pretty please).
best regards
WS 

... 24 posts hidden. Click here to view all posts.... 
 
Digger
Registered: Mar 2005 Posts: 302 
.prg would be good :) 
 
Rastah Bar
Registered: Oct 2012 Posts: 164 
I can see some optimizations. For example, you can get rid of 2 LSRs by first adding ($0401,x)/2 and ($3ff,x)/2 and dividing the result by 4.
lda $401,x
lsr
sta pot
lda $03ff,x
lsr
clc
adc pot
lsr
lsr
sta pot
Also, does it ever clip? ($400,x)/2 <= 128 and ($3ff,x)/8+($401,x)/8 <= 64, so their sum will not exceed 192.
And I would use a ZP address for pot. 
 
Sparta
Registered: Feb 2017 Posts: 12 
(clc)
lda 03ff,x
adc 0401,x
ror
adc 0400,x
ror
sta 0400,x
adc 0402,x
ror
adc 0401,x
ror
sta 0401,x
Ps. Check out my fire effect in Tunnel Vision.
Edit. If unrolled, you can omit ,x indexing. 
 
Wertstahl
Registered: Apr 2012 Posts: 34 
sparta, that looks very sleek. i was afraid that something like that, which i do not fully understand, might work. how did you come up with this solution? 
 
Sparta
Registered: Feb 2017 Posts: 12 
Many many years of code optimization. :))
(JK, I am just a hobby coder)
Actually, I used something similar in my fire effect in Tunnel Vision. Except, I did not have enough memory to fully unroll the loop and I also modified the result using a cosine tab. In the fire effect, the 3rd addition comes from the char line below. Something like this:
0400=(((03ff+0401)/2)+0428)/2
When you add to 8bit numbers, the result will be a 9bit number with 18th bits in AR and the 9th bit in C. ROR will divide this 9bit number by 2, rolling the C in AR. This will also modify C again, however, CLC can be safely omitted in most of the cases, because the difference in your result is <=1, and the next ROR will half that, too. 
 
Wertstahl
Registered: Apr 2012 Posts: 34 
although the rol solution (above) also has this effect of smearing things into one direction, which i am currently trying to suppress so i can do everything in one go, using lookup tables: (having some brightness trouble currently, though)
way less easy than i thought.
(both images show a 4x3 cross and a 3x3 square blurred)
Oh! Thank you for your explanation Sparta! Much appreciated! 
 
Sparta
Registered: Feb 2017 Posts: 12 
Double buffering will avoid the skew as you will not overwrite your original values.
Also, keep in mind the above solution is not a true average of the 3 values:
b=(a+2b+c)/4 
 
Wertstahl
Registered: Apr 2012 Posts: 34 
And, because i didnt yet say what this is for: it is for a battle tactics ki precalculation. Now i said it. 
 
Wertstahl
Registered: Apr 2012 Posts: 34 
Ah! I had a double buffering version before but for some reason fell back to single frame! Thanks alot for the hint! That should do the trick! 
 
Sparta
Registered: Feb 2017 Posts: 12 
lda buffer11
adc buffer1+1
ror
adc buffer1
ror
sta buffer2
lda buffer1
adc buffer1+2
ror
adc buffer1+1
ror
sta buffer2+1
Put it in a loop if you want. Good luck! 
Previous  1  2  3  4  5  Next 