Hi all. I am using a custom text window and this is the result:
(http://www.wadjeteyegames.com/temp/text-align.PNG)
For some reason, the text offset is further down and to the left than it should be. Both the top/bottom and left/right images have the same amount of black space so theoretically the text should be right in the middle? Is there a way to offset the Y position of the text so it displays a few pixels higher?
Any help is appreciated!
-Dave
I know this isn't the type of solution you want. But you could just add more black space to the bottom image. That way it would appear as though the text is more centered. The only downside, is huge amounts of black space on the top and bottom of the text window.
I suggest you only do that though, if you can't find a proper solution.
Yeah that's what I tried doing, but as you say it adds a LOT of extra black space which I don't like. If there's a way around it, I'd prefer doing it that way.
Are you using a TrueType font? Bitmap font? Does anything change if you switch between the two? Hope it's not too much to ask, but if that doesn't change anything, could you try the same setup in 3.3?
In addition to what Gurok said, does the resolution of the custom text window elements have inconsistencies? (Corners are the same size, corners width = side width, corner height = top/bottom height)..
For me it looks like AGS does not use (or not enough) middle vertical part of the text box. Probably because of the way it finds the "best" combination of border parts.
It would be a great help for diagnosing the problem if you could provide the resources you are using in this example, or at least sizes of all graphic items in the text box (including font).
I've experimented with a bunch of different true type fonts in different sizes and the result is the same, but the font in the screenshot is called "Prospero Bold" and was imported at size 10.
And here are the asset images!
(http://www.wadjeteyegames.com/temp/twindow/TopLeft.png) (http://www.wadjeteyegames.com/temp/twindow/Top.png) (http://www.wadjeteyegames.com/temp/twindow/TopRight.png)
(http://www.wadjeteyegames.com/temp/twindow/Left.png) (http://www.wadjeteyegames.com/temp/twindow/Right.png)
(http://www.wadjeteyegames.com/temp/twindow/BottomLeft.png) (http://www.wadjeteyegames.com/temp/twindow/Bottom.png) (http://www.wadjeteyegames.com/temp/twindow/BottomRight.png)
One thing I can confirm is that when using TTF font the text is (or may be) printed lower than needed. I can clearly see that some letters are drawn over the bottom border.
This is reproduceable both in 3.3.5 and 3.4.0.6.
I am not sure about horizontal position, if I remember correctly, the text in the speech box is always left-aligned; but I would need to check the engine code to clarify this.
I could not get the font Dave uses, so I downloaded first random free font which looked distinct enough: http://www.webpagepublicity.com/free-fonts/c/CarawayBold.ttf
The reason is either AGS not using TTF data right, or font itself has incorrect ascent/descent property.
I made a very simple test, and found out that AGS does not properly deduce the possible TTF height. It seem to not take font descent into account (that is - parts of letters that appear below font baseline).
Explanation of font values: http://i.stack.imgur.com/LwZJF.png
This is very easy to see with following script:
String test_string = "I guess you want to know?";
int hh = GetTextHeight(test_string, eFontFont3, System.ScreenWidth);
DrawingSurface* ds = Room.GetDrawingSurfaceForBackground();
ds.DrawingColor = Game.GetColorFromRGB(255, 255, 255);
ds.DrawLine(0, 100, System.ScreenWidth, 100);
ds.DrawLine(0, 100 + hh, System.ScreenWidth, 100 + hh);
ds.DrawingColor = Game.GetColorFromRGB(255, 0, 0);
ds.DrawString(20, 100, eFontFont3, test_string);
ds.Release();
What this code does: it draws two white lines with red text in between. The white lines are separated by the font's height, at least they should be, but in reality some letters may appear partly beyond bottom line.
Probably AGS gets TTF's height as a difference between Ascent and Baseline, and not Ascent and Descent, as it should have.
EDIT: Scrapped the conclusion, I am not sure yet. Something is wrong either with font data, or library that reads it.
I need to experiment with the FreeType library code first.
EDIT2: It also could be that the font height is correct, but the text is drawn lower than expected. Still this mistake occurs somewhere in the FreeType library.
Unfortunately, I've found, the ascender/descender metrics embedded in the font data are not very reliable as indicators of how far up or down the character glyphs can go. And I actually don't think that's really the purpose: they're more sort of reference lines for the "typical" ascender/descender. (But even for that use, the values are not set correctly for many fonts.) I don't know of any accessible values that define any kind of bounding box that characters are guaranteed to fit within. This is part of what makes font rendering so tricky and bug-prone. It could very well be that FreeType has bugs that are more evident in low-resolution contexts like AGS games than in most other applications.
Quote from: Snarky on Sat 02/04/2016 20:42:09
This is part of what makes font rendering so tricky and bug-prone.
That actually explains a lot. Now I know why I've always had weird bugs when using fonts in all sorts of different applications.
Huh. Interesting that this is the first time this issue has come up? Or is this something specific to TTF fonts?
That said, instead of playing around trying to fix out the font issue, a cheap fix would be to give the developer the ability to offset the x/y position of the text within the window? That's what I was hoping to do in the first place. :)
I was going to try out a newer version of FreeType library, because AGS uses a very old version of it, to see if that may help.
As for the workaround, this is a viable idea as well, although I believe this offset property should be applied to Font rather than Text Window, because it will be drawn wrong anywhere in game.
Quote from: Dave Gilbert on Sun 03/04/2016 19:30:17
Or is this something specific to TTF fonts?
Yes, it is. These issues I've mentioned don't apply to bitmap fonts (although there are some other issues here with lack of control over how text is positioned inside the text frame that do).
Wow. My plays with library code actually gave result. I was able to fix this error.
It appears that Allegro Font library does not tell REAL graphical height of the font, but the height you (AGS) asked it to use. Apparently it does not always match the size of letters, which could be smaller or higher, depending on how precise this font can scale up and down.
Frankly, this is quite weird...
To fix it I had to include FreeType library headers directly though, because I needed to know internal font structure.
That's amazing, CW! Thanks so much. Will this be in the next update of 3.4?
Quote from: Dave Gilbert on Mon 04/04/2016 22:25:59
That's amazing, CW! Thanks so much. Will this be in the next update of 3.4?
That may be, if I figure out how to organize these changes properly... also I would need to test this out on some existing games which use TTF to be sure they still run okay.
You're welcome to use mine once you get to that point. Just let me know.
I have an update. Some of information here is rather little help for end-user, but I wanted to post it nevertheless, for history.
The Font library AGS uses (AlFont) is of an old version, and even probably modified by Chris Jones. The latter cannot be confirmed, because we do not have its original source code, but I found that our Linux port does not use standard AlFont library, but a modified source, with changes by Jochen Schleu (JJS), and his comments in the code mention that he had to reverse-engineer some modifications from the Windows version to make Linux port work same way.
(I vaguely remember reading some post by CJ himself about modified libraries, but I cannot find it right now.)
I updated the library to the latest version available in the Web. The immediate result was that the text offset error is gone.
Applying modifications by JJS on top of that version made error return.
This means that either old versions of this library had this behavior, or it was introduced by some CJ's changes (if there were any). (And Linux port simply simulates it for consistency).
However, another comment by JJS mentions that these changes are necessary because otherwise some font heights do not work well. This makes the situation more complicated. It is possible that there was another issue with some another font long ago, that required these changes.
I may try to look into JJS's bug tracker he had when he was working on his ports alone, to find any information on why these changes were deemed necessary.
In either case, I think updating to most recent library is the way to go anyway (that was actually done for Linux port). But we will have to make sure that TTF fonts work as expected in AGS after this. We will have to edit the library source code ourselves if something is not right, because apparently it is no longer maintained (also some things may be AGS-specific).
Anyway, here is an engine built with the newest library (based on 3.4.0.6):
http://www.mediafire.com/download/j2w18bxw1yzh7o0/acwin_3.4.0.6--alfont-new.zip
Remember, this is for test only!
Git branch:
https://github.com/ivan-mogilko/ags-refactoring/commits/libs--alfont
Alright, the situation proved to be more complicated, but at least I clarified the reasons behind the changes mentioned above.
As I said in this thread before, the real (true type) fonts have Ascend and Descend parts (- upper and lower components, positioned above and below baseline). The problem with them is that if they are defined incorrectly (e.g. larger than required), the text line may appear being offset or vertically unaligned (although mathematically not being so), e.g. higher or lower than needed.
Similar thing may occur, if the font has particular letters (maybe even special characters) that have higher height, or have to be drawn higher or lower than most letters. Even though the game text may never have these characters, the font is still drawn having these in mind, which may cause text line look like it is shifted up or down.
The fonts library used by AGS had modifications that aligned font's Baseline with the bottom line of the user-defined height, making whole text being drawn slightly (or not slightly) lower than it logically should have be.
Why this was done? I cannot tell for certain, but there is one guess I have after experimenting with some games. It looks like most TTF fonts used in AGS games had increased Descend parameters (for the reasons I told above), and when they were drawn properly, having full font height in mind, most of the text appeared offset upwards. I guess someone (maybe it was Chris Jones) simply removed Descend parameter from calculations, thus fixing alignments for these fonts.
This worked well, until people started using TTF fonts with more explicit Descend usage, like the font Dave uses in his game. AGS simply draws lower parts of letters "outside" text bounds.
Now, this is real problem, because if I return the default fonts library behavior, some of the fonts will appear unaligned (this will have most effect when text is vertically aligned to center or bottom).
The only solution I see now is to add some per-font options that would control how the particular font is drawn.
For example:
- Font's height only counts Ascender (upper part). This will be backwards-compatible too.
- Font's height counts both Ascender and Descender.
This hasn't been mentioned yet, but a simple, immediate solution here would be for Dave to edit the font file. I don't know what the licence restrictions are on the font, but it's fairly easy to edit ascender, descender, x-height, whatever is necessary and save a custom version for use with AGS. There are various font editors available. FontCreator and FontForge come to mind. FontForge is also free. I know it's just a workaround, but it would take the pressure off for finding an engine-based solution.
Quote from: Gurok on Mon 11/04/2016 02:07:57
This hasn't been mentioned yet, but a simple, immediate solution here would be for Dave to edit the font file. I don't know what the licence restrictions are on the font, but it's fairly easy to edit ascender, descender, x-height, whatever is necessary and save a custom version for use with AGS. There are various font editors available. FontCreator and FontForge come to mind. FontForge is also free. I know it's just a workaround, but it would take the pressure off for finding an engine-based solution.
True, basically all he has to do is to put Baseline to where currently Descend line is.
Quote from: Crimson Wizard on Mon 11/04/2016 01:49:06
The only solution I see now is to add some per-font options that would control how the particular font is drawn.
For example:
- Font's height only counts Ascender (upper part). This will be backwards-compatible too.
- Font's height counts both Ascender and Descender.
I think it would be better to, as Dave suggested, just have a parameter for vertical text offset (baseline shift) that would allow you to shift the text up or down. And perhaps another parameter for the line spacing (leading), in case the one calculated from the ascender/descender values isn't correct. I think this would be more intuitive to work with, more flexible, wouldn't require users to look deeply into what's wrong with the font metrics, and is more consistent with the type of options offered by other applications.
Small clarification to what I wrote yesterday: current AGS behavior does not stretch ascender, nor stretch letters visually, but simply aligns baseline with the bottom line of the user-defined height. The letters stay same, but some empty vertical space is added above.
I just want to add, that I tested that test-build with some pretty old AGS games.
And... it had some really odd effects.
This is what the text was supposed to look like:
[imgzoom]http://orig08.deviantart.net/e59c/f/2016/102/c/1/supposed_to_look_like_by_danvzare-d9ynkh5.png[/imgzoom]
And this is what it ended up looking like:
[imgzoom]http://orig01.deviantart.net/5c80/f/2016/102/e/8/actually_looks_like_by_danvzare-d9ynkhb.png[/imgzoom]
Of course, I think there's more than one problem going on here, just because of how old the game is. But still, I thought I'd bring it to someone's attention.
Can you post a link to this game?
I saw similar effect in other game, but it was far less noticeable.
Apparently the library finds smaller(?) or thinner style of the font when looking for matching font size.
That looks like a high-res font in a low-res game? I know those tend to look VERY ugly.
Quote from: Crimson Wizard on Mon 11/04/2016 17:05:57
Can you post a link to this game?
Here you go: http://www.adventuregamestudio.co.uk/site/games/game/1078/
Quote from: Danvzare on Mon 11/04/2016 17:43:38
Quote from: Crimson Wizard on Mon 11/04/2016 17:05:57
Can you post a link to this game?
Here you go: http://www.adventuregamestudio.co.uk/site/games/game/1078/
I found there is more than just TTF rendering problem, apparently version 3.4.0 has some error that makes game choose incorrect font for drawing speech text. I will have to investigate that separately.
That's pretty lucky you stumbled across that one (no sarcasm intended).
Here is new test version with some fixes:
http://www.mediafire.com/download/vcxuwbtkuv2l2yd/acwin_3.4.0.6--alfont-new-2.zip
But I believe it could be easier for Dave Gilbert to just modify the font, as Gurok suggested above. With FontForge, for example, it should be a minute of work (simply change one global font parameter).
Also, the latest version of the font library I put into use is somehow less forgiving to mistakes in the font. For instance, the LucasFan font, used by all the Maniac Mansion Mania games is not drawn as nicely anymore. I found there are some tricks that could possibly help in sake of backwards compatibility, but they require more work.
I wanted to say, that I am going to follow old Snarky's (I think it was him) advice to just add "vertical offset" property to the fonts.
Upgrading library, as I planned months ago, may require additional work, related to both implementing compatibility modes and dealing with automatic building we have now; and I am sparing much much less time to AGS now.
In any way, this "vertical offset" may come useful event if the library gets upgraded, for precise tuning of imperfectly designed fonts and backwards compatibility.
Seems like the best solution. Thanks CW!