Nyh wrote:If got very decent sprite routines with preshifted data, you can do 44 different masked 16x16 sprites with 16 colours.
This is the data that I wanted to hear ! However, it seems a little bit low to me at first sight, but I`m not yet familiar with the platform.
To put it into other perspective, 16x16x44 = 11264 pixels. Which is almost the same as 32x70x5 (I want tall sprites, maybe not 32x70, but close to it). But this would mean that I`d be able to change only 5 frames per second. That is, if I understand the data above correctly, and they mean the performance (16x16x44) per second.
On an Atari you don't count the number of pixels in a sprite but the number of words. The 9 pixel on a low resolution Atari screen is made up from bit nr 6 of the 1st word, bit nr 6 of the 2nd word, bit nr 6 of the 3rd word and bit nr 6 of the 4 th word. A pixel has also 4 bitplanes, 16 different values so one color of a palette from 16. With the 32 bit registers of the 68000 you can work at 2 words of screen memory at the same time. Because of the word wise organization of the screen memory a 16 bit wide sprite usually is in 2 x 4 words of screen memory, unless it is exactly aligned with a word, then it takes only 1 x 4 words.
You don't understand the data correctly, the performance is in number of sprites per VBL (Vertical BLank) at 50 Hz, ie 50 frames per second. For your 32 bit wide sprites you need about 336 clocks per line so for a 32x70 sprite you need 23520 clocks. Given 160000 clocks per VBL you can do 6 sprites of that size in 1 VBL (50 frames per second).
Nyh wrote:A single 16x16 preshifted sprite uses 4 kB memory for the sprite data and 2 kB memory for the mask data.
So, that`s 6 KBs per 16x16 chunk. Say, I need 6 chunks per one animation frame of my character (32x48), i.e. 36 KBs per animation frame. I`ll eat up 0.1 MB of memory with just 3 frames. If I wanted at least 4 animations (Breathe,Walk,Attack,Death) with at least 5 frames per each, that would be 5x4x36 = 0.7 MB per character.
For a preshifted sprite you will need:
For a 32x48 sprite you will need (32 pixels is 2 words):
You can safe a lot of memory by not preshifting a sprite at 16 pixels, but only 8, cutting memory usage in half, but the sprite then only can be placed at even pixel positions.
master wrote:So, that`s impossible unless I limit it to emulator use, where I heard it`s possible to use 4 MB of RAM (if I heard correctly). Though that would sort-of kill the original idea of a game runnable on regular Atari 1040 ST.
How many people have upgraded their Atari to 4 MBs ? Would that annoy many people if the game wanted 4 MB of RAM ? Or maybe, I can altogether just forget this issue and take 4 MB for granted ?
No, you can take 1 Mb for granted.
Nyh wrote:Note there is no time alloted for restoring the background, building the playfield or clearing the screen...
That`s actually great, because you provided me with data under extreme cirumstances, so I`ve got a fantastic reference point to measure with. And, most importantly, to set my initial expectancies quality and performance-wise.
There are some possibilities to get some more speed by clever use of movem to load data into registers but I didn't allot any time for setup and sprite management. So I think my calculations are pretty close to the upper limits.
master wrote:A little rant - this is pretty different from PC world, where I`m used to polygonal characters which can compress fantastically. My current compression ratio is around 12:1, since vectors are easily quantizable. Plus, I have interpolation between frames, so the smaller amounts of frames changes just the perception of quality, but not the actual quality - it`s always smooth.
Here, it`s different. I can`t interpolate between 2D frames. Sure, I could store just the data that are different, but if I limit myself to just 4-5 frames per animation, there`s little amount of RAM that I`ll reuse between frames anyway - the actual frames are going to be pretty different one from another.
Yes, on the Atari it is an entirely different ballgame. Not a lot of memory and not a lot of processor cycles to be burned. Although the amount of memory is huge compared to the good old ZX Spectrum or C64, it is just small compared to the amount of memory in modern PC's. The secret of a good game is not a huge amount of eye candy but a good game play.
master wrote:Any ideas, besides lowering the size of sprites ?
Cheat, cheat a lot without the user noticing it. Use less colors, limit sprite sizes and possible sprite positions in clever ways, go for simplicity and fun.
Look at games of Jeff Minter and understand what I am talking about. Playability is not proportional with sprite size, usually it is the other way around.