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.

[pmc]

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

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.

[pmc]

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!

[Leffmann]

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

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.

[Photon]

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).

Originally Posted by Photon

Scali, when you said subpixel, I thought you meant antialiasing!

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

Originally Posted by Photon

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)

Yes. I don't really go into how to do that in the text, but I do point out that you need to do this. Else your polygons will still look wobbly, and the subpixel-corrected fraction doesn't look correct either (and correcting the endpoints is actually the most costly part. Calculating the fraction is very simple from there).
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).

Originally Posted by Photon

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.

Yes, I also choose to always draw top-down.
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.

[Photon]

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.

Originally Posted by Photon

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?

Well, I mean that the blitter will render the lines in horizontal direction rather than vertical direction, meaning that the rasterization (and therefore subpixel correction) rules are slightly different.
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.

Originally Posted by Photon

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.

No problem!
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.