Coat of arms renderer discrepancies

[crschnick]

# rotation; I'm not sure if it is all the same issue or different problems
BUK_absolute_monarchy
CHI_theocracy
PAN
PRU
PRU_subject
SAF_ensign
TRH
WAL_subject
# missing a color; these coas seem to missing a color for one of their colored emblems.
# This color is pink in the game, but black in pdx-unlimiter. But the missing color is likely a game bug so it is not really important
CAS
HOH
SIK
SMI_sweden
WLS_coa

[crschnick]

Reference files: comparison_1.0.6.zip

[crschnick]

About SIL_subject: How exactly does the game arrive at that scaling? The only sub has a x scale of 1.0. To me it looks like the game kinda uses a x scale of 0.5. But where is that defined? I don't really get it

[crschnick]

Or is there some kind of aspect ratio preserving logic? I.e. it will apply the smaller scale on both axes to somehow preserve the aspect ratio?

[grotaclas]

I did some testing with SIL_subject and I think the issue is that the scaling for the sub is capped so that it can't be partially outside the flag. The x-offset is 0.5 for this sub, so the x-scale gets reduced to 0.5. Changing the offset, affects the maximum effective value for the scale. SIL_subject seems to be the only flag where this happens. It can be fixed with the following patch, but I don't know if that's the best place to add this check.

diff --git a/pdxu-model/src/main/java/com/crschnick/pdxu/model/CoatOfArms.java b/pdxu-model/src/main/java/com/crschnick/pdxu/model/CoatOfArms.java
index 8f297a50..297f62ed 100644
--- a/pdxu-model/src/main/java/com/crschnick/pdxu/model/CoatOfArms.java
+++ b/pdxu-model/src/main/java/com/crschnick/pdxu/model/CoatOfArms.java
@@ -2,6 +2,7 @@ package com.crschnick.pdxu.model;

 import com.crschnick.pdxu.io.node.Node;

+import java.lang.Math;
 import java.util.ArrayList;
 import java.util.HashMap;
 import java.util.List;
@@ -164,8 +165,8 @@ public final class CoatOfArms {

                 var scale = instanceNode.getNodeForKeyIfExistent("scale").orElse(null);
                 if (scale != null) {
-                    sub.scaleX = scale.getNodeArray().get(0).getDouble();
-                    sub.scaleY = scale.getNodeArray().get(1).getDouble();
+                    sub.scaleX = Math.min(scale.getNodeArray().get(0).getDouble(), 1 - sub.x);
+                    sub.scaleY = Math.min(scale.getNodeArray().get(1).getDouble(), 1 - sub.y);
                 }
             }

The offset seems to have a minimum of 0, but no maximum, so that an offset above 1 will move the sub completely out of the flag, so it isn't visible anymore.

None of this seems to apply to colored_emblem or textured_emblem which can be (partially) outside the flag with a big scale.

[crschnick]

that sounds like a bad system, what if I want to intentionally cut it off at the border? Would that not be possible?

[crschnick]

the rotation issues you listed are likely caused by the fact that your algorithm to scale the instances when rotation is involved does not exactly behave as in game for rotation angles that are not a multiple of 90

[crschnick]

I applied your patch and pushed a fix for the wrong colors

[crschnick]

Have you tried how the game handles the scaling limitations that you patched in case the scale is negative?

[grotaclas]

that sounds like a bad system, what if I want to intentionally cut it off at the border? Would that not be possible?

Maybe you can apply a mask to cut something off.

Have you tried how the game handles the scaling limitations that you patched in case the scale is negative?

I didn't test that when I wrote my patch. I tested it now and it seems that a negative scale always makes the sub disappear. It doesn't flip it like with textured/colored emblems. So pdx-unlimiter still behaves incorrectly in this case. Maybe we can also apply a minimum scale of 0.

the rotation issues you listed are likely caused by the fact that your algorithm to scale the instances when rotation is involved does not exactly behave as in game for rotation angles that are not a multiple of 90

I think I tried using a scale based on the actual angle, but it gave worse results at least in some cases. But I might have done something wrong, so you could try another approach.

[grotaclas]

The reason for the "weird line in the middle", and "pattern on the outside is missing parts of it structure" and some of the color changes is that applyMaskPixel changes the color values and the alpha. But it should actually only change the alpha.

The following patch fixes this and uses 255,0,255 as the "missing a color" which was responsible for several other color changes as well in cases where the pink default of the game blends into other colors:

diff --git a/pdxu-app/src/main/java/com/crschnick/pdxu/app/gui/game/CoatOfArmsRenderer.java b/pdxu-app/src/main/java/com/crschnick/pdxu/app/gui/game/CoatOfArmsRenderer.java
index 59f43623..0fc18f7a 100644
--- a/pdxu-app/src/main/java/com/crschnick/pdxu/app/gui/game/CoatOfArmsRenderer.java
+++ b/pdxu-app/src/main/java/com/crschnick/pdxu/app/gui/game/CoatOfArmsRenderer.java
@@ -146,9 +146,9 @@ public abstract class CoatOfArmsRenderer {

     public javafx.scene.paint.Color applyMaskPixel(javafx.scene.paint.Color colour, double maskValue) {
         return new javafx.scene.paint.Color(
-                colour.getRed() * maskValue,
-                colour.getGreen() * maskValue,
-                colour.getBlue() * maskValue,
+                colour.getRed(),
+                colour.getGreen(),
+                colour.getBlue(),
                 maskValue
         );
     }
@@ -176,8 +176,8 @@ public abstract class CoatOfArmsRenderer {

         var colors = getPredefinedColors(ctx);
         return color != null
-                ? colors.getOrDefault(color, javafx.scene.paint.Color.TRANSPARENT)
-                : javafx.scene.paint.Color.TRANSPARENT;
+                ? colors.getOrDefault(color, javafx.scene.paint.Color.color(1,0,1))
+                : javafx.scene.paint.Color.color(1,0,1);
     }

     public void emblem(

Though I'm not sure if this pink color should be applied as a default in other locations of the code as well. I tested what happens if I used it in the other places where TRANSPARENT is used in CoatOfArmsRenderer.java, but that had no impact.

From the above mentioned problems, the following are fixed with your changes and this patch: CAS HOH SIK SMI_sweden WLS_coa GWA_republic KAT AFS_zambezi LAO_subject LUA_subject MAC MAD_republic MGL NBS MUG_absolute_monarchy. MYS_theocracy, PAN_theocracy and UOM_state_of_michigan are mostly fixed, but still have small color differences, but I don't know the reason for them. And I noticed that SIL_subject is also affected by the mask problem, so it is not fully fixed yet.

[crschnick]

The rest of the small color differences might also be caused by the blending issues for small structures. So we have to see how it looks like when the blending algorithm is changed.

[crschnick]

Now that I fixed the mask issue, I think the last area should be the blending. Can you share the coa definition that you used to render a close up of a few pixels for the emblem?