SGDK 1.4 embed a new resource compiler tool (rescomp) which has been rewrote in Java (offering many advantages compared to C).
One of the major change with this new resource compiler is the automatic sprite cutting / optimization. In older SGDK version, the resource compiler was doing dumb sprite cutting operation and that was wasting many both VRAM (Video Memory) space and DMA capacity (we can barely transfer 7 KB of data per frame with the DMA so it's important to not waste it).
Take this example, we have 3 different sprites (meta sprite) that we want to cut in smaller hardware sprite as the Megadrive VDP can display sprites going from 8x8 to 32x32 pixels maximum (supporting any combination in between in 8 pixels step).
The old rescomp was simply filling the sprite cell sheet with big 32x32 sprites and using smaller sprites only on edge :
It was efficient in term of number of hardware sprites but definitely a big waste for the number of tile (8x8 pixels block), and so in VRAM usage and DMA capacity !
With the new rescomp tool, sprites are now optimized and using the default and fast optimization method (privileging tiles reduction) you will obtain that result :
The number of hardware sprites is generally higher but the number of tiles is reduced a lot. For Cody example, we increased the number of hard sprites from 6 to 11 but we reduced the number of tile from 96 to 55.
There is also a strategy where we privilege the number of hard sprites (but at the cost of more used tiles), in this case the fast optimization gives 6 hard sprites with 65 tiles (i didn't showed the result here).
Still sprite cutting optimization is not a trivial task and sometime the fast optimization method doesn't provide good enough results, it's why there is an alternate slow method (using genetic algorithm) to help improving automatic sprite cutting. Here's the result using that method :
By default the slow method try to provide a good compromise between the number of hardware sprite and the number of tile. As you can see, there is not much to do about Sonic sprite so result didn't changed from previous method, but it changed quite a bit on Cody and Guy sprites. Cody is now using 9 hard sprites and 52 tiles (solution found in 200000 iterations) while Guy requires 7 hard sprites and 61 tiles. Note that the solution for Guy was after 2000000 iterations (require almost 10 second of processing on my computer) ! Still you generally don't need that much, a solution with 8 hard sprites and 60 tiles was found with 200000 iterations (1 second of computation)
Right now rescomp tool automatically choose the strategy to adopt but later i plan to let more control about sprite cutting strategy from the resource definition.