| |
ws
Registered: Apr 2012
Posts: 251 |
Simple bilinear interpolation in assembler
Hello,
for some reason, with increasing age, i am no longer interested in spending much time on re-inventing 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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting wertstahlps: if anyone hints me towards formatting source code nicely in this csdb thing, i will happily comply.
Just follow the Read more link on the comment entry form.
But in short, wrap your code segments in [ code]/[ /code] (only without the spaces after the "["s) |
| |
ws
Registered: Apr 2012
Posts: 251 |
;-------------------------------------------------
linenums = #$05
linecount byte $05 ;(+1)
blur lda linenums ;---
sta linecount ;---
ldx #$00
do_blurX ldy #$26
x_blurX lda $0400+1,x
lsr
lsr
lsr
sta pot
lda $0400-1,x
lsr
lsr
lsr
clc
adc pot
sta pot
lda $0400,x
lsr
clc
adc pot
bcc noclip
lda #$ff
noclip sta $0400,x
inx
dey
bne x_blurX
inx ;---
inx ;--- these and this mechanism is
;--- just there to provide a visual gap
;--- ofcourse the scanning could be seamless
dec linecount ;---
bne do_blurX ;---
rts
;================
pot byte $0
needs deeper thought, but it works, horizontally, though. |
| |
Digger
Registered: Mar 2005
Posts: 437 |
.prg would be good :) |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
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: 49 |
(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. |
| |
ws
Registered: Apr 2012
Posts: 251 |
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: 49 |
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 8-bit numbers, the result will be a 9-bit number with 1-8th bits in AR and the 9th bit in C. ROR will divide this 9-bit 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. |
| |
ws
Registered: Apr 2012
Posts: 251 |
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: 49 |
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 |
| |
ws
Registered: Apr 2012
Posts: 251 |
And, because i didnt yet say what this is for: it is for a battle tactics ki precalculation. Now i said it. |
| Previous - 1 | 2 | 3 | 4 - Next |
