What is the real power of Akiko chip in cd32 ?

[Crumb]

@Piru

I lack knowledge about how Akiko works but wouldn't it allow the coder to write directly to chipmem groups of 8-32 pixels without relying in a chunkybuffer? wouldn't akiko work as a small buffer that converts chunkypixels to bitplanes? something like that perhaps would allow optimizing chipmem access more. I guess that writting to a chunkybuffer and later copying to chipmem may not be as fast as writting directly to chipmem.

[Crumb]

An interesting note, with my recent port of ScummVM over to AGA (which uses the chipset for double buffering, all of the graphics are generated as chunky screen in FASTRAM) I've found that most speed limitations are not with the AGA chipset, C2P or even the slow bus....it's normally my 030 which is too slow to generate the chunky screen in time.   This is true up to 320x200 8bit, for SuperVGA (640x480 8bit) the AGA chipset/bus speed/C2P lets the side down and you really need to use RTG

Depending on the game it may be more effective to use graphics.library calls and avoid chunky2planar completely.

Using AmigaOS functions instead of using the miggy like a dumb framebuffer would bring advantages, e.g. screenshake can be done without problems with AmigaOS functions like ScrollVPort(), there's no need to copy memory as that slows down the system without any need.