LZ Compression works, used the ban9comp.exe I built from d0k3. Doesn't seem to really improve performance for my logos, though (like you said, some benefit, some get worse.)
i liked it better when it lasted the length of the longest anim (ex. short bottom, held out last frame until longer top finished), now it exits when the shortest anim finishes.
Delta screen updates would be smart, like someone mentioned before. The left-to-right look when clearing the screen at the end, it shows how slow setting all those pixels is (btw, why we seeing that? Isn't it possible to swap screen buffers and have that be a faster transition?)
Anyways, good job on bootanim9, I've used it since day 1, it's great.
Actually, that's not a bad idea at all: prior to displaying any animation whatsoever, set up a memory space (288000 bytes long to be precise) full of 0x00's and switch both fb addresses to point to that memory space; the change should be nearly instanatenous. Meanwhile, I just clear up the "real" fb addresses and switch back to that one. Good thing that it can be done within the ARM9, I'll give it a shot once I have some time.
And yes, the compressed animations will be slower. I've been discussing with
@Docmudkipz and one of the solutions that came up was to actually call ffmpeg with half (or less) the framerate specified, effectively performing frameskipping (more that regular frameskipping) and making it as close as possible to an uncompressed one as far as speed goes, with the added benefit of compression.
Another one which came up while talking to d0k3 was not to allow animations above a certain size threshold to be played back (in my experiments, 35-40% of the original size appeared to be the limit for top screen).
Also, check
this out, it's the version of animation_loop() that I currently use which plays both animations until *both* of them have finished (ofc, if both animations were found).
I guess you should be able to replace it in the current version that is in GitHub, I almost didn't realize it and can currently be considered a bug (a fixed one privately, but still a bug)
If you meant my implementation, i left it
there and will leave it there in case he ever wants to give it a shot and see how it works in comparison with the current method.
It should be faster for animations with localized animation areas, since you don't update the whole screen but just portions of it, but i'm not sure how fast the 3ds handles non-linear memory block write operations, since its writing like, 8 times per block 24 bytes at a time on the 8x8 block mode.
It should be less cpu intensive since it doesn't use compressing but rather just outright skips pieces of data that haven't changed.
But all said and done, it has to be tested on an actual device, and he's seemingly busy with the screen-init stuff for now.
Sorry I haven't looked too much into your implementation, it's just that d0k3's came way earlier (over 20 days ago) and I had promised him to implement it, but real life got in the way. Once I was able to get back to my hobbies, yours came up but I had already studied d0k3's and decided to go with his.
Again, sorry
Also, I'm not really able to test screen init since I'm too much of a pussy when it comes to updating payloads, so I'm currently performing screen init over an already screen-init enabled stage2. It appears to work fine, but until I can test with a regular no screen-init stage2, I can't tell for sure.
If anyone wants to test and doesn't have a screen init a9lh stage2, please let me know.
It'd help inmensely, not only me but the whole project, since it's the biggest out of the few issues I still want to fix for v0.6.
Besides, it isn't really "testing", it's more like, copy a few files and tell me if it works or not, I don't need to test a huge amount of different scenarios.
EDIT: I'm also working on a "manager" of sorts, just a simple 3dsx that can display the animations. That's also one of the things I intend to release alongside v0.6
