Does it mean the boot time will be extended by the whole duration of the animation? Or does it only take the time to load the animation and the system loads other things while the animation is playing?
- Status
However long the animation is, that's how long your boot time is. So it's best to stick with shorter ones
D
Deleted User
Guest
I guess you could duel boot this with ctrboot9 if you really need a bottom screen animation if you want to run this with a older cfw that supports .bin
Last edited by ,
Yes, it increases it by about 250ms + the length of the animation. There's simply no way around this.
As I've said *several* times before, the point of BA9/BAX wasn't to make long animations, just short things. Especially considering the size of the resulting animation file, which is ((top frames*192000) + (bottom frames * 153600) + 128) bytes long. In average, this results in a ~30MiB file.
Honestly, I don't plan to support plain binaries, ELF or FIRM is a far superior container for them as it allows relocation and other fancy stuff.
Last edited by Wolfvak,
Small progress update: I've been sick for a couple of days now and haven't been able to really focus on the main project, so instead I made a simple .NET application that takes in framebuffer dumps and converts them to a BAX animation. I chose .NET because despite my dislike for bytecode interpreters/recompilers, it's portable and thanks to the Mono project, works on all main platforms (Windows, *nix, OSX(?)). It can work both as a GUI application and a console app, in case anyone decides to do batch processing with it. The GUI version supports drag and drop operations, with screen autodetection.
I've tested it under Windows XP Professional 32-bit, Windows 7 Ultimate 64-bit, Debian buster amd64 and Debian stretch mipsel, so it *should* work fine on anything that's somewhat modern.
This brings me to the second issue, the good ol' screen initialization procedure. Now, I haven't been following the scene too closely but from what people told me the framebuffers are passed through R2 to the payload, which severely limits flexibility. For example, BAX uses RGB565 framebuffers to shrink down the IO load (2 bytes per pixel instead of 3, simple math would tell you this is 1.5x faster but realistically the number is more like 1.2-1.3x), but, without writing my own screen init, I'm kinda fucked.
Considering there's already a perfectly good screen initialization being performed already, I think it'd be a better idea to select certain initialization parameters (screen init, N3DS extra RAM, caches, etc) to be selected through the FIRM reserved bytes in a way that b9s can understand them and act accordingly. Of course, this is not currently a thing, which sucks.
Another issue lays in the chainloading: having every application have it's own FIRM loader, probably with some inconsistencies between them is a terrible idea, and I think it'd be better to leave b9s handle those and call it somehow whenever an application requires to chainload (pretty much all current ARM9 applications have to chainload sooner or later, only alternative is to reboot). A clear way to do it would be using the Software Interrupt feature or maybe just having a "kernel function entrypoint".
Overall, BAX is already finished, the only issues remaining are screen init and the chainloading thing. It would be really simple to just add my own, but personally I think it'd be better for everyone to have something similar to what I just described. Until these are fixed/worked around, I don't think I'll be able to release anything - at least not the way I intended.
I've tested it under Windows XP Professional 32-bit, Windows 7 Ultimate 64-bit, Debian buster amd64 and Debian stretch mipsel, so it *should* work fine on anything that's somewhat modern.
This brings me to the second issue, the good ol' screen initialization procedure. Now, I haven't been following the scene too closely but from what people told me the framebuffers are passed through R2 to the payload, which severely limits flexibility. For example, BAX uses RGB565 framebuffers to shrink down the IO load (2 bytes per pixel instead of 3, simple math would tell you this is 1.5x faster but realistically the number is more like 1.2-1.3x), but, without writing my own screen init, I'm kinda fucked.
Considering there's already a perfectly good screen initialization being performed already, I think it'd be a better idea to select certain initialization parameters (screen init, N3DS extra RAM, caches, etc) to be selected through the FIRM reserved bytes in a way that b9s can understand them and act accordingly. Of course, this is not currently a thing, which sucks.
Another issue lays in the chainloading: having every application have it's own FIRM loader, probably with some inconsistencies between them is a terrible idea, and I think it'd be better to leave b9s handle those and call it somehow whenever an application requires to chainload (pretty much all current ARM9 applications have to chainload sooner or later, only alternative is to reboot). A clear way to do it would be using the Software Interrupt feature or maybe just having a "kernel function entrypoint".
Overall, BAX is already finished, the only issues remaining are screen init and the chainloading thing. It would be really simple to just add my own, but personally I think it'd be better for everyone to have something similar to what I just described. Until these are fixed/worked around, I don't think I'll be able to release anything - at least not the way I intended.
Probably a stupid question but what is BAX?Small progress update: I've been sick for a couple of days now and haven't been able to really focus on the main project, so instead I made a simple .NET application that takes in framebuffer dumps and converts them to a BAX animation. I chose .NET because despite my dislike for bytecode interpreters/recompilers, it's portable and thanks to the Mono project, works on all main platforms (Windows, *nix, OSX(?)). It can work both as a GUI application and a console app, in case anyone decides to do batch processing with it. The GUI version supports drag and drop operations, with screen autodetection.
I've tested it under Windows XP Professional 32-bit, Windows 7 Ultimate 64-bit, Debian buster amd64 and Debian stretch mipsel, so it *should* work fine on anything that's somewhat modern.
This brings me to the second issue, the good ol' screen initialization procedure. Now, I haven't been following the scene too closely but from what people told me the framebuffers are passed through R2 to the payload, which severely limits flexibility. For example, BAX uses RGB565 framebuffers to shrink down the IO load (2 bytes per pixel instead of 3, simple math would tell you this is 1.5x faster but realistically the number is more like 1.2-1.3x), but, without writing my own screen init, I'm kinda fucked.
Considering there's already a perfectly good screen initialization being performed already, I think it'd be a better idea to select certain initialization parameters (screen init, N3DS extra RAM, caches, etc) to be selected through the FIRM reserved bytes in a way that b9s can understand them and act accordingly. Of course, this is not currently a thing, which sucks.
Another issue lays in the chainloading: having every application have it's own FIRM loader, probably with some inconsistencies between them is a terrible idea, and I think it'd be better to leave b9s handle those and call it somehow whenever an application requires to chainload (pretty much all current ARM9 applications have to chainload sooner or later, only alternative is to reboot). A clear way to do it would be using the Software Interrupt feature or maybe just having a "kernel function entrypoint".
Overall, BAX is already finished, the only issues remaining are screen init and the chainloading thing. It would be really simple to just add my own, but personally I think it'd be better for everyone to have something similar to what I just described. Until these are fixed/worked around, I don't think I'll be able to release anything - at least not the way I intended.
I know no one likes when people ask these kind of questions, but it has been quite a few months since we've heard anything. Any new news on this yet?Small progress update: I've been sick for a couple of days now and haven't been able to really focus on the main project, so instead I made a simple .NET application that takes in framebuffer dumps and converts them to a BAX animation. I chose .NET because despite my dislike for bytecode interpreters/recompilers, it's portable and thanks to the Mono project, works on all main platforms (Windows, *nix, OSX(?)). It can work both as a GUI application and a console app, in case anyone decides to do batch processing with it. The GUI version supports drag and drop operations, with screen autodetection.
I've tested it under Windows XP Professional 32-bit, Windows 7 Ultimate 64-bit, Debian buster amd64 and Debian stretch mipsel, so it *should* work fine on anything that's somewhat modern.
This brings me to the second issue, the good ol' screen initialization procedure. Now, I haven't been following the scene too closely but from what people told me the framebuffers are passed through R2 to the payload, which severely limits flexibility. For example, BAX uses RGB565 framebuffers to shrink down the IO load (2 bytes per pixel instead of 3, simple math would tell you this is 1.5x faster but realistically the number is more like 1.2-1.3x), but, without writing my own screen init, I'm kinda fucked.
Considering there's already a perfectly good screen initialization being performed already, I think it'd be a better idea to select certain initialization parameters (screen init, N3DS extra RAM, caches, etc) to be selected through the FIRM reserved bytes in a way that b9s can understand them and act accordingly. Of course, this is not currently a thing, which sucks.
Another issue lays in the chainloading: having every application have it's own FIRM loader, probably with some inconsistencies between them is a terrible idea, and I think it'd be better to leave b9s handle those and call it somehow whenever an application requires to chainload (pretty much all current ARM9 applications have to chainload sooner or later, only alternative is to reboot). A clear way to do it would be using the Software Interrupt feature or maybe just having a "kernel function entrypoint".
Overall, BAX is already finished, the only issues remaining are screen init and the chainloading thing. It would be really simple to just add my own, but personally I think it'd be better for everyone to have something similar to what I just described. Until these are fixed/worked around, I don't think I'll be able to release anything - at least not the way I intended.
D
Deleted User
Guest
You could use this, it supports animations on boot: https://gbatemp.net/threads/release-ctrbootmanager-ctrbootmanager9.431647/
I believe there's a tutorial out there to set it up to work similarly to BootAnim9, but keep in mind, it'll only work on the top screen AFAIK.
Yeah i was wondering if this ever got an update boot.firm since Luma got the 9.0 update it removed my animation
D
Deleted User
Guest
How did you go about updating Luma? If you used Luma3DS Updater (aka the updater you should have installed with the guide) and didn't have Luma as your default boot.firm payload beforehand, then it simply replaced your old payload with the newest version of Luma.
Ah I see something simple I overlooked just had to rename Luma 9.0's boot.firm into bootluma.firm
Last edited by MasterJ360,
, Reason: can't spell
Complete rewrite of BootAnim9.
Speaking of which... it's kinda done already, I'll probably upload some videos tomorrow or the day after, but I've hit a block with the animation transcoder.
Basically, libav is a bit of a mess to work with so unless I find an alternative library to decode video frames to raw RGB data I'll have to rely on scripts that use ffmpeg and other utils rather than a full self-contained utility that can do everything (video decompression, delta encoding, transposing, compression, BAX file creation).
So, I'm mostly just posting here asking for suggestions - whether they are about better video libraries or whatever else. Thanks for reading, I guess. Good to see some people are still interested in a concept like this.
The repo will eventually be made public @ gitlab.com/Wolfvak/BAX
Common sense would denote "yes".
Paraphrased from the README: "This requires a loader that provides services compatible to those from boot9strap v1.2."
Haven't tested Luma 9 but I'm pretty sure it'll work, I've thrown some really weird FIRMs at my loader and it hasn't let me down yet.
Haven't tested Luma 9 but I'm pretty sure it'll work, I've thrown some really weird FIRMs at my loader and it hasn't let me down yet.
Alright, second update.
I've decided to go with IVF/VP8/9 only to escape the hell that is libav programming. You can easily convert any video to IVF with ffmpeg anyway, so I don't think it's a big deal.
I hope to have a release by late February, so as a sort of preview I'll post the README I have planned - any suggestions/questions about it is well received, as always.
https://gist.github.com/Wolfvak/a763a876d0a76ca653c79272248bbb8a <- main BAX readme
https://gist.github.com/Wolfvak/59a0cba1b45271998e61e4eeee4ba72f <- makebax readme
I've decided to go with IVF/VP8/9 only to escape the hell that is libav programming. You can easily convert any video to IVF with ffmpeg anyway, so I don't think it's a big deal.
I hope to have a release by late February, so as a sort of preview I'll post the README I have planned - any suggestions/questions about it is well received, as always.
https://gist.github.com/Wolfvak/a763a876d0a76ca653c79272248bbb8a <- main BAX readme
https://gist.github.com/Wolfvak/59a0cba1b45271998e61e4eeee4ba72f <- makebax readme
Last edited by Wolfvak,
Depends on your definition of "future". If you meant some time before the end of the universe, then yeah, probably.
If you mean in the following 3 months, I don't think so.
Wouldn't hold my breath either way.
The main issue with sound is that we don't know how to initialize the DSP... if that's solved (and a path is opened up to it), sending audio data shouldn't be too hard. Compared to (compressed) video data, audio is really small (less than 1/8th of it, depending on your settings).
Last edited by Wolfvak,
, Reason: moar explanation
- Status
Similar threads
-
- Portal
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
@
SylverReZ:
You can make a post on the DS forum about your findings, and they'll do their best to respond. They have a GBAtemp account here, you know.
-
@
Materia_tofu:
oh ye i made a post i did forget they had an account i prob shouldve tagged them in the post+1
tbh -
-
-
-
-
@
BakerMan:
Update on my brother: He's home now, tired and hungry, obviously, but other than that, seems to be doing fine.+2 -
-
-
@
BakerMan:
Well, from what I've heard from my parents, he had a seizure last night, perhaps an epileptic episode, fucking died, had a near death experience, my dad called the paramedics, they showed up, took him to the hospital, and he woke up covered in tubes, and started complaining.
-
-
-
-
-
-
-
-
