Sorry mom, that's not quite right.
Here's the explanation. It might be pretty technical, but it's worth reading, I think.
Back in the day, there were these things called sprites. They were a hardware thing, the video chip directly supported them. You had a given size you could use, and you could say "put this <there>". There were operations in the kernel for collision detection (that weren't very good, I might add), overlap, etc. Sprites were for games, and because of their size, we get the idea that a small piece of clip-art that can be moved around is now called a sprite.
But sprites had several severe limitations. The main one being that you had a limited number available to you. 8 was the limit on the Commodore 64.
So what do you do? There were lots of tricks to get around the problem, but when the Amiga came out, it came equipped with a unique system that made a new system possible. Before I go into this system, I want you to spend a minute thinking about how the screen was rendered.
You're familiar with the vsync rate on your monitor? That means that your monitor will redraw the screen that many times each second. Televisions generally operate at something low, like 20hz. I forget, but that's basically 20 times per second, the screen is redrawn. The Amiga monitors ran at 50hz. I think the European (PAL) monitors ran at 60hz, but I could be misremembering that.
What happens in every screen refresh?
I'll tell you.
The area of memory that I'll call screen RAM is read and drawn on the screen. Deep down inside there's a little more to it than that, but for programmers, all you need to know is that your screen RAM gets rendered exactly like it is. Nowadays, screen RAM is located on the video card (generally, although there are some cards that share their RAM with the CPU). Obviously, the higher your vertical refresh rate, the smoother and crisper the picture.
The system the Amiga had that was unique was called the "blitter", and it was comprised of several specialized areas in a few particular chips on the motherboard (possibly the daughterboard, I forget where it was exactly, remember this was late 80s, early 90s). All it did was copy values from one memory location to another, but it did it very quickly. Later on, the argument would be made that MMX was a blitter system for x86, but MMX is a bit different than that, even. But it was the first evolution of hardware acceleration for graphics, and it took quite a few years for x86 to catch up (lest we forget, the reason the Amiga went down was because Commodore was screwed over by their President and chief accountant, embezzled into a shell, and sold at bankruptcy proceedings when the culpable parties ran from the country. Technologically, it took about a decade for the PC to finally have everything the Amiga had). It should be noted that the blitter system could be tapped to do other tasks besides using it to accelerate graphics, but for this discussion, it's not important to consider those uses of the system.
So, what you have then is a screen. Screen memory is given a particular location in physical RAM, and what you'd do is store a portion of the screen in some other location, and use the blitter to copy that information to the screen RAM. Thus evolved the idea of the blit, or the blob. We call these sprites nowadays, but I started by describing sprites so I could distinguish between them.
A blit is a little unit of graphics stored in memory. When an application starts, it loads all of these little units from files, nowadays it's common to use .png files because of the alpha layer that's in them. When you want to put it on the screen, you rapidly copy it from the location in memory that it's in to the screen RAM. This has the advantage of not having any limits on the number of blits you can have, so long as you have the raw processing power to copy them when you need to. A number of techniques developed to deal with some of the issues, which I'll discuss in a minute. The important difference here is that with sprites, you basically register the sprite with the video system and tell it where the sprite is located. If you want to animate the sprite, you have to remove the old sprite and register a new sprite. As long as you don't change it very often, you can have a very fast sprite. This was pretty much the only game in town when your CPU was 2 mhz. (Yes, that's Two Megahertz, the speed of the 6502 that was in the Commodore 64) With blits, you're limited by the amount of memory you have. Animation is free, just copy a different version of the blit to screen RAM. But you're limited by how much processing power you have.
In practice, it turns out that between the 7mhz processor in the Amiga and the blitter system, hardware sprites went the way of the dodo. The Amiga still had them, Commodore thought you needed them, but nobody used them (except in AmigaBasic, but let's not talk about that). It is quite true that even the 33/44mhz 80486's of the day couldn't match the Amiga in performance, and it's all due to the blitter system. It wasn't until well into the Pentium era that the PC finally matched the Amiga for performance (and commodore had been defunct for some time).
So, what do you do when you use blits? There are a number of issues that hopefully some of you have noticed already. Let's talk about them.
First, when you copy a blit to screen RAM, you
overwrite whatever was there already. If you don't manage your blit carefully, you suffer the blit bleed, where a blit bleeds itself all over the screen. What you have to do instead is store a copy of the background in some other place in RAM, copy it over to erase the previous instance of the blit, and then copy the new instance of the blit. If you do that, then your blit will move smoothly across the screen.
There's another problem. Everytime the screen refreshes, you have a few processor cycles called the vertical blank period. During this time, you can change whatever's in screen RAM without colliding with the video system. If you collide with the video system, you'll get scenes drawn incomplete, and the screen will noticeably flicker. If you can draw your entire scene in the small period of time you get during the vertical blank period, you're golden. However, most scenes require some extra time.
Now we get to the idea of double-buffering. Double-buffering is where you instead of copying blits directly to screen RAM, you copy them to some other location, and then copy that entire area to screen RAM when it's ready, during the vertical blank period. Typically you'd use malloc or somesuch to allocate a block of memory equal to the size you need for the resolution and color depth. Then you'd
do it again. You do it a third time to store the background. Every vertical blank period, the first thing you do is copy the currently active buffer to screen RAM. Then you work on rendering the currently inactive buffer by copying blits and doing all the things you're used to doing by now.
The end result is that you have a smooth display, smooth animation, and no flicker. It's easy on the eyes, and very attractive.
Now, how much of this applies to modern programming?
The answer is "most of it". Anybody who's spent some time in arma's source code looking at how things are rendered will hopefully notice that we use OpenGL's double-buffering capabilities. In the development of hardware acceleration that happened after the Amiga, it became both obvious and possible that putting the double-buffering mechanism in hardware would greatly accelerate graphics. Even today, right this freaking minute, if you write an OpenGL game, the first decision you have to make in your rendering engine is whether or not to double-buffer. Blits nowadays have morphed into textures (semantically, that is), and what was previously called sprites are now handled as blits. X11 gets the common complain that it is *not* double-buffered, and Mac OS X gets loads of praise because it *is* double-buffered. Windows still isn't, and afaik, even with Vista, still isn't double-buffered. That's why you get the horrible flickering when you resize windows.
And finally, to deal with z-man's facetious comment, now that you've read all this and understand it. Sprites continue to exist in hardware! That's true, and crazy, but nevertheless, they are still there. X11 makes the mouse cursor a sprite.
So it really is hardware accelerated even in terms of the olden days. So when z-man says it's a sprite, he ain't kidding you. It really is a sprite. Last I checked, Windows and Mac OS X make it something else, but I could easily (and likely) be wrong about that. Hardware sprites are useless these days, and while they may still exist in hardware, there are more useful ways to achieve acceleration. We can argue all day long over whether or not using a sprite for the mouse cursor is right, but if any of you X11 users have ever wondered about the limited choices of colors and stuff for the mouse cursor, now you know, it's all about sprites.
Anyway, you guys let me know if I missed something. It's possible, this strawberry wine is wonderful.
