Added rudimentary support for font outlines. #83
No reviewers
Labels
No Label
RGSS accuracy
bug
compilation
discussion
documentation
duplicate
enhancement
invalid
performance issue
port request
question
ruby incompatibility
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: MapleShrine/mkxp#83
Loading…
Reference in New Issue
No description provided.
Delete Branch "master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Not sure if there's performance concerns with implementing it this way, but I have noticed no difference in performance over the drop shadow instead of a proper outline.
At the moment it won't respect the alpha value of the outline because of the way alpha on the text color itself is handled, don't think that's a big concern though.
Also did a small patch to hue.frag, the coefficients that were used previously would cause a lot of issues on some GPUs with white pixels turned black.
At first I attempted to fix it by clamping the values to their respective valid ranges, this however only resulted in other visual glitches. I then researched the RGB to YIQ conversion and came across a different set of coefficients that seemed to solve all visual artifacts I have been encountering with white pixels.
I've added a third small patch that I think is sensible. I've adjusted the behaviour of the keybind configuration window in such a way, that keybindings get stored whenever the window is closed instead of only when mkxp exits successfully.
This enhances protection from lost configuration data due to unforeseen crashes.
re hue.frag: Interesting, your changed values are almost identical to the previous one, some even just look "rounded down". What graphics cards where you having the issue with, and with what kind of image and hue shift?
re keybindings: Is there a reason for this change? Did you suffer from a crash that made you lose your binds? In any case, that is the wrong place to write the keybindings to disk, it would belong into
SettingsMenuPrivate::onAccept
.Also, it is generally good practice to make separate pull requests for issues that are unrelated.
Alright I'll clean this stuff up a bit and make new pull requests for the other two commits.
As for GPUs I personally have a GTX 970 so it might be some machine precision thing with the Maxwell Architecture. There are other people that have encountered this issue, but I'm not sure what kind of GPUs they were using.
It basically happened with hue shifting text bitmaps, white text with a flashing outline, achieved with hue_shift every couple of frames. The solid white turned solid black though after the first frame and after the hue_shift shader was applied.
My best guess for this behaviour is some weirdness with atan(0,0) on some GPUs, the decreased precision of the coefficient might've prevented absolute zero I and Q. I'm honestly a bit stumped myself why this change fixed it and why limiting value ranges didn't. I changed a lot more stuff in the shader originally and then reverted everything that didn't help to fix the issue, what was left were the changed coefficients in the end.
whoops I commited all changes by accident in the same commit, I'll get that fixed.
After visually comparing it with RMVA, you should definitely do the outline application after
applyShadow
.That seems like a really odd choice by the rpgmaker devs if true, have you tested it with colored outlines too? Seems weird to me that the shadow would go between the text and the outline.
Actually the TTF font outline render would cause the shadow to render on top of the outline, causing half of the outline to turn black. Does RMVA really do this?
RMVA:
Your impl:
With my suggested change:
I think there might be an issue with my shadow code too where it assumes the text surface to be monochrome, but if it works this way why not do it I think.
Also, do you not own an RMVA license?
Alright, that makes sense then, I'll get to changing it.
I do not own a license, however I also do not do any work on RMVA assets, are there any legal concerns with working on MKXP code without a license? I can totally get one, it's not too big of an expense.
No, there are no legal concerns or whatever, it's just usually better if you can verify that things which you implement behave exactly or at least close to the same as in the original engine that mkxp is trying to preserve. Actually, you don't need to own a license tbh. (I rarely even open RMVA anymore), just a game whose Scripts.xxdata you can edit.
Yeah I usually compare it with how I encounter it in the game I'm helping getting to run on MKXP and it didn't use any outline shadow combinations. I might ask for an uncompressed set of assets so I can edit the scripts and do more in-depth tests.
Here you go: https://www.dropbox.com/s/2spu08m22n6gwix/CleanVA.zip?dl=0
You can also uncompress your assets with ttm_unpack.