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

  • Thread starter Thread starter Wolfvak
  • Start date Start date
  • Views Views 332,019
  • Replies Replies 1,434
  • Likes Likes 75
Status
Not open for further replies.
Last edited by Wolfvak,
Alright, given that you didn't join, I'm gonna assume you're no longer interested in this @4gionz.

Thank you for wasting my fucking time integrating screen init into BootAnim9 while not being able to test it, but rather relying on someone who never showed up.

This is already the second (third?) time this happens, and because of having other background projects (real life being one of them) I can't allow myself to do this kind of crap.
I'm attaching a build with (completely untested) screen init. Due to being not tested and unsupported, I'm not responsible for whatever happens.
Includes compiled binary and sources, not gonna commit to GitHub until I'm sure it works.
 

Attachments

Alright, given that you didn't join, I'm gonna assume you're no longer interested in this @4gionz.

Thank you for wasting my fucking time integrating screen init into BootAnim9 while not being able to test it, but rather relying on someone who never showed up.

This is already the second (third?) time this happens, and because of having other background projects (real life being one of them) I can't allow myself to do this kind of crap.
I'm attaching a build with (completely untested) screen init. Due to being not tested and unsupported, I'm not responsible for whatever happens.
Includes compiled binary and sources, not gonna commit to GitHub until I'm sure it works.
Oh sorry:( I didn't know what you mean when you wrote that message, I have never used irc so I didn't even know really what it meant...and I thought you were sending me there since it says somewhere on the page that your busy with college stuff and it's on hiatus. I'm an idiot sorry man I'm gonna download this build and test it out

Also I hadn't seen your edit with the link to post that clearly states that sorry again

edit2: i tested this version on my non screen init 3ds and it just froze with the blue led on, if you need anything else just tell me. honestly tho if its just gonna waste your time dont bother man i dont NEED this and like i said originally im patient and would prefer not pissing off the dev of a homebrew i like. so anyway this version didnt work for me maybe some else can test it without screen init to confirm.
 
Last edited by 4gionz,
Any chance a version of this could be made that simply loops the animation forever, or even just plays it then powers off the 3ds? I'm using this in combination with arm9loaderhay for a password protected system. I just thought it would be hilarious to have the default payload (loads if you don't press any buttons on boot and does not require a password) just load an animation of the "uh uh uh" screen from Jurassic Park and either just keep looping it or power back down after. I'm not expecting anyone to make this just for a joke like this, but if someone were to do so, that would be amazing.
 
  • Like
Reactions: Wolfvak
...

Getting sick of this
maybe you could add a path fixer, to patch it in memory, I have done this in my latest bootctr9 dev release, and I will upload the source later today, after some code cleanup. Its very simple, nearly only what the pathchanger does, but only inside of the memory.
 
  • Like
Reactions: A_Random_Guy
maybe you could add a path fixer, to patch it in memory, I have done this in my latest bootctr9 dev release, and I will upload the source later today, after some code cleanup. Its very simple, nearly only what the pathchanger does, but only inside of the memory.
Yeah, only problem is that I have to find a way to detect Luma, and I don't want to create payload-specific patches. It's relatively easy, given it's just a UTF-16 string, but I just find it kind of unfair that I have to add code to it. Besides, I don't have write support, so I'd have to patch the payload in memory each time it's loaded, and people are complaining about the speed already, not even caring about the fact that it's not a BA9 issue, but rather a CFW/FIRM one (https://github.com/Wolfvak/BootAnim9/issues/6)
 
Yeah, only problem is that I have to find a way to detect Luma, and I don't want to create payload-specific patches. It's relatively easy, given it's just a UTF-16 string, but I just find it kind of unfair that I have to add code to it. Besides, I don't have write support, so I'd have to patch the payload in memory each time it's loaded, and people are complaining about the speed already, not even caring about the fact that it's not a BA9 issue, but rather a CFW/FIRM one (https://github.com/Wolfvak/BootAnim9/issues/6)
for detection a simple flag file could be used. Maybe in future there will be more cfws that will need a patch like this, that's why I added it, and also because I don't want to patch it every time I update the payload. But yes, the way that the reboot patch works is annoying, and I would have preferred checking the .dat fallback first, to be able to ignore possible problems with bootloaders.

Im also not writing it to the sd, because it should not make any noticeable difference if I search for it every time.
 
for detection a simple flag file could be used. Maybe in future there will be more cfws that will need a patch like this, that's why I added it, and also because I don't want to patch it every time I update the payload. But yes, the way that the reboot patch works is annoying, and I would have preferred checking the .dat fallback first, to be able to ignore possible problems with bootloaders.

Im also not writing it to the sd, because it should not make any noticeable difference if I search for it every time.
I don't really know the internals of Luma that well now, it's changed too much.
Is there any Luma-exclusive flag, something that isn't set *at all* unless you're running Luma (and only Luma)? Or do I have to search arm9payload.bin for "sdmc:/arm9loaderhax.bin" (UTF-16 ofc) every single time?
 
I don't really know the internals of Luma that well now, it's changed too much.
Is there any Luma-exclusive flag, something that isn't set *at all* unless you're running Luma (and only Luma)? Or do I have to search arm9payload.bin for "sdmc:/arm9loaderhax.bin" (UTF-16 ofc) every single time?
I thought about a file that the user can put inside the anim folder, something like fixpath.
and if its available the first appearance of sdmc:/ will be lumas reboot patch. That's how the pathchanger does it.
 
I thought about a file that the user can put inside the anim folder, something like fixpath.
and if its available the first appearance of sdmc:/ will be lumas reboot patch. That's how the pathchanger does it.
Alright, I like that. I'll leave the responsibility to the user, if he fucks up it's definitely not my fault this time at least. One guy even said that my software sucked because it didn't work with Luma :(

I'll get working on it once I fix other issues.
 
This sounds awesome, I will definitely try this when I get the time.






If it doesn't work I will "Sue" you............I love references :P
 
  • Like
Reactions: Wolfvak
Alright, I like that. I'll leave the responsibility to the user, if he fucks up it's definitely not my fault this time at least. One guy even said that my software sucked because it didn't work with Luma :(

I'll get working on it once I fix other issues.
LOL. Don't let these idiots get to you. Not your fault they can't read. It's in this thread how many times? We all appreciate your work! If you are REALLY concerned about people not understanding the whole patch changer thing, maybe just put a big red notice at the top of the main post about it or something idiot-proof like that?
 
This sounds awesome, I will definitely try this when I get the time.






If it doesn't work I will "Sue" you............I love references :P
Please remember to use the path changer if you have Luma installed.
Thanks.

If you are REALLY concerned about people not understanding the whole patch changer thing, maybe just put a big red notice at the top of the main post about it or something idiot-proof like that?

Done. It was big, now it's even bigger and... redder, I guess. I'm not really good at explaining things in a noob-proof way, especially since I don't have control over Luma or ffmpeg. I only provide the main player and @Docmudkipz provided the converter.

Maybe I should provide a small version of ffmpeg that only supports video, with the main video codecs only (h.264, VP8, etc) and GIF. And BGR24 output, of course.
 
Please remember to use the path changer if you have Luma installed.
Thanks.



Done. It was big, now it's even bigger and... redder, I guess. I'm not really good at explaining things in a noob-proof way, especially since I don't have control over Luma or ffmpeg. I only provide the main player and @Docmudkipz provided the converter.

Maybe I should provide a small version of ffmpeg that only supports video, with the main video codecs only (h.264, VP8, etc) and GIF. And BGR24 output, of course.
LOL PERFECT! If people don't get it now, we should all shame and boo them till they leave. Can't get more obvious than the way you have it now. XD
 
Please remember to use the path changer if you have Luma installed.
Thanks.



Done. It was big, now it's even bigger and... redder, I guess. I'm not really good at explaining things in a noob-proof way, especially since I don't have control over Luma or ffmpeg. I only provide the main player and @Docmudkipz provided the converter.

Maybe I should provide a small version of ffmpeg that only supports video, with the main video codecs only (h.264, VP8, etc) and GIF. And BGR24 output, of course.

What do you mean? Does pathchanger come with Luna? And if so what do I change with it?
 
I thought about a file that the user can put inside the anim folder, something like fixpath.
and if its available the first appearance of sdmc:/ will be lumas reboot patch. That's how the pathchanger does it.
Alright, implemented. It requires the user to create a file called 'luma' inside the 'anim' folder. This file doesn't require any special data or something, it's just to indicate BA9's chainloader that we're dealing with Luma3DS.

https://github.com/Wolfvak/BootAnim9/commit/669bf93ab7128b9ab648250a3612adca978f48b8

By the way, I forgot to mention that I also implemented timer support (thanks to you @RednaxelaNnamtra!) and a tiny calibrator, to get the SD card's read speeds.

Once I get compression working, I'll release a new version. That is, if nobody helps me testing screen init of course...

EDIT: I tested it and realized I made an extremely retarded error... I'll fix it in no time
EDIT2: Fix'd
 
Last edited by Wolfvak,
I love it, best homebrew 2016...


But in all seriousness good job, I love this thing :3
 
Alright, I've been working a lot on BootAnim9 v0.6.
Right now it includes:

- Compression (works well for some animations, not so well for others :P)
- Better timer support, framerate is more accurate (it's still limited to the SD read speed)
- Luma payload patching, so you don't have to use the pathchanger
- Overall improved code cleanness

Only thing left to make this a true release would be to include screen init code, so that everyone is able to use it.
But, I need testers, so if you're interested in helping out either PM me or join #BootAnim9 in freenode IRC (here)

Until I don't get screen init working (and update makeanim for the latest version) I won't make a release. You're still free to clone the GitHub repo, compile it and use it, but I won't provide support at all (unless you actually know what's going wrong of course, please don't just say "IT DOESNT WORK WITH SSB/GBA", I'm sick of it).
 
  • Like
Reactions: usagirei
- Compression (works well for some animations, not so well for others :P)
- Better timer support, framerate is more accurate (it's still limited to the SD read speed)
- Luma payload patching, so you don't have to use the pathchanger
- Overall improved code cleanness

I assume also compression helps a bit on the SD-Card Speed issues?
Since you have to read less dat and, the decompression time should be less than a read from the sd, does it give a bit of framerate increase?

EDIT: Maybe pre-fetching the next frame while in a the wait-next-frame loop if its not doing so already too.
 
I assume also compression helps a bit on the SD-Card Speed issues?
Since you have to read less dat and, the decompression time should be less than a read from the sd, does it give a bit of framerate increase?

EDIT: Maybe pre-fetching the next frame while in a the wait-next-frame loop if its not doing so already too.
Compression only works fine on those that actually benefit from it (for example: the GBA bootscreen, PSX bootscreen, animations with little movement, etc)

I'm currently not doing it, and I think it could improve the quality (maybe, maybe not)

"the decompression time should be less than a read from the sd" <- again, this depends on the animation. I perform no way of dithering whatsoever, so animations with a lot of movement will be badly compressed (the MH4U animation compressed down to 14MB but is horrible to use, really laggy)
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum