Naruto Ultimate Ninja Impact Hachibi White Colour

[ghost]

Real PSP

[hrydgard]

It's back? I thought we fixed this one ages ago?

[ghost]

you can fix it?

[Ritori]

Question! is this on latest of ppsspp?

[ghost]

yes v0.9.1-1761-gec84f50

[unknownbrackets]

Is it also broken on 0.9.1? Is this on Windows or...?

-[Unknown]

[ghost]

windows, and my android too

[cv47]

Blending issue? i got this result after change Blend color...strange

[ghost]

Cv47 can you give me your ppsspp apk

[ghost]

please fix it...

[hrydgard]

@NeoDarkness , no fix begging. Only post here if you have useful information.

[dbz400]

@NeoDarkness , if you want to help , please share a savestate .ppt for this scene using latest build .

[ghost]

@raven02 ok

[ghost]

@raven02 http://www.mediafire.com/?15nb2ff820lxgq0 (save state)

[dbz400]

Thanks . I suspect it is the same issue as the https://github.com/hrydgard/ppsspp/issues/3993

[dbz400]

Humm unfornaturely i cannot load it using latest build with this error

13:12:542 Sched I[COMMON]: E:\ppsspp-master\common\ChunkFile.h:600 ChunkReader: Done loading E:\ppsspp-master/memstick/PSP\PPSSPP_STATE\ULUS105 82_1.00_0.ppst 13:12:542 Sched W[KERNEL]: E:\ppsspp-master\Core/HLE/sceKernel.h:454 Kernel: Bad object handle 0 (00000000) 13:12:542 Sched E[KERNEL]: HLE\sceKernelSemaphore.cpp:284 sceKernelReferSemaStatus: error 80020199 13:12:542 muscbThread E[MM]: MemmapFunctions.cpp:55 Unknown GetPointer 00000000 PC 00000000 LR 00000000

[dbz400]

@NeoDarkness , any nearby save point you can have ? ( not savestate)

[dbz400]

It did show correct color initally in GE debugger .if blend color , just wonder where should try to change ?

[dbz400]

Alright .Able to reproduce it from blendcolor

[hrydgard]

But that still looks pretty terrible, all the shading you can see on the real PSP picture is not there.

[dbz400]

Yep , btw , it uses the following

blendcolorstate: FixA=000000 FixB=ffffff FuncA=2 FuncB=10

[hrydgard]

This is probably a multipass algorithm where it draws first the monster without shading, then it draws the shading on top, with that alpha blending mode. For some odd reason the shading layer ends up being white. Which blend equation is used?

[dbz400]

It use the following 2 blendeq

GE_BLENDMODE_MUL_AND_ADD = 0,
GE_BLENDMODE_MUL_AND_SUBTRACT_REVERSE = 2,

[unknownbrackets]

Not that I really expect it to work, but how does the softgpu look?

-[Unknown]

[unknownbrackets]

Did the recent lighting change (that fixed Blade Dancer) fix this?

-[Unknown]

[dbz400]

Just checked .Not yet fixed .Hachibi still in white colour. I do think this one is more related to blending color.

[dbz400]

Softgpu seems to be same issue as GLES

[dbz400]

In GE , it did render with shading but become white later

[dbz400]

Humm probably related to non-lighting here? comment out the following , it become black color

        // Lighting doesn't affect color.
        if (hasColor) {
            WRITE(p, "  v_color0 = color0;\n");
        } else {
            //WRITE(p, "  v_color0 = u_matambientalpha;\n");
        }

[unknownbrackets]

Has this changed at all with shader blending, clut, and block transfer stuff?

-[Unknown]

[daniel229]

Still white.With hardware transform off,it displays the color partly.

hardware transform off

[unknownbrackets]

Well, that's interesting. I think the GE debugger captures from above aren't actually from drawing the skin. It's probably easier to catch with hardware transform off since you can tell if it's actually drawing.

Maybe something is nan/inf like with the fog issues? Like a lighting position or something?

-[Unknown]

[daniel229]

PSP

catch thing like this?

next step

[unknownbrackets]

So, it's shading it, then, right? Using only normals/positions, so it must be lighting params. Maybe we're handling something in lighting wrong when there's no vertex color.

Would help to see lighting and settings tabs for that prim. But yes, looks like you caught it.

Edit: OR, maybe it's the texture coords? Seems like it's a gradient, and texturing is on (since preview is visible), but no texture coords? Texture tab would help too.

-[Unknown]

[daniel229]

lighting and settings tabs

[daniel229]

Texture tab

[unknownbrackets]

So it's using the "tex env map". I don't understand that mode much, but it seems like both light sources are light 3. Maybe we're getting something wrong here because light 3 is just at position 0,0,0...

-[Unknown]

[daniel229]

It shows up more color with HW transform off

[unknownbrackets]

Hmm, that's different from before: https://github.com/hrydgard/ppsspp/issues/4155#issuecomment-47613706

Does it change where it shows the color, flicker, or anything?

-[Unknown]

[daniel229]

Yes,the head change color when it moving. those chenges since https://github.com/hrydgard/ppsspp/commit/1fe2af3421bb3837208e7b81da492eae375d72f1

[daniel229]

D3D9 seems better HW transform off

HW transform on

[daniel229]

It got more white colour in hardware transform off in OpenGL since https://github.com/hrydgard/ppsspp/pull/7520

[unknownbrackets]

That is very interesting. So then, it is probably related to one of stencil->alpha or blending, or possibly alpha masking / logic ops (in case that was interacting with blending.)

Blending should be src * src.a + dst * 1.0. Stencil writes zeros, which should be pretty hard to get wrong, and framebuffer is only 0/1 anyway. Texture appears fully opaque. Hmm.

Is it still changed when using 3ff51588f7b0a02b59e83c20c045c3813f4ed690, or was b5126f7236f32d7c50dd18c484ed4cd7874a2209 what made it more white? Or was it even a3342a72d70e4a38e2073e14d3b70d5e5b0e4fa3 that changed it?

Since it's blending, I wonder if this is some bug related to dual-source blending... hmm.

-[Unknown]

[daniel229]

it's https://github.com/hrydgard/ppsspp/commit/3ff51588f7b0a02b59e83c20c045c3813f4ed690 makes it more white.

[daniel229]

with https://github.com/hrydgard/ppsspp/pull/7629 ,it looks good when hardware transform off in OpenGL.

[unknownbrackets]

Neat, so that's why it wasn't drawing it.

I think Direct3D is likely to be related to dual source blending, then (since it doesn't support that.)

-[Unknown]

[daniel229]

White colour again in opengl with hardware transform off since https://github.com/hrydgard/ppsspp/commit/42bcea7b418422695bfd1be704ff26b61245f9d4

[daniel229]

comment out two of those WARN_LOG_REPORT_ONCE it works fine again.

[unknownbrackets]

That sounds scary. If they are only WARN_LOG_ONCE does it happen?

-[Unknown]

[daniel229]

Still happen.

[unknownbrackets]

Does the same happen in debug as release? Can you comment out only one of them, or if either one is there it does it?

Does changing WARN_LOG_REPORT_ONCE(minmaxz, to WARN_LOG( in both make any difference? Does it log it?

This code really shouldn't be affecting anything...

-[Unknown]