I would like to continue with this discussion:
https://www.allegro.cc/forums/thread/611636/972518#target
I have tried Kris Asick's suggestion but it didn't help. Using OpenGL did not solve the problem. It looks exactly the same. Even the same characters are missing.
I have attached two screenshots. First one is taken before calling al_resize_display() the second one after.
In both cases I try to print this text:
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
Is there any other thing I could try? I run out of ideas...
Do you have some code which would allow others to reproduce the probem?
I haven't been able to reproduce this, with Direct3D, or with OpenGL.
However, I did notice some inconsistencies between the DX and the OGL implementations.
In OpenGL, the screen contents bounce around as you resize the window. Don't think this is really desirable.
In DirectX, the screen is stretched during a window resize until the mouse button is let go of, and only then is al_acknowledge_resize called and the screen contents redrawn.
Here's the code I used. Just draws a couple lines of text at the top left and lets you resize the window.
I can upload some binaries later to show you what they do when I'm not on dialup.
APrince, can you try this code and see if it works for you? See if there are any missing characters when you run it.
Regardless, the safe thing to do whenever the state of your ALLEGRO_DISPLAY object changes, is to clear all contents of video memory yourself prior, then reload everything afterwards.
Did you remember to try this? When your display is resized, remove your font from memory with al_destroy_font(), reload it, and see if the problem persists.
If it does, that would be just plain weird.
I always felt the screen should just be black in GL or D3D on any platform when resizing.
Regardless, the safe thing to do whenever the state of your ALLEGRO_DISPLAY object changes, is to clear all contents of video memory yourself prior, then reload everything afterwards.
Did you remember to try this? When your display is resized, remove your font from memory with al_destroy_font(), reload it, and see if the problem persists.If it does, that would be just plain weird.
Kris, Allegro 5 does this for you if you do not set the ALLEGRO_NO_PRESERVE_TEXTURE flag when you load new fonts. OpenGL does not suffer this problem. Are you really gonna reload everything every time someone resizes the window? Seems silly.
However, your advice about destroying and reloading the font may help as a diagnostic tool to figure out what is wrong with al_acknowledge_resize for him, if anything.
Edit
APrince, did you ever call al_acknowledge_resize()?
Edit2
I'm a dummy. I was testing al_acknowledge_resize, not al_resize_display like the OP said. Regardless, I redid the test code, and al_resize_display does not corrupt my font either.
Also, when a window that has been resized closes, there are all kinds of lines shown on the screen buffer.
Updated test code :
Press b to make the window big, and s to make the window small. These call al_resize_display. Otherwise, the prog remains the same.
Edit3
Forgot to say I am on Vista using MinGW 4.5.0 and the 5.1.4 binaries.
ALLEGRO_NO_PRESERVE_TEXTURE
Normally, every effort is taken to preserve the contents of bitmaps, since Direct3D may forget them.
This comes from the A5 Manual. The words "every effort" suggest to me that on some systems this process may not work properly, so I add this flag to all of my bitmaps and take matters into my own hands.
At least, I would if I was still working in Direct3D. Once I started working with fragment shaders I had to settle with using OpenGL strictly and thus it's not a problem anymore.
However, the fact that going with OpenGL didn't solve APrince's problem is strange and suggests something else may be going on. Allegro's font routines are clearly drawing text properly and the data for the positioning of the missing glyphs is still present in memory, which means it must also still be reading the characters properly.
Somebody recently complained of missing glyphs on Stack Overflow. Using memory bitmaps worked fine.
jmasterx: The problem is not with the screen contents, I need to redraw the window anyway. The problem is that some character are just not drawn anymore even if I redraw it. Then there's just a blank gap just as wide as the letter should be. Bu it is not there!
Elias: I'll try to make some.
Edgar: I'll try it out and let you know.
Kris Asick: I'll try. But it seems strange to me that only some characters would go missing. I am pretty sure that reloading the font will fix the problem but I am interested in the reason as well. I mean it is common thing for the window to get resized and I don't like the idea of loading all the fonts over and over again...
//edit: sorry, I posted the reply to the window loaded from yesterday without refreshing so I hadn't seen all the new posts. I'll try the new code.
Okay. Which versions of MinGW and Allegro are you using?
Well I tried the code. It works fine. No characters are missing.
APrince, did you ever call al_acknowledge_resize()?
No.
I'm on Win7 64 bit. And I don't use minGW but Visual Studio 2010 with windows binaries for Visual studio generated by Michał Cichoń. The version is 5.0.8 but with 5.0.6 it behaved exactly the same way.
And so far I was not able to generate an example for you because it seems to be dependent on many things. For example calling a method that has nothing to do with Allegro at all causes some more characters to disappear but another ones to appear again*. Normally I would consider that a memory corruption but: How would calling some more code make the character visible again? Second: If I do not call the al_resize_display nothing will disappear no matter what I do with the rest of the code. It is really REALLY strange.
*by appear I mean that the ones that were not visible before are now visible and some other that were visible are now blank.
I will try to dig up more...
//edit:
1) If I use the font right before calling al_resize_display. The characters will not disappear. What is even more strange is that only those characters that I use will not disappear. For example in my case the letter 'u' in
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
is missing. Which means only:
"abcdefghijklmnopqrst vwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
...is rendered. If I print
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
before calling resize. 'u' will not disappear after calling resize. If I however print only:
"abcdefghijklmnopqrstvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" ('u' is missing)
then 'u' will be missing after al_resize_display as usual.
2) reloading the font fixes the problem as expected.
Uhm, I guess you could try the binaries for 5.1.4 with your project and see if it does it too. Then we can confirm it is not an allegro problem or else it is one that is persistent.
Allegro 5.1.4 binaries
I just read your edit.
I believe it is due to the fonts not being cached properly. They are cached on demand as you use them, so if you use them all then they will all be in dual memory mode and fully recoverable upon display resize.
The problem comes in where the glyphs were not cached. They can't be restored properly because they may even be uninitialized.
Have you tried a debug build? Run it through the debugger and see if it barks at you for anything.
OK, I'll try 5.1.4...
As for the debug version: I have. If it is the log you are interested in, I have attached it in the old thread referenced by my first post. I don't however remember the state it was in back there so I may need to generate another one. I'll write as soon as I learn something.
//edit: hm, I'm not able to run 5.1.4 it will not pass through al_init(). Also the log file seems not to be generated at all (probably because it crashes too early in init())
This may seem like a dumb question but... what's your system specs?
APrince, can you link against the debug version and get a backtrace? Then 'bt 1 full' in gdb.
Kris Asick: That should not be a problem: Phenom X3, 8 GB DDR3, GTX460.
Edgar: Hm, can you please explain a bit further? From which point in the code do you want the backtrace? I am a bit confused about that. And what do you mean by 'bt 1 full', that misses me entirely...
Thanks
You said init() crashes? Did you mean al_init() crashes too? A backtrace from there. And 'bt 1 full' is just GnuDeBugger shorthand for 'backtrace 1 full' as in tell me everything in the lowest frame on the stack.
So I guess in the MSVC debugger it would be show me the stack when it crashes, and examine the lowest frame with the debugger.
OK, thanks for the explanation. I'll do that in the morning (there's 2 o'clock am local time :-) ).
//edit: Well I have realized I might not have expressed myself quite correctly: By init i meant al_init() but it does not crash, i just returns false meaning the initialization failed. There's no more info about what went wrong and there's no log generated.
//edit2: I will continue yesterday, I'm kinda busy till then.
//edit3: I will try another computer, see if there's any difference and let you know.
//edit4: OK so I made some progress. I was somehow able to run 5.1.4 (well it was probably enough just to rebuild the solution which hadn't cross my mind before). The result is... It is exactly the same as with 5.0.6 and 5.0.8.
I also tried it on another computer. It is the same, only different characters are missing...
This has to be some caching problem as you said... I just can't explain that in any other way.
Well, try what ML suggested a while ago, try loading the font as memory bitmaps. al_set_new_bitmap_flags(ALLEGRO_MEMORY_BITMAP). See if the font still dies when you resize.
Otherwise, the thing that bothers me is that my example code works for you but your own program does not. So I can't rule out it isn't your program yet.
IDK. Can you upload your project source files in a zip/7z file? I can look at them briefly and see if I notice anything obvious.
Well I tried setting the flag. When I do that no text is rendered at all. Above all, it messes the rest of the window content in a completely strange way. Can't even describe that (no images are rendered and primitives are... well, messed up). This happens with 5.1.4 as well as with 5.0.8. I attached the log from 5.0.8.
To be able to show you the code I will have to change it a bit, because the window resize is dependent on a certain serial port device connection. Will have to change that dependency so that the resize is called anyway. I will upload it as soon as I 'm done with that.
Thanks
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.29753] Font fonts/titilliumtext25l001.ttf loaded with pixel size 0 x 12.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.29755] ascent=11.0, descent=-3.0, height=15.0
dtor D dtor.c:184 _al_register_destructor [ 0.29757] added dtor for object 02F6F970, func 0F061B63
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.30116] Font fonts/titilliumtext25l001.ttf loaded with pixel size 0 x 13.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.30118] ascent=12.0, descent=-3.0, height=16.0
dtor D dtor.c:184 _al_register_destructor [ 0.30119] added dtor for object 02F818B8, func 0F061B63
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.30834] Font fonts/titilliumtext25l002.ttf loaded with pixel size 0 x 13.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.30836] ascent=12.0, descent=-3.0, height=16.0
dtor D dtor.c:184 _al_register_destructor [ 0.30837] added dtor for object 02FF3CC0, func 0F061B63
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.36182] Font fonts/tahoma.ttf loaded with pixel size 0 x 12.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.36184] ascent=12.0, descent=-2.0, height=14.0
dtor D dtor.c:184 _al_register_destructor [ 0.36186] added dtor for object 03026F90, func 0F061B63
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.40540] Font fonts/tahoma.ttf loaded with pixel size 0 x 13.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.40542] ascent=13.0, descent=-3.0, height=16.0
dtor D dtor.c:184 _al_register_destructor [ 0.40544] added dtor for object 030094B0, func 0F061B63
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.45055] Font fonts/tahoma.ttf loaded with pixel size 0 x 15.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.45057] ascent=15.0, descent=-3.0, height=18.0
dtor D dtor.c:184 _al_register_destructor [ 0.45059] added dtor for object 0305AA88, func 0F061B63
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.45431] Font fonts/titilliumtext25l002.ttf loaded with pixel size 0 x 10.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.45432] ascent=9.0, descent=-2.0, height=12.0
dtor D dtor.c:184 _al_register_destructor [ 0.45434] added dtor for object 0306EBC8, func 0F061B63
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.45796] Font fonts/titilliumtext25l002.ttf loaded with pixel size 0 x 9.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.45798] ascent=8.0, descent=-2.0, height=11.0
dtor D dtor.c:184 _al_register_destructor [ 0.45799] added dtor for object 0309B5E8, func 0F061B63
font D ttf.c:786 al_load_ttf_font_stretch_f [ 0.46155] Font fonts/titilliumtext25l002.ttf loaded with pixel size 0 x 20.
font D ttf.c:788 al_load_ttf_font_stretch_f [ 0.46156] ascent=19.0, descent=-5.0, height=24.0
dtor D dtor.c:184 _al_register_destructor [ 0.46158] added dtor for object 030AB230, func 0F061B63
The "loaded with pixel size 0 x #" entries seem suspicious. But you aren't loading your fonts with a width of zero are you? That would be silly.
I don't see what is wrong though, as alloc_glyph_region calls seem right later in the log....
The "loaded with pixel size 0 x #" entries seem suspicious. But you aren't loading your fonts with a width of zero are you? That would be silly.
But how would I do that? The prototype of the function looks like this:
ALLEGRO_TTF_FUNC(ALLEGRO_FONT *, al_load_ttf_font, (char const *filename, int size, int flags));
there's just the size parameter that allows me to specify the size. There's no width or height.
I will try to exchange the font for another one and see if the problem persists. I know, it seems silly but I guess we have tried all the probable possibilities. I will also try 5.0.1 or something like that, before the version of the library that generates the font (forgot the name) was switched. Maybe I should mention that I use the ALLEGRO_TTF_NO_AUTOHINT flag when creating the font. That has probably nothing to do with the problem since it only affects the size of the resulting glyphs but maybe it also relates to the "zero width" mentioned by you.
About the source code, I'm kinda busy today but will try to get to it. If not, I will do it tomorrow.
Thanks a lot
//edit:
OK, I've tried 5.0.1. That means I had to disable the above mentioned ALLEGRO_TTF_NO_AUTOHINT flag. But it is the same... Characters still missing. I attach the log from 5.0.1. There may be an interesting line:
font D ttf.c:591 al_load_ttf_font_f [ 0.08597] fonts/titilliumtext25l002.ttf: Preparing cache for 400 glyphs.
...but don't really know.
//edit2:
I am now leaving for 4 days and unfortunately couldn't make it to create a version that you could run and that would demonstrate the problem. I will post it Thursday.
Thanks for everything.
I have an idea. It may be that your font is not associated with the drawing context of the window you are trying to draw to. I played around with this idea a little bit, and for me it resulted in very slow drawing, and missing glyphs during a resize that went away briefly after that. Try the code below and see what I mean. The font was loaded while the first (left) display was current, so it should be associated with that one. That means you may have problems with the right display showing the text properly.
Someone else has to explain about how video bitmaps are attached to a display.
The reason I thought this might be your problem is that you mentioned you have a second window. Any video bitmaps that were loaded on the first window will be attached to that one, so you have to load any resources you need for the second window as well.
Haven't had a chance to look at your code, 21 MB would take two hours to download here at home, so I haven't done it yet. If you upload your source code separately I can take a look at that now, but I won't be able to download the resources until later today maybe I don't know.
When did I say I use 2 displays? Well I don't. There's only one display.
Anyway it is really hard to explain the behavior of the code you posted. First of all it often does not get redrawn when being resized. When it does not I can minimize the window and show it again. The the it is redrawn when being resized but in a really strange way. Just as if the backbuffers would get flipped before drawing all of the text. And moreover just as if the text would be drawn from the back to the front. But in the end (When I let go of the mouse button) it is drawn properly. No characters missing.
Can the problem relate to the number of the fonts I have currently loaded? Because I have 9 fonts loaded at the same time (well actually only 2 types, but in different sizes). And only two of them has have the problem with missing characters.
//edit: OK, I made some progress simplifying the code and... I found this once more related to the calling of the al_get_text_width function. Here is the quotation from the previous thread:
I don't have a clue of what's this about because it seems so random. I also noticed that it seems to be related with the text aligned to the center and thus to calling al_get_text_width. Well I checked the result of this function and it always seems to return the correct width, the only problem is that the consequential text drawing (like x - text_width/2) will fail to print some letters, although their positions are correct. If I replace all the al_get_text_width calls the constants they return it seems* to work fine.
Well I kinda forgot about this but now I am back at this again. Somewhere deep in my code I use string wrapping for which I need to know the width of the the text in order to slice it into the correctly sized lines. Now here is the significant statement for which I stand: "If I do not call al_get_text_width() with some particular font, NO characters of this font will EVER get missing."
Now do you know how could calling this method "damage" the font? This is strange because a function like this should be essentially read-only. Anyway calling this method is not enough. You also need to resize the window. This leads me to the opinion, that it somehow caches out some info which may than get lost when resizing the window.
As soon as I'm done with making a simple example that would demonstrate this problem, I will post it. But I will probably not make it till monday (I'm doing dance show at a ball and I'm kinda short on time :-D).
//edit2: Finally! So, to make the example for you. Just take the first code you posted - the one from the beginning of the thread - and place these lines before the do-while loop:
al_get_text_width(font1, "abcdefghijklmnopqrstuvwxyz"); al_resize_display(display, SCRW, SCRH + 20);
For me it results in lowercase 'y' and 'z' missing. If I replace those letters for uppercase, then 'UVWXYZ' will be missing, but no lowercase letters. The connection is obvious. Only those letter used with al_get_text_width may get missing, as I stated before.
That sounds really odd. I'll take a look when I get home tonight sometime.
Thanks, I'll wait.
Have you tried your code on other computers yet, APrince?
Also, just a thought: What happens if you draw your text, resize the display, draw text again to see which characters are missing, then resize the display AGAIN, and draw the text again to see if the exact same or different characters are missing?
Also, you say you're using VC2010. So do I, and a problem I ran into when I released the previous public alpha of my game was that the energy bar was going extremely wonky. Turned out there was absolutely nothing wrong with the code, it just needed to be rebuilt entirely. IE: Using VC2010's "Rebuild All" function as opposed to just clicking "Build".
There may also be optimization problems. Have you tried compiling with zero code optimizations from your project properties?
Have you tried your code on other computers yet, APrince?
I also tried it on another computer. It is the same, only different characters are missing...
Also, just a thought: What happens if you draw your text, resize the display, draw text again to see which characters are missing, then resize the display AGAIN, and draw the text again to see if the exact same or different characters are missing?
I will try that but I guess that the same characters will be missing. The point is that if I change anything (doesn't have to be anything related to text drawing) and build the project again, different characters are usually missing. Not always though it depends on how "big" the change is. Well i explain this to myself by different cache usage of the two builds. Anyway the key is the al_get_text_width() method. I'm sure. When it is not called, no characters will ever get missing.
Also, you say you're using VC2010. So do I, and a problem I ran into when I released the previous public alpha of my game was that the energy bar was going extremely wonky. Turned out there was absolutely nothing wrong with the code, it just needed to be rebuilt entirely. IE: Using VC2010's "Rebuild All" function as opposed to just clicking "Build".
I know, I run into this problem from time to time as well. But this is not the case as could be deduced from the fact, that I also had to create the example that I posted and that is another solution and thus a different build.
There may also be optimization problems. Have you tried compiling with zero code optimizations from your project properties?
In the debug build, optimizations are disabled by default in VS and I haven't changed it. Well I have also checked that now for you, and yes, they are disabled.
Can you try to debug, since you can reproduce it? I would first change the last parameter of the cache_glyph calls from true to false, in ttf_text_length and ttf_get_text_dimensions. See if it changes anything.
Mostly off topic but just in case some bigger changes will be needed to the ttf addon and someone is going to hack it up - please fix the issue where no glyph can be bigger than 256x256 pixels and also make it waste less video memory - currently it uses a lot more than necessary
Hey yeah, that's a good question. APrince, do you still have this character-missing problem with bitmapped fonts or only with Truetype fonts?
Can you try to debug, since you can reproduce it? I would first change the last parameter of the cache_glyph calls from true to false, in ttf_text_length and ttf_get_text_dimensions. See if it changes anything.
And am I able to debug? I would have to build the allegro, or wouldn't I? I use windows binaries downloaded from the release thread. Either way, you would have to elaborate more on what do you want me to do cause I don't know anything about glyph cache or whatever...
APrince, do you still have this character-missing problem with bitmapped fonts or only with Truetype fonts?
I have never used bitmapped fonts. I may try it but no sooner than tomorrow since I'm not at home and cannot access my computer...
Debugging means digging into the code and finding out the actual cause of the issue, if not actually fixing it. It's hard for people who can't reproduce a bug to fix it just by reading the code and guessing. Obviously you will have to be able to modify and build Allegro.
The code is in ttf.c. You don't always need a complete understanding of the code. It's how everyone gets started.
Yes, I actually didn't need the explanation of what the debugging is but what to debug. The point is that I don't think I can debug the dll supplied in Windows binaries release, but You answered that anyway. The problem is that to build allegro there are lot of libraries required. I already tried that but I just couldn't make all the libraries to work together. But I will try again...
Anyway has anyone tried to reproduce the problem? I think it should be possible since I can do it on 2 computers... Just take this code:
The problem is there for all the Allegro version I have tried (5.0.1, 5.0.6, 5.0.8, 5.1.4)
//edit: I have been trying to test it with allegro bitmap font as proposed by Kris Asick, but I just cannot find out how it works. There's no line in the documentation or tutorials (or at least in those I was able to come). What format should the bitmap have?
https://d1cxvcw9gjxu2x.cloudfront.net/attachments/607221
Here's a bitmapped font I made for a game I'm likely never going to make, properly formatted for A5 usage. (IE: Has a completely transparent background.) It only covers glyphs 32 through 127. If you want to make your own, just use this one as an example and follow this approach:
Arrange all glyphs on a grid.
The pixel at coordinates 0,0 represents what pixels to ignore.
All other pixels will represent glyphs, formed in boxes, including white-space between each glyph.
Information on how to make bitmapped fonts for Allegro can also be found in the A4 documentation. (But yeah, the info really should be added to A5 eventually.)
The problem is that to build allegro there are lot of libraries required. I already tried that but I just couldn't make all the libraries to work together. But I will try again...
I think someone has all the dependencies already build which should make it a whole lot easier.
Anyway has anyone tried to reproduce the problem? I think it should be possible since I can do it on 2 computers... Just take this code:
Thanks, I can finally reproduce it with Direct3D.
Trent, how does this look?
Yeah, R-Z are missing for me when I run his code. Using 5.1.4 binaries, MinGW 4.5, Vista.
Good, I've been getting paranoid about this. But isn't it strange that this bug lasts from the first Allegro 5 and nobody has noticed since then? It's like nobody ever used those two functions together... Which is improbable, I'd say.
It's probably just one of those problems that only happens under certain circumstances, and you were lucky enough to have a machine that fulfilled all the prerequisites.
Can someone who can reproduce the problem please try Peter's patch?
Sorry, but I can't get al_init() to even run with the latest git for A5.1. It just keeps failing, and even though I linked to debugging versions and defined DEBUG, there is no allegro.log file. I don't get it, A5.1.4 works fine for me, there can't be that much different? Maybe it is a binary incompatibility, but I made sure to copy the new dll's into the folder where the exe is. So I don't know what's wrong. I would test it if I could.
Edgar, you've likely got old headers kicking around somewhere so the version check fails.
Okay, that was it Trent, searching the wrong dir for includes and the system include directory has old a5 headers. Oopsie. Anyway, the patch seems to have fixed the problem. I don't get any missing characters now like I did before with 5.1.4.
There you go Peter. Should be ok to apply.
Ok, will do later. Thanks.
Oh and thanks Edgar.
Thanks. I suppose the patch will be applied to a new Allegro release... Right?
And... thanks again.
No problem Trent.
You should test it yourself if you can APrince, just to make sure the problem is gone for you too. You'll have to use cmake and git, but you can do it.
Sorry for the late answer I have been ill for some time now. OK, I will try. If I do not write anything it either means I had no problem with that (unlikely) or I died trying (or possibly left to see, became a sailor and have no desire in programming anything ever after :-D ).
You should definitely join the navy, travel the world, and get some exotic girl pregnant, marry her, and never look back.
Thanks for the support, I knew You would know the right thing to do...