Fixing Font rendering (Still an active WIP) -- Owen Meyers

     Like all games, Project [REDACTED] needs a HUD in order to display information to the player. The original system for displaying text in our game was functional, but not particularly good. It was thrown together in haste, and it clearly shows. In order to rectify this, I scrapped it and rebuilt it from scratch. It's still an active work in progress, however, I can very easily give a brief description of the problems. First, it was unreliable in placing the text. Text that was placed in one position on one screen resolution would be in a different position if the screen resized. That text would also have to be placed mathematically OUTSIDE the screen in order to be shown properly. Clearly, if we wanted to resize the screen, we'd need a better system. Secondly, the font itself was rather fuzzy and had a strange reverse scaling issue, where smaller scaling values resulted in a larger font. Both of these needed to be addressed to make the font a bit better on the viewer.

    The first problem was resolved by changing how the text quads were generated. Essentially, they were being placed about a central pivot point that was in NDC space, but all the conversions were done at the wrong time. Some coordinates would be in NDC while being used in a math operation with a coordinate in screen space. I fixed this by simply remaking the math behind generating a quad. The pivot point was moved to the top left corner of the text to make it significantly easier to place. This introduced a new problem, however, as some text that needs to be centered in the screen needs more math in order to place properly, namely requiring a measurement of the string's length first. That's a problem that can be resolved by simply adding a helper function to measure a string's length in screen space for use in positioning calculations.

    The second problem was resolved by generating a new font layout texture. This was done using a third party tool that would generate a text atlas from a given font. I generated the font to be 256 points large, thus giving us a high resolution texture to work with. This resulted in more crisp text at larger scales, but also fuzzy letters at smaller scales. This is because of bilinear filtering that is happening over the UI layer, when it should have no filtering at all. This still needs to be resolved and will likely be relatively simple to resolve.

The regenerated font texture. It's white text with a transparent background, sorry for that. The font texture is larger than the previous one by about a factor of 5.


The text generated on the HUD. It's higher resolution than the previous text, but notice the slight amount of fuzziness on the edges. Also note the slight artifacting on some characters. This is the result of faulty UVs that need to be accounted for.


Comments

Post a Comment

Popular posts from this blog

Adding assets to every enemy -- Owen Meyers

Image
      As with every game, it is very important to have assets to denote which enemy is which. Being able to tell at a glance what enemy you are encountering before receiving a face full of buckshot is incredibly important. The issue for Project [REDACTED] is that we didn't have any artists working full time to deliver assets for the enemies. Thus, it fell upon me, the designer of the asset pipeline, to acquire assets for every enemy. This led to having to fix models and integrate animations, with each problem being subtly different.     Take, for example, the shotgunner model. His original model was designed for an OpenGL renderer, and was flipped 180 degrees for that very reason. In addition to this, he was also placed halfway in the ground, likely due to something required for that game's collision to function. Fixing this model to function for our renderer required that it be re-rigged and most of the animations acquired from Mixamo. With the help of Kris, and several hours
Read more

Sphere to AABB collision

       I had a problem today when trying to detect sphere to AABB collision. For some reason the collision check that I made was never turning true even though I could clearly see the sphere hitting the AABB. This was a big problem as we needed this collision to detect whether any entities are hitting walls.     I discovered that the problem with this bug was that I was improperly getting the closest point in the AABB to the sphere. The way I fixed this problem this problem was by getting the max vertex that the circle center could be and using that to get the closest point on the AABB to then determine the minimum vertex between the sphere's max vertex and the max of the AABB.  Once I found this point, I could properly compare the distance of that point to the center of the sphere. This solution will allow detection between walls and any sphere collider such as the player collider, and enemy collider. This is very important to make sure they both stay within the level bounds.
Read more