[WIP] Fix silent hill snow

[iwubcode]

A while back I looked into why silent hill snow wasn't rendering. What I found was that this hack is actually keeping snow from being outputted.

Talking on IRC, we are still not sure why this is. I'm going to investigate more (at some point) but for now just curious to see how much taking out this hack breaks other games.

[phire]

Do note, you haven't actually removed the hack, that would require always running the code from the if block above.

What you have actually done is made the hack even less accurate. The correct behaviour is to write the texture to memory. With efb2tex, we write zeros to memory instead of the texture. WIth that commented out, we write nothing to memory.

The efb2ram path works correctly right? I wonder if the function that writes zeros to memory has a bug and is overwriting a few bytes that it shouldn't be overwriting.

[iwubcode]

What you have actually done is made the hack even less accurate. The correct behaviour is to write the texture to memory.

Fair point, doing nothing is still a hack.

However, it isn't clear to me what that code is actually doing and so I wondered what would break if I took it out.

I'll admit, I'm still feeling my way through a lot of Dolphin code. For this issue, I put print statements in every single invalidate call (in TextureCacheBase) and nothing got hit. I would expect it to be hit because otherwise why would the snow be disappearing?

I've mentioned this before but comparing the hash against zero'd out memory doesn't make sense to me because then the two hashes would never be the same, so we'd always hit that branch in Load()...

The efb2ram path works correctly right?

Yes it does.

I wonder if the function that writes zeros to memory has a bug and is overwriting a few bytes that it shouldn't be overwriting.

Even though I don't understand the zero'd out memory, I did think of that. It's probably another angle I need to look at but I wanted to understand what the zero'd memory was even accomplishing. Hence why I posted this early (also to get this out in the open, in case others had ideas).

[iwubcode]

phire was a great help but this pull request is not close to ready. Closing for now.

[mimimi085181]

The point of zeroing the memory is to track if the cpu thread has written something to that memory offset, a new (non efb) texture for example. In that case, we wouldn't want the efb copy to be loaded, but a new texture to be created from the data in memory.

If i had the game, i would check if everything is even accessing the same memory, so where efb2ram writes the data to memory, which data is zeroed on efb2tex, and which data is actually hashed. Like, if it's hashing even 1 byte too much, then the hash would include data that would randomly change, causing Dolphin to seemingly randomly deciding to not load the efb copy.

Also, i would check if Dolphin actually uses the efb copy texture that is created, or it creates some normal texture with the data in memory.

[phire]

It appears that this is more of a CPU issue rather than a GPU issue.

The snow gets baked into a fifolog, Recording a fifolog with efb2ram on (or patched out zeroing) results in a fifolog with snow, that plays back even in efb2tex. Recording a fifolog with with efb2tex results in a much smaller fifolog that doesn't have any snow even when you play it back with efb2ram.

This is possibly the point where you break out the memory breakpoints and start debugging the game.

[degasus]

@phire Have you checked that on single core? Were there some async operations like efb access?

[mimimi085181]

Well, i thought something really weird was going on. Does this patch(removing the zeroing of memory for efb copies on efb2tex) make the snow visible on efbtex or not? If it does, i'd say the snow is there before the efb copy, or i don't know, something really weird. If it doesn't, it seems like a regular efb2ram "issue", meaning, it just needs efb2ram.

Something else to test would be to load efb copies without checking the hash. If that works, the snow is part of the efb copy and whatever is going on is just confusing Dolphin.

[phire]

I'm suspicious that it's just a regular efb2ram issue which happens to work (but not 100% accurate) when the original memory backing the texture isn't overwritten.

[iwubcode]

@degasus - For what it's worth, I always test (and play) my games on single core now (after games like Disaster have issues, I just don't bother with dual core).

@mimimi085181 - yes this patch did fix the snow for efb2tex.

Also, I did a quick check the other day and looked at the "CalculateHash" function and it does seem to be an exact overlap with what the zero'd out memory is doing.

Phire and I talked about this on IRC the other day and think it's something in the game code, so not directly related to the graphical operations.

@phire - curious why you think it's related to CPU, is it because it's not reproduce-able in fifolog? Is it possible there's just an issue with fifolog where it's saving something and then the game is using that state? I have no idea how fifolog works.

Also, why would it be a efb2ram issue when it works in efb2ram? Did you mean efb2tex?

Are blocks' data laid out sequentially or as they would be in a texture? Ex: if the memory is 2x2 in a 4x4 block are the pixels in the first 4 spaces of the first row or the first two spaces of the first two rows? Documentation made it seem like it was the first 2 rows but wanted to make sure.