blackmagic3 - brand new OpenGL 2D renderer#2553
Conversation
2D renderer is now responsible for its framebuffers, along with a nicer mechanism for "this renderer doesn't render to RAM framebuffers".
oh god, what a mess.
…acking stuff. also, reset it properly on reset.
…ders easier to work with
…ted as both 1st and 2nd target (could produce garbage)
|
So back to Bowser's Inside Story, I had three more suspect points of possible issues. The first two were the boss battle transitions (since other ones were broken), but fortunately they work great bowser_fight.mp4mario_fight.mp4But I found one more issue that's hard to capture on video, on the giant battles (suspect point three) there's some flickering background colors that are very noticeable. I tried to capture it and you can kind of see some weirdness in the background, but it's not as bad as seeing it live at 60fps: flickering.mp4This happens on both OpenGL renderers but is fine on master (notice the background stays static): no_flicker.mp4Here's a save state to quickly test this: |
|
I figured out why the flicker happens but I'm too tired to fix it right now I'll fix it tomorrow and then maybe we're good to go for a merge? |
|
While the new commit did reduce the flickering, it did not completely eliminate it sadly. The video still appears to capture some, though on 60fps it's not as bad as before: less_flicker.mp4 |
|
indeed... this commit should hopefully fix it for good. I can't see any now. |
|
Almost 2 hours later (waiting on my local vcpkg packages to update), I was able to test and confirm no more flickering remains: fixed.mp4I cannot say that I won't encounter more bugs with 100% confidence, but that requires me to do a full playthrough to check. However I don't want to delay this getting merged, so I'd rather make issues after the fact. With that said, I don't think there should be more special edge cases that could be broken in this game. |
|
my plan is to merge this pretty soon anyway, so more people can get it and test it the remaining issues will be addressed later |
|
Welp, just when I thought this game was done with it's tricks, right after the giant battle is over, Mario & Luigi's head icons sure got broken:
Entering an area and then leaving just results in the sprites dissappearing completely:
And now the action icons got broken too:
And the emulator seemingly hangs for a bit during screen transitions too: hanging.mp4Shutting down the emulation and reloading the game solved these issues, but it's concerning they even appear after a type of battle you see 4 times in total in the game. Beyond the save state I shared for the battle itself (finishing it should trigger these bugs), here's another save state taken in this broken state (loading it does bring back all of these bugs even after rebooting the game): |
|
does it still happen if you don't use the savestate? reusing savestates from earlier versions (or commits) often causes issues. |
|
Appreciate the suggestion, but that's irrelevant. I didn't use save states while getting this error, I loaded my save file, did the battle from the start and saw the glitch. So no, it wasn't caused by save states EDIT: The save state shared in that last message (the one in the broken state) was made with the latest commit. |
|
I tried the savestate you provided and the sprites are also corrupted when using the software renderer, so it won't be very useful there :/ I'll try going from the battle savestate, if I can play this somewhat competently |
…different offsets/sizes)
|
This should fix the issue. Bad news is, the savestate you provided can't be relied upon - it's already in a broken state. |
Meh, no big loss. Whole point of that save state was just to share the brokenness of it all. I'll test in a bit and report back. |
|
indeed, indeed. for anything inbetween melonDS releases, savestates should be considered a moving target, so, yeah. |
|
Well, their faces are back as they should be now:
And stuff is now less broken after the battle is over too: stability_update.mp4To compensate, one more graphical bug (not present on Software renderer, but present on both OpenGL renderers):
Here's a blurry software screenshot to show how it should look like:
And a save state that takes you to that very screen: If that's not useful, here's another save state that takes place right before the end screen (so you don't have to do this battle again lol): |
|
that seems to be an issue with the 3D renderer(s), texture alignment -- this part is rendered by the 3D engine |
|
In that case, hopefully there's nothing more to uncover with this game this time. I didn't expect to find so many issues on one game alone. |
|
well, thanks for your testing, that has been some great bughunting! |
|
@Arisotura You are the GOAT. Literally fixed a 7 year old issue; the best Emulator dev out there. |
* reworked renderer structure to more closely reflect DS hardware, and have a general "renderer" object instead of two separate ones * new OpenGL 2D renderer - hi-res display capture, hi-res rotscale * 3D renderers support hi-res display capture as well * 3D: clear bitmap support * 2D: extra accuracy (extra green bit, mosaic fixes, forced blank fixes) * more accurate video timing state machine * support for POWCNT1 bit 0 (LCD enable) closes melonDS-emu#421, closes melonDS-emu#473, closes melonDS-emu#568, closes melonDS-emu#1851, closes melonDS-emu#1242, closes melonDS-emu#1510, closes melonDS-emu#1544, closes melonDS-emu#2348






This branch includes the following:
I'm opening the PR so I can receive some input before going and merging this, and maybe do some last minute fixes.
There's more graphical work planned, but it won't be part of this branch for now.
closes #421, closes #473, closes #568, closes #1851, closes #1242, closes #1510, closes #1544, closes #2348