Homebrew [RELEASE] BootAnim9 - Custom boot animations for your 3DS!

  • Thread starter Thread starter Wolfvak
  • Start date Start date
  • Views Views 329,271
  • Replies Replies 1,434
  • Likes Likes 75
Status
Not open for further replies.
I'm getting a slideshow effect between frames when the animation plays on boot. Can anyone help with this?
You either didn't properly convert the resolution of your video to the resolution of the console or you didn't input the correct fps for the video.
 
You either didn't properly convert the resolution of your video to the resolution of the console or you didn't input the correct fps for the video.
Okay so let me ask something potentially stupid:
How do you detect the framerate of a .gif? Or do I just keep messing around with the tool until I get it right?
 
Okay so let me ask something potentially stupid:
How do you detect the framerate of a .gif? Or do I just keep messing around with the tool until I get it right?
open a cmd in the directory of the image and use "ffmpeg -i (image.gif)". It should tell you as much info as you need about the file including framerate
 
open a cmd in the directory of the image and use "ffmpeg -i (image.gif)". It should tell you as much info as you need about the file including framerate

That's actually technically incorrect. Frame rate is variable on gifs - delays are set per-frame, not whole-file. Then again, ffmpeg averages this while converting, so whatever it gives is 'good enough'
 
Alright I've been thinking of redoing the config format, which will be separated by spaces in the future (char 0x20).

It'll also have the framerate as regular ascii text for better readability, and will be renamed to config.txt (since it's regular text now).
I have no idea on how to handle the compression flag, since putting "1" is counter intuitive with text. I might do something like "raw", "d0k3" instead.
I'm open for suggestions here, and to clarify, with the new format it'd be something like
Code:
30 raw
or
Code:
15 d0k3
 
  • Like
Reactions: chaoskagami
Alright I've been thinking of redoing the config format, which will be separated by spaces in the future (char 0x20).

It'll also have the framerate as regular ascii text for better readability, and will be renamed to config.txt (since it's regular text now).
I have no idea on how to handle the compression flag, since putting "1" is counter intuitive with text. I might do something like "raw", "d0k3" instead.
I'm open for suggestions here, and to clarify, with the new format it'd be something like
Code:
30 raw
or
Code:
15 d0k3

Why should we even need to specify raw? Abscense of a compression type could just be treated as raw. I'd also recommend calling it 'lzd' or something, since lz+delta is pretty common, and I mistype d0k3 as d03k so often only to correct myself before posting (no offense intended, d0k3!)
 
Last edited by chaoskagami,
Why should we even need to specify raw? Abscense of a compression type could just be treated as raw. I'd also recommend calling it 'lzd' or something, since lz+delta is pretty common, and I mistype d0k3 as d03k so often only to correct myself before posting (no offense intended, d0k3!)
Well, I obviously treat unspecified compression as none, that's the default (as always). On the other hand "lzd" does sound better. Hopefully people are smart enough to fully read the instructions.

(BTW your signature appears to be kill @chaoskagami, at least for me)
 
Now it works.... and currently using Chromium.
Alright, format works fine, but I'd like to implement screen init and double buffering too... which imply working with the ARM11... ugh.
Since I'll have my second mid-term tests starting this Saturday (and also the next two Saturdays), this will be just *a bit* delayed.

I've also wanted to restructure a small section of BA9: currently I'm wasting a lot of space because my main payload loads a chainloader, both using FatFS, so 5KB wasted. Maybe I should copy the chainloaded payload (arm9payload.bin) to a temp location in memory, and then use the chainloader to copy from that temp location to 0x23F00000, which is the regular location for non-GW payloads (those fuckers did some weird shit).
 
  • Like
Reactions: pbanj
Now it works.... and currently using Chromium.
Alright, format works fine, but I'd like to implement screen init and double buffering too... which imply working with the ARM11... ugh.
Since I'll have my second mid-term tests starting this Saturday (and also the next two Saturdays), this will be just *a bit* delayed.

I've also wanted to restructure a small section of BA9: currently I'm wasting a lot of space because my main payload loads a chainloader, both using FatFS, so 5KB wasted. Maybe I should copy the chainloaded payload (arm9payload.bin) to a temp location in memory, and then use the chainloader to copy from that temp location to 0x23F00000, which is the regular location for non-GW payloads (those fuckers did some weird shit).

Double buffering is unlikely to help the tearing situation much. In the original implementation, it still had screen tearing when you were doing a memory -> memory copy.

I handle chainloading like that in my CFW, incidentally - with additional argument passing. License is incompatible between our repos, but feel free to use my code as a reference. I don't really care. ;)

...Aaaand now I know why gateway payloads break. What's their origin in memory? IMO we all should be using PIE/PIC binaries but w/e
 
Last edited by chaoskagami,
...Aaaand now I know why gateway payloads break. What's their origin in memory?
Well, Launcher.dat has a really weird origin, but GWs arm9loaderhax.bin *should* work fine. It's probably an error in how they manage the MPU, or a cache error (on their side). In any case, try flushing the cache right before you jump to their payload.
 
Well, Launcher.dat has a really weird origin, but GWs arm9loaderhax.bin *should* work fine. It's probably an error in how they manage the MPU, or a cache error (on their side). In any case, try flushing the cache right before you jump to their payload.

Both D-Cache and I-Cache are flushed before a branch and it doesn't work, actually. It's the ONLY payload that doesn't work. I had to fix the cache errors because my start.s is different from every one on the planet and cache errors otherwise.

(That really weird origin on Launcher is because it's virtual arm11, not physical.)
 
Last edited by chaoskagami,
Both D-Cache and I-Cache are flushed before a branch and it doesn't work, actually. It's the ONLY payload that doesn't work.
Let's just wait until Brickway™ unleashes their shitty extremely reliable implementation of arm9loaderhax Gateway™ FAST BOOT™

On another note, if someone here knows their ARM11 stuff, a PR to add screen init would be greatly appreciated :)
 
  • Like
Reactions: pbanj
Let's just wait until Brickway™ unleashes their shitty extremely reliable implementation of arm9loaderhax Gateway™ FAST BOOT™

On another note, if someone here knows their ARM11 stuff, a PR to add screen init would be greatly appreciated :)

They can't even copy the right code, heh. I doubt there will be more stability. More like explosive bricking.

I would, but all the screeninit implementations are GPLv3 (and banim9 is GPLv2 only.) I mean, there's really no other way to implement it, but I like to pay attention to this stuff.
 
Last edited by chaoskagami,
They can't even copy the right code, heh. I doubt there will be more stability. More like explosive bricking.

I would, but all the screeninit implementations are GPLv3 (and banim9 is GPLv2 only.) I mean, there's really no other way to implement it, but I like to pay attention to this stuff.
DAMMIT STALLMAN

Well, at least it gives me a good reason to properly learn assembly, I guess.
 
  • Like
Reactions: chaoskagami
DAMMIT STALLMAN

Well, at least it gives me a good reason to properly learn assembly, I guess.

Assembly is fun. Writing stuff in assembly will near almost always be less than half the size of GCC-generated code (even on -Os)
 
Making every anim to 30 fps still doesnt make it faster, oh well, it's still nice to look even though they seem to be on slow motion.
 
Making every anim to 30 fps still doesnt make it faster, oh well, it's still nice to look even though they seem to be on slow motion.

Are you sure you encoded to raw frames at 30 FPS and not 30 SPF (is that even a thing? Seconds per frame?)
 
Are you sure you encoded to raw frames at 30 FPS and not 30 SPF (is that even a thing? Seconds per frame?)

I only added config files to anims like the sony one which was very slow imo. I didn't render myself new animations.
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum