Breath of Fire 3 flickering screen.

[7zip]

The screen non stop keeps flickering the same issue was with the jpcsp emulator but the fps were slow but with ppsspp the fps is is very high or normal just the non stop flickering is a issue. hope it can be resolved easily.

[thedax]

I wonder what the issue with this might be; I tried both framebuffer options, and they don't seem to help or change anything, so I guess it being an FBO issue is out, yeah?

I mean, the log does mention it decimates and creates some FBOs, but..

[unknownbrackets]

Apparently hard coding the framebuf to 0 "improves" it, although it still skips. Most likely this means it's having trouble rendering to 00044000 properly. Could be a render-to-texture issue maybe.

-[Unknown]

[thedax]

Forcing it to be 04088000 or 040c4000 also seems to help, but it shrinks the screen size slightly:

When forced to be 0:

Like unknown said, however, it causes a frameskipping-like effect to have it be forced like this, so a hack wouldn't be useful here(not that I'd encourage it anyway, we want to fix it right)..

[unknownbrackets]

This log:

https://gist.github.com/thedax/4dec71d33edb8618165d

If I'm reading it right, it renders to 00044000 from 0x04088000 (512/512x512). And, apparently always displaying 0x04088000 does work. Hmm.

-[Unknown]

[thedax]

So here's a summary up to this point:
Forcing the framebuffer to be any 3 out of the 4 locations show useful graphics: 00000000, 04088000 and 040c4000 while 00044000 = black screen, and forcing it to be any of those 3 causes a frameskipping-like effect.

Also, Unknown thinks it's a render-to-texture issue.

[thedax]

This issue should probably be renamed to: Breath of Fire 3 Render-to-texture issues.

Also, since @raven02 seems to be on a roll with fixing graphical issues lately, maybe he has some insight?

[dbz400]

@thedax , Will test out soon :)

[zackerydsburch]

I don't know if this will help anybody out or if it's even important, but I'm having the same problem on Kingdom Hearts Birth By Sleep. What seems to help for me is turning the frame skipping off for down a few frames. Doing that seems to at least make the screen flicker less, but makes the game run slower. If I had to guess, the emulator is literally skipping that frame and displaying a brief black screen which creates the flicker effect we see. I don't know if that's considered a rendering problem or not though. Also notable is that switching the in-game color scheme to 32-bit verses the 16-bit also seemed to help. Don't know if that's useful all at.

[thedax]

The softGPU that's upcoming by neobrain doesn't have the flickering issue, so when it's complete, we can maybe take a hint from it to see what we can do to get the game working better in OpenGL.

[hyperspeedgx]

The flickering screen fix for BOF3, fix the flickering screen issue of Silent Hill Origins and Shattered Memories too?

#1541

[unknownbrackets]

This appears to be a strange render-to-texture bug. If all render to texture is disabled, and copy to memory is enabled, it shows fine. So that implies the source FBO (04088000) does have the correct data. For some reason, binding it as a render-to-texture isn't working properly, but flushing to memory does. Hmm.

-[Unknown]

[Ramsus]

#3476

This does fix the blinking screen issue, however it does not solve the flashing black bar at the top. Load up the game then alt-enter after the Capcom logo. Flashing black bar. Any ideas?

[dbz400]

Looks like this flash top black bar only happen when switching resolution either 1-4x or full screen .

[Ramsus]

raven02, it also happens when you save state, load state, or do anything that involves the overlay UI... I strongly suspect it is the UI here as the black bar is the same position and size of the overlay message. But I lack the skills to test my theory. Evertime I edit the UI or main window the project fails to compile. Perhaps someone with better skill can test my theory, when they have the time.

[thedax]

Somewhat new info:

Since a recent revision added new warning logs for FBOs sharing depth buffers, BoF3 is now reporting this:

34:02:743 GameMain W[SCEGE]: GLES\Framebuffer.cpp:608 FBO using other buffer as depthbuffer (unsupported), 040c4000/00000000 and 00000000/00000000

34:02:743 GameMain W[SCEGE]: GLES\Framebuffer.cpp:610 FBO sharing existing depthbuffer (unsupported), 040c4000/00000000 and 00044000/00000000

Sure, the game works now without flickering in read FB mode, but it'd be lovely if it didn't need it.

[thedax]

Here's a frame dump as it draws a frame(and flickers):
https://gist.github.com/thedax/260028d0e06323394c2f/raw/2f05dc39d430bd0639f1eed0e6e47cf0167ec40e/gistfile1.txt

[esptro]

Just use the perfect settings you find for ppsspp on YouTube. Adjust frameskipping to 1 AND Mode to read framebuffers to memory (GPU). Worked like a charm for me, no flickering.

[thedax]

The game doesn't need frameskip to run fine (well, I guess on mobile it might, or really weak PCs). But at any rate, the issue is now more about: Can the game be ran without hacks like FB -> Mem.

[thedax]

More info: when the screen is black (e.g. flickering), the texture is 0x04088000 (512x512). Color is 0x00044000 when it flickers.
Framebuffer: 00044000, w=512
Alpha Blend: Enabled
Alpha Test: Enabled
Tex Format: 5551
Tex Filtering: 000107
Tex U Scale: 1.0
Tex V Scale: 1.0

[solarmystic]

The game is rather wonky using the latest build right now (v0.9.1-1671-g51a3e16), using Read Framebuffers to CPU on its own doesn't resolve the flickering and instead just produces a stationary flickering CAPCOM logo image that is about to fade into the background but never does. Will do a bisect to see when this started and the last unaffected build (that at least ran properly with FB to Mem CPU enabled on its own)

[solarmystic]

Short revision history after doing some bisecting on Windows:-

v0.9.1-1626-ga7346e5 a7346e5 :- Last build with no flickering when Read Framebuffers to CPU is enabled, effectively the last working build for this game when Read FB to Mem CPU is taken into account.

v0.9.1-1627-g0a47509 0a47509 :- First build to just display a black screen after the CAPCOM logo when Read Framebuffers to CPU is enabled. Intense flickering present when normal Buffered Rendering is enabled. Read Framebuffers to CPU functionality in BOF3 essentially broken, starting from this revision. The game is responsive in the background, and the BGM can be heard. This continues until....

v0.9.1-1630-g7a0b1e4 7a0b1e4 :- Problematic behaviour slightly altered. Screen flickers after the CAPCOM logo is displayed, but the screen itself does not move ahead after the aforementioned CAPCOM logo display, it remains in the background. This behaviour remains the same in all revisions up to the latest one when Read Framebuffers to CPU is enabled, which was previously required to circumvent the flickering in Buffered Rendering mode, which is also still present.

v0.9.1-1671-g51a3e16 :- Issue still present, game is not playable with either normal buffered rendering mode or Read FB to Mem CPU mode on its own. Interestingly enough, enabling Frameskip (set to 1 for instance as mentioned by @esptro), helps to alleviate the issue somewhat but introduces significant amounts of juddering to the picture which makes for an uncomfortable gameplay experience.

Tested on the following machine:-

[hrydgard]

Thanks for your investigation, I know where to look for a bug now ...

[solarmystic]

The game now behaves as expected (i.e. not flickering anymore) when Read Framebuffers to Mem (CPU) is enabled since v0.9.1-1672-gae94e5c thanks to ae94e5c by @hrydgard

[hrydgard]

Great news :)

[unknownbrackets]

I think I know what is happening here. It all makes sense now. Evil game.

The game is basically doing triple buffering: drawing to one place, and then using a texture to draw that to the actual render target, and then swapping between two of those.

The two framebuffers it displays are 0x00000000 and 0x00044000.
The two framebuffers it draws to are 0x04088000 and 0x040c4000.

However, the only render-to-texture it uses for BOTH frames is 0x04088000. In other words, even after drawing to 0x040c4000, it still uses 0x04088000 as the texture to render to 0x00044000.

As it happens, the texture is 512x512, meaning 0x04088000 - 0x04108000. Assuming it's stretching when rendering to the actual target (see the first screenshots in this issue), both drawn frames are probably <= 256 pixels tall.

In other words, it's likely trying to use a render-to-texture source that is actually composed of two rendered framebuffers. The vertices are probably outside the FBO, resulting in clamping, and thus, black.

We could theoretically detect this, but there'd be false positives - in many cases games use a 512x512 texture because the height is 272, but they don't really need any other framebuffer composed in.

-[Unknown]

[dbz400]

In latest build , it is flickering very strangely now. ( Up and down and overlapping)

[thedax]

Looks fine in 0.9.6-95-g0cd1c3a for me, with FB -> CPU.

[dbz400]

Try uncomment this 2 lines

int drawing_width = ((gstate.region2) & 0x3FF) + 1;
int drawing_height = ((gstate.region2 >> 10) & 0x3FF) + 1;

Then comment out these 2 lines

//int drawing_width, drawing_height;
//EstimateDrawingSize(drawing_width, drawing_height);

[dbz400]

Then test it again in buffered rendering mode , you will see .

[hrydgard]

And watch 100 games get broken because doing that doesn't make any sense.

[dbz400]

Yep , at least now we know it is framebuffer sizing issue.

[unknownbrackets]

Well, are you sure? I think it might just be "saved" by tex wrapping. I remember seeing some stuff that made me pretty sure it was drawing both frames onto a single canvas and then drawing from there, although I could certainly be wrong.

Specifically iirc it expects 0x04088000 to be > 512 tall, so that it can texture from it. But it draws with the framebuffer pointing to 0x040c4000 (which is like 512x240 or something.)

Probably it looks funny now if it's wrapping the 512 tall texture, since 240 < 272, and I'm guessing the framebuffer is 272 like most are. That means that it will wrap to 480 - 272 = 208, so probably the bottom 32 pixels or so will be cropped off. Assuming wrapping is enabled, which it really must be for my change to have affected things here.

If you force the height to 240 it will probably look better but will be forced to 50% the framerate I guess...

-[Unknown]

[dbz400]

I think it is combination of both tex wrapping and framebuffer sizing. Either missing of them, flickering appears

[andoruB]

Tried on 0.9.7.2-132-gaee5f0d, having similar issues as solarmystic #issuecomment-26074469
With Buffered Rendering mode it flickers, and read framebuffers to memory (either CPU or GPU) give me a black screen and crackling sound. I'm not sure if the latter is yet another GPU/driver problem.
But instead it works fine when setting the frameskip to 1, it doesn't judder as solarmystic reported, but the framerate/motion is quite choppy. Also when casting spells in-game or in some battles, the emu slows down and the audio becomes choppy. (could be my slow PC)
Also an interesting thing that happens, I'm not sure if it did happen to the previous users who went by the frameskip method noticed this. If I set the frame to 1 when the field (or I think you guys call it texture) is in an "odd" state, it keeps it in that position on the screen.
By odd state I meant when the texture is not shown fully on the screen. I think there are three states which alternate when the flicker occurs:

• when the texture is fully shown on the screen (normal)
• when the texture top is displayed at about 1/5 of the screen (odd)
• when the texture top is displayed at around 4/5 of the screen (odd)
  And those states keep alternating (or follow each other in succession), causing the flicker.

So, when I turn on frameskipping on 1, and the frame at that time had the texture in the first state mentioned above, the texture is displayed at about 1/5 of the screen constantly (but doesn't flicker)

Hope this makes sense. Sorry for the long convoluted explanation =P

[thedax]

Minor update: with Simulate Block Transfers enabled, the game doesn't flicker anymore under buffered rendering, but the internal framerate is effectively halved. Better than flickering, though..

[unknownbrackets]

Does this help it?
https://github.com/unknownbrackets/ppsspp/tree/bof3-workaround

Although... I'm not 100% sure if it's safe. I think it's safe. Perf impact should be very small.

-[Unknown]

[thedax]

I was slightly mistaken earlier, it does not need SBT to run without flickering anymore.

@unknownbrackets: That aside, your tree indeed seems to make the game work at full speed without the halved framerate, and without needing SBT or fb -> mem. I haven't played much (about 5 minutes so far), but I've not noticed anything wrong with it, glitch-wise or performance-wise.

[solarmystic]

@unknownbrackets @hrydgard
It seems like the flickering issue in BOF3 is back, even with Simulate Block Transfers/Function Replacements enabled.

Bisect points to v0.9.8-1220-g40f13d5 40f13d5 as the first responsible commit

v0.9.8-1219-gf664979 f664979 is the last unaffected commit, but that one runs at "a halved framerate" (see #2759 (comment)) so it's not perfectly normal either.

The temporary solution is to force Read Framebuffers to Memory once again.

Please reopen the issue, thanks in advance.

[solarmystic]

Okay, so the "halved framerate" issue for BOF3 (which is a seperate one from the flickering) started once again from v0.9.8-1188-g0b9db17 0b9db17

v0.9.8-1187-g822f936 822f936 is the last unaffected revision, effectively making it the last one completely devoid of any issues in the graphical department.

[solarmystic]

In summary:-

v0.9.8-1187-g822f936 822f936 : Last build without any graphical issues.

v0.9.8-1188-g0b9db17 0b9db17 : First one to have the halved framerate issue again.

v0.9.8-1219-gf664979 f664979 : Last one without the flickering issue.

v0.9.8-1220-g40f13d5 40f13d5 : First one to have the flickering issue again, in addition to the halved framerate issue.

All builds tested with default settings (Buffered Rendering + Simulate Block Transfers enabled)

EDIT:- Please reopen the issue.

[solarmystic]

Fixed again by #6383

[thedax]

Please reopen, this has reappeared again as of #6468 's merge.

Bisect result shows:
git.exe bisect good

553c870 is the first bad commit
commit 553c870
Author: Unknown W. Brackets checkins@unknownbrackets.org
Date: Sun Jun 29 17:29:02 2014 -0700

Execute savedata io on a separate thread.

Some savedata is sorta large, like 1MB, this makes it save more smoothly.

:040000 040000 b5c12b200c3936d1ef6a75e1ec34313e2a7cc5c5 42c8ee8eb51ed4c6f93f08edc28543662e96a9a3 M Core

If I revert to the commit just before it, 51909a3, it does not flicker.

[unknownbrackets]

That makes no sense. Arg. Darn.

-[Unknown]

[thedax]

I'll add that 32-bit vs. 64-bit makes no difference. I used default settings as well.

[unknownbrackets]

From a log, it seems like this is because it's now detecting some framebuffers as 272 tall instead of 240. I think I have a way to fix it, we'll see soon...

-[Unknown]

[unknownbrackets]

Those are not screenshots from Breath of Fire 3.

-[Unknown]