Improving Ascii.png for 960x720

Create issue
Issue #58 resolved
Kill-o-matic created an issue

Okay, this will be a bit complicated to explain. While I was trying to figure out how image sprite editing and replacement works, I've noticed that there was a serious inconsistency in th14 and th14.3 when running in 960x720 - namely that glyphs from the main font in Ascii.png are not positioned on the same vertical baseline, to the point that some get clipped. (bottom screenshot)

I played around with the file and was able to fix this (middle centre screenshot) by moving the 2nd and 3rd row up and the 5th row down, I also moved only the ^ on the 4th row down, because it was getting clipped. (Final modified PNG is in the middle right). However, when I tried to remove the characters on the 4th row that I hadn't modified, to reduce the image size, something weird happened. Clipping artefacts (middle left screenshot) started to appear near them, even though they weren't there when thcrap was replacing those sprites with identical ones. I have no idea how that is possible, but regardless, there should probably be some kind of alignment fix included in script_latin in the future.

On a related note, as part of the translation I'm doing, I also modified the images (top row PNGs) to change every instance of the decimal mark (framerate display, spell timer, power value and bonus multiplier) from a dot to a comma and got rid of the thousands separator comma from the score display (by putting a single semi-transparent pixel in its box), as is the standard in most of Europe. Now, I'm no artist, so these may look quite ugly, and I don't know if anyone else will care about decimal marks, and I don't feel like figuring out how to work with Github for something that minor, but I'll leave the images here in case you think the idea has any merit.

Comments (5)

  1. nmlgc repo owner

    You might have noticed that the edges between adjacent sprites in the sprite boundary images appear to be two pixels thick, rather than just one. It might not be obvious, but this tells you exactly and unambiguously where one sprite ends and the next one begins.

    This shows that the top pixel row of the tall glyphs in the 5th line (h, i, j, k, l, and t) of the original image actually bleed into the 4th line by one pixel. Therefore, moving down the 5th line of glyphs correctly would simultaneously modify the 4th line, too. By deleting these seemingly unmodified original glyphs, you effectively kept the sprite bleeding from the 5th row.

    I repeated the steps to fix ascii_960.png on my end and encountered no further artifacts. I also compressed the capital W by one pixel in order to make it fit within its own sprite boundaries. The final fixed image is now included in base_tsa, as this is essentially a fix of original game data, independent of any language or script.


    I have been thinking about correctly localizing decimal and digit group separators as well. However, things are not as easy as simply inserting corrected images into script_latin, as there are still enough Latin script languages which do use decimal points and a comma for digit grouping. (In the case of Spanish, they would even differ between European and American variants.)

    The comprehensive solution to this issue would be to introduce a new patch that only switches these separators, and to then add a dependency on that patch to every language that needs it. However, this would require people to reconfigure their patch stacks to see it. I consider this to be another problem in itself, and it really does feel like a flaw in the whole design of patch configuration. I've already had to tell people to reconfigure once - after the introduction of script_latin in 2014-01-03 - and I've received enough complaints about glitches from people who didn't read that note on the download page.

    Therefore, I decided to put off dealing with the separator issue until I would have reworked patch stacks to automatically reconfigure itself whenever dependencies are added or removed. Especially now that every other part of the system is capable of updating itself, this really shouldn't be a problem either.

    So it's probably best for every translation patch to do these changes on its own, at least for the time being.

  2. Kill-o-matic reporter

    Well, obviously ZUN doesn't do the whole "testing your games for obvious mistakes" thing. Th14.3's ascii_960 clearly has the sprite borders clipping "Bonus" to the right and "Rest" to the left. I left the "Failed" sprite in there (even though I didn't see it used anywhere in the game), minus the clipped bit from "Rest", just in case. I'm not sure where this should go, as it will only be useful for the lang_en patch and its derivatives.

    And shouldn't images that come with a certain patch's dependencies (and thus will be stacked before any further modifications are made) be visible along with the source PNGs in the wiki page for that language's images? Otherwise, it's kind of confusing seeing things in the game that you didn't edit in.

  3. Log in to comment