Subpixel-corrected lines and polygons on Amiga

[Mrs Beanbag]

this is awesome, I am going to try this.

The planets on Damocles/Mercenary III are subpixel correct circles, which I remember thinking was rather neat.

[wawrzon]

mercenary 3.. ive never figured out what was going on in there, might be one of the strangest games i ever tried.

[Mrs Beanbag]

One thing I might try next is to use the HAM screen mode as a polygon filler.  You'd only need HAM5 as well, not full HAM6.

The theory is, fill the whole screen with $10 which copies the pixel to the left but changes the blue component, then you can fill any shape instantly by using the paletted colours $0-$F (as long as these colours only use red and green components), simply plot the colour you want down the left hand edge and make sure to set it back again on the other edge.  One could render something like a tunnel fairly easily.

[bbond007]

One thing I might try next is to use the HAM screen mode as a polygon filler.  You'd only need HAM5 as well, not full HAM6.

The theory is, fill the whole screen with $10 which copies the pixel to the left but changes the blue component, then you can fill any shape instantly by using the paletted colours $0-$F (as long as these colours only use red and green components), simply plot the colour you want down the left hand edge and make sure to set it back again on the other edge.  One could render something like a tunnel fairly easily.

I have been struggling with OpenGL ES programming and I have also recently decided to finally learn c programming on the Amiga. I thought maybe it would help me in both areas to try and implement the HAM5 mode polygon filler. I think maybe I struggle with OpenGL because I don't understand basic old school 3D. That and I suck at math...

Anyway, here are the results so far. As you can see its not perfect. I have also found that HAM5 mode does seem to work correctly on my Amiga 1200, however does work on my WinUAE and my Minimig 1.1.

On all of the downward winding lines of each polygon I'm looking at the pixel (actually 4 because I don't know how to find the exact pixel) at the midpoint of the line I'm about to draw to determine if I should draw the line. I guess its either that or I would have to sort the polygons so they draw left to right. I'm sure there must be a better way to do this.

Sorry for the iPhone screen shots. I don't have any program on the Minimig ATM to capture HAM screens.

Thanks

nate

[Mrs Beanbag]

Anyway, here are the results so far. As you can see its not perfect. I have also found that HAM5 mode does seem to work correctly on my Amiga 1200, however does work on my WinUAE and my Minimig 1.1.

Hey!  Nice!

[bbond007]

Here is the test program, I'm still trying to figure out why it likes to crash on my a1200...

also, I think subpixel correctness could really help this out, the problem with the bleeding in the HAM mode is somewhat related to the routing of the lines... oh, I'm lost...

EDIT:
I just removed the bad language from the source and included it...

[Scali]

Perhaps I can be of some assistance.
 

I guess its either that or I would have to sort the polygons so they draw left to right. I'm sure there must be a better way to do this.

Well, sorting the polygons may prove troublesome, as you'll want to sort them back-to-front as well.
 

I think subpixel correctness could really help this out, the problem with the bleeding in the HAM mode is somewhat related to the routing of the lines... oh, I'm lost...

 
Well, subpixel correct rendering is not required for bug-free polygons. Conversely... if your rendering is not bug-free without subpixel correction, it might improve somewhat, but I don't think it will become 100% bug-free.
 
The key to bugfree polygons is to have a strict rasterizing order. The most common is to render left-to-right and top-to-bottom.
When you render in that order, you will generally choose to render the first pixel of an edge/polygon on the left, and on the top, but not the last pixel of the polygon on the right and on the bottom.
Namely, if the endpoint is shared by two edges/polygons, then the second edge/polygon will draw the pixels that you skipped for the first one. Because the last pixel of the first polygon is now the first pixel of the second polygon. Hence it is rendered exactly once.
 
You could choose any rasterizing order, as long as you are consistent with all edges in all polygons.
 
I briefly cover this in my blogs, also pointing out that ordering your edges is reasonably simple when you go with strictly clockwise or strictly counter-clockwise order. The polygon can be seen as a circular linked list, which you can just rotate around until you have the top vertex first. Then moving from begin-to-end in the list gives you one side of the polygon top-down, and moving from end-to-begin in the list gives you the other side top-down.
 
I hope that makes some sense.

[bbond007]

I briefly cover this in my blogs, also pointing out that ordering your edges is reasonably simple when you go with strictly clockwise or strictly counter-clockwise order. The polygon can be seen as a circular linked list, which you can just rotate around until you have the top vertex first. Then moving from begin-to-end in the list gives you one side of the polygon top-down, and moving from end-to-begin in the list gives you the other side top-down.
 
I hope that makes some sense.

A little. At least I think I understand now why I seem to have two lines to the exact same points taking different routes. Same line, just drawn in different directions. I understand how to fix that now from reading your blog - "we sort the points of each line on their y-coordinates, so they are always rendered top-down"

I know I have the ordering of my edges done consistently as the surface removal scheme relies on that.

I guess where I'm getting lost is for the application of the HAM mode renderer.

I would probably just like to eliminate redundant lines(draw them once in the correct color) because I'm not trying to make a mask for a filling operation. Is there any sort of trick to doing that?

I hope I can get this working. I was initially kind of discouraged that HAM5 did not work on the 1200, but I just remembered it has HAM7  
Thanks

nate

[Scali]

A little. At least I think I understand now why I seem to have two lines to the exact same points taking different routes. Same line, just drawn in different directions. I understand how to fix that now from reading your blog - "we sort the points of each line on their y-coordinates, so they are always rendered top-down"

Yes, the thing is that you're working with fractions, and if you render top-down, the rounding to integer works slightly differently from when you render bottom-up.
If you apply subpixel-correction, the issue will get less obvious, but you will still run into rounding problems every now and then.
But if you always render in the same direction, you always get the same rounding behaviour, so no matter how inaccurate the line drawer itself is, it will at least always be inaccurate in the same way.
 
The Amiga blitter can draw lines in 8 different directions, but it does not perform any sorting, so you still get the same issues.
If you render a line from A to B, then the same line from B to A in xor-mode, you'll see that the blitter will not draw the exact same pixels everywhere.
Therefore, you should sort your lines if you want the blitter to draw them consistently.

[Scali]

I believe Triton's Crystal Dream is also purely 16-bit (Crystal Dream II is 32-bit though).

On a slightly related note:
Yes, Crystal Dream is just 16-bit (in fact, the readme says it should run on a 286, although they recommend a 386).
But I found out when I tried to run it on my 486DX2-80 machine. The audio didn't work properly, even though I have an original Sound Blaster Pro in that machine.
So I decide to patch the code, and I wrote a small follow-up blog on it:
http://scalibq.wordpress.com/2012/03/14/oldskool-demo-fixing/
 
And well... to me, Crystal Dream is at least half an Amiga demo
For starters, it features fast untextured polygon stuff, and plays MOD music. Very much an Amiga vibe to the demo (and one of the first, if not THE first, to get Amiga-like quality on PC).
One of the coders is Vogue, previously active on Amiga for Phenomena (not sure if Mr. H has also been active on Amiga, but he sure knows how to write MOD routines).
And Triton are the guys who gave the PC people FastTracker, arguably the best tracker for non-Amiga systems, especially in those days.