09 January 2012, 09:37 | #1 |
Posts: n/a
|
Subpixel-corrected lines and polygons on Amiga
Hello,
I have recently picked up programming on the Amiga again, and decided to tackle the age-old problem of rendering polygons using the Amiga blitter. I have kept a log of my progress, which you can find here (yes, it also includes some PC/DOS programming stuff, the Amiga stuff starts in part 2): http://scalibq.wordpress.com/2011/11...d-skool-style/ But in particular I'd like to share parts 5 and 5.1, because after dissecting the blitter's capabilities, I realized that it was possible to apply subpixel-correction to the lines, at relatively low extra cost: http://scalibq.wordpress.com/2011/12...t-real-part-5/ http://scalibq.wordpress.com/2012/01...real-part-5-1/ Hope you guys like this little trick. |
09 January 2012, 10:58 | #2 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Regarding your leaking blitter fills at start / end points of lines, are you aware of this undocumented blitter quirk:
http://eab.abime.net/showpost.php?p=206412&postcount=6 Basically you have to do a couple of little tricks with your hardware linedrawn lines to get hardware blitter filling to work correctly. I posted about here: http://ada.untergrund.net/forum/inde...pic=618&page=0 Last edited by pmc; 09 January 2012 at 11:03. |
09 January 2012, 11:19 | #3 |
Posts: n/a
|
Yes thanks, pmc. I found that trick when I implemented my original non-corrected routine, which you can find in part 3. I put a link to that post in the text:
http://scalibq.wordpress.com/2011/12...t-real-part-3/ Thing is just that I couldn't work out how to make it work for the subpixel-corrected version in all cases. That's why I replaced the horizontal lines with a CPU routine. It might be possible somehow though. |
09 January 2012, 11:49 | #4 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Ah, OK - cool
I must admit I only skim read the articles on your site there - I'm at work at the moment so only limited time for fun stuff Great stuff by the way - keep it up! |
10 January 2012, 00:28 | #5 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
Interesting that you should post this, I've been thinking about this lately but not gotten around to looking into it myself.
Even with the tell-tale register setups I was curious of why BLTADAT had to be set to a constant $8000 by the user, and thought it could be that fractions were normalized/scaled up to get 16 bits of (overkill) precision, and that BLTADAT held the fraction and it always being set to $8000, effectively 1/2, was the reason the end-points snap to the middle of the pixels. Anyway I see now that it would've been a dead end, and I think it's great you've taken the time and effort to dig into and have come up with this, really great work |
10 January 2012, 12:01 | #6 |
Posts: n/a
|
Glad you liked it!
As for the $8000 constant.. I believe it is used as the pixel mask. It is rotated around according to (X AND $F) to plot the right pixel (as the blitter always works with words). So using eg $8080 would draw two lines, 8 pixels apart horizontally. I wonder if there's any way to make that useful :P Perhaps it could be used when you want to draw a grid. As long as the vertical gridlines are < 16 pixels apart horizontally, you could draw two or more with one line? I've never tried it though, so I'm not sure if it would even work. |
10 January 2012, 13:02 | #7 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,627
|
Yes, BLTADAT is the "pixel". Scali, when you said subpixel, I thought you meant antialiasing! Heartbreaker Also, are you using subpixel precision start and endpoints, rather than "middle of pixel"? (Sorry, didn't have time to read it all at lunch break)
IMO shaking lines are more due to endpoint calculation precision than anything else, but... I've always saved the last muls (to divide) to last to get longword precision, swapped, and added 1 and shift down 1 to round. As for "adjusting lines to avoid the blitter fill artifacts" (FillLineFix?), you must make sure you don't change the slope or your algorithm to move the center of the line is botched, of course. There are a few options there, I prefer the "drawdown/blth-1/ldelta+1" (NeverOverlapDown?) method over the setpixel, drawcclockwise/length-1, moveleftright1table methods, since the more homogeneously your lines are drawn, the more control you have over exactly where the pixels end up. One thing I learned that I can share is that whatever algorithm you use, if it doesn't work with XOR there will always be a circumstance that causes blitter artifacts. So use XOR, it will expose your "blitter fill fixer" algorithm. This means that an algorithm that doesn't enforce a system for homogeneous slope WILL get in trouble - at complex joint edges, if not before. It can be any system, but it should set exactly identical pixels between two random endpoints on a bitmap (identical pixel count is not a must - it may exclude start- or endpoint at will). |
10 January 2012, 13:53 | #8 | ||
Posts: n/a
|
Nope, just rendering lines and polygons with subpixel-precision, as modern 3d accelerators do.
I don't think antialiasing will be possible with decent performance on a standard OCS/ECS Amiga :P Quote:
I just wanted to explain how to set up the blitter for it, rather than doing a complete explanation on subpixel-correction in general (there are other/better sources for that, no doubt). Quote:
Which is where the CPU-routine comes in: it draws lines where abs(dy) < abs(dx) top-down as well. For non-corrected lines that is not a problem, the blitter draws the horizontally oriented lines well enough to avoid fill problems. But so far I couldn't make these lines work 100% after subpixel correction. It is key to make it start and end on the proper scanline, and it seems to overshoot the endpoint in vertical sometimes... which is hard to control since it renders horizontally, rather than top-down. |
||
10 January 2012, 21:18 | #9 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,627
|
Regardless of whether any line renders vertically or horizontally, it's possible to draw them downward, ie. swap endpoints if the startpoint is lower down. Or what did you mean?
When that is done, I foresee you will still have problems even if you do the hgt-1/LDelta+1 fix on the CPU lines as for the blitter lines (if you choose that method), simply because of 1 special case: theoretically startxy and endxy could be slam in the middle of a pixel, and the deltas would be affected. Could this be it? hgt, ie. dy, and LDelta when made integers could be 1 too large for the conventional blitter or CPU value fixes to work. Maybe one way to narrow it down would be to use half-pixels, to see exactly at which angles or whatever it happens, limit the cases to fix. Maybe also to use color01 for blitterlines and color03 for cpulines, to see which one is causing it. (Not color02 as that wouldn't change bpl0 and you wouldn't catch all fillbugs.) I'm giving you advice without you asking for any, which sometimes can be taken as offensive. I assure you it's not meant as such Call it speculation about something I for some reason (some coders know this reason ) care about, if you like. |
11 January 2012, 12:37 | #10 | ||
Posts: n/a
|
Quote:
The difficulty is that you want to control the start and end position in Y-direction, but since the line-length is now specified in horizontal amount of pixels, it makes the calculations more difficult. And slight errors may still make it jump to the next scanline unexpectedly. Quote:
It's nice to have some other people thinking along with this problem. Thing is, I've been busy with this for quite a while now, and I've tried many things, so I suffer from a bit of 'blitter fatigue' On the one hand that means that I may have already tried some things, but I have made small mistakes... so I think it won't work while in reality it should have. On the other hand, I am not exactly jumping with joy to try new things. I need a bit of time off I just kept picking up the routine and trying new things, day in, day out... Trying to figure out where it goes wrong. Then I got to the part where I at least had the vertical lines working, and had a working substitute for the horizontal lines... I gave the horizontal lines a few more tries after that, but then I decided I just wanted to present the idea as-is, and leave the horizontal problem for another day. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Corrected shaders for WinUAE | guest.r | support.WinUAE | 419 | 30 April 2023 14:25 |
[FS-UAE] Optimized or corrected Amiga Game Database Entrys | nexusle | support.FS-UAE | 3 | 24 August 2012 21:30 |
Winfellow and Command Lines | Fiend | support.WinFellow | 3 | 26 August 2006 00:25 |
1085s dodgy lines? | chaoticjelly | support.Hardware | 3 | 21 August 2006 21:12 |
Would you like some polygons? | Dalai | Retrogaming General Discussion | 7 | 05 October 2004 00:20 |
|
|