fastboot3DS
fastboot3DS copied to clipboard
derrekr
Splash occasionally appears messed up.
This happens at least on commit c417a8a4752779879af78253da21171c09e1ae92, though i do not know if it happens in ef732dc8da6c3ab4ffffe0e1629feeceeb347796, the latest commit at the moment.
I would add an image, but I do not have a means of such at the moment
Can confirm that it happens with the latest commit as well. The splash appears randomly corrupted when fb3ds boots from FIRM0, but it always seems to look normal if fastboot3DS.firm is chainloaded through something else first (like GM9 or Luma). O3DS here, if that matters.
Not able to reproduce this. I need more infos.
When does it corrupt? While entering the menu (through the HOME button) or quick boot? Does it happen with custom splash (on the SD) or with builtin aswell? Did you rebuild it with a different splash baked in?
I usually use quiet mode, so I originally noticed it while entering menu, but it definitely happens with other two boot modes too.
For quick mode even the "Press HOME to enter menu" text that appears on bottom screen also gets corrupted.
All of that happens with default builtin splash, I've never actually tried using custom splashes (neither from SD nor by replacing the builtin one), but I can try when I have some time later, if that can help.
P.S. Changing splash duration, whether it's shorter or longer, doesn't seem to help either.
Yeah, i can't reproduce this. It's working on my o3DS with debug and release builds. You are building under Windows, correct? Possibly the link order affects this and changes timing. I built everything under Linux. Can you upload one of these broken builds? I have an idea what the problem could be.
The last commit i just pushed is unrelated btw and can be ignored.
Yeah, I build under Windows. Here's that one that I currently have installed: http://www.mediafire.com/file/tchiu6qs6wabpbq/fastboot3DS.firm
Same with your build. Ok, a blind attempt at this. Try the attached build.
[removed build]
With this test build there seems to be no corruption with both normal mode and while entering menu with quiet mode.
Quick mode still has some minor corruption on both screens…
Does it matter what was used to flash the firm? I used GM9 for both builds, latest commit from the staging branch.
Ok. All i changed was the 3 ms wait in GFX_init() waiting for VBlank instead. At least this confirms it's timing related.
Doesn't matter.
[removed build]
No change unfortunately, the quick mode is still corrupted. But I noticed something weird, with both test builds… When I boot with no SD card the corrupted splash looks different almost every other time, but when the card is inserted it always (at least most of time) looks the same, and the corruption is less severe. The config is the same on both SD and CTRNAND.
What about this one? I'm running out of ideas to be honest.
[removed build]
Same. :(
Actually, the corruption is random almost every boot now, no matter whether SD is present or not. Though, maybe even last time I was just "lucky" to get the same looking corruption several times, because when I tried to increase splash duration to take some photos it started getting random ones more often. Oh well, I guess at least I can try to show how it looks like (the third pic is what was appearing the most on last two builds with SD card inserted):
I'm sorry for not being of much help here, and thank you for your patience.
That kinda looks like the corruption i was getting a long time ago on N3DS XL which seemed texture copy related and got "fixed" with a workaround. I recently pushed a fix which was supposed solve this properly. Looks like this is an entirely different bug after all and was never properly fixed.
I'm going to take another look into the gsp module because i remember some unknown reg writes which could be related. If that doesn't work i'm going to try another workaround.
…I'm an idiot. It completely flew over my head that neither OP nor I have ever mentioned that this bug started to occur exactly after this commit. I don't think I've ever seen it happening before that, and I just tried compiling the commit before that, and it works just as it should!
Oh, yeah. That was the workaround i was talking about. I thought this was the same bug but it's not. I still want to try fixing this correctly.
Sorry for wasting your time like that. xP
I tested the latest commit you just pushed, and now everything looks perfect!
Ok, what about this one? If you have more than one 3DS test it on all of them.
[removed build]
Sorry for late reply, I went to sleep. That build seems to act the same as old buggy ones: all three boot modes are borked this time. Unfortunately, I only have one console, perhaps @FlameKat53 can help with more tests?
I basically only wanted to know if this build works and if it does, does it work on all models? Since it doesn't work the other tests are superfluous. I thought maybe these extra reg writes will do it but unfortunately not :/