Added rudimentary support for font outlines.

Daverball commented

2014-12-25 23:50:00 +00:00

(Migrated from github.com)

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.

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.

Daverball commented

2014-12-26 04:40:09 +00:00

(Migrated from github.com)

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.

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.

Daverball commented

2014-12-26 19:22:43 +00:00

(Migrated from github.com)

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.

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.

Ancurio commented

2014-12-27 07:56:19 +00:00

(Migrated from github.com)

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.

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`.

Ancurio commented

2014-12-27 07:58:06 +00:00

(Migrated from github.com)

Also, it is generally good practice to make separate pull requests for issues that are unrelated.

Daverball commented

2014-12-27 12:39:31 +00:00

(Migrated from github.com)

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.

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.

Daverball commented

2014-12-27 13:23:57 +00:00

(Migrated from github.com)

whoops I commited all changes by accident in the same commit, I'll get that fixed.

Ancurio commented

2014-12-31 10:02:10 +00:00

(Migrated from github.com)

After visually comparing it with RMVA, you should definitely do the outline application after applyShadow.

After visually comparing it with RMVA, you should definitely do the outline application after `applyShadow`.

Daverball commented

2014-12-31 12:25:28 +00:00

(Migrated from github.com)

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?

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?

Ancurio commented

2014-12-31 12:37:31 +00:00

(Migrated from github.com)

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?

RMVA: ![rmva](https://cloud.githubusercontent.com/assets/1173822/5587654/a438999e-90f1-11e4-9453-2cad4d493205.png) Your impl: ![mkxp1](https://cloud.githubusercontent.com/assets/1173822/5587656/ae1bbe6e-90f1-11e4-8adf-a809f2a7c289.png) With my suggested change: ![mkxp2](https://cloud.githubusercontent.com/assets/1173822/5587659/b68513a2-90f1-11e4-9552-985bcbb76bc2.png) 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?

Daverball commented

2014-12-31 12:44:12 +00:00

(Migrated from github.com)

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.

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.

Ancurio commented

2014-12-31 12:49:08 +00:00

(Migrated from github.com)

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.

Daverball commented

2014-12-31 12:54:52 +00:00

(Migrated from github.com)

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.

Ancurio commented

2014-12-31 13:10:20 +00:00

(Migrated from github.com)

Here you go: https://www.dropbox.com/s/2spu08m22n6gwix/CleanVA.zip?dl=0

You can also uncompress your assets with ttm_unpack.

Here you go: https://www.dropbox.com/s/2spu08m22n6gwix/CleanVA.zip?dl=0 You can also uncompress your assets with [ttm_unpack](http://ancurio.bplaced.net/mkxp/ttm_pack/).

Added rudimentary support for font outlines. #83