Glowing graphics in Ultimate Ghosts 'n Goblins

[ReyVGM]

I don't know if this has been reported yet, but throughout the game, the graphics seem to start glowing sometimes. It's like a bloom effect or something like that. It gets really bad toward the last stage.

I can confirm that the glowing effect does not happen on a real PSP. The first image has the glowing effect, then 2nd image does not. On the 3rd image, glowing effect is really bad.

[unknownbrackets]

https://github.com/hrydgard/ppsspp/wiki/How-to-find-a-graphic-issue-with-the-GE-debugger

Could be stencil/alpha, likely it's directly accessing framebuffers/blocktransfers/something, though. Might also be clut.

-[Unknown]

[ReyVGM]

Ok, here are a bunch of screenshots, hopefully it's what you're looking for since there were a LOT of parts highlighted in red.
http://www.filedropper.com/ultimategng

And just in case my screens are not what you need, here's a save state at the place where the glowing is the worst:
http://www.filedropper.com/ultimategngsave

[thedax]

This game does some weird stuff (at least it seems weird to me, it might not to you guys). Once it's done drawing all of the polygons and textures, it seems to shrink the scene it's rendered down to almost nothing on a 512x512 texture, and then it passes over it once with a dark blue colour, then it passes over it numerous other times, shrinking and re-enlarging it multiple times, eventually adding what looks like a bilinear filter layer on top of it or something (it goes from a pixellated look to a more smooth look) once it's back to the regular size. After this, it goes over top of the screen one last time to add this bloom layer.

Flags: https://gist.githubusercontent.com/thedax/7f89bdf3154ddaf7a68f/raw/f317e257bd18f6c9593be5895ee345a5f5b77162/gistfile1.txt
Lighting: https://gist.githubusercontent.com/thedax/5cd5e093e94d83df76de/raw/a1e375d58608a7320a02b188b2ebfc1efd13ccc9/gistfile1.txt
Texture: https://gist.githubusercontent.com/thedax/33a1f9e73670b81a9565/raw/d9d8f75c34ea206f427ef6fd0ebe7f488edc70f0/gistfile1.txt
Settings: https://gist.githubusercontent.com/thedax/51edfb3577cb16268268/raw/65d9996f4d52fee187fe44e1d3d0d18dcb2d2fbb/gistfile1.txt
Vertices: https://gist.githubusercontent.com/thedax/3b74bac5ea845e118b0d/raw/398e83b7f90114aafa9819fac8c137da2ca4a7b6/gistfile1.txt
Matrices: https://gist.githubusercontent.com/thedax/44c670049dc88c44bd3b/raw/ae66b0d9ded9e21a3f69969f155e2a798d00a67a/gistfile1.txt
Lists: Start PC PC Stall State Started Interrupted
0x08D7B180 0x08CAC7C8 0x08D7B19C Running Yes No

Screen of where I took the info:
http://i.minus.com/iIanI8JNZWK25.png

Once it's done with that thin and tall rectangular prim, going all the way across the screen, it applies the bloom to the entire screen (each tall and thin rectangular prim seems to be the bloom being applied?), but the entire screen didn't appear red like Rey's. The next texture after that is a small flame. I wonder if only the small flames are supposed to have this bloom? My real PSP is still lost at the moment, so I can't double check..

[unknownbrackets]

Yeah, that's how several other games (Wipeout Pure, Sword Art Online, Gods Eater Burst, etc.) apply bloom too.

Since it has a >= 0 alpha test, I'm guessing this is a stencil -> alpha issue... I assume it looks right in the software renderer?

-[Unknown]

[thedax]

It looks like it's slightly too dark in softGPU, but that's just me (look at the knight):

[ReyVGM]

I noticed while watching the actual game on a PSP that in the case of the first level, those purple ghouls are the only ones that are supposed to be glowing.

[hrydgard]

Could possibly be yet another stencil/alpha issue, where the game is failing to mask away the glow from things that shouldn't, well, glow. Oh right @unknownbrackets already guessed that, heh.

[ReyVGM]

What is the SoftRenderer? Is that the Non-Buffered Rendering?

[thedax]

No, it's under Settings -> Graphics -> Software Renderer. Scroll to the bottom of the graphics tab/sheet and you'll see it. You can't enable it while a game is already running, though.

[ReyVGM]

Ah right, thanks!

[ReyVGM]

Here are some comparison images:

SoftGPU On:

Buffered Rendering before the ghouls appear (SoftGPU off)

Buffered Rendering after the ghouls appear (SoftGPU off)

Non-buffered Rendering (SoftGPU off)

The softGPU one seems to give the glow to the ghouls, but Arthur does seem darker.

[unknownbrackets]

Has this improved in the latest git build, especially with "simulate block transfers" on?

Might've been clut related too, many games apply a clut during bloom it seems like.

-[Unknown]

[thedax]

No, there's no difference with GLES as of v0.9.8-1062-gd8e9878. The software renderer is still the same as Rey's post.

[ppmeis]

Tested with latest build. It looks better than before, but the glow effect in ghosts is missing. It's visible in softgpu.

Normal GPU:

Normal GPU with stencil hack causes global glow effect:

Softgpu:

Real hardware:

[unknownbrackets]

I wonder if the stencil mask change might've helped this? I suspect not since I don't see it in reporting.

It's using 5551 so there's just one bit of stencil. Since the stencil hack affects it I'm assuming it must be related to that, so the question is - where should it be updating the stencil?

You can try the following:

1. Get to the point where you're viewing this screen.
2. Open Debug -> Disassembly and click "Stop".
3. Click "Breakpoint" and then enter 0x04000000 as the address, 0x88000 as the size. Accept the other default options.
4. Hit Go. If it pauses immediately or as soon as a ghost appears, the game is likely writing manually to the stencil bit in a way we don't yet detect.

Otherwise, it could be we're missing some handling for INCR or DECR but I don't think that's it. Not sure what other options there are, CLUT can't write to stencil... maybe a block transfer? But doesn't seem like it's doing one of those.

-[Unknown]

[thedax]

I just had a quick go with the disassembly idea, but it never seems to pause at all, so I don't think it's writing stencil manually.

[unknownbrackets]

If you look at the stencil tab, I assume it's always zero (black) right? Not red anywhere? Or does it draw some red in some areas (not the preview... I guess maybe it should use different colors for stencil/depth and draw preview), but then turn black later?

It's possible it's manually drawing the stencil to another buffer like 0x04187000, can try more breakpoints but there will be more false positives...

-[Unknown]

[thedax]

It's mostly black, but it does occasionally draw to the stencil tab/buffer (when rendering some of the geometry, and upon pressing draw prim again, the previous area that was just drawn turns black. It seems to draw to the stencil buffer quite a bit when rendering the ghosts' flames and the HUD (at the appropriate locations of where the flames are, and the HUD is; it doesn't look abnormal to me).

[unknownbrackets]

https://gist.githubusercontent.com/thedax/51edfb3577cb16268268/raw/65d9996f4d52fee187fe44e1d3d0d18dcb2d2fbb/gistfile1.txt

Your previous export showed the stencil test disabled. Does it ever draw with it enabled? And what are the settings when it does?

If there's stencil data on the flames, and forcing the stencil test off makes things work but on everything not just flames, it seems to me we are not correctly applying the stencil test.

-[Unknown]

[thedax]

No, it's never enabled as far as I can tell. I followed it for one frame (with step prim), and "Stencil test enable" is always 0.

[thedax]

If I use step prim, it looks like the stencil test is never enabled, but with step draw, it becomes enabled when the ghosts are drawn (and then hangs PPSSPP and the GE debugger forever).

[thedax]

As far as I can tell, this has been fixed in the latest builds. Before closing it, @ReyVGM or @ppmeis, can you confirm?

[ppmeis]

@thedax tested with latest build. Same status:

SoftGPU looks good:

[ppmeis]

Tested with latest build. Same status:

OpenGL

D3D9

[ppmeis]

Tested with latest build. Same status. GE Debugger dump:

ULES00419_0001.zip

[unknownbrackets]

When the purple ghouls are drawn (tex: 0x0886cc10), it uses INCREMENT for stencil. The framebuffer is 5551, so this should mean to max out stencil.

So I think this only happens when dual source blending is not enabled. I suspect that means Intel cards for OpenGL, and all Direct3D 9.

-[Unknown]

[ghost]

I can also reproduce this issue on Nayuta both opengl and vulkan.

NPJH50625.ppdmp.zip

[ghost]

Hack settings lower resolution for effects doesn't help btw.

[unknownbrackets]

From the slow issue for Nayuta, we have these buffers:

• Main rendering happens to 0x04000000 / 0x04044000 (512x272x2), typical double buffering.
• Depth is at 0x04088000 (512x272x2.)
• Temp buffer for bloom rendering is at 0x040CC000 (512x272x2.)
• (0x2000 gap at 0x04110000)
• Bloom resize buffer A at 0x04112000 (128x128x2)
• (0x2000 gap at 0x0411A000)
• Bloom resize buffer B at 0x0411C000 (128x128x2)
• (rest of VRAM after 0x04124000)

Each one is cleared upon first use in the frame, so there's no bleed happening. But it does work correctly in the software renderer... however, that's partially an artifact of the frame dump. Because it uses buffer B as a texture before clearing it (likely for motion blur of the bloom.)

The temp buffer for bloom looks right, up through 1434/1454 (sorry this is a dump from #14223.) It's the resize buffers where things get funny.

To do the bloom it:

1. Clears resize buffer A.
2. Copies resize buffer B to buffer A (blending at about 62% using vertex color and alpha blending with a fixed alpha.)
3. Draws the rendered bloom scene to resize buffer A, using 100% (but note that it's a darkened render) using alpha blending to keep the dest color 100%.
4. Clears resize buffer B.
5. Copies 25% of resize buffer A to resize buffer B, alpha blending again, about 5 times at offsets to blur it.
6. Blends this back to the main buffer at using alpha blending with a fixed alpha to 100% both src and dest.

In software, skipping the tex overwrite for those buffers (if (framebuf->addr != 0x0411c000 && framebuf->addr != 0x040cc000 && framebuf->addr != 0x04112000) { to be sure), it still looks good. The last frame is much darker. They look like this:

It's much brighter in hardware (both look similar):

If I force the initial copy from temp buffer B to blend to zero (step 2 above), it initially looks good but the brightness picks back up. I wonder if this is just down to it using 5551 and maybe colors just multiply out slightly higher than they should.

This is probably different from the Ghosts 'n Goblins thing.

-[Unknown]

[ppmeis]

Tested in latest build. Bloom appears only when enemies are on the screen, also effect is applied to more elements than before, which is not correct according to real hardware.

Vulkan without enemies:

Vulkan with enemies:

Software render looks fine: