load81 wrote:
* I know that today, given a cross development environment like 64tass or Acme, most programmers loop over their sprite data files and build the sprite in memory. I've even see the technique but now that I'm looking for an example of it I can't find it. Can someone point me in the right direction?
Regarding this question, I'm not exactly sure of the scenario you're describing. There's a few cases where something like this might happen:
- Many programs use stock compression or linker utilities like exomizer, which can copy binary data to various areas of RAM. You tell the compressor which binaries you want to load in where, and it packs it all together into 1 executable that will decompress all the data to where it needs to be. So this can have program code in one place, data in another, and drop sprite data right in the proper locations for immediate display.
- The VIC-II chip only can see 16KB of memory at once, so if you have a lot of sprite frames, all of them might not fit simultaneously in a VIC-II bank along with fonts, character screens, bitmap screens, etc, and only those which are currently needed get copied into the VIC-II's view.
- It's kind of wasteful to have horizontally flipped versions of all your animation frames, so copying them in manually allows you to perform inline transformations on them, instead of just pointing to different statically defined frames.
- Keeping sprites compressed in RAM (like only storing 8x8 pixel sprite data for bullets or something) and decompressing them into full 63-byte sprite frames as needed can save a lot of memory footprint.