Blitter line drawing: nothing happens

[ross]

Originally Posted by StingRay

Scali is located in Neverlands , not in Sweden.

Hi Sting, so Scali was Peter Pan!

I'm sorry Niklas, so definitely you're not.

[Photon]

Originally Posted by Niklas

Hi, I have the repository https://github.com/niklasekstrom/blitter-subpixel-line that was mentioned above.

I just updated it with the document "Sub-pixel accurate rasterization of polygons using the Amiga blitter.pdf" that describes how to calculate the values that the blitter should be programmed with in order to do sub-pixel accurate rasterization. It builds on the document "Drawing lines using the Amiga blitter.pdf" so you probably have to read both documents to understand what is going on, but as you have already gotten line drawing using the blitter to work you will probably understand most things quickly.

I'm happy to answer any questions!

Higher than 1px accuracy is defo better than some 3D calculation routines that even have less than 1px accuracy for the coordinates in a bunch of demos

(I.e. your coordinates must be, let's say, 1/512px worst case resolution first of all, then you can know that your subpixel starting point is not off. 512 is from maximum line length 410px in lores, i.e. slope partial pixel counter mustn't slip.)

I think it's a good initiative. The PDF says the Blitter starts out in the center of a pixel - I'm not so sure about that. Center along the minor axis, possibly. Any algorithm could be checked for centricity by simply fixing one point as origin and moving the other in a circle, and draw a line between them. If the origin doesn't slip, the algorithm is pixel-centric.

Software or hardware algorithm, you will be working with a slope delta y that increments and wraps at pixel boundaries. This means that a line that crosses the exact middle of a minor axis pixel boundary, two pixels will not be plotted since it's the minor axis - and this affects symmetry (these are the kinds of problems Knuth solved for font plotting in struggling to get his TeX work out).

So I appreciate it, but at the same time a bit skeptical as it requires math and implementation proof, and a few examples such as plotting 360 degrees of a line in an 8x8 pixel matrix as comparison to check.

It's very likely better than just calculating the endpoints and blitter values with integer math as usual.

Some slighter improvements can be had using only 4 quadrants, and reducing blit height without affecting SDelta/LDelta. This with the XOR fill mode will give coherent slopes, appearing smoother, but also wreck symmetry. For filling with CPU or Blitter, this gives lines that overlap exactly if drawn over each other. This latter point is also a test of a pixel-centric as well as a subpixel accuracy linedraw. I would say that if you get slight glitches, obviously it can't be used for filling, but a pixel-centric, or a pixel-centric and subpixel accurate algorithm would give these glitches. It's just the nature of the digitization however accurate. If you escape them, it would be just that example and in another you would get them.

If filling isn't required, line thickness comes into the equation to calculate the area inside the current pixel, even if that area is rounded, floored, or ceilinged to whole square pixels.