Coding Competition #1

[DanScott]

OK... so now that other thread is completely cluttered, and I have finally some free time... it's time for coding competition #1

This first task is very Amiga OCS/ECS orientated (oriented for our American friends )

Write a function to interpolate between two Amiga OCS/ECS 12-bit RGB values over 0 to 15 steps ( i chose this, as there are 0 to 15 steps to interpolate a colour from $000 to $fff)

Inputs:
d0.w = Colour 1 (12bit RGB)
d1.w = Colour 2 (12bit RGB)
d2.b = Step value (0-15)

Output:
d0.w = Final Interpolated Colour (12bit RGB)


Please assume all other registers are in an undetermined state, and thus need saving and restoring as part of the function.

There will be 2 winners... one for the shortest code, and another for the fastest code

For the fastest code, a look-up table will be allowed (up to a maximum of 1kb), and the initialise function to generate the look-up table will not be counted in the cycle count of the routine.

Please refrain from turning this thread into a discussion, or going off-topic

Thanks

Dan

[ross]

Hi Dan, I ask for some clarification.

RGB Colour 2 single components can be minor of Colour 1?
(ex. C1=$785, C2=$f37 so negative step in G component)

If Amiga OCS/ECS then pure 68k?

I can count on zeroed upper bit of d2 and $0RGB?

There is a minimum precision for the interpolation rounding?

(I've written the 'shortest code' version in hurry and i'm sleepy so better go to bed and recheck tomorrow , xx byte but do not rely too much on this value)

Bye,
ross

[DanScott]

Yes, both RGB values can be ANY value whatsoever

pure 68000. Assume unused upper bits in d0,d1&d2 are all zero too.

Precision... well it has to be pretty accurate...

[meynaf]

Code no longer here as DanScott wanted...

[ross]

Hi meynaf, very squeezed code

I have a version in a laptop that is not with me now.
It is different from Yours.
Last night I wrote it late and I do not remember by heart
But no divu, two muls and no 4 component but 3.
(i'm in waiting of Dan response )

Bye!
ross

[DanScott]

I forgot to say... Please do not post the code in this thread. Meynaf, can you remove your code from your post please

PLEASE SEND ALL ENTRIES TO ME VIA P.M MESSAGE HERE!!

This makes it fairer, so others won't use someone elses code as a basis for their own.

Optimisations can be discussed after competition closes and results are announced.

CLOSING DATE FOR ENTRIES is SUNDAY 9th APRIL

[meynaf]

Originally Posted by DanScott

I forgot to say... Please do not post the code in this thread. Meynaf, can you remove your code from your post please

PLEASE SEND ALL ENTRIES TO ME VIA P.M MESSAGE HERE!!

Done.

Originally Posted by DanScott

This makes it fairer, so others won't use someone elses code as a basis for their own.

Optimisations can be discussed after competition closes and results are announced.

Fairer but now we're blind - no way to know if we're the best or totally out of it...

[ross]

Ok, got some time to check my late-night code (a mess but the idea was good, even an initialized and unused register..).
Different approach than meynaf (like usual, i'm sure if I show my code he can strip-down 2 byte )

For the 4 component, round perfect(*) version: xx byte
The pretty usable trunc integer version: xx byte

(*i've written a reference code in c with double precision type vars and the results are the same)

Now the fast version...

Bye!
ross

[a/b]

For the speedy version, can the lookup table be placed within 8-bit distance of the code (=> pc relative with index and 8-bit displacement), or it has to be in an entirely different DATA/BSS section?

[ross]

Sorry to go slightly off-topic, but is surely related.
I've to show this beauty,I am always fascinated by doodling generated by code.

On left my generated data, on right meynaf generated data. Look the diffs

Bye,

[paraj]

Originally Posted by ross

Ok, got some time to check my late-night code (a mess but the idea was good, even an initialized and unused register..).
Different approach than meynaf (like usual, i'm sure if I show my code he can strip-down 2 byte )

For the 4 component, round perfect(*) version: xx byte
The pretty usable trunc integer version: xx byte

(*i've written a reference code in c with double precision type vars and the results are the same)

Now the fast version...

Bye!
ross

I can match xx bytes for a truncating version*. Now it's time to see if I can find any improvements.

*) No point in submitting yet, for reference the md5sum of my implementation is: bdede35f639ab9a7d200629095d4c5a3 c1.xxbytes.s

[meynaf]

I could beat my first version and therefore i submitted the new one in replacement. This old code has been read by others anyway so it was kinda necessary...
No more 4x loop (i initially missed the obvious) and this is all i will tell here.

[Thorham]

Originally Posted by DanScott

Inputs:
d0.w = Colour 1 (12bit RGB)
d1.w = Colour 2 (12bit RGB)
d2.b = Step value (0-15)

That's a pretty bad interface, yuk I'll skip this one.

[DanScott]

Originally Posted by Thorham

That's a pretty bad interface

How?

A function that takes 3 data regs and spits out a result...

[DanScott]

Originally Posted by a/b

For the speedy version, can the lookup table be placed within 8-bit distance of the code (=> pc relative with index and 8-bit displacement), or it has to be in an entirely different DATA/BSS section?

However you want It's the cycle count of the routine that is important

[Thorham]

Originally Posted by DanScott

How?

A function that takes 3 data regs and spits out a result...

Forget what I said, I misread the spec Thought you had to interpolate from one color to another in a number of steps and output to an array It's fine if it's just lerp (d2 should be a word, though).

[meynaf]

Originally Posted by Thorham

(d2 should be a word, though).

Originally Posted by DanScott

Assume unused upper bits in d0,d1&d2 are all zero too.

@Thorham :
Not waken up properly today, mate ?

[Thorham]

Originally Posted by meynaf

Not waken up properly today, mate ?

Didn't have enough coffee

[ross]

Hi all, beated my previous 'small code' not-math-precise-but-enough-accurate version (*).
So I've two small version upped: rigorous math accurate and pretty accurate.
Is Dan choice of what to consider. In my opinion both are beautiful pieces of tiny code

Now trying to shrink 4KB table into 1KB for the fast version.

(*)it's highly likely that at the end my code match the new announced meynaf one
i'm very curious about that.. the optimization made was not trivial
my stupid tabbed doodle in previous post enlightened me

[ross]

Originally Posted by DanScott

--cut--
Inputs:
d0.w = Colour 1 (12bit RGB)
d1.w = Colour 2 (12bit RGB)
d2.b = Step value (0-15)

Output:
d0.w = Final Interpolated Colour (12bit RGB)


Please assume all other registers are in an undetermined state, and thus need saving and restoring as part of the function.
--cut--

Hi Dan, sorry to be pedantic...

I've a doubt regarding register saving.
For the fast routine i destroy even the input value in d1 and d2.
I have to maintain their value? (is not simply the cycles for their saving to (re)consider but the routine itself)

The rule "assume all other registers are in an undetermined state, and thus need saving and restoring as part of the function"
is not clear if includes them or not..

An alternative can be like system routine that save all but d0-d1/a0-a1.

Each cycle counts in fast routine

Thanks, bye,
ross