Yeah, that's exactly it!tepples wrote:What you describe is the clairvoyant algorithm, which can't run in real time but is optimal when run offline: "When a [value] needs to be swapped in, the [compiler] swaps out the [value] whose next use will occur farthest in the future."
That's a pretty good idea! The difficult part would be deciding whether to use the accumulator or an index register to load a new value, since you'd have to predict what kind of modifications that value would go through in the future.I wonder to what extent you can save bytes by planning out which values can be calculated with ASL/LSR/ROL/ROR (and thus kept in A) or with DEX/INX/DEY/INY (and thus kept in X or Y).
But then the background animations might feel laggy.Bregalad wrote:Then give the main character's animation update higher priority.
Certainly not every frame, but some effects (quick attacks, visual deformations, etc.) would need new graphics every other frame.Does the player change frame every frame ? No, very unlikely, even if you have very detailed graphics frames of animation will last at least 4 hardware frames.
In addition to the main character, I have to animate waterfalls, flowers, power ups, and other background objects. These will probably animate at a steady rate of 15 frames per second, and since there could easily be 4 of these animated items in a level it would be tough if everything had to share 1 slot. Still, I don't have the RAM to hold patterns, so for me this isn't an option anyway.Unless you use re-writable patterns for all enemies/whathever, but that would not be a good idea on the NES anyway.
My rule is that the "compressed" code can't take longer to execute than the raw LDA STA chain. I'm considering making the encoder count how many cycles it saves by not loading values that were already in one of the registers and use those cycles for extra compression (such as using subroutines for longer repeated patterns). JRS + RTS takes 12 cycles, so only after avoiding 6 load operations I would be able to call a subroutine once (obviously, any savings inside the subroutine will be counted as many times as the routine is called).tepples wrote:As I understand the problem that tokumaru stated, we're trying to minimize cycles first and then break ties by minimizing bytes.