Sword of Moonlight > Devs
EXIT: Let there be light
Holey Moley:
height_adjustment Patch for SOM_MAP
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.4.zip
It occurred to me that SOM_MAP uses a larger font for its event text input boxes.
Since this extension enlarges fonts, and so enlarges the text boxes, the larger box will no longer fit its text.
I couldn't reliably enlarge the text to fit the box, so instead I did a quick-fix by adding an invisible margin to fill in the space. It also works a little differently if you go beyond the bottom of the box, in which case, there might be issues if there is not room for a scroll bar in the margin.
(I think SOM_MAP does this mainly because it uses a proportional font, unlike SOM_PRM and SOM_SYS, and these boxes need a fixed-width font.)
Hopefully the larger font can be read as easily as the enlarged font. This extension is not meant to be perfect, but it's important to get the wrapping right, since that's how it appears in the game, or in the script editor if your project is well organized.
Holey Moley:
PlayStation VR Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.4.zip
I have another PSVR now. It has more or less the same characteristics as the one I returned...
I've made the text stereoscopic, even though I'm not sure what is the correct parameters for doing so, it's more clear now at every setting.
I generally cannot see much difference with the millimeter pupil distance setting, but I'm pretty confident it's correct.
I think a problem is the FOV setting. I know now that it needs to be much higher. I'm not sure how high, but in this patch I've set it to 100! I feel the best number is somewhere between 90 and 110. It's not a number that should be adjustable, but I can't really see a great deal of difference at these settings.
It's hard to believe the correct number is so extreme. You get a sense of moving very quickly at 50, and so 100 is very quick, as you can imagine. 100 on a monitor would appear ridiculous. It never dawned on me to try such settings, but I noticed that looking around a room just didn't look right, in obvious ways.
Without a more precise way to determine the FOV I'm thinking I will just wait until free-look is working and see if that helps to determine the correct FOV. It should feel unreal if the FOV is not correct. It's hard to tell with the controller though... and maybe I should try to set up a map that has a good amount of distance with many boxy things to compare.
P.S. Right now I'm working on COLLADA-DOM stuff primarily. I don't want to dive into VR again. But I wanted to check this new headset immediately. This patch has slightly less correction for greenness. I don't know if the set is less green, or it could be because I changed a correction that guarantees now pixel components are ever black to be closer to true black, whereas before it was using the first black-level that SOM doesn't treat as colorkey (although, technically it's Direct3D that did colorkey that way.)
Holey Moley:
Save Event menu scale/position patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.4.zip
This release makes menus more square for VR. I'm not sure I mentioned this here. In any case, the Save Event menu is not a fixed address (it turns out) and so it was often at a different address in the release build... but never in the debug build. This patch does a dirty fix that should work. Otherwise the Save Event menu can get scaled/positioned irregularly, often with little to nothing visible afterward.
It's always annoying when something shows up in release builds but not in the debug build, since there isn't a convenient way to debug it, and I mainly work with debug builds, and so rarely notice such bugs. Fortunately this is a good find.
Holey Moley:
PSVR color reproduction patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.4.zip
I'm quite happy with the color in this patch, under the circumstances. I feel like I can recommend buying a PlayStation VR for SOM. What I didn't expect is now (don't ask me how because I don't know) the game's Brightness setting looks good set to 0, whereas until now, I always had to crank it all the way up to be able to see color definition in dark colors.
The trick to getting half-decent color is to 1) never let pixels be pure black. 2) make dark pixels increasingly more purple, in order to overpower the green.
The question is how much to purple dark pixels and what pixels are considered to be dark. This patch adds a power-2 function to the mix, to make the map nonlinear, and I played with inverting before versus after the power-2 (square) is done. I think doing this transform in nonlinear sRGB space is not helping, but it's done so to keep it simple.
Also, because the PSVR picture is pallid, the "saturation" is ramped up a little bit. It's useful to set the saturation to 0 to "desaturate" the picture, to see if indeed looks like a b/w image, or if it is too purple or green. I've built in the potential to fiddle with these numbers, but I hope they are consistent across all PSVR displays.
The saturation is done after the lens color correction, which is not ideal, but it's not practical otherwise.
I've chosen a very conservative figure in terms of adding purple, so that the picture is neither too purple nor too green, but might be somewhat of either, but I think that the eye acclimates.
The PSVR color is pretty bizarre in general... it makes things in Moratheia that are quite clearly brown/black become bright green or blue, which is strange, because there is little to no green or blue in the pixel value if you take a screenshot and examine it in artistic software. It's hard to describe, but generally speaking it looks alight for our apparently primitive VR displays. (The sarcophagi in the final area/tomb are examples of neutral/black things that appear to be bright green/blue depending on color correction settings.)
Holey Moley:
Demo/patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.5.zip
This is actually a patch to a demo. I don't believe the demo is changed much from the current release, besides having an improved VR mode.
Specifically this patches a bug caused by the new menu squaring extension work, that slipped past me, because the player resets the menu's scaling when canceling out of the Options menu, which I of course hadn't thought to consider, because it's a completely senseless thing to do.
I also noticed that 1280 x 800 had a pixel gap in the frames that is plugged. And I'd left some squaring logic in a rough state because I believed it was unlikely, because it dealt with scaling that was taller than wide... but because the scaling is in proportion to 640 x 480, 1280 x 1024 is actually taller than it is wide, in proportional terms, so this pathway required more attention. I just luckily noticed this when trying to get to the bottom of the cancellation bug. (I can't recall if the bug happens only when the resolution is changed prior to canceling or if always, but it's probably the former case, since it took me a while to notice this issue.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version