|
Just a word or two regarding performance...
The total number of pixels displayed by a copperscreen display is limited by the speed of the copper itself.
The copper can do approx. 57 MOVEs per scanline in normal 15kHz PAL/NTSC resolutions.
This means that if you want to have chunky-pixels that are 2 scanlines high, you can have up to 114 chunky-pixels horizontally.
If you want to have chunky-pixels that are 3 scanlines high, you can have up to 128 chunky-pixels horizontally. (You'll stop at 128 since you're double-buffering the palette.)
This means that the best resolution you'll get for a full-screen copperscreen is 2.5x3 pixelsize.
If you have a copperscreen at a high resolution, the copper will consume a lot of your chipmem bandwidth too. If you target 68030+ then you are probably better off with a C2P based solution.
Chipmem write bandwidth: ~7MB/s
Fastmem read bandwidth, Blizzard 1230: ~30MB/s
Fastmem read bandwidth, Blizzard 1260: ~35MB/s
You'll want to do all rendering to a temporary buffer in fastmem, and once that is done you c2p convert the result into chipmem. (You can do some improvements on the scheme, but that's the gist of it.)
Let's presume that you want to render 320x200 chunkypixels, at 1x1 pixelsize.
320x200x8bpl of graphics data = 64000 bytes of data.
Copying 64kB of data fast->chip takes roughly 15ms (i.e. 75% of a frame).
35MB/s read speed for fastmem translates into 700kB/frame. Considering that you will be reading & writing 64kB just for the *screen writes* (assumiung no overdraw), you are going to consume considerably more bandwidth than that on datacache misses for the texture accesses.
That's why you haven't seen a lot of really smooth 1x1 full-on 3d graphics in games on the miggy. [In demos it's easier, since there you can tweak the camera and the environment until the performance target has been achieved.]
|