mame icon indicating copy to clipboard operation
mame copied to clipboard

Violent Storm Palette fix

Open TheCoolPup opened this issue 10 months ago • 15 comments

For a while the colors on this game has been very washed out compared to real pcb footage but i think i found the perfect settings to fix the colors somewhat, heres a comparsion and i hope it helps

Image

Image Before

Image and after

TheCoolPup avatar Feb 22 '25 01:02 TheCoolPup

To my eye, that looks worse. It looks like when someone cranks up the saturation control on the TV to an ungodly level. Look at how it make the “GO!” text less legible.

cuavas avatar Feb 22 '25 06:02 cuavas

If you look at pcb footage apparently it's supposed to look like that?

TheCoolPup avatar Feb 22 '25 19:02 TheCoolPup

I think there's something subtle with the protection causing the 'off' colours in the first place.

There have been reports of some bootlegs having the 'off' colours and some having more 'correct' colours using the exact same monitor setup that displays the original game without it looking washed out.

Also if you go into the service mode and do the colour test, it's not showing what it should there either.

Konami did like their subtle protections, sometimes directly interacting with memory, so there could be more to it than what is simulated for the movement right now.

There's a small chance it's some non-standard resistor network on the boards though, there are other cases like that (Data East's Crude Buster) where in some cases the expected resistors got replaced with standard ones during repairs.

mamehaze avatar Feb 22 '25 19:02 mamehaze

I'd assume something simpler like the last thing you mentioned: nonlinear resistor array for r/g/b. I'd even say possibly 'gamma proms' like Namco System 22 are more likely than it being subtle protection.

happppp avatar Feb 22 '25 19:02 happppp

either way direct footage from any original PCB is far less washed out https://www.youtube.com/watch?v=0hEZvGd4whM

people aren't specifically adjusting their capture set-ups for this PCB, so it's something with the board, maybe there's even some software controlled gamma in addition to the brightness, could be a simple case of an unemulated register on the mixer chip that nothing else uses like this.

mamehaze avatar Feb 22 '25 20:02 mamehaze

The bootleg in mame has the correct colors , it's an issue with the 55555 or 55550 emulation (the bootleg cracks / patches it all out so looks good in mame)

Adjusting the overall brightness is NOT the fix.

Hammy1986 avatar Feb 22 '25 20:02 Hammy1986

I'm not seeing any difference with the overall bootleg colours in MAME apart from the service mode colour test does work there (which is a bit weird, why patch just that to work correctly, did they not know how to improve the game colours too?)

mamehaze avatar Feb 22 '25 20:02 mamehaze

could even be related to https://github.com/mamedev/mame/pull/13400

mamehaze avatar Feb 22 '25 21:02 mamehaze

It would seem like the color test palette doesn't get copied over properly (in viostorm). The palette colors are located at 0x015EFC, and the function responsible for uploading them sits at 0x012288. It interacts with the 55550, I'm not familiar with this chip. But this might be a good place to start looking into.

FredYeye avatar Feb 23 '25 18:02 FredYeye

Name Size Ram address 55550 address Value
1 300 00 0x98
1 304 01 0x00
1 305 02 0x0F
Src 4 310 04 0x015EFC
2 302 08 0x0006
Size...? 4 314 0A 0x00000080
Dest 4 318 0E 0x330800
2 308 12 0x0002
Size? 4 31C 14 0x00000040

Here's the data being written to the 55550 the first time around. As far as I can tell, it should send 16 colors (64 bytes) per transfer, and it sends every other color (4 bytes copied, 4 bytes skipped) per transfer.

FredYeye avatar Feb 23 '25 19:02 FredYeye

I wonder if some of those other params can adjust things like the contract / gamma when copying said palettes.

mamehaze avatar Feb 23 '25 20:02 mamehaze

konamigx_state::K055550_word_w():

case 0x98: {
	const u32 dst = (m_prot_data[0x07] << 16) | m_prot_data[0x08];
	const u32 src = (m_prot_data[0x02] << 16) | m_prot_data[0x03];

	for(int x = 0; x < 16; ++x) {
		mspace.write_dword(dst + x *4, mspace.read_dword(src + x * 8));
	}
} break;

My most definitely correct implementation of this memory transfer! Just needs some, uh, polish.

Image

FredYeye avatar Feb 23 '25 22:02 FredYeye

didnt even know that screen was broken hahahaha

Image

TheCoolPup avatar Feb 23 '25 23:02 TheCoolPup

In any case, this fixes the viostorm palette test. The implementation of this memcpy operation is obviously not complete, so I'll only send a PR if more qualified mame devs think I should.

If I had more test cases I could improve it, but the color test menu is the only instance of this operation I know of.

FredYeye avatar Feb 23 '25 23:02 FredYeye

use the size param and it's probably ok IMHO

doesn't solve the problem of the ingame graphics having washed out palettes, but nice to know that specific test mode case is tied to the protection.

makes me wonder if they do it with the protection there to bypass something else related to the rest of the game palettes, but who knows

mamehaze avatar Feb 23 '25 23:02 mamehaze