Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Violent Storm Palette fix #13394

Open
TheCoolPup opened this issue Feb 22, 2025 · 15 comments
Open

Violent Storm Palette fix #13394

TheCoolPup opened this issue Feb 22, 2025 · 15 comments

Comments

@TheCoolPup
Copy link

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

@cuavas
Copy link
Member

cuavas commented Feb 22, 2025

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.

@TheCoolPup
Copy link
Author

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

@mamehaze
Copy link
Contributor

mamehaze commented Feb 22, 2025

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.

@happppp
Copy link
Member

happppp commented Feb 22, 2025

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.

@mamehaze
Copy link
Contributor

mamehaze commented Feb 22, 2025

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.

@Hammy1986
Copy link

Hammy1986 commented Feb 22, 2025

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.

@mamehaze
Copy link
Contributor

mamehaze commented Feb 22, 2025

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
Copy link
Contributor

could even be related to #13400

@FredYeye
Copy link
Contributor

FredYeye commented Feb 23, 2025

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
Copy link
Contributor

FredYeye commented Feb 23, 2025

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.

@mamehaze
Copy link
Contributor

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

@FredYeye
Copy link
Contributor

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

@TheCoolPup
Copy link
Author

didnt even know that screen was broken hahahaha

Image

@FredYeye
Copy link
Contributor

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.

@mamehaze
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants