Kurohyou 2 missing some screen after framebuffer-clut merged

[daniel229]

Join to the battle,would see these screens,these screens used to be overbright,and there a demo for the game, does the some thing.

framebuffer-clut merged

old build

framebuffer-clut merged

old build

[unknownbrackets]

Hmm. Just to confirm that it's not some other changes from that branch, commenting out this single line brings back the old functionality:

program = depalShaderCache_->GetDepalettizeShader(entry->framebuffer->format);

But, I'm not really sure what's wrong here.

-[Unknown]

[hrydgard]

Can you check the clut parameters (shift, offset etc) and the blend mode when it's texturing from the depal texture?

[unknownbrackets]

from fmt 1, clut fmt 3: ((color >> 0) & 0x1f) | 0, blend: -1: 2,3
from fmt 1, clut fmt 3: ((color >> 5) & 0x1f) | 0, blend: 0: 10,10
from fmt 1, clut fmt 3: ((color >> 10) & 0x1f) | 0, blend: 0: 10,10

(-1 means blending disabled, just quick logging.)

Earlier on, while showing the map, not sure if this is correct either, it uses:

from fmt 0, clut fmt 3: ((color >> 0) & 0x1f) | 0, blend: -1: 2,3
from fmt 0, clut fmt 3: ((color >> 0) & 0x1f) | 0, blend: 0: 10,10
from fmt 0, clut fmt 3: ((color >> 1) & 0x0f) | 0, blend: -1: 10,10
from fmt 1, clut fmt 3: ((color >> 0) & 0x1f) | 0, blend: -1: 2,3
from fmt 1, clut fmt 3: ((color >> 5) & 0x1f) | 0, blend: 0: 10,10
from fmt 1, clut fmt 3: ((color >> 10) & 0x1f) | 0, blend: 0: 10,10

It's doing both of these each frame, of course, during the effect.

Maybe this is interacting with in-shader blending or something... nope, still the same with that forced off.

-[Unknown]

[hrydgard]

If you just output the color (scaled appropriately) without doing the palette texture lookup, do you get some image? If so the clut may be black or something...

[unknownbrackets]

Well, it looks okay, but it notably uses a texture at 0x04288000 for example.

I added as a quick hack:

    if (Memory::IsVRAMAddress(texaddr)) {
        texaddr = texaddr & ~0x00600000;
    }

And now it also logs during the map part:

from fmt 0, clut fmt 3: ((color >> 8) & 0xff) | 0, blend: -1: 2,3

But it doesn't affect the battle part. For some reason stepping is causing the vertex decoder to crash, arg...

By the way:
http://www.pspdemocenter.com/page.php?id=3969

-[Unknown]

[hrydgard]

Okay thanks, I'll take a quick look at the demo tomorrow and see if I can figure something out, but if you're not seeing it, it's probably a tricky one :) Vertex dec crash is worrying but should be possible to figure out.

[unknownbrackets]

http://report.ppsspp.org/logs/kind/608

It looks like this is using a memcpy blit, which is rare. Not sure why I didn't see it in the log, so maybe it's not at the same time.

-[Unknown]

[unknownbrackets]

I think I figured it out. It's annoying.

The framebuffer is 5650. Then it draws it onto itself, using a clut, BUT it uses a destination format of 5551 afaict. I suppose it wants to add alpha. It may do more than this, but this generally seems like why it renders totally wrong.

I guess we could track a format last render (after the set texture)?

-[Unknown]

[hrydgard]

"a format last render" = the format of the last render? Yes, I suppose so, but I wonder if we really need to. Why would the destination format matter to us? Oh right, ugh, for the alpha elimination hacks I suppose.. If you hack that out (like, mark all framebuffers as having alpha), does it work?

[unknownbrackets]

No the problem is that it's rendering to AND from the same vfb. vfb->format was already updated, so we interpret the bits (for clut) of the red/green/blue wrong and look up the wrong color.

Yes, track a format value as of the last render.

Has nothing to do with alpha tracking. We're using absolutely completely wrong palette indexes right now.

-[Unknown]

[hrydgard]

Ah I see now, sorry. This is all pretty confusing :)

Feel free to track such a value, I think it makes sense.

[unknownbrackets]

Hmm, still didn't do the trick...

-[Unknown]

[unknownbrackets]

So, this does even other things:

1. It uses a VRAM mirror to render a framebuffer, which we don't currently support. I guess just for swizzling, not sure.
2. Not sure why (don't see it rendering here...) but 04116200 in softgpu (used as a palette) has stuff. In gles, it's all zeroes.

-[Unknown]

[hrydgard]

For gpu-only effects where the CPU doesn't get involved, we should be able to just mask away the mirror bit, as we have no use for the swizzling.

As for 2, maybe it's doing something insane like using part of a framebuffer as a palette? That's some nasty trickery if so...

[unknownbrackets]

Indeed, this game has an FBO at 0x04116200, which is the CLUT. So like Brave Story, it's using a rendered area as CLUT, but unlike it, it's doing so from a render-to-texture.

-[Unknown]

[daniel229]

Fixed now.