| |
TWW
Registered: Jul 2009
Posts: 545 |
Fractional Scaling - Math problem
Alright.
Say you got the fraction 44/93.
Then you want to scale it to a predetermined denominator of 128 which would give: 61/128 (rounded).
61 is found by calculating 44*128/93.
One multiplication and a division is a bit heavy if you plan to do real-time stuff.
The fastest way I have come up with so far is this:
Set up a 16 bit index table for 1-128 which gives the scaling factor of the denominator (i.e. 1,376 for 128/93). 7 bits for the whole number (1-128) and 9 bits for the decimals giving some accuracy.
Then multiply this with the original numerator to get the scaled numerator.
Still stuck with a small lookup-table (256b) and a 16 by 8 bit multiplication.
Any suggestions on how to do this faster (without spending 16k on a lookuptable)? |
|
... 20 posts hidden. Click here to view all posts....
|
| |
TWW
Registered: Jul 2009
Posts: 545 |
So I finally found some tmie to finalize this stuff now when we're all global crisis'ing and all;
I've utilized jackassers extreemely fast multiplier along With the principles discussed above and it came out like this:
// Calculate Pixel Error - Steep slopes
// Y = DeltaY
// X = DeltaX
lda FractionTableLo,y
sta !SMC1++1
sta !SMC3++1
eor #$ff
sta !SMC2++1
sta !SMC4++1
lda FractionTableHi,y
sta !SMC5++1
eor #$ff
sta !SMC6++1
!SMC1:
lda Square1Lo,x
sec
!SMC2:
sbc Square2Lo,x
!SMC3:
lda Square1Hi,x
!SMC4:
sbc Square2Hi,x
clc
!SMC5:
adc Square1Lo,x
sec
!SMC6:
sbc Square2Lo,x
// A = Pixel Error
Tables:
.align $100
.pc = * "Math Tables"
FractionTableHi:
.fill 256, >round(65536 / i) + 0.5
FractionTableLo:
.fill 256, <round(65536 / i) + 0.5
Square1Lo:
.fill 512, [i*i/4] & $ff
Square1Hi:
.fill 512, [i*i/4] >> 8
Square2Lo:
.fill 512, [[[i-255]*[i-255]]/4] & $ff
Square2Hi:
.fill 512, [[[i-255]*[i-255]]/4] >> 8
I like it even thoug it introduces some degree overhead and eats some memory.
EDIT: i use it for hires, 256 pixels wide. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Four years later?! :D Haha, nice TWW! :D |
| |
Digger
Registered: Mar 2005
Posts: 437 |
No laugh JackAsser, I've been working on shit for 6 years and still have those "aha!" moments ;-) |
| |
TWW
Registered: Jul 2009
Posts: 545 |
hehe I see clarifications are in order.
If You see Post #7 I solved this ages ago using 8k tables but was Limited to DX/DY max 128.
If You see in my last post it's now for bitmap hires (256 pixels in X) which would add more tables so I figgured I'd try this way now as my line-algo is more mem-intensive.
I am still not sure if this is the best way to solve it though... |
| Previous - 1 | 2 | 3 - Next |
