25 April 2018, 20:59  #21 
Omnia fert aetas
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,077

Hi Sting, so Scali was Peter Pan!
I'm sorry Niklas, so definitely you're not. Last edited by ross; 25 April 2018 at 21:25. Reason: erased a bit of nonsense, I have already written enough :P 
25 April 2018, 21:43  #22  
Moderator
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,568

Quote:
(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 pixelcentric. 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 pixelcentric 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 pixelcentric, or a pixelcentric 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. Last edited by Photon; 25 April 2018 at 22:01. 

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)  
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Blitter line mode examples?  LuigiThirty  Coders. Asm / Hardware  4  17 August 2017 08:26 
Fast Blitter Line Clipping  71M  Coders. Asm / Hardware  2  03 March 2014 22:33 
Clipping line for blitter fill  leonard  Coders. Asm / Hardware  12  27 April 2013 12:03 
Drawing a line...  Lonewolf10  Coders. Tutorials  24  06 September 2011 00:46 
Line mode blitter  absence  Coders. General  4  25 September 2009 20:50 

