Subpixel-corrected lines and polygons on Amiga

[Scali]

Hello,
 
Some of you may already have seen my post on abime.net, but if not, I'd like to share it here as well:
 
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.

[Scali]

Thanks Piru!
Didn't we used to hang out together in #amycoders years ago?
In which case, ltns!

[Scali]

Hum, am I on the right forum?
But yea, I guess part of why us Amigans weren't impressed much with the PC platform was that PC programmers didn't use the hardware to the fullest.
Sure, even though EGA and VGA have some trickery, they're not quite as advanced as the Amiga's blitter. On the other hand, they're not as bad as 'just a framebuffer'. Mind you, EGA has sort of a 'chunky2planar' mode built in, which the Amiga does not (with the exception of the Akiko chip in the CD32... and why didn't they put it in standard A1200 and A4000? They would have made wolf3d/doom clones easier and faster, and the Amiga may have survived as a gaming platform longer).
 
I guess the same can be said for Atari ST. Not as advanced as an Amiga, but you could do some clever tricks (and later models DID have a blitter, I only found that out much later. Again, not as good as the Amiga one, but nevertheless, better than nothing). There just weren't that many great games and demos that showcased them. In retrospect, I think some Atari ST demos may actually be even more impressive than Amiga demos.

[Scali]

I read somewhere that Atari ST emulation requires more precise CPU emulation that is necessary for Amiga and MAC emulation. I don't believe I have ever seen an actual Atari ST in action.

Sounds reasonable yes. On Amiga, most time-critical stuff is done with the copper, not the CPU. So the copper emulation needs to be very precise, but the CPU generally doesn't.
Atari is more like a C64, where you often craft code to run exactly X cycles, then you change some hardware registers at exactly the right pixel.
 
Perhaps this is not the best place to admit it... But I have an Atari ST myself. I got it after its prime though, somewhere in 1997 or so I think. See, one of my other hobbies is music, and I wanted an Atari for Cubase. I've tried a few games and demos on it, but concluded they were not as good as the Amiga. Partly because I didn't 'get' them, I suppose. I mean, a lot of Atari demos use fullscreen parallax scrolling effects. To an Amiga guy that's a bit of a 'so what?'. But if you know what hoops the Atari guys had to jump through to make it possible on their machine, it's a different story.
There's not a lot of 3d stuff on Atari ST... But this one is pretty incredible: http://www.pouet.net/prod.php?which=109
And that's just software too, not even using the blitter found on the later models.
 
I have no excuse for the music though... even a C64 sounds better than the Atari ST, if you ask me.
 

I remember seeing Ultraforce Vector demo back when I had a 286 with Tsing et4000 VGA and that demo was the first demo I had seen on the PC that impressed me. I also had an A500 at the time. Most everything else up to that was just some fake raster bars and scrolling text done with pure CPU brute force. the other impressive thing to consider about the Vector demo is that the PC's SandBlaster card of that day had one grainy 8 bit channel so they are doing some CPU sound mixing there too.

Yea, that's when PC scene started to get serious. Around 1990/1991 the first modplayer routines appeared on PC, and soundcards started getting support.
3d was still mostly bruteforce, but that was exactly what the PC was good at. The 286 was already a much faster CPU than the 68000, with speeds up to 25 MHz.
And VGA was nicer for chunky effects, as it had a native chunky format.
 

VGA was not really bad hardware at all. The bigger issue was the brain-dead CPU it was attached to with the 64K segmented architecture.

I think the sad part is that the 386 had been around since 1985, but it took until about 1992 before 32-bit code became commonplace. DOS did not support the 32-bit mode, and there were no alternatives, until eventually the DOS extenders arrived.
But it makes the Vectordemo even more impressive I guess, because it just runs in 16-bit mode. I believe Triton's Crystal Dream is also purely 16-bit (Crystal Dream II is 32-bit though).
 
I'm still a bit in two minds about VGA. Some parts of it are nice... other parts are nasty. Chunky mode is nice, unchained mode is nice... But the latches being only 8-bit large is rather limited. Lack of proper blitting and shifting is also a shame. And the fact that you can only address 64k of memory at a time. That means that in chunky mode, you cannot use a backbuffer in videomem. In fact, having to use separate videomem in itself is nasty. Reading back videomem has always been a bottleneck. The only way to avoid that was to have a buffer in sysmem. But that meant you had to memcpy() it to videomem every frame. And with the slow ISA bus and no proper DMA to do that for you... it wasn't pretty. It wasn't really feasible until 486 and VLB arrived, and the copy speed was getting good enough.

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

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