Archive:
Eased back into work with an engine upgrade. Yes, I know, I should wait for 4.26.1, but I was feeling brave and tbf, UE4 upgrades have been a complete doddle compared to the constant nightmares I had with Unity.
Interestingly, the upgrade uncovered a couple of race conditions in one of the NPCs; stuff that never should have worked. I always feel a bit weird when I fix bugs like that, but, touch wood, that was about the worst of it.
Made some changes to the camera, played through the build looking for breakages, and tried to work out what I want to do for the rest of the week. Told you that I was easing back in…
Went through the bug spreadsheet and fixed most of the issues found in my Xmas build. One thing that popped up was support for Ultra-wide monitors.
I’d not considered these in the slightest, but one of my Beta buddies sent me some screenshots. By default, UE4 preserves camera-sensor width -> viewport width, which means ultra-wide monitors have a greatly reduced vertical display. This is immediately obvious in interiors, as you can only see half the room.
I have to admit, I was a little puzzled about how to fix this. There’s nothing in the camera that really helps. Restricting the aspect ratio leaves black bars on the sides of the screen, which I’m guessing makes the ultra-widers cry. To make matters worse, I’ve, ahem, done some cheeky changes to the camera settings to get the amount of depth of field that I want: rather than use a standard 16:9 filmback setting, I’ve created a really really narrow camera sensor (>10:1), in order to have stuff like the tree-tops, and dungeon walls, fall out of focus even though they’re 5-10 meters above the player’s head… It’s like a dodgy tilt-shift effect.
I tried a few different things before it dawned on me… I’m already doing Cheaty McCheat camera-sensor dimensions. It’s not going to hurt to scale them even more… So now, if the camera detects the viewport's aspect ratio is greater than 16:9, it’ll scale the sensor-width by the difference. Minus a bit of a fudge factor. It’s only doing this on map load, so if you start scaling the window expecting it to update, it won’t.
There’s a fair bit of fisheye on the edges of a 21:9 display, but that’s what you get for having a stupid monitor in the first place.
More bug fixing.
Another Xmas build issue: I’m not supporting HDR. I assumed UE4 would do it by magic if Windows was already set to output HDR. It doesn’t.
I don’t develop on an HDR display, so the Xmas build (on Steam) was the first time I’ve seen the game on my OLED, and it looked very washed out. I need to add an option somewhere, so I toggle HDR. And ideally, it should detect it on boot. Dug into it a bit and worked out what I need to do.
Started working on the Settings screen. Managed to get some layout done, but I’ve not had time to wire it up.
My settings screen is all wired up. I’ve not tested HDR yet. I need some time in front of my OLED, but my other half uses the lounge as her office during the day. Weekend job.
I also added a “Build Notes” pane to the main menu, so Beta Buddies can get a quick heads up on the changes.
Background Music wasn’t playing correctly (at all) the second time you entered the game, so I fixed that.
Sword Charge & Spin Attack VFX have been broken since the 4.26.0 upgrade. It appears to have been to do with FObjectFinder in the constructor. Removing that, and replacing the assets in the blueprint with straight dupes fixed them both. Am now wondering if this is a problem with all Niagara systems that have path references in the C++ constructor.
And finally… I’ve had fuzzy shadows forever, almost like a broken screen-space effect (see below) so I decided to dig into it.
Turns out, the contact shadow length on my directional lights was too large, which caused the fuzz. Pinging that back down to something sane, in world units, got rid of it entirely.
Holy Shit that looks better.
Made a build to test HDR on my OLED and fell down a rabbit hole.
Windows 10 tells my TV to go into HDR, but it’s not clear if it’s actually sending 10bit colour to the telly, or not. A TV being in HDR mode and a TV displaying HDR content are two different things.
When toggling HDR, UE4 will clamp to the closest “best” settings it can get, but it does so pretty much silently. So, bit of a debug ‘mare, but I did finally sus it.
First, you may want to force Windows 10 to actually output 10bit colour. You’ll most likely have to use the Nvidia colour settings to output YUV422 before this is even an option. My lounge PC needed this to be manually set. My laptop (Dell XPS15) seemed to be fine, but it’d already been configured with the Dell pro colour sw.
Second, toggle HDR somewhere sane, after start-up, like your splash-screen’s level blueprint. If you do it too early, things will pop.
Bit of a detour, but I’m much happier now that it’s sorted. It’ll sing once I do some colour grading.
