Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Simple bilinear interpolation in assembler
2018-05-08 16:24
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....
 
2018-05-08 18:21
ChristopherJam

Registered: Aug 2004
Posts: 1409
If you want nice long tails without summing multiple elements per output value, you might need to use an infinite impulse response filter, and probably run it left to right then right to left to make it symmetric.

Maybe something like this? (untested)
.for i in 0,39
  adc screen+i
  lsr
  tax
  lda times_3_over_2,x
  sta screen+i
  lda times_1_over_2,x
.endfor


(basically moves a quarter of the contents of each cell into the next one along, so any peaks get smeared over the next several cells, getting weaker as it goes along)
2018-05-08 19:11
ws

Registered: Apr 2012
Posts: 251
Thank you so much for the immediate responses!

I have been discussing and chewing on it a little bit and in addition with your thoughts (which all in all is interpolation of thoughts, right?) i'll be playing around with some code soon and i'll post my results here.
2018-05-09 07:59
Oswald

Registered: Apr 2002
Posts: 5094
Quote: i made a graphical example of what i want to achieve.

http://www.wertstahl.de/example.jpg

maybe this clears up things alot, please excuse that i find no other way to express what i am trying to do.


by the looks of this you need rather blur routine. Simply average 4 neighbour cells for each cell, or fire effect in other words.

The question is what you have in mind, how does that differ from blur ?

there have been "plasmas" out there wich work by averaging (interpolating if you like) out between a few hotspots, but they do look ugly.
2018-05-09 15:50
chatGPZ

Registered: Dec 2001
Posts: 11386
depending on what you are doing, you can also try randomly tweaking your own filters, perhaps throw some dithering into the mix, vary the number of taps you are using. (eg using 3 values only, with different factors). you can perhaps also speed it up a lot by limiting the range of the source values (again depends on what you are doing) so you can use table lookups for everything.
2018-05-09 15:53
soci

Registered: Sep 2003
Posts: 480
Quote: Are you looking to interpolate between the values, to get higher resolution?

Or are you wanting to smooth the data without changing the number of cells?

Either way, a useful building block is to calculate a mean with
  clc
  lda value1
  adc value2   ; computes a 9 bit sum in [carry, acc7..acc0]
  lsr          ; divides result by two, leaving 8 bit value in A
  sta result

Unroll.


It's ROR and not LSR, right? Otherwise the usable value range is half.
2018-05-09 19:02
ChristopherJam

Registered: Aug 2004
Posts: 1409
Quoting soci
It's ROR and not LSR, right? Otherwise the usable value range is half.


Argh! Yes, you're right of course. Same applies to my code in comment #6, I meant to use ROR there, too.

Thanks for catching that.
2018-05-09 19:06
ws

Registered: Apr 2012
Posts: 251
i am currently like half out of the door for xyz but this came to mind, it is just code, not tested.



datafield byte $f,$8,$0,$0, $0,$0,$5,$0
byte $0,$f,$0,$0, $2,$0,$0,$0
byte $f,$0,$0,$0
byte $0,$0,$0 ;simple headroom

gamma byte $0,$0,$0,$1, $1,$1,$1,$1
byte $2,$2,$3,$4, $5,$6,$7,$8
byte $f,$f,$f,$f, $f,$f,$f,$f
byte $f,$f,$f,$f, $f,$f,$f,$f ; peak clipping for demonstration

stor byte $0

;================

blur ldx #$00

do_blur ldy datafield,x
lda gamma,y ;get target value for base cell
sta datafield,x

;----------------
tay ;remember last shade of blur
lda gamma,y ;and blur again

clc
adc datafield+1,x ;combine values
tay
lda gamma,y ;and blur the combined value

sta datafield+1,x ;store

;----------------

tay ;remember last shade of blur
lda gamma,y ;and blur again

clc
adc datafield+2,x ;combine values
tay
lda gamma,y ;and blur the combined value

sta datafield+2,x ;store

;----------------

tay ;remember last shade of blur
lda gamma,y ;and blur again

clc
adc datafield+3,x ;combine values
tay
lda gamma,y ;and blur the combined value

sta datafield+3,x ;store

;----------------

inx
cpx #$14
bne do_blur

rts

;================

please excuse the fucked-up formatting.
2018-05-09 19:23
lft

Registered: Jul 2007
Posts: 369
Quoting ChristopherJam
Quoting soci
It's ROR and not LSR, right? Otherwise the usable value range is half.


Argh! Yes, you're right of course. Same applies to my code in comment #6, I meant to use ROR there, too.

Thanks for catching that.


Although, if half the value range is acceptable, then one could use ASR #$fe to clear carry in preparation for the next computation.
2018-05-09 19:25
ws

Registered: Apr 2012
Posts: 251
i'd rather have some sort of gamma curve that i can adjust via table. but thanks for clearing up rol vs asl and lsr
2018-05-09 21:35
ChristopherJam

Registered: Aug 2004
Posts: 1409
Nice approach :)

Small optimisation suggestion, which would also give you a little more control:

I notice you have snippets like
    tay
    lda gamma,y       ; decay
    sta datafield+2,x ; store
    tay
    lda gamma,y       ; decay more

May I suggest instead:
    tay
    lda gamma,y       ; decay
    sta datafield+2,x ; store
    lda gamma2,y      ; decay more

where gamma2=gamma[gamma[i]], or some refinement thereof.

You can also drop all but the first CLC if your gamma/gamma2 values are all under 128.
Previous - 1 | 2 | 3 | 4 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Durandal
Alakran_64
syntaxerror
MWR/Visdom
Flashback
zscs
haschpipan
anonym/padua
Guests online: 107
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Diskmag Editors
1 Magic  (9.8)
2 hedning  (9.6)
3 Jazzcat  (9.5)
4 Elwix  (9.1)
5 Remix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.047 sec.