Soul Calibur: Projectiles and other hit effects lack color (reported through forum PM)

[hrydgard]

The reporter gave the following comparison videos:

PSP: https://www.youtube.com/watch?v=kjvOjlfgYJg PPSSPP (although a pretty old build, but the issue remains): https://www.youtube.com/watch?v=Yz0MIEinRf8&x-yt-ts=1422579428&x-yt-cl=85114404&feature=player_detailpage#t=142

As can be seen, most of the flashy sword swing/hit effects are more colorful on the real PSP.

Might it be some render-to-CLUT issue?

[unknownbrackets]

Can someone with this game on Windows try thy the GE debugger?

-[Unknown]

[GamerzHell9137]

This is what you need?

[unknownbrackets]

Yes, but I want to see what the other tabs look like (mainly lighting and texture, but also settings.)

-[Unknown]

[GamerzHell9137]

Here

http://puu.sh/fhUCX/ecb77dc96c.txt

[unknownbrackets]

Well: Texture L0 addr 09276cb0, w=128 CLUT 0927acb0

Could be a render-to-clut, but must be followed by a memcpy or something if so.

Hmm: Tex format 000105

Debugger needs some more formatting there, I guess. Hmm, what does that bit do??

-[Unknown]

[AizerMortenort]

@hrydgard can this be fixed?

[AizerMortenort]

Any progress?

[hrydgard]

No. If there would be any, you'd see a fix being committed.

[unknownbrackets]

Has this improved at all? I'm wondering if the render-to-clut stuff merged recently will have any impact.

-[Unknown]

[daniel229]

Still white color.

[unknownbrackets]

The texture itself is all white right? So it must be colored by lighting? Unfortunately the link to the other tabs has expired.

-[Unknown]

[daniel229]

They are all white.

others https://gist.github.com/daniel229/cea63cec86f0f311403c

[unknownbrackets]

I'm seeing again a bit in tex format, dunno what it does or if it does nothing...

This blends the white purely additively on the screen, but I see no color. I really think the CLUT is wrong.

Does it work in softgpu?

-[Unknown]

[daniel229]

No,it doesn't.

[unknownbrackets]

Hmm. Does it work in JPCSP? JPCSP doesn't seem to recognize that other bit either. If it doesn't work there, maybe there's some magic CLUT bit that does something crazy.

Another idea: if you get to the GE debugger thing above (they are all white), and then go to texture, and change the CLUT address from whatever it is (e.g. 0926e740) to that + 0x200 (so e.g. 0926e940), does it show anything interesting?

It must be getting the red/whatever color from /somewhere/... maybe it's one of the unknown registers.

-[Unknown]

[daniel229]

jpcsp does not work either.

This texture is brown? and it should be displayed as red.

This white texture should be displayed as yellow

• 0x200 to the CLUT address did not change anything.

[unknownbrackets]

Hmm. Maybe (texformat >> 8) masks out certain bits of the texture somehow?

Oh, sorry, you might have to click "Step into" after changing the clut address to update the preview. Not sure. If so, should probably fix that...

-[Unknown]

[daniel229]

Still not seeing any change.

That brown texture is just before the white texture,The white txture is what it draw.The brown one I don't know where it draw to.

[hrydgard]

The brown and white textures are probably the same texture with different CLUTs. That brown might even look a lot like red when drawn additively?

Yeah, that bit in texfmt is mysterious .. Maybe change the starting point in the CLUT? I guess that's what you were thinking with the 0x200 offset unknown?

[unknownbrackets]

Just wondered if there was colored data somewhere nearby, in case the 0x100 bit in the tex format did something like offset the CLUT? Seems weird. Actually, it would be in the loaded CLUT as you say, probably. Dunno.

-[Unknown]

[unknownbrackets]

I did some testing on a PSP and:

• Still can't figure out what the 0x100 bit in tex format does, if anything.
• White is the correct result based on the GE registers from @daniel229 - simulated the same lighting, texture, framebuffer, etc. settings.
• If material update is set to 1 (or that bit is set, at least), then red is the correct result; but it's set to 0.
• Aside from dithering, the test matches PSP vs PPSSPP.

Basically, the MODULATE tex func is being used here to make it red, but the update flag needs to be set to consider the vertex colors.

I even tried setting update to 1, drawing, setting it back to 0 (without resending any colors), and drawing again - in case something tricky happens there. No dice.

So I think that means one of these things:

1. A bug in PPSSPP is causing the game to use the wrong update value (either never writing/executing the correct one, or incorrectly writing/executing the 0.)
2. There's some tricky patching / sceGeSetCmd / etc. happening while the list is running.
3. Some weird glitch that my test is failing to trigger, and the game just accidentally works on a real PSP (seems unlikely, but who knows.)
4. Something else should be making it red that I've missed.

I suspect the CLUT is not involved here (unless it's the thing I've missed.)

-[Unknown]

[unknownbrackets]

Could you try exporting a GE debugger dump on PC? I'm wondering if there's another draw involved here.

To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.

After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.

-[Unknown]

[ChurroBoi]

@unknownbrackets Here you go, never used GE Debugger so hopefully I didn't take any missteps.

ULUS10457_0006.zip

[unknownbrackets]

This is perfect, thanks. Any reference pictures of what this attack should look like on a real PSP?

Texturing from Texture L0: 0x088e6480 (128x128) in this dump. It's using a grayscale CLUT, not unexpected. All 256 colors of the CLUT are part of the grayscale, though.

Hmm...

-[Unknown]

[ChurroBoi]

Unfortunately I don't own a real PSP and finding gameplay of this in above average quality is a bit difficult haha. Here is the closest thing I could get, Siegfrieds attacks are blue. Also just to note, when a fighter hits the ground in the original PSP there is a brown cloud of dust, however in PPSSPP it is pure white, I think the issue isn't weapon specific.

[unknownbrackets]

Hmm, this also seems like a good capture of it, more or less:

https://youtu.be/sqJejB3Ez1o?t=20s

It's from 2009, so probably not from an emulator.

Worth noting: since this is blue and the other is red, it definitely can't be some sort of swizzle or mask: the same bit is set for both. For the same reason, it also can't be dithering: the same dither matrix is used for this blue effect as the red one.

I also didn't see any cases of red being rendered offscreen, e.g. some sort of VRAM/RAM interaction. But this bug occurs in the software renderer anyway.

My strong suspicion is that the CLUT is somehow wrong (but not sure how - maybe rendered in some previous frame?), because the effect is also too opaque. Unless the GE registers are wrong, I think the alpha values should not all be a constant 255...

-[Unknown]

[hrydgard]

And there's no red / blue in the lighting or in vertex colors? We know we have some lighting bugs, for example in Virtua Tennis the lighting is only correct in the software renderer...

[unknownbrackets]

Nope. But, hmm. Actually, if I disable lighting entirely it looks bluish, maybe the right color, but too faint. Changing it to no lighting and using 2.0 * src.a looks like it could even be right, still seems a bit too faint. It does have color doubling enabled...

Maybe I need to dig up that test and see if I can make sure it's accurate. Maybe color doubling does something weird like ignoring lighting for the doubling?

-[Unknown]

[ChurroBoi]

Have investigated a bit more and it seems nearly ALL graphical effects have been 'white washed' On the original PSP at the start of a round there is small yellow nova effect when the text fades, and on a KO a large orange nova effect (linked below). All special guard break attacks have a bright lightning effect which matches the colour of the current characters default weapon trail colour and Counter hits flash a light purple, and when characters hit the floor the is a puff of brown dust. On PPSSPP however, ALL of these effects are essentially bleached white, the only effect intact is the standard hit effect. Whatever bug is in play seems to affect everything across the board. Unsure if helpful but thanks for continuing to look into it.

[hrydgard]

@unknownbrackets in https://github.com/hrydgard/ppsspp/issues/7395#issuecomment-251018769 you mention that it looks right if you modify the update flags . Maybe there's some combination of update flag bits that's not valid on the hardware? or corruption happens of the display list on the command that sets the update flags? (seems exceedingly unlikely though)..

@ChurroBoi good to know, thanks!

[unknownbrackets]

The update flag doesn't have extra bits, though - that's why I've been so paranoid about logging any extra bits.

Unfortunately, I didn't keep the test so will need to recreate. But I'm pretty sure I'd accounted for doubling...

In the GE dump, at least within PPSSPP, changing the update flag in the GE debugger after breaking on 0x088e6480 makes it super transparent, but I can't really tell if that's correct or not. It doesn't look terribly blue, but it's very faint in any case.

-[Unknown]

[unknownbrackets]

So, executing the dump as-is on a PSP nets this:

Which could mean:

• Recording, or the playback I've just created, is buggy.
• Emulation is causing the game to behave differently / not write proper GE commands.
• We're missing a render to CLUT or some other operation, and so it was not included in the recording.
• This frame is actually supposed to be white, and the slow PSP LCD is in play here (unlikely.)

-[Unknown]

[hrydgard]

Huh! Yeah now that's really interesting...

[unknownbrackets]

GE dump creation has improved a bit and might catch some of those cases (specifically the CLUT render) better. Is it possible to create a new GE frame dump of this issue?

That said, since it doesn't work in softgpu I'm not sure what it can be...

-[Unknown]

[ghost]

GE Dump. SoulCalibur.zip

[SangQuangPhung]

Today I'm giving a little info on flashy slashes hoping this will improve all characters and custom weapons getting their slash effect color back. In this picture you are seeing Nightmare swinging his sword flashily because he uses the "Soul Edge(Final Form)" equipped from Customize (this sword I don't know how to get it because I'm using the file save unlocks all on gamefaq). And that's all the information about the "flashy slash" that I discovered hope it will help the Devs to improve the bugs on this topic in the future.

and sorry for my bad English

[unknownbrackets]

That's very interesting. Does that mean this bug isn't a bug - it's supposed to be white until you get certain equipment?

Can anyone validate on an actual PSP?

-[Unknown]

[GamerzHell9137]

That's very interesting. Does that mean this bug isn't a bug - it's supposed to be white until you get certain equipment?

Can anyone validate on an actual PSP?

-[Unknown]

Can compare with PS Vita (Adrenaline) and can confirm that the effect is not properly emulated on PPSSPP. Still the same things posted above apply. Both PPSSPP and PS Vita use a new save and compared quick battles btw them. On PPSSPP its white while on PS Vita its a transparent red.

Latest PPSSPP

[hrydgard]

Yeah, seems likely that Nightmare's attack above is just a special case that renders differently.

This one remains one of the weirdest rendering mysteries...

[hrydgard]

I know from sources that the PS4/5 remaster has to hack around it, and early videos of it even show that it has the same problem: https://youtu.be/NSQrQmT6bTQ?t=215

So it's either a game or a really bizarre hardware bug and if the former, the OS is probably patching the game to fix it.

[hrydgard]

Found another video showing what it looks like on hardware: https://www.youtube.com/watch?v=-oO6DUtfimc, I think it's a bit clearer than the previous linked one.

I tried a different quick hack where we simply force update |= 1 throughout the game, doesn't seem to hurt other graphics much, the result has the correct color but is too faint, similar to previous results by unknown, maybe by about half.