weirdami wrote:
pyrre wrote:
But it still looks awesome
Only Amiga makes it possible. :-D
Hardly...
In actuality anything that can plot on the screen can do it, just no hardware accelerator: done by the CPU.
As for the size issue, as Piru mentions, it's pretty standard stuff. For each polygon with N corners you need 2 coordinates, an X and a Y. That can be stuffed in 2 bytes each (so 4 bytes) or you can do 1 byte each because of the low resolution (<255). You can also do compression on those (so effectively having less than 1 byte per coordinate), like a lzh/hoffman type stuff. Finally you don't need the coordinates for each frame because you can use animation/tweening/interpolation to move a certain corner from location A to location B. That's HUGE savings.
An example of a great game that was really small, yet pretty awesome, and used the same techniques: Out Of This World / Another World.
As correctly stated by SamuraiCrow, you can very easily stuff lots of data that are 1 plane because each pixel is represented by 1 bit, which means that an entire bit plane of 320x240 pixels is 320*240/8 bytes. Pretty small. Furthermore, you'd typically use Run Length Encoding (RLE) which is very simple but gives huge savings. A simple version goes like this: if you have a 'run' of 20 pixels in the ON state and then 40 pixels in the OFF state (see-through) and then 30 more pixels in the ON state, then you could take 3 bytes to describe it: 20,40,30 and your code would interpret those as 'runs', now, if the next byte was a 0 for example, you could use that as a special 'key' to denote that the next few bytes won't be runs, but individual pixel values, so the next 1 byte could have alternating pixels, which would look like: 10101010, which in decimal would be: 170 and NOT 170 pixels in a row (that would be a 'run' and wouldn't have a leading byte of value 0).
All in all, demos fscking rule! And the Amiga demos are some of the sweetest!
