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
Building a better flashlight #7
Comments
Something interesting I just noticed: When you decrease the flashlight's intensity on the PC version the dynamic objects also become darker. But we don't want this. On the PS2 version, the flashlight is dimmer but the dynamic objects are the same brightness as the default PC version. I believe the PC version has addresses that control the dynamic object's illuminations separately from the flashlight? See examples below: PC version (default flashlight)Notice how bright the walls are (too bright) but also notice how bright the enemy is: PC version (adjusted flashlight)The walls are at the same/correct level as the PS2 build now but the dynamic object (enemy) has become way too dark: PS2 versionNotice how the walls in our PC adjusted flashlight screenshot are the same as in this PS2 screenshot below. However, the enemy in this PS2 shot is the same brightness as the default PC flashlight levels (first image): |
Some testing updates. The big take-away here is that changing Bigmanjapan's luminescence fix addresses to 0 instead of 2-6 makes the fix work if you also adjust flashlight levels:
✔️ Flashlight is at PS2 brightness levels and reach for environments
✔️ Flashlight is at PS2 brightness levels and reach for environments Thoughts
|
Setting intensity to 2.200000048 makes the flashlight work on 2nd preset. I guess it's fine if it does the job. Easy way to fix hotel issues would be to revert all the addresses back to default values upon James watching the tape cutscene. It seems that once the flashlight is gone some light sources take those addresses for themselves.
sh2pc.exe+542B50 (00942B50) float I don't post much for now because the flashlight system is extremely complex and it takes time to understand it and not just poke blindly. Edit: These three seem to control brightness of dynamic objects excluding James model. NOPing functions on this addresses make flashlight turning on effect stuttering, so they should be manipulated in other way. Also should take into consideration that every change that is made to dynamic objects brightness will affect cube room location. So there might be a need to make an exception function to control cube room brightness. sh2pc.exe+1B7D65C (01F7D65C) float R These control intensity of the dark part of the flashlight spread. sh2pc.exe+542A60 (00942A60) float Some common brightness? 00942C3C float Edit: Might be wise to use these addresses for Flashlight Reach, they don't reset upon transition. Similar to my and Aero's flashlight intensity addresses. sh2pc.exe+3F7A88 (007F7A88) float - controls light reach in every rooom besides mannequin room? Edit: Not sure thre is a need to decrease light reach value? It's a direct reason for "Dynamic objects do not smoothly fade when leaving flashlight's reach" issue. |
The only concern here is: What if someone loads a save file after the hotel tape cutscene?
These are good ideas! And I apologize: I used the wrong word previously. I should not have said they need to "glow." Instead, they need to have areas where light touches them to be brighter (while the flashlight overall remains dimmer). Here's what it looks like when I increase 00942B50: ^ While the mannequin is back at the right level all the dynamic objects' shadows no longer have an influence on themselves. (This would happen in the multiple rooms I tested.) So this is something we would not want to do...
Nice! I know you want to find another solution due to the flashlight stuttering but this seems to fix the dynamic objects' levels without touching our dimmed down flashlight levels. So that's a step in the right direction! I set these values to ...except for James who still seems to be dimmed by the reduced flashlight levels: ...and there is automatic flashlight stuttering in Room 205:
Personally, if we can make the flashlight work and look good for all other areas of the game then I don't think people would mind much if the just cube room goes back to vertex lighting.
I adjusted the flashlight reach levels to make it more similar to the PS2 version. There may be another way to achieve this? It depends on how "true to the source" we want to make it. Lastly, from your video here Bigmanjapan I was able to re-create the PS2 noise grain filter nearly perfect. Here is what I changed:
Here is a comparison: |
Notes for posterity: I know we aim to not use these addresses but I'd like to mention they negatively affect the water.
|
A little more experimentation. I have not done a full play through with these settings:
Notes: |
I suggest doing this one section at a time. Let me know if you have any trouble with it. Ask @Polymega what this feature should be called if you're not sure what to name it. Please look at line 00000002 of the code below. If this is not possible, then you could try excluding all values that aren't 7.0 float instead. Replace
This reduces the brightness of movable objects for specific rooms so that they no longer appear to glow.
Changing the preset value solves a few issues, like the old double-sided flashlight bug and brightness inaccuracies.
Same exact code as above, just different memory location for the
Extends the distance of the flashlight so that NPCs don't suddenly become dark.
Increases the maximum flashlight brightness of movable objects. This ensures a completely smooth transition when turning on the flashlight.
|
Maybe: @AeroWidescreen I'm really proud of what you've accomplished here. This fix is a beast, to say the least. The flashlight is such a pivotal tool in the game that will naturally affect so many things (read: memory addresses), that this was no walk in the park to implement--and to implement as well as you did. This was an off-and-on again project that took months to perfect, as the flashlight adjustments could change other things that one might not readily expect. I hope that anyone else reading this will really appreciate the time and talent Aero_ put into this, just the same as what all other team members do for all sorts of other fixes for the game. Throughout the many iterations your fix went through, I'm honored to have play tested them all, and to see your work and approach grow was a bit inspirational. Thank you once again for lending your talents in improving such a damn important part of the overall experience to this game. |
Thank @AeroWidescreen! I will work on these ASM functions once I finish the one here. |
@AeroWidescreen, are the "Otherworld Hotel Kitchen" and the "Otherworld Hotel Stairwell" supposed to use the same addresses?
|
I think that was a typo. It should be this (only showing the memory addresses, not including any ASM below):
|
@Polymega, @AeroWidescreen, below is my first attempt to add this feature into the module. Take a look at it and let me know if I made any mistakes. I did some quick test, but not sure exactly what it is supposed to look like. Test module: d3d8.zip Note: this only works on v1.0. |
Awesome! Thanks Elisha. I have an immediate observation for this fix:
|
The crash is being caused by this section of the code:
You're putting "3F333333" in the brackets, instead of the address. Kind of surprising that this was the problem, considering how easy it is to mess up the rest of the code. lol |
Thanks @AeroWidescreen and @Polymega, Try this one. It should no longer crash: d3d8.zip |
This was probably the hardest fix to implement over all the recent fixes we've been adding. And... with the exception of that one little snafu at the beginning... everything worked great! Well done! Great work with its implementation Elisha, and excellent work once more for your creation here Aero_!! |
@AeroWidescreen, I am working on converting this code to work on all versions of SH2. However I am having trouble figure out how get several addresses programmatically. In the test module I just hard coded the addresses for v1.0. Any idea how to programmatically get these addresses?
|
@elishacloud Try this. Location of pointer (v1.0 exe): 0047C309 008037E0 0047C309, Offset +24, Offset +680 = 007F72F0 0047C309, Offset +34, Offset +2A0 = 007FEB10 0047C309, Offset +34, Offset +490 = 007FED00 |
Thanks @AeroWidescreen! That is exactly what I needed. Here is an update that should work on v1.0, v1.1 and DC. Take a look at it and let me know if there are any issues with it. Testing module: d3d8.zip |
@elishacloud |
Thanks @AeroWidescreen, code for this is in check-in eb54c20. |
Sorry for the slight delay. Like Aero_, I didn't do full playthroughs for all versions this go-around, but tested all the specialized rooms/cutscenes that this fix adjusts (where it's most likely to break) and it all works great across the board. Great work again, gentlemen. |
Thanks @Polymega. We are one step closer to releasing the next update. |
Yes sir. @AeroWidescreen would you want to finalize the lighting transition bug fix for this release as well? Version 2 of your Cheat Table has it all working and just needs one additional room added to it, and light address value changes for two of the areas to complete it. (Please ignore all the specularity posts below in that thread. The conversation migrated to an appropriate thread later on.) |
What an amazing--and amazingly-challenging--fix this turned out to be. But Aero_ shined brightly and Elisha ported it home. And thanks to Bigmanjapan for much of your research with the flashlight as well, which absolutely helped in many aspects! An update has been released with this fix in it. See v1.3.1340.0 |
Edit: I did my final edits to this ReShade filter tonight. I changed the flashlight intensity value from 2.400000095 to 2.200000048.
@AeroWidescreen @Bigmanjapan
With how much work and testing has been done and continues to be done to fix the flashlight I felt it would be best to dedicate a thread just for the topic at hand. Specifically because this thread is about shadow castings which is unrelated to the flashlight illumination issues.
So what are the four main goals in fixing the flashlight? Well, three you already know about and I'd like to introduce a fourth goal:
Why am I suggesting dimming the flashlight? Please see here:
http://enhanced.townofsilenthill.com/SH2/comparisons/flashlight.htm
What you are seeing there is four images:
What I have been doing the past several days is making a "PS2" filter for ReShade. The goal is to simply apply this filter for the most PS2-like visuals on the PC version. I've been tinkering and fine-tuning the settings as best as possible. I could get the filter to look so close to the PS2 version in regards to gamma, contrast, and overall levels except for areas that involve the flashlight.
After a bit of confusion I finally realized: It's because the PC version's flashlight is overall brighter than the PS2 builds.
So using Cheat Engine I changed the following:
And that is the results you see in the link above.
Now, the big question is: Is it worth changing the flashlight levels for a more PS2-like experience? After playing around some with these new levels, I kind of think so. Even when the "PS2" filter is off, and you're playing the game with the default visuals, the adjusted flashlight levels still look more "right," in my opinion. Additionally, maybe it could make fixing the other two flashlight bugs easier? (The backlighting and dynamic objects going to full brightness first.)
I'd suggest you guys try these settings out for yourself and tell me what you think? And remember: If you used these adjusted light settings in conjunction with the PS2 filter I'm making it'd look that much better.
But changing these settings comes with odd visual bugs. When you turn the light on it goes to full brightness (float 7) before jumping back down to 2.200000048 (also note that values 4-7 don't change the light levels... after 4 it stays at max brightness). Also, when entering a new room the flashlight will very quickly flicker from brightness 7 back down to 2.200000048. And naturally--and unsurprisingly--enemies/dynamic objects still glow to a higher brightness before dimming back down.
Also, I have not done a full play test with these changes in effect yet so it may crash the game; I'm not sure.
What's your thoughts, gentlemen?
The text was updated successfully, but these errors were encountered: