al_draw_multiline_text() return value
Kev Callahan

I don't think that has been asked before as it didn't show up in my search..

Is there any mileage in al_draw_multiline_text() returning the number of lines it's created/drawn?
It returns a void at the moment which seems wasteful.

I understand I could call al_do_multiline_text() and setup a callback to count them, but this feels I'm doing the same thing twice (I see everything appears to use al_do_multiline_ustr( ) anyway).



That sounds like a good idea, unfortunately we can't change the function's signature due to ABI backwards compatibility.

Chris Katko

I alway get ABI and API confused. So you're saying, adding a return value would break the BINARY compatibility right so things won't link anymore, right? Because it seems like functionally, turning a void into an int (that people will ignore by default) seems doable.

Also, do we have any plans to allow for breaks ABI in A5? Because if so, I'd definitely put this one on the TODO list when that happens. It seems like an oversight in its current form, and a super simple fix.

For a practical matter for Kev, you could "fork" the function and just call it al_draw_multiline_text2() or al_draw_multiline_text_ex() in your code.

I honestly never realized we had a multi-line text function in A5 (since IIRC A4 never had it) and I always just write my own as it's pretty simple to do a function that works in 90% of cases. (e.g. No auto-wrapping.)


adding a return value would break the BINARY compatibility right so things won't link anymore, right?

Yes, that's the claim I am making. It's not that it won't link, though... when you break ABI with C functions, you get random segfaults and/or bizzare behavior that's hard to debug.

That said, maybe changing void to int is not ABI incompatible, but we'd need to investigate if it is.


Also, do we have any plans to allow for breaks ABI in A5?

In version 5.3/5.4.

Kev Callahan

Thanks for not shooting the idea down ;)
Didn't know ABI was important and no idea if it would affect it; as was stated it won't really affect API as no-one would be checking return value anyway..

I may create my own 'forked' version, I'm currently using 'do_multiline..()'for now and may just stick with that, but I like code to be optimised.

I've already added a few functions to my allegro build, such as a kc_al_set_opengl_texture() which I created to link a VPU video texture created by eglCreateImageKHR() with Allegro (couldn't figure out a better method, probably quite a bodge.. and very specific to the platform, but it works).. so that's obviously an option.


Yes, when I made those functions, I didn't consider this. It would be useful, but I agree the ABI of Allegro must remain stable, so perhaps adding a new function that does return the line count could would help?

I'm a bit surprised people still don't know about these function though. Multi line text was a widely demanded feature so I implemented it. But apparently not everyone who wanted the feature was informed of this?

Chris Katko

Not sure if I'm a representative sample. I wasn't involved much in A5 suggestions, I was midway through my degree so I was a ghost here for a few years.

But yeah, I always rolled my own, so I never even thought to look in the docs for one.


Another interesting value would be the max. width actually used by the longest (widest?) line.

Edgar Reynaldo

Duh. Just tack an ex onto it like they did with allegro 4 :
al_draw_multi_line_text_ex(... , DRAW_INFO* d)

Kev Callahan

Or, it's not urgent, just update it in 5.3?
Sounds like very few people knew it existed anyway..!

Thread #617002. Printed from