Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: Scali on January 12, 2012, 01:46:01 PM
-
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/ (http://scalibq.wordpress.com/2011/11/23/just-keeping-it-real-old-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/2011/12/28/just-keeping-it-real-part-5/)
http://scalibq.wordpress.com/2012/01...real-part-5-1/ (http://scalibq.wordpress.com/2012/01/06/just-keeping-it-real-part-5-1/)
Hope you guys like this little trick.
-
Nice reading.
-
Thanks Piru!
Didn't we used to hang out together in #amycoders years ago?
In which case, ltns!
-
Thanks Piru!
Didn't we used to hang out together in #amycoders years ago?
In which case, ltns!
Yes we did :)
-
Awww! Get a room you two ;)
Seriously, fun read! I never knew the old PC gfx chips had so much hardware in them!
-
Seriously, fun read! I never knew the old PC gfx chips had so much hardware in them!
Neither did I, until I started reading Michael Abrash's Black Book. (http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/graphics-programming-black-book-r1698) EGA and VGA especially are just loaded with features you never hear about anywhere else, it's a shame so few games take advantage of them. (Dangerous Dave in the Haunted Mansion does, I think Jazz Jackrabbit probably uses them as well, but a whole lot of stuff just uses unadorned framebuffer graphics.)
-
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.
-
The c2p function provided by Akiko was of little real value... As soon as you have fastram, the CPU can outperform it. A true chunky mode would have been much more welcome :(
-edit- Though it should be noted that we did get the Akiko c2p free with the CDROM controller, where as fast ram would have added a few more cents to the cost of the machine and Commodore couldn't entertain that idea ;)
-
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.
I have to agree. Some of the Atari stuff is just mind-boggling, especially considering the limitations. I've had many very interesting chats with Wiztom of Aggression (he's a game developer at Housemarque btw) about Atari and how the custom HW differ from Amiga.
-
@Scali
Pretty cool. Thinking that it took >25 years to find out what the Blitter really can do kinda scares me... ;)
-
I have to agree. Some of the Atari stuff is just mind-boggling, especially considering the limitations. I've had many very interesting chats with Wiztom of Aggression (he's a game developer at Housemarque btw) about Atari and how the custom HW differ from Amiga.
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.
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.
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. Still, I loved the Borland Turbo C and Turbo Pascal IDE. That is what really got me into programming. One really good source for banging the VGA (and other) hardware in Turbo Pascal was SWAG. Unfortunately I can't find the archive with the nice original DOS based reader.
Sadly I never programmed on the Amiga in anything other than basic.
-
Welcome to the site. As intro posts go, that was pretty interesting stuff. I only read the last part so far, so I think I'll grab a quick brew and read the rest.
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/ (http://scalibq.wordpress.com/2011/11/23/just-keeping-it-real-old-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/2011/12/28/just-keeping-it-real-part-5/)
http://scalibq.wordpress.com/2012/01...real-part-5-1/ (http://scalibq.wordpress.com/2012/01/06/just-keeping-it-real-part-5-1/)
Hope you guys like this little trick.
-
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.
-
Cool interesting stuff, maybe I'll put some of it to use one day :)
-
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.
-
mercenary 3.. ive never figured out what was going on in there, might be one of the strangest games i ever tried.
-
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.
-
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
-
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!
-
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...
-
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.
-
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
-
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.
-
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.