• The size of the buffer is 256x256, with a color depth of 256.
• Your circleroutine has to accept following input:
  • D0.l/D1.l: X / Y (middle)
  • D2.l radius (1-127)
  • D3.b color
  • A0: Pointer to chunky buffer.

  • The other registers are in undefined state. (Your routine will be disqualified, if it is using input from any other register, than the mentioned ones)

• All registers may be trashed, except a7.
• The circle has to be closed. (no gaps)
• The circle is not meant to be filled !
• The circle must be symmetrical (not egg-like shapes.. )
• no clipping required
• The routine must be working on 68020-68060! When you are sick enough to use selfmodifying code, make sure that it does also work on 040/060.
• The speed-tests will be done on a 68040/40. The time needed to draw an amount of circle at different positions and with different sizes will be measured. (small hint: I added some more info in the compo-machine in the linecompo package.

But Trover whose routine won, did show that it is possible to do both a (relatively) fast and shor routine. He also contributed with a 36 bytes version, which needs only 40 rasterlines to draw the testcircles.

The routines in the "shortest" compo had to draw three circles. Two with a radius of 32 and one with a radius of 64. The testroutine is included in the contribution package, which can be downloaded at the bottom of this page.

This competition was won by Piru. His routine is generating subroutines for every radius, cleverly gathering pixels to .l and .w writes. Due to this it is very cache dependant. So the very clean and short routine by Blueberry, who became second, is faster in a lot of cases.

The winning routine by Trevor. This is the 36 bytes version, which is a lot faster. The 34 bytes version is using a "moveq #-128,d7" at the beginning instead.

This routine is using the parametric equation of a circle: X=r*cos(t) ,Y=r*sin(t). The sinus and cosinus function is calculated by a recursive formula with a stepwidth of 1/256. So a full circle takes 2*pi*256 steps, which is enough to draw a closed circle. Read the Sinustable Generation Tutorial for further info. ("Another Algebraic Approach")

;Winning routine by Trevor, 36 bytes version.

	move.w	#256*7,d7	;steps*2*pi

	lsl	#8,d2		;d2=x

	moveq	#0,d4		;d4=y

.hamburger

	move.w	d2,d5

	asr.w	#8,d5

	subx.w	d5,d4		;y=y-(x/256)



	move.l	d4,d6

	asr.w	#8,d6

	addx.w	d6,d2		;x=x+(y/256)



	add.b	d1,d6		;000000000000y+y1

	lsl.w	#8,d6		;00000000y+y10000

	move.b	d5,d6		;00000000y+y1000x

	add.b	d0,d6		;00000000y+y1x+x0

	move.b	d3,(a0,d6.l)	

	dbf     d7,.hamburger	; :P

It is using a kind of "bruteforce" approach. It is stepping through the whole 256x256 array of the chunky buffer and calculating the distance from the midpoint of the circle for each pixel with the pythagoras formula. If the distance is between r+1 and r, the pixel is considered to be on the circle. (A rasterized circle has an area in fact.. :) )

Since a squareroot-routine , which would be needed for the formula d=sqrt(x^2+y^2), is extremly slow and not that short Piru used another trick. He divided d^2 by r. And checked for the range [r-1;r] r e Z then. This is mathematically not entirely correct (figure that out byself.. :) ) but it seems to be accurate enough, since the circles drawn with this routine are looking ok.

;Second placer by piru, 38 bytes.

	moveq	#0,d7		init loop counter, also y:x 24:8



.loop	moveq	#0,d4		clear x

	move.l	d7,d5		

	move.b	d7,d4		x=offs & $00ff	

	lsr.w	#8,d5		y=offs>>8

	sub.w	d0,d4		x=x-xc

	sub.w	d1,d5		y=y-yc



	muls.w	d4,d4		x^2

	muls.w	d5,d5		y^2

	add.l	d5,d4		x^2+y^2

	divu.w	d2,d4		(x^2+y^2)/r

	sub.w	d2,d4		(x^2+y^2)/r-r

	bgt.b	.nopix		(x^2+y^2)/r-r>0 ?

	addq.w	#1,d4		(x^2+y^2)/r-r+1

	blt.b	.nopix		(x^2+y^2)/r-r+1<0 ?

	move.b	d3,(a0)		put pixel

.nopix

	addq.w	#1,d7		loop 64k times

	addq.l	#1,a0		walk forward in buffer

	bne.b	.loop