Super Stardust missing bloom effect.

[daniel229]

this game just like dante's inferno #4845 before artifact over the screen,,while dante's inferno is fixed,this game isn't.

ppsspp

psp

[daniel229]

gedebugger on 0.9.8-1064
before the artifact

next step it come out

[unknownbrackets]

Hmm, subtract fixed-fixed? And that looks like a clear in the first step.

Does it work in the softgpu?

-[Unknown]

[daniel229]

Softgpu is fine.

[unknownbrackets]

Turns out this is blending src * 2.0 * src.a + dst * 2.0 * src.a with a mostly black src. Effectively this color doubles dest, but we avoid slow blending in this case because it causes artifacts and slowness. It seems it also performs color doubling, so it's on super brightness mode.

-[Unknown]

[unknownbrackets]

If anyone has this game and PowerVR or Mali device, it may look correct there.

If it does, it might be possible to make this work on recent desktop GPUs, not sure.

-[Unknown]

[Panderner]

The title screen are no longer dark but after bloom effect the The Letters R, S, T and the ™ Symbol Starts flickering

[unknownbrackets]

Someone captured some frame dumps of the alternating frames of the flicker, attached here with PSP renderings generated:
#6371_NPEG00008_logo_flicker1.zip
(I edited them to force skip the bloom buffer to prevent any worry about that being involved.)

At least based on these frames, it doesn't seem to be a rendering issue unfortunately:

They look different the same way on a PSP and in the software renderer.

At 136/165, the triangle strip uses f333/f333/f333/f333, but somehow it decodes to different in one frame dump. So that's interesting. But it uses morph (which isn't represented in the source values of f333) and an interesting vertex type:

• u8 TCs
• 4444 colors
• s8 normals
• s8 positions
• 7 morph variants (as many as you can have)

Each vert is 10 bytes, there are four verts, so 320 total bytes. The memory looks identical between the two frame dumps.

For the morphs, which only differ between each other by color (again, identical between frame dumps):

• For the first two verts, all are f333 except 5-6 (of the 8.)
• For the second two verts, all are f333 except 6-7 (of the 8.)

The morph weights differ between the frame dumps:

• In the first, darker one, only weight 8 is 1.
• In the second, brighter one, weight 7 is 0.121572 and weight 8 is 0.878418.
• All other weights are 0, but it seems there's some animation here so they're probably used in that.

The result is that we get a slightly brighter gray for the second frame dump, which is the source of the flicker. So it seems like some sort of issue with how it's establishing the morph weights? Does this really not happen in the software renderer? If not, maybe somehow it determines the weights based on some CPU read of VRAM? Or some other bug...

It sets the morph weights shortly before rendering the logo, so it's not like they're stale either.

-[Unknown]

[unknownbrackets]

Note from #16131: this does happen in softgpu. Hmm..

-[Unknown]

[Panderner]

The bloom is working properly for Vulkan but still broken for other backends:

Other Backends:

Vulkan:

GE dump:
In-game.zip
Title.zip

[Panderner]

But in Android the bloom is broken in vulkan but OpenGL is correct:

OpenGL:

Vulkan:

[unknownbrackets]

From a previous time I looked into this, I think there was some timing thing involved here. Are you sure it's consistent if you restart the game 3-4 times with the same backend?

-[Unknown]