GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)

[IsmAvatar]

If I'm not passing enough glyph information to the backend, just tell me what you need, and I'll add it. It was a rather rudimentary set of fields, but it seemed sufficient to me. A glyph has a height and a baseline. The y2 would be the difference between the two.

[TheExDeus]

Yeah, but I need the highest offset from the baseline. I will illustrate:

Here is the code:

Code: [Select]

str="This is text. p and q";
draw_set_font(font_0);
draw_text(10,10,str);
draw_circle_color(10,10,2,c_red,c_red,0);
draw_line(10,10+string_height(str),10+string_width(str),10+string_height(str));I added explanation in paint.net. So I need to get the highest y2 value to subtract from the baseline. The red dot is the drawing origin position.

edit: Also on the side note. Which file is used: GAME_GLOBALS.h or key_game_globals.h? Or both? Or none? Because when I include GAME_GLOBALS.h it shows that "string does not name a type" which makes me think that it is not actually included anywhere (and my search didn't return anything either). key_game_globals.h is included in roomsystem.cpp but it even has this besides it:
"//TODO: Remove all instances of this line. It's just sloppy. Figure out the dependencies manually.". So how exactly I add globals? I want to make keyboard_string (or at least very limited version). The basics is just adding this line:

Code: [Select]

if (last_keybdstatus[i] != keybdstatus[i]) keyboard_string+=chr(i);To void input_push() functions "for" cycle inside WINDOWScallback.cpp. You can clearly see lots of problems (like adding every button on the keyboard to a string), but what I need is just basics for a little test so I don't mind about this.

[IsmAvatar]

So go through every glyph in the text and return the largest (height - baseline)?

As for your other question, that's a Josh question, since I don't have a clue about that stuff.

[Josh @ Dreamland]

HaRRi: That's because the offsets I calculate in the texture are relative to the baseline rather than to the bottommost point on any glyph or the topmost. You are simply adding the height of the glyph to the supplied "y" coordinate of draw_text. You should instead be adding the difference between the topmost point of the tallest glyph and the baseline.

I will add a calculation for the aforementioned value, which you will use to offset the supplied "y".

IsmAvatar: No further action is required of you.

[TheExDeus]

HaRRi: That's because the offsets I calculate in the texture are relative to the baseline rather than to the bottommost point on any glyph or the topmost. You are simply adding the height of the glyph to the supplied "y" coordinate of draw_text. You should instead be adding the difference between the topmost point of the tallest glyph and the baseline.

I am fully aware of this. That is why I asked if a new value will be introduced to show the highest y coordinate of the bottom most point. So basically you are going to give me this value via the struct? So I will be able to just do this:

Code: [Select]

yy = y - fnt->baseoffset;Or something similar? I can actually do all of this myself, but I wanted to ask if this is ok way to do it. Anyway, I will wait until the next rev. Is everything working correctly in the latest rev? That's the reason I still use 710. Time to update I guess.

[IsmAvatar]

Windows users: Update at your own risk. After updating, copy ENIGMA.exe from dummystuff to root, delete Compilers/Windows/gcc.ey, and run ENIGMA.exe, which will cause the gcc.ey file to be regenerated with more appropriate settings.

[TheExDeus]

Checking the repository I am sure the fnt->baseoffset wasn't implemented... so I still can't 100% finish the text functions. I did try to add this myself, but the only place I found the font struct actually being populated was in the font_add_sprite function, but then it works only when the font is created from the sprite. So where is the code that does it for the included fonts? Somewhere in the plugin?

[Josh @ Dreamland]

CompilerSource/compiler/components/write_font_info.cpp writes the structures containing the font data. This is where you'd insert the baseline position;

CompilerSource/compiler/reshandlers/refont.h defines that structure; add a member to it.

Most of the glyph iteration is done in CompilerSource/compiler/components/module_write_fonts.cpp; you may need to copy one of the for loops out ahead of time to calculate that member (if so, you don't need to edit the structure in refont.h).

[TheExDeus]

Its funny that all of this was done already. At the beginning I opened module_write_fonts.cpp and added the necessary code so it would write the y2 position (which actually was texture coordinates and I wasn't paying attention). Then I opened fontstruct.h and added the necessary variable to the structure. Then I opened fontinit.cpp and noticed this:

Code: [Select]

        if (fontstructarray[i]->glyphs[gi].y2 > ymax)
          ymax = fontstructarray[i]->glyphs[gi].y2;Which is EXACTLY what I wanted. So I just added this:

Code: [Select]

fontstructarray[i]->yoffset = - ymin + 1;(Its not ymax, because I needed height-ymax, which ymax - ymin -ymax = -ymin) And that's it. So Josh could of added thous 3 lines in total himself. I followed logical steps just to be lough at in the end. Thats not funny. :|

[Josh @ Dreamland]

I made some move toward implementing that for you, but I forget where I left off. *shrug*
Sorry about that.
Case-closed then, yes?

[TheExDeus]

but I forget where I left off

Near the first line probably.

Case-closed then, yes?

Yes, I also committed 801, but SF doesn't show that for some reason. Thou I didn't change font_add_sprite function, forgot about that.

[IsmAvatar]

When populating the glyphs, I never assume that a specific character will always be the lowest, because I could always come across a font that either has a different set of glyphs (think wingdings) or works differently (e.g. the 'g' character is level with the baseline for goofiness, but some other character, like capital letters, take up an extra height). As such, I iterate every character looking for the one with the greatest heights/offsets.

[TheExDeus]

That's good, because my changes don't really change the position or height of a separate glyph. It looks for the biggest y2 and then subtracts that from the whole y position when drawing. When this is done it draws properly.

Also, I just tested and I can't even load wingdings in LGM, it just renders boxes. And that leads to my next question - How UTF support will be added? I am actually quite incompetent in that matter, because UTF standard has more than hundred thousand characters, and then I guess fonts just have the basic chars in them and not all of them, right? I doubt games that has UTF support renders all of thous chars on a texture, but they do use them somehow. For example, in Source Engine games (like CS:S) I have seen chinese symbols in chat while I don't actually have that charset installed. LGM's scripting editor does seem to handle utf chars so no problem there (though I don't know if gm6 format supports them, but the newest gmk does).

Next thing is about draw_set_halign(). I have an idea on how to do this, but that will involve cluttering the draw_text functions. I wouldn't want to make them slower than they need to be. This is the original line:

Code: [Select]

int xx = x, yy = y+fnt->yoffset; and it will have to be changed to this:

Code: [Select]

  if (halign == fa_left){
    xx = x;
  }else if (halign == fa_middle){
    xx = x-string_width(str)/2;
  }else{ //fa_right
    xx = x-string_width(str);
  }I did fa_left the first because its the default and usual alignment. So in default case this will slow the code down by a one if statement. On the other hand things like fa_middle require me to know the width of the string, and string_width() is O(n). And this only for the halign.

[Josh @ Dreamland]

That code doesn't consider newlines. Not having the code as fa_left fucks everything up, efficiency wise. You're best to fork up front.

[polygone]

There should be functions added for draw_get_halign / valign these are missing from gml.