Malcolm Lear makes some magical things to make me read } With large sprites you can reduce flicker significantly by combining the } background redraw } and sprite data in memory and write the lot to screen in one go. This } eliminates the problem } of writing to screen memory twice where the old and new sprite positions } overlap. }
Beware if you intend to use high-colour, or even non-native mode sprite (such as mode 4 in high colour). The automatic adaptation made by GD2 is nice but limited to about 60x60 (a little more, but not a lot). No size problem normally with sprite in the exact mode of the screen. But if you intend portablity, that means have the sprite in all the possible mode. (Q40 and QPC2 have different ones!) (I have some converting code which can be used to set the sprite definition according to the machine it is running on, allowing to store only once the high-colour definition, and adapting at launchtime to Q40 or QPC2). Also, if you intend to foolishly use the same sprite structure, just changing the actual data (not the pointer, but the real data bytes), there is a cache mechanisms which may provide some debugging fun (NOT). For instance, using a pattern of 1 pixel and a blob of whatever size you want, if you just change the actual pixel colour by writing the colour in the pattern data, it won't be taken into account UNLESS you draw some other things before (because otherwise, the pattern is assumed to be in the cache, thus, the conversion is not refreshed and you keep getting the old colour!!). You can also alternate between two patterns, which waste less cpu.
