creating a circle in graphics?

[chassty]

Hello there, I am currently working on a graphics program and I am having a little trouble in figuring out how to draw a circle. If anyone might have any suggestions I would much appreciate it. I have included some code in which I drew a single line.



c14disply proc near
push ax
push bx
push cx
push dx

mov bx,00
mov cx,100
mov dx,320
c24:
mov ah,0ch
mov al,06h
int 10h
inc cx
cmp cx,550
jne c24

mov cx,100
inc dx
cmp dx,322
jne c24

pop dx
pop cx
pop bx
pop ax

ret

c14disply endp

 

[AmkG]

I would suggest that you get yourself a nice big book about programming the video cards. A good one is "Programmer's Guide to the EGA and VGA cards." The topic of graphics is extremely complex.

Note that your line routine is extremely inefficient, because you are using BIOS routines, which are very bad in practically everything that requires speed. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[datac5155]

A circle is just plotting a point around a center X,Y Position. You need to rotate that point around the Z Axis using sin and cos (some people use predfined tables for "speed", but for the sake of data space they are too inaccurate for me).

But AmkG is right, bios is bad for drawing. Way too slow.

DataC5155 DataC5155

"...NO FATE..."

 

[straiph]

you can use the FSIN and FSINCOS commands to calculate the positions.
F stands for floating point so you need to understand how the FPU (floating point unit) works.

If you look at the FAQ there is a link to download some manuals which has full documentation on using the FPU.

I hope this helps you in creating more efficient and faster routines.

Straiph.
0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[AmkG]

Even FSIN and FSINCOS are pretty slow... the book I mentioned has an optimization which uses ints, I can't remember the exact algorithm but if you're still interested I might try to dust the book a bit.

To reduce the calculation overhead, compute from zero to 45 degrees. Then just do the ff. computations:

otherpoints(x,y)
{
x2=x;y2=-y;
x3=-x;y3=y;
x4=-x;y4=-y;
x5=y;y5=x;
x6=y;y6=-x;
x7=-y;y7=x;
x8=-y;y8=-x;
drawpoint(x,y);drawpoint(x2,y2);drawpoint(x3,y3);drawpoint(x4,y4);
drawpoint(x5,y5);drawpoint(x6,y6);drawpoint(x7,y7);drawpoint(x8,y8);
}

So instead of computing from 0 to 360 (an entire circle) you compute for points up to 45, then 'flip' the coordinates. Each calculated point thus gives rise to 7 other points, so that a single calculation does 8 points at a time.

There are also other optimizations which put into consideration the fact that the screen is composed of pixels; a similar optimization exists for lines (it's called the Bresenham Line algorithm).
"Information has a tendency to be free. Which means someone will always tell you something you don't want to know."