Page 1 of 1
Victor 6560 Replacement - Added graphics ops, just for fun
Posted: Tue Jan 23, 2024 6:30 pm
by JonBrawn
I've not been working on Victor, the 6560/61 replacement FPGA, for a little while due to health issues. To break myself back into working on it I implemented some graphics primitives, just for fun.
Drawing points, lines, boxes, rectangles, circles and filled circles:
https://www.youtube.com/watch?v=PLyyZbsmuM0
Using the user-defined palette and point plotting to draw pictures:
https://www.youtube.com/watch?v=gmZlC_MBcGY
Re: Victor 6560 Replacement - Added graphics ops, just for fun
Posted: Wed Jan 24, 2024 12:45 pm
by Mike
on YouTube, you wrote:Regrettably, not perfect circles. They are perfect circles in memory, but the wild & whacky pixel aspect ratio of the VIC-20 squashes them into ovals.
That, and also with regard to your inquiry about the
PAR for PAL/NTSC you might want to take a sharp look at my ellipse routine (snippet taken from one of my example programs for MINIGRAFIK):
Code: Select all
49 REM ** ELLIPSE DRAW
50 X=0:Y=B:S=B*B:T=A*A*(2*Y-1):U=2*B*B:V=2*A*A:E=0
51 X1=MX+X:Y1=MY+Y:P1=X1>=0ANDX1<160:P2=Y1>=0ANDY1<192
52 X2=MX-X:Y2=MY-Y:P3=X2>=0ANDX2<160:P4=Y2>=0ANDY2<192
53 IFP1ANDP2THEN:@1,X1,Y1
54 IFP1ANDP4THEN:@1,X1,Y2
55 IFP3ANDP4THEN:@1,X2,Y2
56 IFP3ANDP2THEN:@1,X2,Y1
57 IFX=AANDY=0THENRETURN
58 F=E+S:D=0
59 G=F-T:IFABS(F)>ABS(G)THENF=G:D=1
60 G=E-T:IFABS(F)>ABS(G)THENF=G:D=2
61 E=F
62 IFD<2THENX=X+1:S=S+U
63 IFD>0THENY=Y-1:T=T-V
64 GOTO51
This is a 2nd order Bresenham derived from the conic section equations. Only additions, subtractions, comparisons and taking the absolute value in the main loop, and a few multiplies during init. No 'expensive' operations like divides, sine, cosine or square root.
With suitably chosen half axes, you can then compensate for the non-1:1 PAR. Note though even for half axes 'just' in the range 0..255, the values in the work variables E, F, G, S, T, U and V can become rather large and need 32-bit registers to store them correctly.
Re: Victor 6560 Replacement - Added graphics ops, just for fun
Posted: Wed Jan 24, 2024 10:10 pm
by JonBrawn
I'm assuming (MX,MY) is the center point and that A and B are the major and minor radii?
What you have here looks very similar to the code I have in Victor, give or take the ellipsy bits. I'll stare at this for a while and see if I can get it going.
Thanks!
Rounded rectangles would be neat, but that special-cases a whole bunch of pixels at the corners.
Re: Victor 6560 Replacement - Added graphics ops, just for fun
Posted: Thu Jan 25, 2024 1:45 pm
by Mike
JonBrawn wrote:I'm assuming (MX,MY) is the center point and that A and B are the major and minor radii?
Yes - to be more specific, A is the half axis in parallel to the x co-ordinate and B the half axis in parallel to y.
Rounded rectangles would be neat, but that special-cases a whole bunch of pixels at the corners.
Alternatively, you might consider
polygon fills. I have posted one
example, also for MINIGRAFIK, in the 'MG batch suite' thread. However, even though the algorithm can be implemented with integers, it is probably best expressed in floating point. The latter allows the line segments to be defined with sub-pixel accuracy and the algorithm is guaranteed to only plot the pixels strictly
within that polygon: polygons sharing sides can be 'stitched' without gaps, and also without overlapping pixels (except in
very rare cases).
Re: Victor 6560 Replacement - Added graphics ops, just for fun
Posted: Sat Feb 03, 2024 8:35 pm
by JonBrawn
Mike wrote: ↑Wed Jan 24, 2024 12:45 pm
...you might want to take a sharp look at my ellipse routine (snippet taken from one of my example programs for MINIGRAFIK):
If you're following in my footsteps, you might need to know that the range of some of those variables is somewhat larger than you'd imagine:
For a resolution of 172x184, e(-5735412:5685399) f(-5519016:17239104) g(-16635359:16303849)
These require 26 bits to hold the signed value.
Re: Victor 6560 Replacement - Added graphics ops, just for fun
Posted: Sun Feb 04, 2024 3:48 am
by Mike
I am very well aware of that.
Mike wrote:Note though even for half axes 'just' in the range 0..255, the values in the work variables E, F, G, S, T, U and V can become rather large and need 32-bit registers to store them correctly.
CBM BASIC can represent these numbers within its floating point format without any rounding errors, and my implementation in 6502 machine code actually uses 4 bytes for these variables to store them as 32-bit signed integer.